Subject: [Netmod-ver-dt] Design Team Welcome

From: Robert Wilton <[email-masked]>
Date: Mon, 14 May 2018 18:01:54 +0100

Welcome, and thank you for expressing your interest in the YANG version 
design team.

This has taken a while to get set up, so we need to get going quickly.

My proposed approach is to initially try and give weekly meetings via 
webex video conferencing.  We can cancel/skip any meetings that are not 
required.   I'll try and generate a proposed agenda prior to the 
meeting, and also generate meeting minutes for these.

I don't know the exact span of timezones for the various DT members, but 
I know that we have some in US/Canada and others in Asia, and quite a 
few in European timezones.  Hence, for my initial gambit, I have put out 
three 1 hour slots between 12 pm and 3 pm GMT, for each day of the 
week.  The hope is to try and find a regular weekly time slot that we 
can all generally make, so please try and be accommodating if possible.  
But if these are clearly not workable for your timezone then please let 
me know.

The Doodle Poll link is here.
https://doodle.com/poll/pawq5k67rganxm7g

As per the DT charter, I see that our initial focus running up to the 
next IETF is on two areas:
(1) Agree of a definition for the problem statement of what is being solved.
(2) Agree a succinct list of requirements that any solution must 
fulfill, or is desirable to fulfill.

Hence, please may I ask you to think about these two areas, send 
comments to the alias, and be prepared to discuss them at the first 
meeting, which I will schedule for later this week (if we agree on a 
Thursday or Friday), or otherwise next week.

It is also worth pointing out that some of this work has already been 
done as part of the two drafts below, which could potentially act as a 
good starting place.

https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update
https://datatracker.ietf.org/doc/draft-wang-netmod-module-revision-management

Thanks,
Rob

---

From: Benoit Claise <[email-masked]>
Date: Mon, 14 May 2018 19:09:34 +0200

Hi Rob,

Thanks for this.
Who are the DT members?

Regards, Benoit
> Welcome, and thank you for expressing your interest in the YANG 
> version design team.
>
> webex video conferencing.  We can cancel/skip any meetings that are 
> not required.   I'll try and generate a proposed agenda prior to the 
> I don't know the exact span of timezones for the various DT members, 
> but I know that we have some in US/Canada and others in Asia, and 
> quite a few in European timezones.  Hence, for my initial gambit, I 
> have put out three 1 hour slots between 12 pm and 3 pm GMT, for each 
> day of the week.  The hope is to try and find a regular weekly time 
> slot that we can all generally make, so please try and be 
> accommodating if possible.  But if these are clearly not workable for 
> your timezone then please let me know.
>
> _______________________________________________
> Netmod-ver-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod-ver-dt

---

From: Robert Wilton <[email-masked]>
Date: Tue, 15 May 2018 10:12:07 +0100

Hi Benoit,

In the end, we decided to add everyone who has expressed an interest to 
the DT alias, but really the team will be defined by those who actively 
participate in the meetings and work.

The current membership is:

   Balazs Lengyel
   Benoit Claise
   Ebben Aries
   Joe Clarke
   Juergen Schoenwaelder
   Mahesh Jethanandani
   Michael (Wangzitao)
   Qin Wu
   Reshad Rahman
   Rob Wilton (lead)
   Sue Hares

Thanks,
Rob

On 14/05/2018 18:09, Benoit Claise wrote:
>> done as part of the two drafts below, which could potentially act as 
>> a good starting place.
>>
> .

---

From: Robert Wilton <[email-masked]>
Date: Tue, 22 May 2018 15:50:50 +0100

The result of the Doodle Poll is that Thurs 3-4 pm Eur/London is the 
best time.  I've set up a webex for an initial meeting this Thursday.

I have a meeting every fortnight that overlaps with the second half of 
that slot, so sometimes I may need to drop off the call for a while, but 
I'm sure that we will be able to manage it.

Thanks,
Rob

> https://datatracker.ietf.org/doc/draft-wang-netmod-module-revision-management 

Subject: (Forward to others) WebEx meeting invitation: NETMOD YANG Version DT
From: Robert Wilton <[email-masked]>
To: <[email-masked]>
Date: Tue, 22 May 2018 14:46:47 +0000

