Subject: [Netmod-ver-dt] Propose cancelling today's Netmod Ver DT meeting

From: Robert Wilton <[email-masked]>
Date: Thu, 5 Jul 2018 11:22:44 +0100

I suggest that we cancel today's meeting.  Please can you let me know if 
you feel otherwise.

We have got the requirements draft posted - thanks Joe.

I've not written NETMOD slides yet, so there is nothing there to review 
yet, and quite possibly we can review those over email anyway.

I think that it probably makes sense to wait for feedback on the 
requirements (if any) at IETF, and then we can start discussing solutions.

In terms of potential solutions, we clearly have the clacla draft, which 
although it doesn't currently address all requirements, it is reasonably 
well developed.

It would be useful if DT members could think of any other reasonable 
solutions that would meet some/all of the requirements.  If other 
pragmatic solutions are available then I think that it would be useful 
to spend at least a bit of time considering them, basically to ensure 
that we have done due diligence in the problem space, and are not just 
selecting the clacla solution because it is the most developed solution 
available.

I think that as a design team we may also want to consider whether we 
should be producing a single solution draft, or perhaps splitting the 
problem up to multiple solution drafts. Particularly if the solution 
requires a new version of YANG, which could take a long time, we might 
want to consider whether splitting the work would allow part of the 
problem to solved more quickly, leaving some parts of it to follow in a 
later revision of YANG.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Jul 2018 12:28:04 +0200

On Thu, Jul 05, 2018 at 11:22:44AM +0100, Robert Wilton wrote:
> 
> I think that as a design team we may also want to consider whether we should
> be producing a single solution draft, or perhaps splitting the problem up to
> multiple solution drafts. Particularly if the solution requires a new
> version of YANG, which could take a long time, we might want to consider
> whether splitting the work would allow part of the problem to solved more
> quickly, leaving some parts of it to follow in a later revision of YANG.
>

My take is that we should wrap up the DT and defer the integration of
the solution (there is only one so far) to the next version of
YANG. My preference would be to put all key resources on doing the
next version of YANG in say a year's timeframe instead of creating
more confusion and work dependencides. Fragmenting work does not
really make it faster. (I do not expect that my view is shared by
others.)

/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: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 5 Jul 2018 13:14:21 +0000

By "in say a year's timeframe", do you mean that the work will start in a year? Based on YANG 1.1 experience, how much time do you think the next version of YANG would take?

Regards,
Reshad.

On 2018-07-05, 6:28 AM, "Netmod-ver-dt on behalf of Juergen Schoenwaelder" <[email-masked] on behalf of [email-masked]> wrote:

    
    /js

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

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 5 Jul 2018 15:16:58 +0200

I would opt for a faster solution. Yang 2.0 or even 1.2 might take some 
time.

regards balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Jul 2018 15:31:16 +0200

No, my proposal is to start after the summer break and to be done in a
year, summer 2019. YANG 1.1 did take longer than a year but this time
I think we do not need to run a lenghty selection process to find out
which additions / changes are part of the next version of
YANG. Instead, we can nail things down _before_ the work starts. The
clearer the constraints are on what is in scope, the faster things can
move. Of course, we need to check time availability of key
contributors.

For me, the major things are:

- revised versioning
- generalization of yang-data to describe data structures not tied to datastores
- refactorization (remove NETCONF stuff, factor out XML encoding, alignment with NMDA and newer terminology, ...)
- bug fixes

Ideally, we have a solution proposal / idea for all things that go
into the next version of YANG. (We did not have this for YANG 1.1 and
hence it took time to explore the solutions space for many issues.)

If Martin et al. have time, I do believe this can be done in a year.

Back to versioning: In order to have a complete solution, there is
also likely work to be done on the protocol side (how does a client
select a version context?) and perhaps also on the infrastructure side
(YANG library extensions). Anyway, if there is consensus to change the
YANG update rules and the versioning, I do not see that a design team
needs to do the work.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Jul 2018 15:34:58 +0200

Balazs,

