Subject: [netmod] YANG next

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 23 Jul 2019 12:03:17 -0400

Hi,

this morning I attended the side meeting "Next Step of IETF YANG". I was
somewhat misled into thinking that it would be about future evolution of YANG
the language, which was not the case at all. However, my personal conclusion
from the meeting is that it would be a total disaster to throw in a new version
of YANG within the next few years or so.

The operators and equipment vendors are busy putting together YANG modules and
tools, filling the gaps, coping with NMDA, schema mount, IETF versus OpenConfig
etc. A new YANG version (and modules written in it) would IMO be extremely
counter-productive at this rather turbulent stage.

So, if we want to continue the yang-next discussion, I think we first have to
figure out how to evolve YANG without making waves in the current YANG pond and
let the operators and vendors do their work, without which YANG can never
succeed.

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Balázs Lengyel <[email-masked]>
Date: Tue, 23 Jul 2019 16:22:30 +0000

Hello,
I share your concerns. However I see some ways of mitigating the problem:
1) Maybe the extension based solution is better than many people would
believe. If we put new features (like status-information,
import-revision-or-derived, preliminary-status etc.) into extensions e.g.
Yang1-2:status-information older systems can just ignore them while never
systems would still be able to use them. This might not work for all new
functionality, but would definitely work for some.
2) Some yang-next ideas are really clarifications of yang 1.1 (e.g. Clarify
YANG "status" keyword usage (e.g., hierarchical)) so they will not disturb
current users.
Regards Balazs

-----Original Message-----
From: netmod <[email-masked]> On Behalf Of Ladislav Lhotka
Sent: 2019. július 23., kedd 12:03
To: NETMOD WG <[email-masked]>
Subject: [netmod] YANG next

Hi,

this morning I attended the side meeting "Next Step of IETF YANG". I was
somewhat misled into thinking that it would be about future evolution of
YANG the language, which was not the case at all. However, my personal
conclusion from the meeting is that it would be a total disaster to throw in
a new version of YANG within the next few years or so.

The operators and equipment vendors are busy putting together YANG modules
and tools, filling the gaps, coping with NMDA, schema mount, IETF versus
OpenConfig etc. A new YANG version (and modules written in it) would IMO be
extremely counter-productive at this rather turbulent stage.

So, if we want to continue the yang-next discussion, I think we first have
to figure out how to evolve YANG without making waves in the current YANG
pond and let the operators and vendors do their work, without which YANG can
never succeed.

Lada

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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 23 Jul 2019 09:22:37 -0700

On Tue, Jul 23, 2019 at 9:03 AM Ladislav Lhotka <[email-masked]> wrote:

> YANG

I hope a summary of the meeting is posted to the WG mailing list.

> and
> to
IMO a new version of YANG would not be disruptive (if done right).
The issue is whether it is cleaner in the long-run to introduce NBC changes
properly
with a new version number, or not so properly, through YANG extensions.

E.g -- adding a leaf to the datastore that says "I don't follow the rules
in 7950"
is still breaking the YANG 1.1 contract.  Using extensions instead of real
statements
is problematic because they are optional to implement (as you point out all
the time).

Seems like the WG is going the YANG extension route, which has its own set
of problems
compared to a new YANG language version.

Lada

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 23 Jul 2019 13:38:30 -0400

> functionality, but would definitely work for some.

This could work only for extensions that do not affect YANG semantics. For
example, if a server actively uses schema mount, then a client that ignores it
is next to useless.

For critical extensions that affect YANG semantics, it would IMO be necessary to
develop modules supporting them in separate branches, along with their 1.1-only
versions.

> YANG "status" keyword usage (e.g., hierarchical)) so they will not disturb

Of course, clarifications and bug fixes are OK.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 23 Jul 2019 14:00:29 -0400

> I hope a summary of the meeting is posted to the WG mailing list.

I think so, minutes were taken.

> with a new version number, or not so properly, through YANG extensions.

I don't see much difference provided that the extensions will be properly
signalled. But we have to take into account that some tools that people use may
not be updated for quite some time, and if they cannot properly work with
modules written for the new version (or extensions), then things will break.