You can forward this invitation to others.  

Hello,

Robert Wilton invites you to join this WebEx meeting.

NETMOD YANG Version DT
Every Thursday, from Thursday, May 24, 2018, to no end date
3:00 pm  |  GMT Summer Time (London, GMT+01:00)  |  1 hr
Meeting number (access code): 200 574 017 
Meeting password: UdTbwvpT (83829878 from phones)

Add to Calendar
https://cisco.webex.com/ciscosales/j.php?MTID=mffa258c3b406059f64d332f17bd31aae

When it's time, join the meeting.
https://cisco.webex.com/ciscosales/j.php?MTID=m17e7eef8ba31a53254efa7c8c33048dc

JOIN FROM A VIDEO SYSTEM OR APPLICATION
Dial sip:[email-masked]
You can also dial 173.243.2.68 and enter your meeting number.
From the Cisco internal network, dial *267* and the 9-digit meeting number.  If you are the host, enter your PIN when prompted.  

JOIN BY PHONE
+1-866-432-9903 Call-in toll-free number (US/Canada) 
+1-408-525-6800 Call-in toll number (US/Canada)

Global call-in numbers:
https://cisco.webex.com/ciscosales/globalcallin.php?serviceType=MC&ED=435913767&tollFree=1

Toll-free dialing restrictions: 
https://www.webex.com/pdf/tollfree_restrictions.pdf

Can't join the meeting?
https://collaborationhelp.cisco.com/article/WBX000029055

IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session.

---

From: Benoit Claise <[email-masked]>
Date: Thu, 24 May 2018 14:50:33 +0200

Dear all,

Thinking about today's objectives.

See 
https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2

    2 
<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2>.  The Problems  . . . . . . . . . . . . . . . . . . . . . . . .3 
<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-3>
      2.1 
<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.1>.  Slow Standardization  . . . . . . . . . . . . . . . . . .3 
<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-3>
      2.2 
<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.2>.  Some YANG Modules Are Not Backward Compatible . . . . . .3 
<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-3>
      2.3 
<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.3>.  Non-Backward Compatible Errors  . . . . . . . . . . . . .4 
<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-4>
      2.4 
<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.4>.  YANG Module Transition Strategy . . . . . . . . . . . . .4 
<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-4>
      2.5 
<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.5>.  Need to Allow Non-Backward Compatible changes . . . . . .5 
<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-5>
      2.6 
<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.6>.  Clear Indication of Node Support  . . . . . . . . . . . .5 
<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-5>
      2.7.  No way to easily decide whether a change is Backward
            Compatible  . . . . . . . . . . . . . . . . . . . . . . .6 
<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-6>

We could start by looking at those problem statements.
Note that some of the bullet points are expressed as "requirements", 
derived from problem statements:

      2.5 
<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.5>.  Need to Allow Non-Backward Compatible changes . . . . . .5 
<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-5>
      2.6 
<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.6>.  Clear Indication of Node Support  . . . . . . . . . . . .5 
<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-5>

The document could be re-structured this way:

    2 
<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2>.  The Problems  . . . . . . . . . . . . . . . . . . . . . . . .3 
<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-3>
      2.1 
<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.1>.  Slow Standardization  . . . . . . . . . . . . . . . . . .3 
<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-3>
      2.2 
<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.2>.  Some YANG Modules Are Not Backward Compatible . . . . . .3 
<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-3>
      2.3 
<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.3>.  Non-Backward Compatible Errors  . . . . . . . . . . . . .4 
<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-4>
      2.4.  No way to easily decide whether a change is Backward
            Compatible  . . . . . . . . . . . . . . . . . . . . . . .6 
<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-6>

    3.  The Requirements. . . . . . . . . . . . . . . . . . . . . . .3 
<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-3>
      3.1.  Need to Allow Non-Backward Compatible changes . . . . . .5 
<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-5>
      3.2.  Clear Indication of Node Support  . . . . . . . . . . . .5 
<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-5>

Note 1: there is also an implicit requirement: "SHOULD be aligned with 
openconfig"
              SHOULD in the sense: unless you have a good reason, don't 
