Subject: [netmod] NETMOD WG YANG 1.1 virtual interim meetings

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 7 Aug 2015 08:32:05 +0200

The NETMOD WG will hold a series of weekly virtual interim meetings in
order to resolve YANG 1.1 review comments. The meetings will take
place on Mondays between 17:00-18:00 CEST. The dates for the virtual
meetings are:

2015-08-24
2015-08-31
2015-09-07
2015-09-14
2015-09-21
2015-09-28
2015-10-05
2015-10-12

We will use the meeting slots as needed (i.e., we may skip slots if
there is nothing to resolve anymore).

Additional information will be announced on the NETMOD mailing list:
http://www.ietf.org/mail-archive/web/netmod/current/maillist.html

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Benoit Claise <[email-masked]>
Date: Fri, 7 Aug 2015 17:41:33 +0200

Dear all,

During the YANG Model Coordination Group webex call today, we discussed 
this oper status and structure open issues. We're ready to help 
facilitate the discussion between the different proposals
We could compare the pros/cons of the different solutions from our point 
of view.

To allow us some preparation time, alternate proposals should be posted 
a week before the NETMOD interim meeting, i.e. Sept 3rd.

The YANG Model Coordination Group 
<http://www.ietf.org/iesg/directorate/yang-model-coordination-group.html>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 7 Aug 2015 17:57:12 +0200

Lets please not mix YANG 1.1 work with other discussions at this point
in time.

/js

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Benoit Claise <[email-masked]>
Date: Fri, 7 Aug 2015 18:11:55 +0200

I obviously replied to the wrong email. My bad.
Let me start again

Regards, Benoit

---

From: Andy Bierman <[email-masked]>
Date: Fri, 7 Aug 2015 09:22:41 -0700

> Lets please not mix YANG 1.1 work with other discussions at this point
I would really like the WG and IESG to decide how YANG is going to be
updated to support ephemeral state and operational state.

It seems there are many documents waiting on YANG 1.1, yet
only 1 or 2 actually use anything from YANG 1.1.

If YANG 1.0 is not being deprecated then I do not see
any reason to link documents to YANG 1.1 unless they
actually use it.

Is the plan to start work on YANG 1.2 before YANG 1.1 is even published?
If so, then say so.  Let's not pretend YANG is stable
or that all new improvements after YANG 1.1 are going to be
done with extension hacks.

If the IESG and the WG had a development plan for this work,
it might help vendors decide when and what to support.

/js

Andy

> > <http://www.ietf.org/iesg/directorate/yang-model-coordination-group.html
> >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 9 Aug 2015 09:50:21 +0200

> it might help vendors decide when and what to support.

I can't speak for the IESG, I can't speak for the WG - the WG has to
speak first.

My personal goal is to complete YANG 1.1 with the feature set that we
all worked on hard during that last year. I believe in the value of
finishing something. The alternative is to keep YANG 1.1 a moving
target for at least another year to come (and likely even longer, who
knows which wishes comes next and how long it takes to settle all the
semantic issues with ephemeral state).

Since the solution direction for ephemeral state is not even set yet
(and ephemeral state might not even be a feature that every
NETCONF/RESTCONF implementation may choose to support), I would rather
work with YANG extensions as long as possible (and if not possible,
consider alternatives such as YANG 1.2 once we 'understand the
edits'). At this stage, my personal preference is to finish YANG 1.1
with the feature set that we have now.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 10 Aug 2015 09:33:47 +0200

> any reason to link documents to YANG 1.1 unless they

… or unless they use something more significant than "anydata".

Specifically, witholding the RESTCONF suite is IMO counterproductive.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C