This problem is actually not limited to YANG itself - people are reporting
problems with the transition to NMDA. 

> 
> E.g -- adding a leaf to the datastore that says "I don't follow the rules in
> 7950"

Yes, hence critical extensions. However, the problem is still the same - these
changes require updated tools, and not all tools will be updated immediately. I
think that we should make sure that (at least in the IETF) all modules will be
compatible with tools supporting YANG 1.1, say for the next 5 years.

Lada

> 
> Seems like the WG is going the YANG extension route, which has its own set of
> problems

---

From: Lou Berger <[email-masked]>
Date: Tue, 23 Jul 2019 13:49:29 -0400

On 7/23/2019 12:03 PM, Ladislav Lhotka wrote:
> somewhat misled ...

This IETF's "side-meeting" approach to non-WG meetings is quite 
confusing.  This meeting was *not* a WG nor was it part of any NetMod WG 
coordinated activity.

Of course, any discussion on yang or other in-charter topics is always 
welcome on the list.

Lou

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 23 Jul 2019 19:14:25 +0100

> I think so, minutes were taken.

I scribbled.
So did Dan King.
We sent our scribbles to Geng Liang and Qin Wu. 
They will process.

It was a side meeting. 
As Lou says, it was not part of any existing WG. Nor was it a BoF.

How and where and if the minutes are published is not a question for me to
answer.

Adrian

PS I don't think this was a debate about creating a new version of the YANG
language, and I don't think extensions or modifications to the YANG language
were high on the list of "fixes" to the questions raised in the meeting.
That doesn't mean that debate shouldn't/cannot happen, just that it is not
(highly) relevant to the discussion at hand.

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 23 Jul 2019 14:21:20 -0400

> We sent our scribbles to Geng Liang and Qin Wu. 

Thanks for that.

> were high on the list of "fixes" to the questions raised in the meeting.

Right, this is what I said in the beginning of my message.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 23 Jul 2019 20:23:04 +0200

> problems with the transition to NMDA. 

The YANG update from 1 to 1.1 mostly affected compiler writers - and
to a much lesser extend module authors and module implementors. NMDA,
affects client and server implementors much more directly, additional
instrumentation on the server side needs to be written, application
logic on the client side needs to be adjusted. NMDA is an evolution of
architectural principles and this already indicates that there is a
certain investment to make.

If we discuss YANG next, we should compare it to the YANG 1 to 1.1
transition and not to the NMDA transition. When we started YANG 1.1
work, there were people who said that nobody would implement it. But
then implementations were adopted relatively fast when we finalized
YANG 1.1.

While a collection of patches (updates) of YANG 1.1 may sound simpler,
I am not sure this is really true. We will loose a common baseline and
instead get complexity since we will get systems that all support
different sets of patches (updates) of YANG 1.1. I believe we are all
much better off if we have a common baseline language and tools that
support the common baseline language. Again, if done right, YANG next
will mostly affect compiler writers and tool makers and not so much
module authors and implementors.

/js

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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 23 Jul 2019 11:35:31 -0700

On Tue, Jul 23, 2019 at 11:00 AM Ladislav Lhotka <[email-masked]> wrote:

> > > figure out how to evolve YANG without making waves in the current YANG
> pond
> > > and
So you want to work on YANG 1.2, but just the parts you want to change? ;-)
There is no such thing as a critical extension in YANG 1.1.
IMO it would be a bad idea to develop standard modules that relied on tool
support of
any extension. A tool is allowed to skip any extension when parsing a
module.
This cannot be changed in YANG 1.1.

> compatible with tools supporting YANG 1.1, say for the next 5 years.
I am OK with the current WG priorities such as versioning.
Those YANG extensions simply clarify YANG 1.1 so no rules are broken
and no YANG 1.1 functionality is removed if a tool ignores the extensions.
Also OK with not working on YANG 1.2 or critical extensions.
There are no must-have features at this time.

Lada
Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 23 Jul 2019 17:43:41 -0400

> So you want to work on YANG 1.2, but just the parts you want to change? ;-)