I believe it is an illusion that you can get a faster solution. The
limiting factor is usually the people doing the work. Changing the
update rules and the versioning mechanism is not a simple extension
of YANG. It meanwhile should be clear that it requires changes of
YANG plus extensions of protocols.

/js

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 5 Jul 2018 15:39:25 +0200

Hello Jurgen,
I fear that once we open the doors to YANG 1.2 or  2.0 people will come 
with extra ideas with what should go into it.
regards Balazs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Jul 2018 15:54:48 +0200

This is a matter of setting the scope before the work starts. If you
run a contest where everybody can submit new ideas, it will take two
years. This is what happened with YANG 1.1. (And we had the nasty
relationship to I2RS even back then but this now seems history.)
Instead, let the chairs define a narrow scope and then get WG approval
for it and then you start.

If you call it YANG 2.0, you likely send the wrong signal. The new
version number should be picked at the end, not at the start. I
believe we want YANG 1.2 from a marketing perspective (so much about
semantic version numbers ;-). We simply add / fix stuff for which
there is a certain evidence that the changes are needed. Nothing else.
The tools update from 1.1 to 1.2 should be way less work than the
upgrade from 1 to 1.1 was.

/js

On Thu, Jul 05, 2018 at 03:39:25PM +0200, Balazs Lengyel wrote:
> Hello Jurgen,
> I fear that once we open the doors to YANG 1.2 or  2.0 people will come with
> extra ideas with what should go into it.
> regards Balazs
> 
>

---

From: Robert Wilton <[email-masked]>
Date: Thu, 5 Jul 2018 17:10:43 +0100

Hi Juergen,

On 05/07/2018 14:31, Juergen Schoenwaelder wrote:
> YANG. Instead, we can nail things down _before_ the work starts.
Yes, if we do this as an update to YANG, then I completely agree that 
the spec for the work needs to be tied down before the work starts.

>   The
Yes, this list makes sense to me.

I think that we would need to look through the list of issues at 
https://github.com/netmod-wg/yang-next/issues:
  - List issues would definitely be included (bugfixes).
  - List issues should be discussed, perhaps in the NETMOD Friday 
session (since there is currently 30 mins free).

> hence it took time to explore the solutions space for many issues.)
So, I think that some of the YANG versioning work falls into this category.

> YANG update rules and the versioning, I do not see that a design team
Yes, I think that it likely that updates would likely be needed to both 
protocols and YANG library.

I think that this would mean that quite a lot of docs would need to be 
updated at the same time:
  - YANG, YANGlib, NETCONF, RESTCONF, XML-encoding (new draft), perhaps 
protocol commons draft (issue 13 comment), would with-defaults also fold 
in (it feels like it should), what about schema-mount?

In principle I like the idea of getting the house in order, because it 
will make future updates easier.

The downside is that I think that we would have done really well to get 
this all done in 18 months.

The one thing that we don't want to do is stagnate, this should be 
discussed in Montreal, if we can get a clear sense of direction that 
would also be useful.

Thanks,
Rob

---

From: joel jaeggli <[email-masked]>
Date: Thu, 5 Jul 2018 09:42:01 -0700

On 7/5/18 6:39 AM, Balazs Lengyel wrote:
> Hello Jurgen,
> I fear that once we open the doors to YANG 1.2 or  2.0 people will
> come with extra ideas with what should go into it.
> regards Balazs
Not speaking for the other chairs, but as a former AD I definitly favor
limiting open-endedness to new work that the working group takes on
under it's charter.  Discussion  might be far ranging but by the time we
accept that we're going to start creating milestones for work under our
charter it should be focused.

---

From: Lou Berger <[email-masked]>
Date: Thu, 5 Jul 2018 14:06:21 -0400

> charter it should be focused.