deviate. No need to fracture the industry some more
Note 2:

    This document does not address the potential need of an automatic
    way to discover that a YANG-MODULE-B obsoletes YANG-MODULE-A, so
    that YANG-MODULE-A should not be given any attention. This problem
    is  currently solved by RFC obsolete tag as a level of indirection
    between the YANG modules.

Finally, note that 
https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-3 
is the derived solution, based on the problem statements/requirements.

Talk to you later today.

Regards, Benoit
> that slot, so sometimes I may need to drop off the call for a while, 
> but I'm sure that we will be able to manage it.
>
> Thanks,
> Rob
>
>

---

From: Joe Clarke <[email-masked]>
Date: Thu, 24 May 2018 09:00:55 -0400

Unfortunately, I have a conflict for today's call.  In general, this
time works, and I will make the next call.

Benoit noticed some missing text in our -04 revision of the module
update draft.  This was due to a missed merge on my part.  I'm posting
an -05 with all of the text that was intended for -04 (intended vs.
applied and all :-) ).

Joe

On 5/24/18 08:50, Benoit Claise wrote:
> <https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2>.  The Problems  . . . . . . . . . . . . . . . . . . . . . . . .   3
> <https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.1>.  Slow Standardization  . . . . . . . . . . . . . . . . . .   3
> <https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.2>.  Some YANG Modules Are Not Backward Compatible . . . . . .   3
> <https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.3>.  Non-Backward Compatible Errors  . . . . . . . . . . . . .   4
> <https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.4>.  YANG Module Transition Strategy . . . . . . . . . . . . .   4
> <https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.5>.  Need to Allow Non-Backward Compatible changes . . . . . .   5
> <https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.6>.  Clear Indication of Node Support  . . . . . . . . . . . .   5
>            Compatible  . . . . . . . . . . . . . . . . . . . . . . .   6
> <https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.5>.  Need to Allow Non-Backward Compatible changes . . . . . .   5
> <https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.6>.  Clear Indication of Node Support  . . . . . . . . . . . .   5
> <https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2>.  The Problems  . . . . . . . . . . . . . . . . . . . . . . . .   3
> <https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.1>.  Slow Standardization  . . . . . . . . . . . . . . . . . .   3
> <https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.2>.  Some YANG Modules Are Not Backward Compatible . . . . . .   3
> <https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.3>.  Non-Backward Compatible Errors  . . . . . . . . . . . . .   4
>            Compatible  . . . . . . . . . . . . . . . . . . . . . . .   6
>    3.  The Requirements. . . . . . . . . . . . . . . . . . . . . . .   3
>      3.1.  Need to Allow Non-Backward Compatible changes . . . . . .   5
>      3.2.  Clear Indication of Node Support  . . . . . . . . . . . .   5

---

From: Benoit Claise <[email-masked]>
Date: Thu, 24 May 2018 17:39:53 +0200

Dear all,

As discussed today, here is a proposed structure proposal
OLD:

    2 

NEW:

    2 
      2.5.  Import by revision is too strict.
	   NEW SECTION TO BE WRITTEN BY BALAZS

What do you think?

Regards, Benoit

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 24 May 2018 16:57:45 +0000

Looks good to me.

Regards,
Reshad.

From: Netmod-ver-dt <[email-masked]> on behalf of "Benoit Claise (bclaise)" <[email-masked]>
Date: Thursday, May 24, 2018 at 11:42 AM
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[email-masked]>, "[email-masked]" <[email-masked]>, Balazs Lengyel <[email-masked]>
Subject: Re: [Netmod-ver-dt] document structure proposal

Dear all,

   2<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2>.  The Problems  . . . . . . . . . . . . . . . . . . . . . . . .   3<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-3>

     2.1<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.1>.  Slow Standardization  . . . . . . . . . . . . . . . . . .   3<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-3>

     2.2<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.2>.  Some YANG Modules Are Not Backward Compatible . . . . . .   3<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-3>

     2.3<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.3>.  Non-Backward Compatible Errors  . . . . . . . . . . . . .   4<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-4>

     2.4<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.4>.  YANG Module Transition Strategy . . . . . . . . . . . . .   4<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-4>

     2.5<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.5>.  Need to Allow Non-Backward Compatible changes . . . . . .   5<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-5>

     2.6<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.6>.  Clear Indication of Node Support  . . . . . . . . . . . .   5<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-5>

           Compatible  . . . . . . . . . . . . . . . . . . . . . . .   6<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-6>
