Subject: [netmod] tracking new YANG language issues

From: Kent Watsen <[email-masked]>
Date: Tue, 1 Sep 2015 16:40:25 +0000

[chair hat on, changed subject line]

On 9/1/15, 11:05 AM, "Lou Berger" <[email-masked]> wrote:

>This is exactly the (sub) model reuse issue I was getting at in
>http://www.ietf.org/mail-archive/web/netmod/current/msg13357.html
>
>I think this new capability (i.e., the ability to define complex,
>augmentable and reusable structures that are "included" when defining
>more complex models) would be a good new issue to track.
>
>Lou

Yes, we need to start tracking new YANG language issues like this one.
How/where is the question...

First off, anything that can be implemented using a YANG language
extension should be submitted as a draft and released that way.
Everything else is essentially destined for a 6020bis-bis - agreed?

The big question, which may not even have to be answered immediately, is
if 6020bis-bis is YANG 1.2 or a 2.0.  That is, will we confine ourselves
to backwards compatibility or not.

Personally, since I don't have a sense for how much 2.0 there might be, I
think it would be interesting just to collect the YANG 2.0 ideas now.  It
would be good to see what all else is out there besides the I2RS and
OpenConfig stuff we already know about.

Thoughts? - how should we proceed?  - use GitHub issue tracker?

Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 1 Sep 2015 18:47:11 +0200

> Everything else is essentially destined for a 6020bis-bis - agreed?

I suggest people write I-Ds if they have any far reaching ideas.

At this point in time, I think the WG needs to focus on wrapping up
YANG 1.1. There are several other chartered work items this WG has
signed up for. While it is nice to constantly throw in new ideas, I
strongly advice everybody to focus on finishing existing chartered
work.

/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: Giles Heron <[email-masked]>
Date: Tue, 1 Sep 2015 17:58:59 +0100

> I suggest people write I-Ds if they have any far reaching ideas.

I think GitHub would be better.  The overhead is much lower than writing a draft.

> strongly advice everybody to focus on finishing existing chartered

agreed.

Giles

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 1 Sep 2015 19:30:55 +0200

> I think GitHub would be better.  The overhead is much lower than writing a draft.

IETF processes usually starts with ideas presented in I-Ds. I do not
care much which tools people use to produce I-Ds.

/js

---

From: Giles Heron <[email-masked]>
Date: Tue, 1 Sep 2015 18:45:55 +0100

> care much which tools people use to produce I-Ds.

sure, that is the process in general.  But I’m unconvinced that it’s the right way to proceed with YANG.  E.g. we used a numbered of issues for YANG 1.1.  So why not a numbered list of suggestions for YANG 2.0?

Giles

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 1 Sep 2015 19:58:24 +0200

> sure, that is the process in general.  But I’m unconvinced that it’s the right way to proceed with YANG.  E.g. we used a numbered of issues for YANG 1.1.  So why not a numbered list of suggestions…

The formal answer is that the WG is charted to do YANG 1.1 and not
2.0. The other answer is that (a) collecting issues is easy, (b)
finding agreement on issues is difficult, (c) getting the final text
written and _all the details that pop up worked out_ is very hard
work. Unfortunately, you see many people working on (a), less people
on (b) and finally very few doing (c).

/js

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Tue, 1 Sep 2015 20:52:47 +0000

FWIW, I prefer I-D as well.  This is a very well established and very well understood process.  One advantage is that things are very easy to find (from the documents page).  Regardless which way is chosen, having the IETF datatracker page as an entry point from where to find stuff is IMHO a must.
--- Alex

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Tuesday, September 01, 2015 10:58 AM
To: Giles Heron <[email-masked]>
Cc: Randy Presuhn <[email-masked]>; [email-masked]
Subject: Re: [netmod] tracking new YANG language issues

> sure, that is the process in general.  But I’m unconvinced that it’s the right way to proceed with YANG.  E.g. we used a numbered of issues for YANG 1.1.  So why not a numbered list of suggestions…

The formal answer is that the WG is charted to do YANG 1.1 and not 2.0. The other answer is that (a) collecting issues is easy, (b) finding agreement on issues is difficult, (c) getting the final text written and _all the details that pop up worked out_ is very hard work. Unfortunately, you see many people working on (a), less people on (b) and finally very few doing (c).

/js

---

From: Nadeau Thomas <[email-masked]>
Date: Tue, 1 Sep 2015 16:55:03 -0400

> On Sep 1, 2015:1:58 PM, at 1:58 PM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

	Juergen is technically correct, although conversations with the AD have started about adjusting our charter to facilitate a 2.0 rev of Yang. If you have input/opinions around whether or not we should
embark on this, I suggest sending a note to Benoit.

	I am also collecting issues to publish into a draft, that will document these problems right now. 
If anyone has issues they wish to document and want to contribute, please contact me offline. 

	—Tom

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 2 Sep 2015 01:51:31 +0200

On Tue, Sep 01, 2015 at 04:55:03PM -0400, Nadeau Thomas wrote:
> 
> Juergen is technically correct, although conversations with the AD
> have started about adjusting our charter to facilitate a 2.0 rev of
> Yang. If you have input/opinions around whether or not we should

Sorry, any such debate belongs into the WG first. I do not recall
having seen a WG charter to put up a revision of something on the
charter where the current revision of the same thing is not even
complete. The process you run is really backwards. The process usually
is roughly this:

- some people publish individual I-Ds
- the WG discusses these individual I-Ds
- the WG forms and opinion whether the work should be taken on
- if the work does not fit the current charter, the WG consults
  with the AD concerning a charter revision

Tom, it seems you are mostly running this backwards if you start with
a private charter revision discussion with the respective AD.

/js

---

From: Alia Atlas <[email-masked]>
Date: Mon, 21 Sep 2015 18:43:01 -0400

On Tue, Sep 1, 2015 at 4:52 PM, Alexander Clemm (alex) <[email-masked]>
wrote:

> FWIW, I prefer I-D as well.  This is a very well established and very well
> understood process.  One advantage is that things are very easy to find
> (from the documents page).  Regardless which way is chosen, having the IETF
> datatracker page as an entry point from where to find stuff is IMHO a must.
>

Just on this point, it is possible to add a URI pointer on a WG's charter
page on the datatracker.  Currently an AD needs to do this.
I've done this for wikis for some RTG working groups.

Regards,
Alia

> > On 1 Sep 2015, at 18:30, Juergen Schoenwaelder <
> [email-masked]> wrote:
> > >
> > >> On 1 Sep 2015, at 17:47, Juergen Schoenwaelder <
> [email-masked]> wrote:
> > >>>
> > sure, that is the process in general.  But I’m unconvinced that it’s the
> right way to proceed with YANG.  E.g. we used a numbered of issues for YANG
> 1.1.  So why not a numbered list of suggestions for YANG 2.0?
> >
>
> The formal answer is that the WG is charted to do YANG 1.1 and not 2.0.
> The other answer is that (a) collecting issues is easy, (b) finding
> agreement on issues is difficult, (c) getting the final text written and
> _all the details that pop up worked out_ is very hard work. Unfortunately,
> you see many people working on (a), less people on (b) and finally very few
> doing (c).
>
> /js
>
> --