I am actually fine with not doing any changes to YANG 1.1 at all, except perhaps
bug fixes. This doesn't necessarily mean closing the NETMOD WG, it would IMO be
immensely useful to rewrite the language specification and remove NETCONF- and
XML-specific part.

> There is no such thing as a critical extension in YANG 1.1.

One alternative to doing nothing is to introduce critical extensions but
temporarily forbid their use in IETF modules (so that existing tools continue to
work). This would allow for developing and testing new YANG features without
causing troubles to current YANG users. Specific areas and communities may
decide to treat some crictical extensions as required and use tools that support
them.

> any extension. A tool is allowed to skip any extension when parsing a module.
> > in

Yes, work on versioning and packages should continue.

> There are no must-have features at this time.

I agree.

Lada

> > of

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 23 Jul 2019 21:50:54 +0000

Hi Lada,

I still think that it makes sense to do YANG Next, on the assumption that it will take a couple of years to work out, maybe longer if the work doesn't properly get started until the YANG versioning work has progressed further.

When I look at the YANG Next issue list, I think that there are quite a lot of things on that list (some of which are quite small) that would be good to do, and will help modelling efforts.

Thanks,
Rob

-----Original Message-----
From: netmod <[email-masked]> On Behalf Of Ladislav Lhotka
Sent: 23 July 2019 12:03
To: NETMOD WG <[email-masked]>
Subject: [netmod] YANG next

Hi,

this morning I attended the side meeting "Next Step of IETF YANG". I was somewhat misled into thinking that it would be about future evolution of YANG the language, which was not the case at all. However, my personal conclusion from the meeting is that it would be a total disaster to throw in a new version of YANG within the next few years or so.

The operators and equipment vendors are busy putting together YANG modules and tools, filling the gaps, coping with NMDA, schema mount, IETF versus OpenConfig etc. A new YANG version (and modules written in it) would IMO be extremely counter-productive at this rather turbulent stage.

So, if we want to continue the yang-next discussion, I think we first have to figure out how to evolve YANG without making waves in the current YANG pond and let the operators and vendors do their work, without which YANG can never succeed.

Lada

---

From: Balázs Lengyel <[email-masked]>
Date: Tue, 23 Jul 2019 21:55:21 +0000

+1   Balazs

-----Original Message-----
From: netmod <[email-masked]> On Behalf Of Rob Wilton (rwilton)
Sent: 2019. július 23., kedd 17:51
To: Ladislav Lhotka <[email-masked]>; NETMOD WG <[email-masked]>
Subject: Re: [netmod] YANG next

Hi Lada,

I still think that it makes sense to do YANG Next, on the assumption that it
will take a couple of years to work out, maybe longer if the work doesn't
properly get started until the YANG versioning work has progressed further.

When I look at the YANG Next issue list, I think that there are quite a lot
of things on that list (some of which are quite small) that would be good to
do, and will help modelling efforts.

Thanks,
Rob

-----Original Message-----
From: netmod <[email-masked]> On Behalf Of Ladislav Lhotka
Sent: 23 July 2019 12:03
To: NETMOD WG <[email-masked]>
Subject: [netmod] YANG next

Hi,

Lada

---

From: Qin Wu <[email-masked]>
Date: Wed, 24 Jul 2019 02:40:35 +0000

Thanks Adrian for clarification. The goal of YANG side meeting is not to discuss YANG-Next but fill the gap with operator community.
Thanks Dan and Adrian to take minutes. I have uploaded to IETF YANG Side meeting wiki page. 
To folks who participant in the meeting, thanks for your participation and input. If there is any correction needed, please
let us know.
Room: Notre Dame - Tuesday ¶
Occupancy: up to 50 attendees 
Configuration: classroom 
Location: ​Notre Dame 

Meeting NameArea ContactMeeting Description More information 
08:30 Next Step of IETF YANG OPS Area bill.wu@… Discuss the gap between IETF YANG and Industry needs The presentation slides and minutes: ​https://github.com/sunseawq/IETF-YANG-side-meeting 
The relevant draft is ​https://www.ietf.org/id/draft-wu-model-driven-management-virtualization-05.txt 