NEW:

   2<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2>.  The Problems  . . . . . . . . . . . . . . . . . . . . . . . .   3<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-3>

     2.1<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.1>.  Slow Standardization  . . . . . . . . . . . . . . . . . .   3<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-3>

     2.2<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.2>.  Some YANG Modules Are Not Backward Compatible . . . . . .   3<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-3>

     2.3<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.3>.  Non-Backward Compatible Errors  . . . . . . . . . . . . .   4<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-4>

           Compatible  . . . . . . . . . . . . . . . . . . . . . . .   6<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-6>

   3.  The Requirements. . . . . . . . . . . . . . . . . . . . . . .   3<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-3>

     3.2.  Clear Indication of Node Support  . . . . . . . . . . . .   5<https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#page-5>

What do you think?

Regards, Benoit

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 24 May 2018 23:44:56 +0200

On Thu, May 24, 2018 at 05:39:53PM +0200, Benoit Claise wrote:
> Slow Standardization  . . . . . . . . . . . . . . . . . .3
>      2.2 <https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.2>.

I think what I hear people talking about is 'agile development' and
that the strict backwards compatibility rules we have today do not
work well in an agile development model.

I am trying to get away from this "standardization is slow" argument
because there are many reasons why lets say the IETF is slow and it is
not clear that a different YANG versioning model will have a big
impact in changing this.

Perhaps it helps to formulate the problem using different terms that
describe development models where the strict backwards compatibility
of YANG is believed to be an issue.

/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: Robert Wilton <[email-masked]>
Date: Wed, 30 May 2018 17:52:31 +0100

Hi all,

I had a go at writing the Problem Definition from scratch.  My purpose 
for doing this was to help me determine whether the Problem Definition 
from the clacla draft is complete, and whether it is organized in the 
best way.  I think that was I have written below seems to be mostly 
cover the same issues, but with a different organization, and much less 
detail.  I'm not proposing that this be used instead of the problem 
statement in the clacla draft, but thought that it may be useful to have 
an alternative as a comparison.

Comments, feedback is of course welcome.  Here is what I came up with:

Problems with existing YANG versioning rules.

1. Problems due to inflexible YANG update rules:

i) The requirement that all non-backwards compatible updates must be 
made in a separate module name (with separate module namespace) hampers 
agile development methodogies.  It also appears to slowing down YANG 
module standardization efforts, because of the perceived high cost of 
fixing an imperfect published module.

ii) The existing strict rules on YANG backwards compatibility are not 
sympathetic to minor (non backwards compatible) fixes.  Hence rather 
than allowing an existing data node definition to be fixed, it is 
necessary that a new fixed datanode is be defined, or a new module to be 
defined to fix the bug.  Client and server implementations must be 
updated to make use of the fixed data node.

iii) Requiring all non backwards compatible changes to be defined as a 
new module impacts clients, servers, and other modules.  All importing 
modules must be updated.  Any client/server code using the modules that 
have been updated are likely to also be updated to use new namespace/paths.

iv) Machine generated YANG modules struggle to conform to the existing 
YANG upgrade rules.
Some server implementation struggle to conform to the strict, RFC 7950, 
YANG module update rules.  One way to mitigate this is to publish the 
modules for each server OS revision with a separate module name, but 
this is hard for clients to handle. Another solution is that some 
vendors ignore some of the strict YANG backwards compatibily update 
rules, and allow for non backwards compatible updates without changing 
the module name.

2. Import with revision-date creates tightly coupled dependencies
Using import with revision-date forces module versions to be closely 
aligned.  Hence, if one module is updated (e.g. for a bug fix) then all 
modules that import using revision-date must be updated to import using 
the new revision-date and be republished.  Hence import using 
revision-date is not pragmatically useful in most scenarios.

3. There is no robust way to identify differences between module revisions
Updated modules are published with a new revision date, but this is not 
sufficient to determine the significance of the changes present between 
two module revisions.  Tooling can be used to programmatically compare 
two module revisions to identify the changes, but this is unable to 
cover all scenarios because tooling cannot see changes in data node 
semantics covered by a description statement.