To build on this. We've talked a lot as a group about needing to have a 
away to introduce yang capabilities in a more rapid fashion. To that end 
I'm strongly in favor of taking an approach that follows many other IETF 
groups and protocols  - specifically introduce new capabilities and 
functions via YANG extensions whenever possible and then, on a longer 
period, issue new YANG versions that require support for the extensions 
that have been validated by implementations and the market.  (IEEE 
802.1, e.g., 802.1Q-2018, is another example of standard that follows 
this approach.) I believe this echos comments made by Kent in the past 
as well, but of course he can correct me if we're out of sync.

Of course this is statement of a general position.  I certainly can 
accept that some solutions to some problems will require a major 
revision of the base YANG definition, i.e., just are not suited to being 
defined in an extension.  In the context of this DT, if there are 
solutions that can be done using extension and others that require 
revision of the YANG language I would think that this attribute would be 
part of any alternatives trade-off considers discussion.  From my 
perspective (with any hat), I think the benefits of a solution requiring 
a language revision would have to be quite compelling over any 
extensions-based solution.

If /when this becomes a major consideration for the DT, we should move 
the discussion to the list so that all can participate.

Thanks,
Lou

---

From: Kent Watsen <[email-masked]>
Date: Thu, 5 Jul 2018 22:55:13 +0000

Yes, I share Lou's views that extensions should be used liberally.

That said, for this particular issue, without seeing all the tradeoffs,
I might agree with Juergen that an update to YANG may be needed.  This
was, in fact, my (and Lada's, I think) position when the YANG Doctors
discussed the issue at IETF 100.

As for how "compelling" a versioning option needs to be to trigger
pursuing YANG-next, I feel that we should look at the issue more 
holistically.  Maybe a workaround can be used for this particular 
issue, but there are a number of other issues piling up against
YANG, suggesting that an update may be due.

As some of you may recall, I broached the YANG-next topic at IETF 98.
No one had any appetite to pick it up then.  Admittedly, we were in
the thick of NMDA-madness at the time, but now we're somewhat in the
clear.  In fact, given that the WG is in a lull of sorts, I almost
expect that the WG would set its focus back on charter item #1, not
that the charter items are ordered, but it's listed first for a 
reason  ;)

Kent // co-chair

===== original message =====

Thanks,
Lou

---

From: Benoit Claise <[email-masked]>
Date: Mon, 9 Jul 2018 13:01:35 +0200

Hi,

Recalling the discussion of YANG 1.1 ... everybody wanted minimal 
changes ... as long as their set of requirements was in.
That lead to the evaluation of every requirement, teeth grinding, delay, 
etc.
Avoiding this experience and working with extensions when possible 
should be the preferred way IMO

Regards, Benoit
> .

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 9 Jul 2018 13:03:29 +0200

Sorry, I do not believe you can change the semantics of core
statements like import with extensions. The key is not to run a
requirements collection and sorting process.

/js

On Mon, Jul 09, 2018 at 01:01:35PM +0200, Benoit Claise wrote:
> Hi,
> 
> Recalling the discussion of YANG 1.1 ... everybody wanted minimal changes
> ... as long as their set of requirements was in.
> Avoiding this experience and working with extensions when possible should be
> the preferred way IMO
> 
> Regards, Benoit

---

From: Robert Wilton <[email-masked]>
Date: Tue, 10 Jul 2018 11:59:33 +0100

Hi Juergen,

For the import statement, I'm not sure that I see this as a big issue.

I don't see that the import statement as being fundamental changed, 
instead the extension is just adding a search filter which restricts the 
available modules it will import against.  I see that it is functionally 
equivalent to the import "revision-date" statement which restricts the 
modules that can be imported to only the module that has a matching 
module name and revision-date.

So, what happens if a YANG compile doesn't understand the new "version" 
import substmt?  Well then can ignore it and treat these as regular 
import statements, as they do today.  If the first module they find is a 
compatible version then great, everything works.  If not, then the 
module will probably fail to compile. But exactly the same case exists 
today with the regular import statement.  I.e. you module may fail to 
compile if you import against a module that is too old.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Jul 2018 13:46:15 +0200