Regards!
-Qin
________________________________________
发件人: netmod [[email-masked]] 代表 Adrian Farrel [[email-masked]]
发送时间: 2019年7月24日 2:14
收件人: 'Ladislav Lhotka'; 'Andy Bierman'
抄送: 'NETMOD WG'
主题: Re: [netmod] YANG next

I scribbled.
So did Dan King.

It was a side meeting.

Adrian

---

From: Qin Wu <[email-masked]>
Date: Wed, 24 Jul 2019 11:43:15 +0000

+1
Separate YANG next from YANG next step discussed in yang side meeting, is it the time to call for another workshop in IETF to discuss YANG next and Netconf next.

________________________________
吴钦 Qin
Mobile：+86-13914734360<tel:+86-13914734360>(Mobile Number)
Email：[email-masked]<mailto:[email-masked]>

发件人： Balázs Lengyel<[email-masked]<mailto:[email-masked]>>
收件人： Rob Wilton (rwilton)<[email-masked]<mailto:[email-masked]>>;Ladislav Lhotka<[email-masked]<mailto:[email-masked]>>;NETMOD WG<[email-masked]<mailto:[email-masked]>>
主题： Re: [netmod] YANG next
时间： 2019-07-23 17:56:45

+1   Balazs

-----Original Message-----
From: netmod <[email-masked]> On Behalf Of Rob Wilton (rwilton)
Sent: 2019. július 23., kedd 17:51
To: Ladislav Lhotka <[email-masked]>; NETMOD WG <[email-masked]>
Subject: Re: [netmod] YANG next

Hi Lada,

Thanks,
Rob

-----Original Message-----
From: netmod <[email-masked]> On Behalf Of Ladislav Lhotka
Sent: 23 July 2019 12:03
To: NETMOD WG <[email-masked]>
Subject: [netmod] YANG next

Hi,

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 24 Jul 2019 09:51:46 -0400

> certain investment to make.

But both updates induced some changes in YANG modules that affect users and integrators. Take ietf-ospf module as an example: it is of course a great addition to the YANG module collection, but in order to use it, all tools have to support

- YANG 1.1, e.g. because of the special XPath functions, and

- NMDA, because otherwise state data are missing.

Despite the fact that YANG 1.1 and NMDA are undoubtedly improvements, users may get frustrated if lazy authors (including myself) don't update their tools in a timely manner.

> transition and not to the NMDA transition. When we started YANG 1.1

Both types of changes may have similar effects on YANG users. 

> then implementations were adopted relatively fast when we finalized

When we started YANG 1.1, there were only a few YANG modules around with little practical use, so nobody really cared. The situation is now very different.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Wed, 24 Jul 2019 07:10:23 -0700

On Wed, Jul 24, 2019 at 6:52 AM Ladislav Lhotka <[email-masked]> wrote:

> But both updates induced some changes in YANG modules that affect users
> and integrators. Take ietf-ospf module as an example: it is of course a
> great addition to the YANG module collection, but in order to use it, all
> tools have to support
>
> Despite the fact that YANG 1.1 and NMDA are undoubtedly improvements,
> users may get frustrated if lazy authors (including myself) don't update
> their tools in a timely manner.
>
> >
> When we started YANG 1.1, there were only a few YANG modules around with
> little practical use, so nobody really cared. The situation is now very
> different.
>
>
Not that different.
The IETF does not value stability that much.
Maybe customer expectations are different, but some of us have to follow 2
simple rules:

   - Whatever works SHALL continue to work
   - If you changed how it works, you broke it (even if you fixed it)

Some customers even think they should be able to upgrade from any existing
version to any new version,
and these rules still hold. Therefore every change in server behavior must
be "opt-in" by the vendor and
maybe the client as well. Instead of automatically upgrading because of
course you want the spiffy
new features, vendors want the behavior to stay exactly the same (unless
they choose to change it).

There is no real need for YANG 1.2 unless and until NBC changes need to be
made,
and we try to avoid doing that.

Lada

Andy

---

From: Balázs Lengyel <[email-masked]>
Date: Wed, 24 Jul 2019 14:28:34 +0000