4. Clients cannot determine whether servers implement deprecated or 
obsolete YANG nodes.
Since servers are not required to implement deprecated YANG nodes, 
clients are unable to determine from the schema which nodes are actually 
supported by a server.

Thanks,
Rob

---

From: Joe Clarke <[email-masked]>
Date: Wed, 30 May 2018 13:39:56 -0400

> an alternative as a comparison.

One of the goals with the recent clacla revisions was to reduce some of
the up-front text to get to the heart of the issues more quickly.  Your
approach is in line with that goal.  Thanks.

Reading through these, I think the important points are preserved.

> agile development methodogies.  It also appears to slowing down YANG

*methodologies

> vendors ignore some of the strict YANG backwards compatibily update

*compatibility

> rules, and allow for non backwards compatible updates without changing

One of the vendor-specific points raised in clacla is that some vendor
modules are machine-generated from other data models rather than
authored.  As such, backwards incompatible changes may naturally occur
as it makes sense with respect to the source of truth.  This is
different (at least to some degree) from a vendor ignoring the 7950
guidelines.

Joe

>>> <https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-04#section-2.2>.
>>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 May 2018 20:02:09 +0200

On Wed, May 30, 2018 at 05:52:31PM +0100, Robert Wilton wrote:
> i) The requirement that all non-backwards compatible updates must be made in
> a separate module name (with separate module namespace) hampers agile
> development methodogies.  It also appears to slowing down YANG module
> standardization efforts, because of the perceived high cost of fixing an
> imperfect published module.

This is technically incorrect. You can also keep the module namespace
and simply create new definitions. Perhaps there needs to be an
explanation _why_ this hampers agile development.
 
> sympathetic to minor (non backwards compatible) fixes.  Hence rather than
> allowing an existing data node definition to be fixed, it is necessary that
> a new fixed datanode is be defined, or a new module to be defined to fix the
> bug.  Client and server implementations must be updated to make use of the
> fixed data node.

What is the definition of "minor (non backwards compatible) fixes" -
what are 'fixes'? If you don't define this, the text can be read in
many different ways. Note that I think that pure bug fixes are allowed
even today - but this may be just my reading of RFC 7950.

> iii) Requiring all non backwards compatible changes to be defined as a new
> module impacts clients, servers, and other modules.  All importing modules
> must be updated.  Any client/server code using the modules that have been
> updated are likely to also be updated to use new namespace/paths.

Technically wrong. Whether you use a new module or simply add new
definitions to an existing module is up to the module maintainer.

Also note that making non backwards compatible changes and _assuming_
that all modules using the old definition will work with the new
definition is a very wild guess.

> iv) Machine generated YANG modules struggle to conform to the existing YANG
> upgrade rules.
> Some server implementation struggle to conform to the strict, RFC 7950, YANG
> module update rules.  One way to mitigate this is to publish the modules for
> each server OS revision with a separate module name, but this is hard for
> clients to handle. Another solution is that some vendors ignore some of the
> strict YANG backwards compatibily update rules, and allow for non backwards
> compatible updates without changing the module name.

If modules names with version numbers are difficult for clients, why
would a separate version number be simpler?

> modules that import using revision-date must be updated to import using the
> new revision-date and be republished.  Hence import using revision-date is
> not pragmatically useful in most scenarios.

I might agree with this.
 
> sufficient to determine the significance of the changes present between two
> module revisions.  Tooling can be used to programmatically compare two
> module revisions to identify the changes, but this is unable to cover all
> scenarios because tooling cannot see changes in data node semantics covered
> by a description statement.

This is nonsense. There are diffing tools. We have guidelines that
require a revision statement to explain things. A different versioning
scheme will not help against lazy people.
 
> 4. Clients cannot determine whether servers implement deprecated or obsolete
> YANG nodes.
> Since servers are not required to implement deprecated YANG nodes, clients
> are unable to determine from the schema which nodes are actually supported
> by a server.

Yes, some of the details of the deprecated and obsolete labels need
clarification.

/js

---

From: Robert Wilton <[email-masked]>
Date: Thu, 31 May 2018 11:47:35 +0100