On Tue, Jul 10, 2018 at 11:59:33AM +0100, Robert Wilton wrote:
> I don't see that the import statement as being fundamental changed, instead
> the extension is just adding a search filter which restricts the available
> modules it will import against.  I see that it is functionally equivalent to
> the import "revision-date" statement which restricts the modules that can be
> imported to only the module that has a matching module name and
> revision-date.
> 
> import substmt?  Well then can ignore it and treat these as regular import
> statements, as they do today.  If the first module they find is a compatible
> version then great, everything works.  If not, then the module will probably
> fail to compile. But exactly the same case exists today with the regular
> import statement.  I.e. you module may fail to compile if you import against
> a module that is too old.
>

I am not sure I agree. The reason is that an old tool may pick a
different version and a tool that understands the extension and things
may still compile but they may mean semantically different things.

If we turn YANG into patchwork, then this is likely the beginning of
its end.

/js

---

From: Robert Wilton <[email-masked]>
Date: Tue, 10 Jul 2018 14:25:06 +0100

> may still compile but they may mean semantically different things.
But that exists today.  The module that an import pulls in will depend 
entirely on which module the server chooses to use to satisfy that 
dependency (subject to any restrictions), and that is down to 
implementation choice.

E.g. even if the import choice was version "1.* | 2.*" it is still down 
to the server to decide which particular version of the imported module 
to use.

> If we turn YANG into patchwork, then this is likely the beginning of
I don't agree.  It is good that YANG can be extended without always 
needing new revisions of the language.

But we should also be updating the base specs at the same time, in 
parallel.  E.g. we know that we want to move the NETCONF specific stuff 
and XML encoding specific stuff out of RFC 7950.  The WG would be able 
to schedule this work at any time, if it was so inclined.

I also think that it good when specifications don't become too large, 
otherwise I think that they get hard to maintain.

In summary, I think that allowing for optional features is a good thing, 
if they work well together and there are not too many of them.  The ones 
that everyone needs to implement should go into updated versions of the 
base specification, but developing them in parallel seems like a good 
thing to me.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Jul 2018 16:05:35 +0200

On Tue, Jul 10, 2018 at 02:25:06PM +0100, Robert Wilton wrote:
> dependency (subject to any restrictions), and that is down to implementation
> choice.

Yes, but we do not allow arbitrary semantic changes.
 
> E.g. even if the import choice was version "1.* | 2.*" it is still down to
> the server to decide which particular version of the imported module to use.

He? I am talking about a client.

> I don't agree.  It is good that YANG can be extended without always needing
> new revisions of the language.

Yes, but extensions are not expected basic concepts of the language.

   Care must be taken when defining extensions so that modules that use
   the extensions are meaningful also for applications that do not
   support the extensions.

> parallel.  E.g. we know that we want to move the NETCONF specific stuff and
> XML encoding specific stuff out of RFC 7950.  The WG would be able to
> schedule this work at any time, if it was so inclined.
> 
> In summary, I think that allowing for optional features is a good thing, if
> they work well together and there are not too many of them.  The ones that
> everyone needs to implement should go into updated versions of the base
> specification, but developing them in parallel seems like a good thing to
> me.

Changing versioning is IMHO not 'an optional feature'. Others may see
it differently.

/js

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 10 Jul 2018 16:27:19 +0200

On 7/10/2018 3:25 PM, Robert Wilton
wrote:

If we turn YANG into patchwork, then this is likely the
beginning of

its end.

I don't agree.  It is good that YANG can be extended without
always needing new revisions of the language.

But we should also be updating the base specs at the same time, in
parallel.  E.g. we know that we want to move the NETCONF specific
stuff and XML encoding specific stuff out of RFC 7950.  The WG
would be able to schedule this work at any time, if it was so
inclined.

I also think that it good when specifications don't become too
large, otherwise I think that they get hard to maintain.

In summary, I think that allowing for optional features is a good
thing, if they work well together and there are not too many of
them.  The ones that everyone needs to implement should go into
updated versions of the base specification, but developing them in
parallel seems like a good thing to me.

+1