We already have some RFCs and drafts that propose extensions that would/could go into YANG 1.2.  I would like to have an “official” agreement/document/wiki that lists what is planned to go into 1.2 whenever it happens. That would help us to have a platform that contains a well defined set of additions beyond YANG 1.1.

Regards Balazs

From: netmod <[email-masked]> On Behalf Of Andy Bierman
Sent: 2019. július 24., szerda 10:10
To: Juergen Schoenwaelder <[email-masked]>; Andy Bierman <[email-masked]>; NETMOD WG <[email-masked]>
Subject: Re: [netmod] YANG next

On Wed, Jul 24, 2019 at 6:52 AM Ladislav Lhotka <[email-masked] <mailto:[email-masked]> > wrote:

Not that different.

Maybe customer expectations are different, but some of us have to follow 2 simple rules:

Some customers even think they should be able to upgrade from any existing version to any new version,

and these rules still hold. Therefore every change in server behavior must be "opt-in" by the vendor and

maybe the client as well. Instead of automatically upgrading because of course you want the spiffy

new features, vendors want the behavior to stay exactly the same (unless they choose to change it).

There is no real need for YANG 1.2 unless and until NBC changes need to be made,

 

Lada

Andy

---

From: Robert Varga <[email-masked]>
Date: Wed, 24 Jul 2019 16:31:05 +0200

> Despite the fact that YANG 1.1 and NMDA are undoubtedly improvements, users may get frustrated if lazy authors (including myself) don't update their tools in a timely manner.

Well, honestly, YANG 1.1, while compatible when viewed from the
perspective of a client processing XML, has a different metamodel than
YANG 1.0.

One example for all: YANG 1.0 metamodel did not require multiple
inheritence anywhere, whereas YANG 1.1 requires it to deal with 'base'
being '0..n' instead of '0..1'.

While it is a relatively simple change on the surface, making it happen
in a software ecosystem (with API stability guarantees, release cycles,
etc.) does frustrate users even in presence of non-lazy authors (who
also get frustrated)...

Regards,
Robert

---

From: Robert Varga <[email-masked]>
Date: Wed, 24 Jul 2019 16:33:51 +0200

> immensely useful to rewrite the language specification and remove NETCONF- and

+1. There are plenty of ambiguities and NETCONF/XML pollution in the
spec. Having the specifications in a DAG would be immensely useful :)

Regards,
Robert

---

From: Kent Watsen <[email-masked]>
Date: Wed, 24 Jul 2019 17:28:51 +0000

> spec. Having the specifications in a DAG would be immensely useful :)

Agreed and I should've mentioned before that Martin said in Prague that he'd already started this effort, seeing it as a necessary pre-step before making other changes.  I'm unsure if the intention is to release this by itself as an RFC 7950 bis but, if looking for a minimal change, that might be it.  The next rung up would be to just add clarifications.  The next rung up from there would be to add only backwards-compatible changes (currently targeted by [1]).  The last rung being to also target NBC changes (there's no consensus to do this).

[1] https://github.com/netmod-wg/yang-next/projects/2 <https://github.com/netmod-wg/yang-next/projects/2>
 
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 24 Jul 2019 19:37:45 +0200

> > - NMDA, because otherwise state data are missing.

I believe the majority of parsers (there were not that many) started
to support YANG 1.1 quite quickly after RFC publication. NMDA support
will take longer and this is not a surprise.

To me, it makes sense to distinguish these two updates. And neithers
says what the update of YANG next will be. Implementation complexity
and transition complexity was one of the things we considered for each
YANG 1.1 improvement.

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 24 Jul 2019 11:32:24 -0700

On Wed, Jul 24, 2019 at 10:28 AM Kent Watsen <[email-masked]> wrote:

> Agreed and I should've mentioned before that Martin said in Prague that
> he'd already started this effort, seeing it as a necessary pre-step before
> making other changes.  I'm unsure if the intention is to release this by
> itself as an RFC 7950 bis but, if looking for a minimal change, that might
> be it.  The next rung up would be to just add clarifications.  The next
> rung up from there would be to add only backwards-compatible changes
> (currently targeted by [1]).  The last rung being to also target NBC
> changes (there's no consensus to do this).
>
>
This WG sure likes to spend time refactoring documents.
Moving lots of text will create bugs and strong coupling, and only help the
standards purists.
It will be a lot of work for the WG and IESG to review such a massive
document split,
and in the end we have no improvement in YANG, just more RFCs to read.

Andy

[1] https://github.com/netmod-wg/yang-next/projects/2

---

From: Robert Varga <[email-masked]>
Date: Wed, 24 Jul 2019 22:37:24 +0200

On 24/07/2019 20:32, Andy Bierman wrote:
> On Wed, Jul 24, 2019 at 10:28 AM Kent Watsen <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 
>     Agreed and I should've mentioned before that Martin said in Prague
>     that he'd already started this effort, seeing it as a necessary
>     pre-step before making other changes.  I'm unsure if the intention
>     is to release this by itself as an RFC 7950 bis but, if looking for
>     a minimal change, that might be it.  The next rung up would be to
>     just add clarifications.  The next rung up from there would be to
>     add only backwards-compatible changes (currently targeted by [1]). 
>     The last rung being to also target NBC changes (there's no consensus
>     to do this).
> 
> 

Sorry, I am not watching very closely so I have not noticed.

I regard the NETCONF coupling in RFC6020/RFC7950 as technical debt,
which when addressed will allow us to have better discussions about
modeling intent vs. XML representation.

> Moving lots of text will create bugs and strong coupling, and only help
> the standards purists.

Not necessarily. I agree with limiting the amount (and type) of text
being moved and modifications done in between.

> and in the end we have no improvement in YANG, just more RFCs to read.

No improvement in to YANG in terms of number of features, yes.

Even if it ends up being more documents, if they are smaller and more
logically structured, they are more approachable.

Reading RFC7950 (216 pages) is far from sufficient for understanding
YANG, as you also need to understand NETCONF, which leads you down the
RFC6241 rabbit hole.

If we can get a more approachable first document, lowering the entry
barrier will be beneficial to people outside the WG(s).

Regards,
Robert

---

From: Balázs Lengyel <[email-masked]>
Date: Wed, 24 Jul 2019 20:38:19 +0000

+1, Balazs

From: netmod <[email-masked]> On Behalf Of Andy Bierman
Sent: 2019. július 24., szerda 14:32
To: Kent Watsen <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] YANG next

On Wed, Jul 24, 2019 at 10:28 AM Kent Watsen <[email-masked] <mailto:[email-masked]> > wrote:

 

Moving lots of text will create bugs and strong coupling, and only help the standards purists.

It will be a lot of work for the WG and IESG to review such a massive document split,

Andy

[1] https://github.com/netmod-wg/yang-next/projects/2 <https://github..com/netmod-wg/yang-next/projects/2> 

Kent

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 24 Jul 2019 21:18:12 -0400

> modeling intent vs. XML representation.

Absolutely. Also note that in RFC 7950 we even don't have a sound definition of
an instance data tree.

> logically structured, they are more approachable.

Right. The base YANG spec should only define the language and rules for
validating instance data.

> barrier will be beneficial to people outside the WG(s).

I again fully agree. The entry barrier is unnecessarily high, which may not be
apparent to vintage members of the NETCONF/NETMOD gang.

Lada

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 25 Jul 2019 12:56:20 +0000

I also think that there is significant value to splitting the NETCONF and XML specification out of RFC 7950 (but keeping XML examples).  I think that this may be beneficial to YANG’s longevity, and I’m sure that it would make it easier to maintain and extend the NETCONF/RESTCONF/YANG document set in future.

Thanks,
Rob

Sent: 24 July 2019 14:32

On Wed, Jul 24, 2019 at 10:28 AM Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:

Andy

[1] https://github.com/netmod-wg/yang-next/projects/2<https://github..com/netmod-wg/yang-next/projects/2>

Kent

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 25 Jul 2019 09:24:08 -0400