On 30/05/2018 19:02, Juergen Schoenwaelder wrote:
> and simply create new definitions.
No, not technically incorrect.  This is refers to non backwards 
compatible changes.  Adding non backwards compatible updates to the same 
module breaks the rfc 7950 module update rules.

Backwards compatible updates, added as new definitions, or new modules, 
is not the issue here.

>   Perhaps there needs to be an
OK

> even today - but this may be just my reading of RFC 7950.
My interpretation of the RFC 7950 rules is that it does not allow bug fixes.

> definitions to an existing module is up to the module maintainer.
No, not technically wrong.  Again, this is refers to non backwards 
compatible changes.  Adding non backwards compatible updates to the same 
module breaks the rfc 7950 module update rules.

> definition is a very wild guess.
Yes, and I think that this point is one that should be discussed further.

> would a separate version number be simpler?
For several reasons:
  - There is currently no specification for how version numbers should 
be specified in the module name, each vendor is likely to do it 
differently, so a client cannot easily determine what has changed 
between module revisions, or what the scope of those changes are.
- Putting the version number in the name forces all leaves to be on 
separate qualified paths.  So, even if there were non backwards 
compatible changes to only 5% of a modules nodes, all nodes would 
change, likely forcing the client to make a lot more changes to support it.

> scheme will not help against lazy people.
This isn't about people being lazy, but trying to make like easier for them.

I agree that tooling can and should be used where possible, but I don't 
think that it is perfect.  E.g. it cannot understand a change in a 
description statement that means that a change that tooling may flag as 
backwards compatible is in fact not backwards compatible.

So, this then requires that a human has to diff all the modules between 
revisions to figure out what has changed.

However, it seems more efficient to me that if the author of the module 
changes could identify the scope of the changes in a machine readable 
way that might reduce the workload for the clients.  They can still use 
the same diffs tools, but it provides some easy indication of whether 
the updated module is likely to be trivially compatible or not.

A separate problem (perhaps this should also be described in the problem 
description) with a revision date is that it doesn't allow any sort of 
forking.  E.g. if I have a module A published at revision R, which is 
then updated with new functionality at revision R2 then it is not 
possible to create a updated (bug fixed) revision of R without pulling 
in all the new functionality in R2.

This problem is hit for machine generated YANG modules where you want to 
the revisions of the modules to align with particular releases.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 31 May 2018 13:41:37 +0200

On Thu, May 31, 2018 at 11:47:35AM +0100, Robert Wilton wrote:
> No, not technically incorrect.  This is refers to non backwards compatible
> changes.  Adding non backwards compatible updates to the same module breaks
> the rfc 7950 module update rules.
> 
> Backwards compatible updates, added as new definitions, or new modules, is
> not the issue here.

In both cases, you add new definitions, you do not make changes. Its
the same. I disagree with your interpretation.
 
> module breaks the rfc 7950 module update rules.

See above, in both cases you create new definitions.
 
>  - There is currently no specification for how version numbers should be
> specified in the module name, each vendor is likely to do it differently, so
> a client cannot easily determine what has changed between module revisions,
> or what the scope of those changes are.
> - Putting the version number in the name forces all leaves to be on separate
> qualified paths.  So, even if there were non backwards compatible changes to
> only 5% of a modules nodes, all nodes would change, likely forcing the
> client to make a lot more changes to support it.

Dealing with multiple versions has costs. I am not convinced that a
tuple is singificantly more costly than a triple.

> changes could identify the scope of the changes in a machine readable way
> that might reduce the workload for the clients.  They can still use the same
> diffs tools, but it provides some easy indication of whether the updated
> module is likely to be trivially compatible or not.

This is what the revision statement and its description statement is
for. This is already solved.

/js (leaving now and likely being offline until next week)

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 31 May 2018 15:45:41 +0200

Hello Rob,

Missing: A way to indicate a schema node will be removed in the next 
release, but ensure it is still working today.

Correction on 3): I need a simple way to determine if the changes are 
compatible or not. I don't want a list of changes (diff can do that kind 
of).

regards Balazs