On Thu, 2019-07-25 at 12:56 +0000, Rob Wilton (rwilton) wrote:
> I also think that there is significant value to splitting the NETCONF and XML
> specification out of RFC 7950 (but keeping XML examples).  I think that this
> may be beneficial to YANG’s longevity, and I’m sure that it would make it
> easier to maintain and extend the NETCONF/RESTCONF/YANG document set in
> future.

Agreed. And if we do it without changing YANG (except for absolute musts, if
there are any), we can reasonably expect that it can be done relatively quickly.

Lada

> > Agreed and I should've mentioned before that Martin said in Prague that he'd
> > already started this effort, seeing it as a necessary pre-step before making
> > other changes.  I'm unsure if the intention is to release this by itself as
> > an RFC 7950 bis but, if looking for a minimal change, that might be it.  The
> > next rung up would be to just add clarifications.  The next rung up from
> > there would be to add only backwards-compatible changes (currently targeted
> > by [1]).  The last rung being to also target NBC changes (there's no
> > consensus to do this).
> >  
> 
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 25 Jul 2019 07:41:42 -0700

Hi,

Was this a big topic at the side meeting?
The issues blocking NMDA, schema-mount, and other deployment problems
are related to YANG document organization?  I doubt it.

So how would this work?
There will be 2 versions of YANG 1.1?
If old YANG 1.1 is equivalent to new YANG 1.1, can a developer safely
ignore the new RFCs?
If not, then something changed that was not supposed to change.

The old YANG 1.1 RFC will be obsolete and the 2 (or more) new YANG 1.1 RFCs
will replace it?
Then of course all the RFCs that reference RFC 7950 might have to be
updated so the subject matter
is cited from the correct new YANG 1.1 RFC.

IMO this will only serve to confuse the end-users and offer them no real
benefit at all.
As for finishing quickly because the NETMOD WG is so fast and has nothing
better to work on anyway...  sure.

Andy

On Thu, Jul 25, 2019 at 5:56 AM Rob Wilton (rwilton) <[email-masked]>
wrote:

> I also think that there is significant value to splitting the NETCONF and
> XML specification out of RFC 7950 (but keeping XML examples).  I think that
> this may be beneficial to YANG’s longevity, and I’m sure that it would make
> it easier to maintain and extend the NETCONF/RESTCONF/YANG document set in
> future.
>
>
>
> Thanks,
>
> Rob
>
>
>
>
>
> *From:* netmod <[email-masked]> *On Behalf Of *Andy Bierman
> *Sent:* 24 July 2019 14:32
> *To:* Kent Watsen <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [netmod] YANG next
>
>
>
>
>
>
>
> <https://github..com/netmod-wg/yang-next/projects/2>
>
>
>
> Kent
>
>
>
>
>
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 25 Jul 2019 18:59:52 -0400

> Was this a big topic at the side meeting?

I think I wrote quite clearly that YANG itself was no topic there - except
perhaps complaints regarding the IETF/OpenConfig schism.

This fact means to me that the problem is not missing features in YANG but
rather missing YANG modules at all different places, and so making a new version
of YANG doesn't seem like a good idea to me - we should leave existing module
writers in peace and encourage new ones. And a better specification could
certainly help with the latter. 

> are related to YANG document organization?  I doubt it.

Well, people at that meeting probably already made their way through the
existing specs, although I seriously doubt that they understand all the dark
corners. The problems is with newcomers, who may be deterred by the existing
complexity and turn to something else - and alternatives do exist.

> If old YANG 1.1 is equivalent to new YANG 1.1, can a developer safely ignore
> the new RFCs?

The new RFCs may obsolete/update 7950 as necessary. I assume, however, that some
limited changes may be necessary, so it may in fact be YANG 1.2 that's described
in the new RFCs. I don't think it is a big deal.
> Then of course all the RFCs that reference RFC 7950 might have to be updated
> so the subject matter

I have a different opinion.

> better to work on anyway...  sure.

Well, if you compare time spent on YANG 1.1, it was considerably shorter than
the time spent of many modules, and not only in NETMOD - routing, acl, ospf, is-
is, to name a few.

Lada

> > Cc: netmod@ietf..org
> > > making other changes..  I'm unsure if the intention is to release this by