On 5/30/2018 6:52 PM, Robert Wilton wrote:
> cover the same issues, but with a different organization, and much 
> less detail.  I'm not proposing that this be used instead of the 
> problem statement in the clacla draft, but thought that it may be 
> useful to have an alternative as a comparison.
>
> made in a separate module name (with separate module namespace) 
> hampers agile development methodogies.  It also appears to slowing 
> down YANG module standardization efforts, because of the perceived 
> high cost of fixing an imperfect published module.
>
> necessary that a new fixed datanode is be defined, or a new module to 
> be defined to fix the bug.  Client and server implementations must be 
> modules must be updated.  Any client/server code using the modules 
> that have been updated are likely to also be updated to use new 
> namespace/paths.
>
> Some server implementation struggle to conform to the strict, RFC 
> 7950, YANG module update rules.  One way to mitigate this is to 
> publish the modules for each server OS revision with a separate module 
> name, but this is hard for clients to handle. Another solution is that 
> some vendors ignore some of the strict YANG backwards compatibily 
> update rules, and allow for non backwards compatible updates without 
> changing the module name.
>
>
> aligned.  Hence, if one module is updated (e.g. for a bug fix) then 
> all modules that import using revision-date must be updated to import 
> using the new revision-date and be republished. Hence import using 
> Updated modules are published with a new revision date, but this is 
> not sufficient to determine the significance of the changes present 
> between two module revisions.  Tooling can be used to programmatically 
> compare two module revisions to identify the changes, but this is 
> unable to cover all scenarios because tooling cannot see changes in 
> data node semantics covered by a description statement.
>
>
> clients are unable to determine from the schema which nodes are 
> actually supported by a server.
>
> Thanks,
> Rob
>
>

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

---

From: Benoit Claise <[email-masked]>
Date: Thu, 31 May 2018 15:50:29 +0200

> See above, in both cases you create new definitions.
When you create new definitions and obsoleting the old ones in a new 
YANG module, you "hampers agile development methodologies."
Yes, you might be compliant with RFC7950 "updating a module" rules, but 
it doesn't matter, the point is that you need to modify _all _your 
configuration/monitoring scripts b/c you deal with new managed objects. 
Don't forget that there might a cascading effect:
     change to the script to configure/monitor network element
     => change to the script to configure/monitor service in a 
controller/orchestrator
     => change to the script above the orchestrator

With semver, the promise is that you keep the same object names, so the 
changes to your script should be smaller.

Do you still need to test/validate (and potentially update) all your 
scripts? Absolutely, if the changes are important.
Semver major,minor,patch should provide a hint on much might change.
To come back to one of your point below, I agree with:
      "Also note that making non backwards compatible changes and 
_assuming_
     that all modules using the old definition will work with the new
     definition is a very wild guess. "

> for. This is already solved.
Are you really convinced that there are no issues and we've been 
spending time making up a problem?

Regards, Benoit

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 31 May 2018 15:58:45 +0200

Hello,

In reality many incompatible changes are handled in
clients/scripts quite easily. A module may have many different
parts. So if I make an incompatible change in ietf-system to the
NTP part, my scripts handling authorization just

- find from the semver number that checks are needed

- read the revision description finding that it only concerns
NTP

- end of processing, no real change to do :-)

This is much simpler then updating every single path in the
script because the module name/namespace changed. IMHO this case
where a client depends only on part of the module is quite
typical.

regards Balazs

On 5/31/2018 3:50 PM, Benoit Claise
wrote:

On 5/31/2018 1:41 PM, Juergen
Schoenwaelder wrote:

When you create new definitions and obsoleting the old ones in a
new YANG module, you "hampers agile development methodologies."

Yes, you might be compliant with RFC7950 "updating a module"
rules, but it doesn't matter, the point is that you need to modify
all your configuration/monitoring scripts b/c you deal
with new managed objects. Don't forget that there might a
cascading effect:

With semver, the promise is that you keep the same object names,
so the changes to your script should be smaller.

Do you still need to test/validate (and potentially update) all
your scripts? Absolutely, if the changes are important.

Semver major,minor,patch should provide a hint on much might
change.

"Also note that making non backwards compatible changes and _assuming_

that all modules using the old definition will work with the
new

For several reasons:

Regards, Benoit