[netmod] Re: Draft minutes for IETF 120 available

[Reshad Rahman]

 Hi,
Small correction to #7:"I found it off" -> "I found it odd"
Regards,Reshad.
On Monday, August 5, 2024 at 06:43:26 PM EDT, Lou Berger  
wrote:  
 
 All,

Thanks to our new WG secretary we have minutes posted at 
https://datatracker.ietf.org/doc/minutes-120-netmod

Please review and send any comments/corrections/requests to the list.

Thank you!

Kent, Lou (and James)

___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org
  ___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: Fwd: New Version Notification for draft-andersson-netmod-yang-module-filename-01.txt

[Reshad Rahman]

 Hi Per,
    Perhaps this formulation is still to arbitrary that both revision-date and
    ys:version can be used? The formulation is taken from the module
    versioning document almost verbatim, but there have been a few
    iterations of this paragraph.
Yes we went through a few iterations of that text. At some point we even had 
text about 1 copy of each module and use of soft links etc...But my 
recollection is that at the end of our weekly discussions, and maybe that was 
never reflected in the document, is that we wanted to allow use of both 
revision-date and ys:version in filenames. 
Regards,Reshad. 
On Monday, July 8, 2024 at 06:45:32 AM EDT, Per Andersson 
 wrote:  
 
 Hi Reshad,

On Sun, Jul 7, 2024 at 3:59 PM Reshad Rahman  wrote:
>
> Hi Per,
>
> Thanks for doing the work. I just took a quick look at the document and I 
> have 1 basic comment/question:

Thanks for the review!


> Section 2 has the following text where it says "instead of". IIRC when we had 
> this in the module versioning document, the intention was to allow both forms.
>
>    If a revision has an associated YANG semantic version (ys:version)
>    then it is RECOMMENDED that the YANG semantic version is used instead
>    of the revision date in the file name of a YANG file, where it takes
>    the form:
>
>        module-or-submodule-name [['@' revision-date]['#' ys:version]]
>            ( '.yang' / '.yin' )
>
>    E.g., acme-router-mod...@2024-05-15.yang or
>    acme-router-module#2.0.3.yang.

I have uploaded a new revision which says

  If a revision has an associated YANG semantic version (ys:version)
  then it MAY use the YANG semantic version instead of the revision date
  in the file name of a YANG file, where it takes the form:

Perhaps this formulation is still to arbitrary that both revision-date and
ys:version can be used? The formulation is taken from the module
versioning document almost verbatim, but there have been a few
iterations of this paragraph.


--
Pell
  ___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

[netmod] Re: Fwd: New Version Notification for draft-andersson-netmod-yang-module-filename-01.txt

[Reshad Rahman]

 Hi Per,
Thanks for doing the work. I just took a quick look at the document and I have 
1 basic comment/question:
Section 2 has the following text where it says "instead of". IIRC when we had 
this in the module versioning document, the intention was to allow both forms.
   If a revision has an associated YANG semantic version (ys:version)
   then it is RECOMMENDED that the YANG semantic version is used instead
   of the revision date in the file name of a YANG file, where it takes
   the form:

   module-or-submodule-name [['@' revision-date]['#' ys:version]]
   ( '.yang' / '.yin' )

   E.g., acme-router-mod...@2024-05-15.yang or
   acme-router-module#2.0.3.yang.
  Regards,Reshad.
On Thursday, July 4, 2024 at 04:28:14 PM EDT, Per Andersson  
wrote:  
 
 Dear NETMOD WG,

I have uploaded an experimental draft to datatracker containing the YANG module
file name convention that was previously included in the YANG module versioning
and YANG Semver work.

In short, the draft presents a convention to name YANG modules not only with
revision dates but also with YANG semantic version, i.e. the following would be
supported:

    modul...@2023-11-05.yang

    module-b#2.0.0.yang


--
Per



-- Forwarded message -
From: 
Date: Thu, Jul 4, 2024 at 8:20 PM
Subject: New Version Notification for
draft-andersson-netmod-yang-module-filename-01.txt
To: Per Andersson 


A new version of Internet-Draft
draft-andersson-netmod-yang-module-filename-01.txt has been successfully
submitted by Per Andersson and posted to the
IETF repository.

Name:    draft-andersson-netmod-yang-module-filename
Revision: 01
Title:    YANG module file name convention
Date:    2024-07-04
Group:    Individual Submission
Pages:    6
URL:      
https://www.ietf.org/archive/id/draft-andersson-netmod-yang-module-filename-01.txt
Status:  
https://datatracker.ietf.org/doc/draft-andersson-netmod-yang-module-filename/
HTML:    
https://www.ietf.org/archive/id/draft-andersson-netmod-yang-module-filename-01.html
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-andersson-netmod-yang-module-filename
Diff:    
https://author-tools.ietf.org/iddiff?url2=draft-andersson-netmod-yang-module-filename-01

Abstract:

  This document presents YANG module file name convention.  The
  convention extends the current YANG module file name using
  revision-date, with the YANG semantic version extension.  The YANG
  semantic version extension allows for an informative version to be
  associated with a particular YANG module revision.



The IETF Secretariat

___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org
  ___
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

Re: [netmod] I-D Action: draft-ietf-netmod-yang-module-versioning-11.txt

[Reshad Rahman]

 NETMOD WG,
A lot of changes went in -11, these changes were discussed on the mailing list, 
at IETF118 and during the weekly calls.
Summary of the changes:- The revision-label-scheme has been removed. This is 
because we will have a single versioning scheme.- The revision-label extension 
has been removed. It has been moved to the YANG semver document (and renamed 
"version").- The section on resolving ambiguous imports has been removed.- The 
extension recommended-min has been renamed to recommended-min-date and, as the 
name indicates, is now date specific.- The section on file names has been 
removed. So we stick to file names as per RFC7950.- The section on versioning 
of YANG instance data has been removed- Removed the statement that whitespace 
changes requires a new version.
Regards,Reshad (on behalf of authors and contributors).


On Friday, March 1, 2024, 03:03:37 PM EST,  
wrote:  
 
 Internet-Draft draft-ietf-netmod-yang-module-versioning-11.txt is now
available. It is a work item of the Network Modeling (NETMOD) WG of the IETF.

  Title:  Updated YANG Module Revision Handling
  Authors: Robert Wilton
            Reshad Rahman
            Balazs Lengyel
            Joe Clarke
            Jason Sterne
  Name:    draft-ietf-netmod-yang-module-versioning-11.txt
  Pages:  35
  Dates:  2024-03-01

Abstract:

  This document refines the RFC 7950 module update rules.  It specifies
  a new YANG module update procedure that can document when non-
  backwards-compatible changes have occurred during the evolution of a
  YANG module.  It extends the YANG import statement with a minimum
  revision suggestion to help document inter-module dependencies.  It
  provides guidelines for managing the lifecycle of YANG modules and
  individual schema nodes.  This document updates RFC 7950, RFC 6020,
  RFC 8407 and RFC 8525.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-11

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-yang-module-versioning-11

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
  ___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adoption call for draft-ma-netmod-immutable-flag-09

[Reshad Rahman]

 I support adoption of this document by the WG.
The interim really helped, for me anyway.
Regards,Reshad.
On Thursday, February 22, 2024, 12:42:30 PM EST, Kent Watsen 
 wrote:  
 
 NETMOD WG,
This email begins a 2-week adoption poll for: 
 YANG Metadata Annotation for Immutable Flag 
https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag-09
There is no known IPR on this draft:
 https://mailarchive.ietf.org/arch/msg/netmod/g_Rh24gXHZcfTUXDo0xZ-sXK-vU/
Please voice your support or technical objections to adoption on the list by 
the end of the day Mar 7 (any time zone).
PS: This draft was discussed in our recent Interim, where a show-of-hands hands 
showed unanimous support for adoption.
Thank you,Kent (as co-chair)
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
  ___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Deviating in circles

[Reshad Rahman]

 Hi Jan,
Does the same question arise with augments?
Inline.

On Tuesday, February 27, 2024, 03:39:37 AM EST, Jan Lindblad (jlindbla) 
 wrote:  
 
  Dear NETMODers,
I'm on site at the annual EANTC interop-event in Berlin, and came across an 
interesting case relating to import and deviations that I'd like the views of 
the list on.
According to RFC 7950:
   There MUST NOT be any circular chains of imports.  For example, if   module 
"a" imports module "b", "b" cannot import "a".
This is clear and I believe most people find this reasonable enough.
With this rule in mind, I can make two modules a and b, where a imports b. 
Module b does not and cannot import a.
module a {yang-version 1.1;namespace "http://example.com/ns/a";prefix a;
import b {prefix b;}
typedef A {type uint32;}
leaf aa {type A;}leaf ab {type b:B;}}
module b {yang-version 1.1;namespace "http://example.com/ns/b";prefix b;
typedef B {type uint32;}
leaf bb {type B;}}
Now let's add a deviation in a separate module d. The deviation module can 
import both a and b (since neither a or b imports d), and it changes the 
structure so that module b now refers to a type in module a.
module d {yang-version 1.1;namespace "http://example.com/ns/d";prefix d;
import a {prefix a;}import b {prefix b;}
deviation /b:bb {deviate replace {type a:A;}}}
As far as I can tell, this follows all the explicit YANG rules regarding 
deviations and imports. Still, it would not have been possible to create this 
YANG structure without a deviation. Module b cannot refer to types or objects 
in module a without an outside intervention.
Is the construct in module d legal? RFC 7950 is not very clear on the subject, 
but it does say:
   After applying all deviations announced by a server, in any order,   the 
resulting data model MUST still be valid.
If "applying" means actually replacing the original module text with the 
deviated text, then I'm fairly sure module d would violate the rule against 
circular imports. If "applying" is something that happens on a more "global" or 
"logical" level, then maybe this should be allowed?
 I don't know what was the intention of the 7950 authors and not even sure 
what would be the "right thing". My guess would be it's more in the "logical" 
level.
By allowing deviations of this kind, we might create a temptation for people to 
use deviations for their own modules in order to create YANG structures 
otherwise not possible. I find this problematic, since I don't like deviations 
much. On the other hand, allowing deviations of this kind increases the freedom 
of expression in the YANG world. I think many would regard a moratorium as 
another YANG CLR (crappy little rule).
If we were to decide that this sort of deviation is allowed, wouldn't a logical 
conclusion be that we should drop the circular imports rule? Compilers could 
very well track which modules have already been imported (like in python), and 
not go into unbounded spin just because there is a circular reference loop.
 yang-next?
Regards,Reshad.
As a side note, recent versions of the OpenConfig model have fallen into this 
YANG-module reference trap. Some OC modules violate RFC 7950 rules because 
their authors were not able to plan ahead and divide their modules properly 
into layers. They have skipped importing modules that they are using because 
their compiler errors out if they do the import, but the compiler they use 
misses/tolerates the illegal reference without the needed import. If modules 
could mutually import each other, this problem would be easily solved. Several 
major vendors of YANG-based servers have navigated around this problem by 
essentially using a single module (namespace) for most of their functionality. 
Then there are no restrictions for what part of the model can reference what 
else, but everything ends up in a single (rather huge) namespace.
Thoughts?
Best Regards,/jan
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
  ___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Is changing the type with union a BC change?

[Reshad Rahman]

 Hi Jason,
I agree for the second case, and IIRC we did discuss that in the 
yang-module-versioning context.
But the first case, I don't understand why it's NBC if there's a new type. 
Encodings of the OLD types wouldn't change?
Regards,Reshad.
On Thursday, January 18, 2024, 09:36:46 AM EST, Jason Sterne (Nokia) 
 wrote:  
 
 
Hi guys,
 
  
 
The second case is NBC. I remember wondering the same thing myself but the type 
in OLD is foo which the type in NEW is union. That is NBC (and in some 
encodings outside of XML, sending that leaf with type foo vs type union, member 
foo would be different).
 
  
 
OLD
 
type foo;
 
 
 
NEW
 
type union {
 
   type foo;
 
   type bar
 
}
 
  
 
The first case is NBC if the addition of the new member adds a new type to the 
list of members. So it depends on the underlying types of foo, bar and baz.  If 
they were all strings, for example, then it is BC.  But if foo and bar are 
“int” and then “baz” is a string, then adding that new member type into the 
union is NBC.
 
  
 
Jason
 
  
 
From: netmod On Behalf Of Jan Lindblad
Sent: Thursday, January 18, 2024 5:13 AM
To: Italo Busi 
Cc: netmod@ietf.org
Subject: Re: [netmod] Is changing the type with union a BC change?
 
  
 
| 
 
  | 
CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.
  |


 
 
Italo, 
 
  
 
Yes, this too would be BC according to the rules. There may be some situations 
where this kind of change might be disruptive in the real world, however, for 
example if you did this to a list key.
 
  
 
Best Regards,
 
/jan
 
  
 
  
 
  
 

Thanks Jan
 
 
 
Following the same logic, also the following change can be considered BC:
 
 
 
OLD
 
type foo;
 
 
 
NEW
 
type union {
 
   type foo;
 
   type bar
 
}
 
 
 
Is my understanding correct?
 
 
 
Thanks again
 
 
 
Italo
 
 
 
From: Jan Lindblad  
Sent: giovedì 18 gennaio 2024 10:33
To: Italo Busi 
Cc: netmod@ietf.org
Subject: Re: [netmod] Is changing the type with union a BC change?
 
 
 
Italo,
 
 
 
Yes, in my judgement this change should be considered BC according to YANG 
rules.
 
 
 
Note that the BC concept is a sort of *agreement* between client and server 
implementors that determines what kind of changes a) are allowed + b) have to 
be tolerated. Even when things are BC, that does not guarantee that things will 
always keep interoperating properly.
 
 
 
Best Regards,
 
/jan
 
 
 
 
 
 
 




 

On 17 Jan 2024, at 23:22, Italo Busi  
wrote:
 
 
 
I have some questions/doubts about whether changing a type with union is a BC 
or NBC change
 
 
 
For example, is the following change a BC or NBC change?
 
 
 
OLD
 
type union {
 
   type foo;
 
   type bar
 
}
 
 
 
NEW
 
type union {
 
   type foo;
 
   type bar;
 
   type baz
 
}
 
 
 
Section 11 of RFC7950 is silent on this case although this change is expanding 
the allowed value space and therefore it looks like a BC change
 
 
 
Thanks, Italo
 
 
 
 
 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
 


  
 ___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
  ___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)

[Reshad Rahman]

 +1 Jason. From an IETF process pov, yes the most expedient thing to do is to 
replace MUST with SHOULD. While this may be good for the IETF, it makes things 
worse for consumers/clients of YANG models: it'd allow NBC changes without any 
indication that NBC changes have been made!
Regards,Reshad.
On Thursday, September 28, 2023, 04:57:46 PM EDT, Jason Sterne (Nokia) 
 wrote:
 
 
 Hi all,

IMO - We've already started moving out of the "stuck" situation. We no longer 
have to debate whether a new YANG 1.2 is needed for allowing an NBC change. 
That will be the end of a big distraction and circular discussions for the WG.

I'm not so convinced we want to rush and do a separate RFC just for that one 
part of Module Versioning (and one part of the original versioning 
requirements). It is a key/critical part, but we should continue discussing 
what other parts we'd want to also tackle as part of the "first" versioning RFC.

I'm very doubtful we should relax MUST to SHOULD NOT without also at least 
making the rev:non-backwards-compatible marker mandatory (as per Module 
Versioning). The marking is a key part of making this all better for consumers 
of modules and clients (one of the main problems is the current silent NBC 
changes happening).

We should also clarify that marking an element as "status obsolete" is NBC. 
That has major impact on clients who are trying to continue using an old 
version of the module.

(and there are likely at least a few other pieces from Module Versioning that 
should be in a "first" RFC)

Jason

> -Original Message-
> From: netmod  On Behalf Of Jürgen Schönwälder
> Sent: Thursday, September 28, 2023 9:12 AM
> To: Reshad Rahman 
> Cc: Kent Watsen ; netmod@ietf.org
> Subject: Re: [netmod] YANG Versioning: discussion around 7950 bis or errata
> (from Key Issue #1)
> 
> 
> CAUTION: This is an external email. Please be very careful when clicking 
> links or
> opening attachments. See the URL nok.it/ext for additional information.
> 
> 
> 
> The truth is that we did bug fixes in the past. We now have maneuvered
> us into a situation where work is put on hold because we do not even
> do bug fixes anymore (and yes, I know, the line between bug fixes,
> alignment with moving targets and other changes is vague and needs to
> be decided on a case by case basis). The fastest way to get unstuck is
> to write this one page content RFC that changes MUST to SHOULD and
> then we at least get out of the being stuck situation.
> 
> /js
> 
> On Thu, Sep 28, 2023 at 01:00:23PM +, Reshad Rahman wrote:
> >  As a client (consumer of models), I do not want only the MUST -> SHOULD
> change, IMO that would be worse than the current situation.
> > Regards,Reshad.
> >    On Wednesday, September 27, 2023, 09:16:10 PM EDT, Kent Watsen
>  wrote:
> >
> >  This was my thought as well, that it would be best to have the 
> >smallest-possible
> draft update 6020/7950.  That way, when someone follows the “Updated” links,
> they’re not overloaded with material that could’ve been left out.
> > Jason was saying that just doing MUST/SHOULD by alone isn’t great, that at
> least the "rev:non-backwards-compatible” extension statement should be
> included and, by extension I suppose, the rules for editing the revision 
> history.
> Presumably revision labels could be left out.  IDK what minimal is possible.
> > K. // contributor
> >
> >
> >
> > On Sep 27, 2023, at 7:06 PM, Rodney Cummings
>  wrote:
> >
> >
> > It is easy to write a short RFC updating RFC 7950, changing one sentence 
> > from
> MUST to SHOULD.
> >
> >
> > I agree. I found that I cannot enter a response to the poll, because I 
> > disagree
> with both Option 1 and Option 2.
> >
> > My concern is that there are many people out there who are implementing
> YANG, but who do not follow discussions on this mailing list. I'm concerned 
> that
> there is a serious risk that those people will interpret the change from MUST 
> to
> SHOULD as "backward compatibility is irrelevant for YANG". We all know that 
> the
> concern is about bug fixes and so on, but without explaining that in a short 
> and
> focused manner (i.e., the short RFC described above), that will be lost in 
> the noise
> of the larger draft-ietf-netmod-yang-module-versioning change.
> >
> > draft-ietf-netmod-yang-module-versioning is a great draft, but I think it 
> > should
> move forward as an independent RFC, distinct from the MUST/SHOULD change.
> >
> > Rodney Cummings
> >
> > -Original Message-
> > From: netmod  On Behalf Of Jürgen Schönwälder
> > Sent: Tuesday,

Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)

[Reshad Rahman]

 As a client (consumer of models), I do not want only the MUST -> SHOULD 
change, IMO that would be worse than the current situation.
Regards,Reshad.
On Wednesday, September 27, 2023, 09:16:10 PM EDT, Kent Watsen 
 wrote:  
 
 This was my thought as well, that it would be best to have the 
smallest-possible draft update 6020/7950.  That way, when someone follows the 
“Updated” links, they’re not overloaded with material that could’ve been left 
out.
Jason was saying that just doing MUST/SHOULD by alone isn’t great, that at 
least the "rev:non-backwards-compatible” extension statement should be included 
and, by extension I suppose, the rules for editing the revision history.  
Presumably revision labels could be left out.  IDK what minimal is possible.
K. // contributor



On Sep 27, 2023, at 7:06 PM, Rodney Cummings  
wrote:


It is easy to write a short RFC updating RFC 7950, changing one sentence from 
MUST to SHOULD.


I agree. I found that I cannot enter a response to the poll, because I disagree 
with both Option 1 and Option 2.

My concern is that there are many people out there who are implementing YANG, 
but who do not follow discussions on this mailing list. I'm concerned that 
there is a serious risk that those people will interpret the change from MUST 
to SHOULD as "backward compatibility is irrelevant for YANG". We all know that 
the concern is about bug fixes and so on, but without explaining that in a 
short and focused manner (i.e., the short RFC described above), that will be 
lost in the noise of the larger draft-ietf-netmod-yang-module-versioning change.

draft-ietf-netmod-yang-module-versioning is a great draft, but I think it 
should move forward as an independent RFC, distinct from the MUST/SHOULD change.

Rodney Cummings

-Original Message-
From: netmod  On Behalf Of Jürgen Schönwälder
Sent: Tuesday, September 26, 2023 5:24 PM
To: Jason Sterne (Nokia) 
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG Versioning: discussion around 7950 bis or errata 
(from Key Issue #1)

It is easy to write a short RFC updating RFC 7950, changing one sentence from 
MUST to SHOULD. This is inline with the goal to not change the language, i.e., 
to keep the version numbers.

/js

On Tue, Sep 26, 2023 at 03:00:19PM +, Jason Sterne (Nokia) wrote:

Hello NETMOD WG,

We've had a poll going for a few weeks to determine if we require YANG 1.2 for 
allowing ("SHOULD NOT") NBC changes (see "Poll on YANG Versioning NBC 
Approach").

As part of that, some discussion has happened on the list around
potentially doing an errata for RFC7950/6020 or a bis of 7950/6020 (if
rough consensus is reached for option 1 of the poll)

7-8 of us discussed this in the YANG Versioning weekly call group today.

First of all: this question of mechanics (errata vs bis vs Module Versioning 
draft) is orthogonal to the poll. Let's first and separately resolve the poll 
and confirm if we need YANG 1.2 or not (that's the fundamental question the 
poll is resolving - everything else is a subsequent issue to be discussed). 
We'll let the chairs confirm when/if rough consensus on the poll has been 
reached.

But *if* the answer to the poll is option 1, then the weekly call group was 
unanimous that we should not do an errata for RFC7950/6020 and we should not do 
a 7950/6020 bis. We should just continue with the Module Versioning draft which 
will update 7950 and 6020.

The primary reason is that we shouldn't just change MUST NOT to SHOULD NOT 
without also tying it together with the mandatory top level 
rev:non-backwards-compatible extension when an NBC change is done. Changing the 
NBC rule to SHOULD NOT needs to be in the same RFC as the mandatory 
rev:non-backwards-compatible tag.

Other reasons:

 *   an errata probably isn't correct since this isn't fixing an intent that 
was present back when 7950 was written (it was clearly the intent at the time 
to block NBC changes)
 *   a bis would be odd without actually introducing other changes to YANG and 
changing the version (this discussion is all based on "if the answer to the 
poll is option 1")

Jason (he/him)




___
netmod mailing list
netmod@ietf.org
https://www.i/
etf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C01%7C%7C22464d2aa09441
f1b1bd08dbbedf65ad%7C84df9e7fe9f640afb435%7C1%7C0%7C638313
638956186415%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DgsZVlBTQtqJjR
tVXs%2Bze%2BrOanijgDEuCn93gbN9Jyw%3D&reserved=0



--
Jürgen Schönwälder  Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf

Re: [netmod] Poll on YANG Versioning NBC Approach

[Reshad Rahman]

 

On Tuesday, September 12, 2023, 11:23:55 AM EDT, Andy Bierman 
 wrote:  
 
 

On Mon, Sep 11, 2023 at 3:39 PM Kent Watsen  wrote:

WG,
Please help the YANG-versioning effort move forward by participating in the 
following poll:
  - https://notes.ietf.org/netmod-2023-sept-poll  (Datatracker login required)



The draft proposed to change many specific MUST and MUST NOT requirements to 
MAY ignore.It has been pointed out that the correct change would be SHOULD NOT 
and the use of MAY is inappropriateaccording to the definitions in RFC 
2119. I thought the authors had agreed on SHOULD NOT (instead of MAY), but 
I don't recall if this was just in the weekly calls or actually communicated to 
the wg alias.
Regards,Reshad.
Yet the WG continues to propose that these rules in RFC 7950 are purely 
optional and can be ignored byany implementation that chooses to do so.
Of course rules that affect backward compatibility and stability do not affect 
the code that compiles a module.They only affect the client code that attempts 
to use the unstable server code.



Kent and Lou

Andy 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
  ___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG module updates based on Errata

[Reshad Rahman]

 Hi Balazs,
AFAIK an errata does not lead to an updated "official" module somewhere. I seem 
to recall that this was brought up by Benoit and/or Rob some time ago, but I 
might be misremembering. I agree that having individual consumers apply the 
errata isn't great.
Regards,Reshad.
On Wednesday, August 23, 2023, 09:28:21 AM EDT, Balázs Lengyel 
 wrote:  
 
  
Hello,
 
If a YANG module in an RFC is updated by errata (e.g. 
https://www.rfc-editor.org/errata/rfc6470) is an official updated IETF  YANG 
module published somewhere?
 
At the moment I don’t find an official update for 
ietf-netconf-notification.yang, thus the only thing my company can do is to 
create and use an unofficial update to the IETF module. That is nasty as a 
vendor should not change IETF modules. But is there any better solution?
 
  
 
  
 
LONG TERM: my preference would be that the errata should include the updated 
module which should be published  on the IETF github. (A full bis updated would 
be preferred, but unlikely to happen.)
 
  
 
Regards Balazs
 
P.S. Sorry if this was discussed, but I don’t remember.
 ___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
  ___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IPR Poll on draft-ietf-netmod-yang-semver-09

[Reshad Rahman]

 No, I'm not aware of any IPR that applies to this draft.

Regards,Reshad.
On Monday, January 16, 2023, 05:59:49 PM EST, Kent Watsen 
 wrote:  
 
 [NOTE: A response is needed from all listed in this message's "To" line, the 
authors and contributors listed in the draft]


Authors, Contributors, WG,

In preparation for a WGLC Call:

    Are you aware of any IPR that applies to drafts identified above?

Please state either:

    "No, I'm not aware of any IPR that applies to this draft"
or
    "Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

    "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
    "No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate. If you are listed as a document author or contributor
please answer the above by responding to this email regardless
of whether or not you are aware of any relevant IPR. This 
document will not advance to the next stage until a response
has been received from each author.

If you are on the WG email list or attend WG meetings but are not
listed as an author or contributor, we remind you of your obligations
under the IETF IPR rules which encourages you to notify the IETF 
if you are aware of IPR of others on an IETF contribution, or to
refrain from participating in any contribution or discussion related
to your undisclosed IPR. For more information, please see the RFCs
listed above and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
Kent and Lou

PS Please include all listed in the headers of this message in your
response.  ___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WGLC on draft-ietf-netmod-syslog-model-28

[Reshad Rahman]

 Hi,
I have reviewed this document and believe it's in good shape. I'd like to see 
the changes suggested by Joe/Mahesh ("stop" action and use of identity for 
actions).
Regards,Reshad.
On Friday, January 13, 2023, 08:05:29 AM EST, Kent Watsen 
 wrote:  
 
 Dear NETMOD WG,

This message begins a two-week WGLC for draft-ietf-netmod-syslog-model-28 
ending on Friday, January 27th.  Here is a direct link to the HTML version of 
the draft:

    https://datatracker.ietf.org/doc/html/draft-ietf-netmod-syslog-model-28

Positive comments, e.g., "I've reviewed this document and believe it is ready 
for publication", are welcome!  This is useful and important, even from 
authors.  Objections, concerns, and suggestions are also welcomed at this time.

Thank you,
Kent (as co-chair)

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
  ___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-28.txt

[Reshad Rahman]

 Hi Joe, Kent,
I think adding a "stop" action would indeed help and yes identities is a good 
idea.
Regards,Reshad.
On Friday, January 13, 2023, 09:22:41 AM EST, Joe Clarke (jclarke) 
 wrote:  
 
 
One thing I was kicking around with Mahesh is a compromise on Reshad’s problem 
by adding a “stop” action.  It won’t address the organization of the 
destination, but it would allow for one to express this semantic.  Moreover, 
the actions could be turned into identities (instead of an enum) to allow for 
future extensibility here.
 
  
 
What does the WG think of these options (now that we’re in another LC)?
 
  
 
Joe
 
  
 
From: Kent Watsen 
Date: Friday, January 13, 2023 at 07:58
To: Reshad Rahman 
Cc: netmod@ietf.org , Joe Clarke (jclarke) 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-28.txt
 
Hi Reshad,
 
  
 
Thank you for explaining.   I share your assessment that it the model may not 
be implementable in rsyslog.  I also cannot fault the model nor advocate a 
change.  It is unknown to me how pervasive the issue may be, but the model did 
go thru a WGLC before, which would've been the time for the various "network 
OS" vendors to flag issues.  Furthermore, there has been no uproar following 
your message below, in fact, I'm the first to respond.  Based on this, my 
assessment (as both Shepherd and Chair) is to proceed the document now.
 
  
 
Kent
 
  
 



 

On Nov 2, 2022, at 3:35 PM, Reshad Rahman  wrote:
 
  
 
Hi Kent,
 
  
 
It's not the text, but the way the YANG model is organized v/s rsyslog 
config+behaviour.
 
  
 
The YANG model is organized with collectors at the top. e.g. for remote 
collectors we have a list of destinations, for each destination a facility-list 
(keyed on facility + severity and ordered-by-user) and for each 
facility+severity tuple we have an action: "block" or "log".
 
  
 
rsyslog config is not organized the same way as the YANG model: it first 
matches on facility+severity and then the action is a "collector" (e.g. 
destination or logfile) or "stop". "stop" is not the equivalent of "block": 
once a "stop" is hit, the message is discarded. This means if other 
destinations were meant to receive this message, they won't.
 
  
 
So translating/mapping the YANG model to rsyslog config is problematic when 
"block" is used. As per previous disclaimer, I am no rsyslog expert. If there's 
anyone who's managed to make it work
 
  
 
And JTBC, I'm not saying the model is wrong since it probably matches how 
many/most network OSes behave.
 
  
 
Regards,
 
Reshad.
 
  
 
  
 
On Monday, October 31, 2022, 08:03:50 PM EDT, Kent Watsen 
 wrote:
 
  
 
  
 
Reshad,
 
  
 
Which text in the draft are you pointing to?
 
  
 
Thanks,
 
Kent // as Shepherd
 
  
 



 

On Oct 17, 2022, at 10:33 AM, Reshad Rahman  wrote:
 
  
 
Hi,
 
  
 
I believe this model is hard (impossible?) to implement with rsyslog since with 
rsyslog as soon as a message is blocked/discarded, no further processing of 
that message takes place (so other destinations won't get the message either). 
I don't have a solution proposal, just an observation...
 
  
 
Disclaimer: I'm not a syslog expert and I have no idea what implementations out 
there typically do.
 
  
 
Regards,
 
Reshad.
 
  
 
On Tuesday, October 11, 2022, 01:11:26 PM EDT, Joe Clarke (jclarke) 
 wrote: 
 
  
 
  
 
This revision does a few things:
 
 
 
·Addresses comment from 114 to use 
ct:asymmetric-key-pair-with-cert-grouping instead of 
ct:asymmetric-key-pair-with-certs-grouping
 
·Fix Mahesh’s email
 
·Replace obsolete RFC references
 
·Adjust some line lengths
 
 
 
This passes YANG validation and IDNITS and addresses all known open comments.
 
 
 
We’d like to ask the chairs to conduct another WG LC for this work.
 
 
 
Joe
 
 
 
From:netmod  on behalf of internet-dra...@ietf.org 

Date: Tuesday, October 11, 2022 at 13:04
To: i-d-annou...@ietf.org 
Cc: netmod@ietf.org 
Subject: [netmod] I-D Action: draft-ietf-netmod-syslog-model-28.txt
 

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

    Title   : A YANG Data Model for Syslog Configuration
    Authors : Joe Clarke
  Mahesh Jethanandani
  Clyde Wildes
  Kiran Koushik
  Filename    : draft-ietf-netmod-syslog-model-28.txt
  Pages   : 41
  Date    : 2022-10-11

Abstract:
   This document defines a YANG data model for the configuration of a
   syslog process.  It is intended this model be used by vendors who
   implement syslog in their systems.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/

There 

[netmod] ipv6-address in RFC 6991 (and bis)

[Reshad Rahman]

Hi,
Looking at the regex patterns for ipv6-address, specifically [\p{N}\p{L}], it 
allows only letters and numerical characters. So e.g '-' and '/' etc are not 
allowed even though they are commonly used in interface names. Is this an 
oversight?
Regards,Reshad. 
typedef ipv6-address {
  type string {
pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}'
  + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|'
  + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}'
  + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))'
  + '(%[\p{N}\p{L}]+)?';
pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|'
  + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'
  + '(%.+)?';
  }
  description
   "The ipv6-address type represents an IPv6 address in full,
mixed, shortened, and shortened-mixed notation.  The IPv6
address may include a zone index, separated by a % sign.

The zone index is used to disambiguate identical address
values.  For link-local addresses, the zone index will
typically be the interface index number or the name of an
interface.  If the zone index is not present, the default
zone of the device will be used.

The canonical format of IPv6 addresses uses the textual
representation defined in Section 4 of RFC 5952.  The
canonical format for the zone index is the numerical
format as described in Section 11.2 of RFC 4007.";
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-28.txt

[Reshad Rahman]

 Hi Kent,
It's not the text, but the way the YANG model is organized v/s rsyslog 
config+behaviour.
The YANG model is organized with collectors at the top. e.g. for remote 
collectors we have a list of destinations, for each destination a facility-list 
(keyed on facility + severity and ordered-by-user) and for each 
facility+severity tuple we have an action: "block" or "log".
rsyslog config is not organized the same way as the YANG model: it first 
matches on facility+severity and then the action is a "collector" (e.g. 
destination or logfile) or "stop". "stop" is not the equivalent of "block": 
once a "stop" is hit, the message is discarded. This means if other 
destinations were meant to receive this message, they won't.
So translating/mapping the YANG model to rsyslog config is problematic when 
"block" is used. As per previous disclaimer, I am no rsyslog expert. If there's 
anyone who's managed to make it work
And JTBC, I'm not saying the model is wrong since it probably matches how 
many/most network OSes behave.
Regards,Reshad.

On Monday, October 31, 2022, 08:03:50 PM EDT, Kent Watsen 
 wrote:
 
 
 Reshad,
Which text in the draft are you pointing to?
Thanks,Kent // as Shepherd


On Oct 17, 2022, at 10:33 AM, Reshad Rahman  wrote:
 Hi,
I believe this model is hard (impossible?) to implement with rsyslog since with 
rsyslog as soon as a message is blocked/discarded, no further processing of 
that message takes place (so other destinations won't get the message either). 
I don't have a solution proposal, just an observation...
Disclaimer: I'm not a syslog expert and I have no idea what implementations out 
there typically do.

Regards,Reshad.
On Tuesday, October 11, 2022, 01:11:26 PM EDT, Joe Clarke (jclarke) 
 wrote:  
 
 
This revision does a few things:
  

   - Addresses comment from 114 to use 
ct:asymmetric-key-pair-with-cert-grouping instead of 
ct:asymmetric-key-pair-with-certs-grouping
   - Fix Mahesh’s email
   - Replace obsolete RFC references
   - Adjust some line lengths
  

This passes YANG validation and IDNITS and addresses all known open comments.
  

We’d like to ask the chairs to conduct another WG LC for this work.
  

Joe
  
 
From: netmod  on behalf of internet-dra...@ietf.org 

Date: Tuesday, October 11, 2022 at 13:04
To: i-d-annou...@ietf.org 
Cc: netmod@ietf.org 
Subject: [netmod] I-D Action: draft-ietf-netmod-syslog-model-28.txt
 

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

    Title   : A YANG Data Model for Syslog Configuration
    Authors : Joe Clarke
  Mahesh Jethanandani
  Clyde Wildes
  Kiran Koushik
  Filename    : draft-ietf-netmod-syslog-model-28.txt
  Pages   : 41
  Date    : 2022-10-11

Abstract:
   This document defines a YANG data model for the configuration of a
   syslog process.  It is intended this model be used by vendors who
   implement syslog in their systems.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-syslog-model-28

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-28


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
 ___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
  

  ___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-28.txt

[Reshad Rahman]

 Hi,
I believe this model is hard (impossible?) to implement with rsyslog since with 
rsyslog as soon as a message is blocked/discarded, no further processing of 
that message takes place (so other destinations won't get the message either). 
I don't have a solution proposal, just an observation...
Disclaimer: I'm not a syslog expert and I have no idea what implementations out 
there typically do.

Regards,Reshad.
On Tuesday, October 11, 2022, 01:11:26 PM EDT, Joe Clarke (jclarke) 
 wrote:  
 
 
This revision does a few things:
 
  

   - Addresses comment from 114 to use 
ct:asymmetric-key-pair-with-cert-grouping instead of 
ct:asymmetric-key-pair-with-certs-grouping
   - Fix Mahesh’s email
   - Replace obsolete RFC references
   - Adjust some line lengths
 
  
 
This passes YANG validation and IDNITS and addresses all known open comments.
 
  
 
We’d like to ask the chairs to conduct another WG LC for this work.
 
  
 
Joe
 
  
 
From: netmod  on behalf of internet-dra...@ietf.org 

Date: Tuesday, October 11, 2022 at 13:04
To: i-d-annou...@ietf.org 
Cc: netmod@ietf.org 
Subject: [netmod] I-D Action: draft-ietf-netmod-syslog-model-28.txt
 

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

    Title   : A YANG Data Model for Syslog Configuration
    Authors : Joe Clarke
  Mahesh Jethanandani
  Clyde Wildes
  Kiran Koushik
  Filename    : draft-ietf-netmod-syslog-model-28.txt
  Pages   : 41
  Date    : 2022-10-11

Abstract:
   This document defines a YANG data model for the configuration of a
   syslog process.  It is intended this model be used by vendors who
   implement syslog in their systems.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-syslog-model-28

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-28


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
 ___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
  ___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call: draft-ietf-netmod-yang-module-versioning-05

[Reshad Rahman]

 Thank you Jürgen for the detailed review. Apologies for the delayed response, 
some of the comments have led to substantial discussions in the weekly meetings.

On Sunday, March 6, 2022, 06:08:04 AM EST, Jürgen Schönwälder 
 wrote:  
 
 Hi,

below is my last call review.

Document: draft-ietf-netmod-yang-module-versioning-05
Date: 2022-03-06

* 1. Introduction

  Is it "module lifecyle problems" or "module versioning problems"?
  Can we perhaps be even more explicit? I also note that
  [I-D.ietf-netmod-yang-solutions] has seemingly expired, perhaps this
  document is not needed if we revise the introduction a bit and make
  it more descriptive. And why are SDOs, vendors and industry
  mentioned as explicit targets? Here is an attempt to make a
  constructive proposal:

  NEW

  The current YANG [RFC7950] module update rules require that updates
  of YANG modules preserve strict backwards compatibility. This has
  caused problems as described in [I-D.ietf-netmod-yang-versioning-reqs].
  This document recognizes the need to sometimes allow YANG modules
  to evolve with non-backwards-compatible changes, which can cause
  breakage to clients and importing YANG modules.  Accepting that
  non-backwards-compatible changes do sometimes occur, it is
  important to have mechanisms to report where these changes occur,
  and to manage their effect on clients and the broader YANG
  ecosystem.

  This document defines the foundation of a flexible versioning
  solution. A companion document [I-D.ietf-netmod-yang-semver]
  extends this work by introducing a semantic versioning scheme. In
  addition, [I-D.ietf-netmod-yang-ver-selection] provides a schema
  selection scheme that can be used by clients to choose which
  schemas to use when interacting with a server from the available
  schema that are supported and advertised by the server. This builds
  on [I-D.ietf-netmod-yang-packages], which provides a mechanism to
  group sets of related YANG modules revisions together into so
  called YANG packages. Finally,
  [I-D.ietf-netmod-yang-schema-comparison] specifies an algorithm
  that can be used to compare two revisions of a YANG schema.

 We have updated text, captured in issues #145 and #146.
* 3.4.1. File names

  - This looks like a SHOULD/MAY clash, what do you really suggest
    here? Better don't use RFC 2119 language if the guideline is kind
    of contradictory. ;-)

      YANG module (or submodule) files MAY be identified using either
      revision-date or revision-label. Typically, only one file name
      SHOULD exist for the same module (or submodule) revision.  Two file
      names, one with the revision date and another with the revision
      label, MAY exist for the same module (or submodule) revision

    An implementation needs to be able to find the modules. If the
    revision date is the unique key used by imports, then probably the
    @ form needs to be there while the # form is nice to have? Well, I
    am not really sure what the text in the I-D suggests. Perhaps it
    says it SHMAY be implementation specific. ;-)

    If we want interoperability at the file name level, a clear and
    unambiguous baseline may be helpful. If we do not expect that,
    there is no need to write rules using RFC 2119 keywords.

 Yes we should remove the RFC 2119 language. We would like to keep the 
option of having the # form since having the revision in the name is 
convenient. Issue #148.
* 3.5. Examples for updating the YANG module revision history

  Assuming the 2.x line is backwards compatible but the 3.x line is
  not. How do I figure this out from the linear revision history
  sorted by dates? Is the idea that I always only have a single branch
  in the revision history in a module? Or can there be multiple
  branches documented? Can branches merge again? If I can include the
  history of multiple branches, is the idea that tools have to
  understand the semantics of the revision labels to reconstruct the
  revision history graph in order to make sense of the
  rev:non-backwards-compatible markers?  The linear order could easily
  lead to misinterpretations, revision 2019-04-01 is BC but it would
  appear in chronological order after 2019-03-01, to which it is NBC.
 We can only have 1 branch in the revision history of a specific module 
revision. If we apply changes in 1 branch to another branch (e.g. the changes 
in 2.x branch applied into the 3.x branch), it would be 1 update in the 3.x 
branch with new date and revision. We would not be getting any of the history 
from the 2.x branch.  The rev:non-backwards-compatible marker is specific 
to a particular revision in that branch. e.g if it's used with version 3.0, 
that means 3.0 is NBC with the previous revision, e.g. 2.5.3, in the linear 
history of 3.0.  It does not convey any information wrt 3.0's compatibility 
with other branches.Issue #147 for text clarification.
* 4. Import by derived revision

  I agree that import by revision or derived is b

Re: [netmod] WG Last Call: draft-ietf-netmod-yang-module-versioning-05

[Reshad Rahman]

 
Hi Jürgen,
We are still discussing some of points in your email in the weekly meeting, we 
will send a consolidated response soon.
Regards,Reshad.
On Sunday, March 6, 2022, 06:08:04 AM EST, Jürgen Schönwälder 
 wrote:  
 
 Hi,

below is my last call review.

Document: draft-ietf-netmod-yang-module-versioning-05
Date: 2022-03-06

* 1. Introduction

  Is it "module lifecyle problems" or "module versioning problems"?
  Can we perhaps be even more explicit? I also note that
  [I-D.ietf-netmod-yang-solutions] has seemingly expired, perhaps this
  document is not needed if we revise the introduction a bit and make
  it more descriptive. And why are SDOs, vendors and industry
  mentioned as explicit targets? Here is an attempt to make a
  constructive proposal:

  NEW

  The current YANG [RFC7950] module update rules require that updates
  of YANG modules preserve strict backwards compatibility. This has
  caused problems as described in [I-D.ietf-netmod-yang-versioning-reqs].
  This document recognizes the need to sometimes allow YANG modules
  to evolve with non-backwards-compatible changes, which can cause
  breakage to clients and importing YANG modules.  Accepting that
  non-backwards-compatible changes do sometimes occur, it is
  important to have mechanisms to report where these changes occur,
  and to manage their effect on clients and the broader YANG
  ecosystem.

  This document defines the foundation of a flexible versioning
  solution. A companion document [I-D.ietf-netmod-yang-semver]
  extends this work by introducing a semantic versioning scheme. In
  addition, [I-D.ietf-netmod-yang-ver-selection] provides a schema
  selection scheme that can be used by clients to choose which
  schemas to use when interacting with a server from the available
  schema that are supported and advertised by the server. This builds
  on [I-D.ietf-netmod-yang-packages], which provides a mechanism to
  group sets of related YANG modules revisions together into so
  called YANG packages. Finally,
  [I-D.ietf-netmod-yang-schema-comparison] specifies an algorithm
  that can be used to compare two revisions of a YANG schema.

* 3.4.1. File names

  - This looks like a SHOULD/MAY clash, what do you really suggest
    here? Better don't use RFC 2119 language if the guideline is kind
    of contradictory. ;-)

      YANG module (or submodule) files MAY be identified using either
      revision-date or revision-label. Typically, only one file name
      SHOULD exist for the same module (or submodule) revision.  Two file
      names, one with the revision date and another with the revision
      label, MAY exist for the same module (or submodule) revision

    An implementation needs to be able to find the modules. If the
    revision date is the unique key used by imports, then probably the
    @ form needs to be there while the # form is nice to have? Well, I
    am not really sure what the text in the I-D suggests. Perhaps it
    says it SHMAY be implementation specific. ;-)

    If we want interoperability at the file name level, a clear and
    unambiguous baseline may be helpful. If we do not expect that,
    there is no need to write rules using RFC 2119 keywords.

* 3.5. Examples for updating the YANG module revision history

  Assuming the 2.x line is backwards compatible but the 3.x line is
  not. How do I figure this out from the linear revision history
  sorted by dates? Is the idea that I always only have a single branch
  in the revision history in a module? Or can there be multiple
  branches documented? Can branches merge again? If I can include the
  history of multiple branches, is the idea that tools have to
  understand the semantics of the revision labels to reconstruct the
  revision history graph in order to make sense of the
  rev:non-backwards-compatible markers?  The linear order could easily
  lead to misinterpretations, revision 2019-04-01 is BC but it would
  appear in chronological order after 2019-03-01, to which it is NBC.

* 4. Import by derived revision

  I agree that import by revision or derived is better than import by
  revision and it would work great with the existing YANG module
  update rules. That said, I do not see how it will work great with
  update rules that allow BC and NBC updates. If we support richer
  update semantics, we will need richer mechanisms to express
  compatibility and it seems wrong to put that information into the
  YANG import statement. To me, it seems much more reasonable to
  maintain the compatibility contraints outside the module such that
  updates on the compatibility rules can be made without having to
  touch the YANG modules.

  To fully automate things, it might be desirable to actually tag the
  specific definitions that changed. When module A imports from B, it
  matters what A is using from B. Perhaps the idea is that algorithms
  compute this on the fly. I fear not all changes may be decidable to
  be either BC or NBC. Has it been considered

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Reshad Rahman]

 Rob, I think your suggestion is a good compromise.
I don't see the issue with deprecating no-zone since it can still be used.
Regards,Reshad.
On Monday, April 11, 2022, 02:43:53 PM EDT, Andy Bierman 
 wrote:  
 
 

On Mon, Apr 11, 2022 at 11:09 AM Randy Presuhn 
 wrote:

Hi -

On 2022-04-11 10:43 AM, Joel M. Halpern wrote:
> Do we have reason to believe that no one outside the IETF has used 
> ip-address as we published in ways that need a zone?

It seems like wishful thinking.  There's really no way to verify that
no one anywhere has used the specification as it was intended.

> It seems to me that the first step in the plan below is reasonable.  But

Agreed.

> changing ip-address itself seems a bad idea.  If one means no-zone, use 
> the -no-zone typedef.

I'd go further.  There are at least two bad ideas in the second step:
    (1) the incompatible change to ip-address


IMO this change aligns with the operational expectations and actual usage.To 
Acee's point, nobody has said (on this list) that they used ip-addressand 
wanted zones, or supported it.
There isn't any YANG statement (yet) that could warn the userthat a typedef is 
going to have an NBC-change in 2 years,and then another (in 2 years) stating 
the NBC change occurred.
Real code (and YANG is just more source code) needs incompatible changesonce in 
a while.  Some languages have deprecation warnings.YANG needs that, and 
hopefully the versioning work will address it.




    (2) the deprecation of ip-address-no-zone, which would trigger
        maintenance headaches for everyone who used that type
        correctly in the first place.


agreed that this does not need to be deprecated 

Hoping that Yang versioning would be able to paper over the
resulting mess strikes me as overly optimistic.



The NBC issues are real (as this thread clearly demonstrates).There are 
corner-cases where an incompatible change is the least worst solution.
 
Randy



Andy 
> Yours,
> Joel
> 
> On 4/11/2022 1:28 PM, Andy Bierman wrote:
>>
>>
>> On Mon, Apr 11, 2022 at 10:07 AM Rob Wilton (rwilton) 
>> > > wrote:
>>
>>     Hi all,
>>
>>     Thanks for the comments on this thread so far.  It would be nice if
>>     we are able to come to some sort of rough consensus to a solution.
>>
>>     I think that there is consensus that the YANG type ip-address (and
>>     the v4/v6 versions) are badly named as the prominent default type
>>     name has been given to the unusual variant of including zone
>>     information.
>>
>>     Based on the comments on this thread, it also seems likely to me
>>     that most of the usages of ip-address in YANG RFCs is likely to be
>>     wrong, and the intention was that IP addresses without zones was
>>     intended.  At a rough count, of the published RFC YANG models at
>>     github YangModels/standard/ietf/RFC/ to be:
>>          86 uses of ip-address
>>          68 uses of ipv4-address
>>          66 uses of ipv6-address
>>
>>          1 use of ip-address-no-zone
>>          4 uses of ipv4-address-no-zone
>>          4 uses of ipv6-address-no-zone
>>
>>     These types appear in 49 out of the 141 YANG modules published in
>>     RFCs.  At a quick guess/check it looks like these 49 YANG modules
>>     may appear in 40-50 RFCs.
>>
>>     As mentioned previously, it is also worth comparing this to the
>>     OpenConfig YANG modules:
>>     They have redefined ip-address (and v4/v6 variants) to exclude zone
>>     information and have defined separate types include zone information.
>>     There are no explicit uses of the "-zoned" variants of OpenConfig IP
>>     addresses in the latest OpenConfig github repository.  However,
>>     approximately a third of the IP address types are still to the
>>     ietf-inet-types.yang rather than openconfig-inet-types.yang, so in
>>     theory some of those 58 entries could still intentionally be
>>     supporting zoned IP addresses, but I would expect that the vast
>>     majority would not.
>>     I do see some strong benefit if this basic type being defined in the
>>     same way in both IETF and OC YANG, and I believe that the OC folks
>>     have got the definition right.
>>
>>     I see that some are arguing that the zone in the ip-address
>>     definition is effectively optional, and implementations are not
>>     really obliged to implement it.  I don't find that argument
>>     compelling, at least not with the current definition of ip-address
>>     in RFC 6991.  I see a clear difference between a type defined with
>>     an incomplete regex that may allow some invalid values and a type
>>     that is explicitly defined to included additional values in the
>>     allowable value space.  Further, I believe that a client just
>>     looking at the YANG module could reasonably expect a server that
>>     implements a data node using ip-address would be expected to support
>>     IP zones, where they are meaningful, or otherwi

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Reshad Rahman]

 Inline.
On Wednesday, April 6, 2022, 06:04:42 PM EDT, Acee Lindem (acee) 
 wrote:
 
 
 Hi Chris (as WG member),

On 4/5/22, 10:47 AM, "Christian Hopps"  wrote:



    > On Apr 5, 2022, at 09:48, Acee Lindem (acee)  wrote:
    > 
    > [wg-member]
    > 
    > The thing is that most of the existing RFCs use inet:ip-address rather 
inet:ip-address-no-zone. It would be better to if we could fix inet:ip-address 
in RFC 6991 BIS to not include the zone similar to what was done in the MIB 
(RFC 4001). However, we're getting the passive aggressive treatment on this 
point. 
    > 
    > If the netmod WG doesn't have the integrity and strength to fix RFC 6991 
in the BIS version, we should consider changing the OSPF and IS-IS base 
specifications before publication to use inet:ip-address-no-zone. 

    [as wg-member]

    I think we should do the right thing in our (LSR) modules no matter what, 
again, what harm does it do to get it right in the modules under LSR WGs direct 
control?

Actually this is a very bad idea. We don't want to endorse the error in RFC 
6991 that could be fixed in the BIS document. I'm certainly not going to change 
the documents I authored when the world expects an IP address to not include a 
zone. I sent an Email to the RFC 9127 BIS (which is currently in IESG review) 
authors about this issue and apparently they agree with me as they chose not to 
respond.  Just way behind on IETF emails. I can't speak for the other 
authors but I don't agree (too late). But I think we should make the change in 
9127-bis. And follow current guidelines, as others have mentioned, to tackle 
what's in 6991-bis.
Regards,Reshad.
Thanks,
Acee

    The netmod change is a much larger action with a large blast radius (not 
saying it's wrong), and perhaps most importantly is also outside of LSR WG 
control. :)

    Thanks,
    Chris.
    [wg-member]


    > Thanks,
    > Acee 
    > 
    > On 4/5/22, 9:33 AM, "Christian Hopps"  wrote:
    > 
    >    If they are new leaf values why not use the correct no-zone variant, 
what's the harm in doing it right? It has a nice side effect of basically 
restricting the base spec zone values to no-zone only. :)
    > 
    >    Thanks,
    >    Chris.
    >    [wg member]
    > 
    >> On Apr 4, 2022, at 12:30, Acee Lindem (acee) 
 wrote:
    >> 
    >> In the MIB,  the base types don't include the zone - 
https://www.ietf.org/rfc/rfc4001.txt
    >> 
    >> It was very unfortunate that the YANG IP addresses included the zone in 
the base types. 
    >> 
    >> Tom - I think it would be hard to find an author where including the 
zone was a conscious decision. 
    >> 
    >> Thanks,
    >> Acee
    >> 
    >> On 4/4/22, 11:55 AM, "tom petch"  wrote:
    >> 
    >>  From: Acee Lindem (acee) 
    >>  Sent: 04 April 2022 15:58
    >> 
    >>  Hi Tom, +Juergen, netmod WG,
    >> 
    >>  I think the question you ought to be asking is whether the base IPv4 
and IPv6 address types should be modified to NOT include the zone and the zone 
versions should be added as a separate YANG type.
    >> 
    >>  The RFC 6991 is under revision now:
    >> 
    >>  https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6991-bis/
    >> 
    >>  However, I'm not sure if the painful backward compatibility discussions 
could be overcome.  We'd also have to admit that it was a big mistake to 
include the zone in the base addresses. In any case, I don't think we just 
start using the no-zone types when the base addresses types are used everywhere.
    >> 
    >>  
    >> 
    >>  Well, there are plenty of uses of the no-zone types as well, so some 
authors, some YANG doctors, have made the conscious choice to use them.  I 
cannot do a search just now but I see no-zone in the dhc and I2NSF WG I-Ds, and 
there are others.
    >> 
    >>  Also, some authors want the zone information as part of their leaf.
    >> 
    >>  Tom Petch
    >> 
    >>  Thanks,
    >>  Acee
    >> 
    >> 
    >> 
    >>  On 4/4/22, 7:11 AM, "Lsr on behalf of tom petch"  wrote:
    >> 
    >>      I assume that this is a refresh while waiting for ospf.yang to wind 
its way through the system
    >> 
    >>      I wonder if the ip address should be the no-zone variant from 
RFC6991 - I never know the answer to that so keep asking.
    >> 
    >>      Some time the contact needs updating to https://datatracker and the 
TLP to 'Revised'
    >> 
    >>      Tom Petch
    >> 
    >>      
    >>      From: Lsr  on behalf of 
internet-dra...@ietf.org 
    >>      Sent: 07 March 2022 03:14
    >>      To: i-d-annou...@ietf.org
    >>      Cc: l...@ietf.org
    >>      Subject: [Lsr] I-D Action: 
draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
    >> 
    >> 
    >>      A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
    >>      This draft is a work item of the Link State Routing WG of the IETF.
    >> 
    >>              Title          : YANG Model for OSPFv3

Re: [netmod] Review of draft-ma-netmod-immutable-flag-00

[Reshad Rahman]

 Hi,
I went through the doc, have not reviewed it extensively but +1 to this comment 
from Balazs. I don't see the use-case for supporting this per instance either.

If we make this a schema property it can be documented in a transparent manner

with a YANG extension statement. If it is handled as instance connected metadata

the client cannot know a-priori whether a data node is or is not immutable. 
This information
is only available in runtime. System integrators, OSS developers will have a 
problem.

Regards,Reshad.
On Wednesday, March 23, 2022, 03:23:32 PM EDT, Balázs Lengyel 
 wrote:  
 
  
Hello,
 
I did a review of the immutable draft. My comments questions are below.
 
Regards Balazs
 
  
 
General)
 
I think this work is important and valuable, but it needs quite a lot 
improvements.
 
  
 
Why is immutable connected to instances. IMO it should be a schema property.
 
If we connect it to instances it is hard/impossible to specify “it is 
prohibited to create a
 
new container, list entry of leaf-list value”. That is clearly needed for the
 
capability-check use-case. Maybe allow it on both schema and instance ?
 
  
 
If we make this a schema property it can be documented in a transparent manner
 
with a YANG extension statement. If it is handled as instance connected metadata
 
the client cannot know a-priori whether a data node is or is not immutable. 
This information
 
is only available in runtime. System integrators, OSS developers will have a 
problem.
 
  
 
As immutability is connected to instance (now) this raises the question how
 
stable this property is? 
 
- We don't say anything; the server can keep it stable or make the data node
 
immutable every odd second and writable every even second
 
- The property should be relatively stable in an unspecified manner
 
- The property shall be set when the data node is created and the property
 
should not change till the data node is deleted/replaced
 
- Can the immutable property be set on just some interfaces e.g. the
 
leaf is readOnly on the CLI but writable on Netconf ?
 
If we make immutable a schema-property, the problem will not arise.
 
  
 
IMO it would be important to list the use-cases we want to solve. I provide 3 
below.
 
  
 
  
 
Ch 1) 
 
I don't like paragraph 2. Someone could say just declare the interface name
 
config=false which is a quite usual solution.
 
  
 
I would rather change the first and second paragraphs to:
 
  
 
"YANG [RFC7950] is a data modeling language used to model both state
 
and configuration data, based on the "config" statement. However there is data
 
that should not be modifiable by the client, but still needs to be declared
 
as config true. Some examples of this problem are presented below:
 
  
 
Interfaces are represented as list entries. The list schema node must be
 
defined as config=true as many of its child leaves need to be configurable by
 
the client. However the interface name and type values are set by the system,
 
based on the hardware actually present in the device, and must not be modified
 
by clients. The natural solution would be to declare the name (which is the
 
list's key) and the type as config=false. However according to the rules of
 
YANG the key leaf for a configuration list must also be config=true. Thus the
 
leaf /interfaces/interface/name is config true even if it might not be
 
writable in some systems.
 
  
 
System capabilities might be represented as system-set data nodes in the model.
 
Configurable data nodes might need constraints specified as "when", "must" or
 
"path" statements to ensure that configuration is set according to the system's
 
capabilities. E.g., 
 
- a timer can support the values 1,5,8 seconds. This is defined in the
 
leaf-list ‘supported-timer-values’. 
 
- When the configurable ‘interface-timer’ leaf is set it should be ensured that
 
one of the supported values is used. The natural solution would be to make the
 
‘interface-timer’ a leaf-ref pointing at the ‘supported-timer-values’.
 
However, this is not possible as ‘supported-timer-values’ must be readOnly thus
 
config=false while ‘interface-timer’ must be writable thus config=true.
 
According to the rules of YANG it is not allowed to put a constraint between
 
config true and false schema nodes.
 
  
 
If configuration is created by the system (e.g., copied from the 
 
datastore to the  datastore it might need to be protected. In some
 
cases there is a need to ensure that system-originated configuration shall
 
not be altered even after it is copied over to the  datastore.”
 
  
 
  
 
Ch 2)
 
"Create an immutable data node with a same value initially set by
 
  the system if it doesn't exist in the datastore, e.g., explicitly
 
  configure a system generated interface name in ;"
 
IMO this is not needed because 
 
- If the data already exists in the  datastore it cannot be
 
created according to Netconf rules. 
 
- If it does not exist in the  datastore there is n

[netmod] Conditional default values?

[Reshad Rahman]

Hi,
My understanding is that we don't have any construct to easily do conditional 
default values. e.g. let's say I want interface MTU to have default 1500 for 
all types except 1. I tried by having conditional leaf nodes (using when on 
type) but I can't have duplicate leaf-nodes in the schema, even if the 2 when 
statements can never be true at the same time. Suggestions?
Regards,Reshad.___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11

[Reshad Rahman]

 I have reviewed this document, no concerns. I believe it is ready for 
publication.
Regards,Reshad.
On Thursday, February 3, 2022, 09:54:23 PM EST, Kent Watsen 
 wrote:  
 
 Dear NETMOD WG,

This message begins a two-week WGLC for draft-ietf-netmod-rfc6991-bis-11 ending 
on Friday, February 18th.  Here is a direct link to the HTML version of the 
draft:

    https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6991-bis-11.html

Positive comments, e.g., "I've reviewed this document and believe it is ready 
for publication", are welcome!  This is useful and important, even from 
authors.  Objections, concerns, and suggestions are also welcomed at this time.

Thank you,
Kent (as co-chair)

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
  ___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Regarding IPR on Regarding IPR on draft-ietf-netmod-yang-semver-06

[Reshad Rahman]

 No, I'm not aware of any IPR that applies to this draft.

On Monday, January 31, 2022, 04:57:24 PM EST, Lou Berger  
wrote:  
 
 

Authors, Contributors, WG,

As part of WG Last Call:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate. If you are listed as a document author or contributor
please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
Lou (Co-Chair)

PS Please include all listed in the headers of this message in your
response.


  ___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Regarding IPR on draft-ietf-netmod-yang-module-versioning-05

[Reshad Rahman]

 No, I'm not aware of any IPR that applies to this draft.

On Monday, January 31, 2022, 04:54:15 PM EST, Lou Berger  
wrote:  
 
 

Authors, Contributors, WG,

As part of WG Last Call:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate. If you are listed as a document author or contributor
please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author.

NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
Lou (Co-Chair)

PS Please include all listed in the headers of this message in your
response.


  ___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-rfc6991-bis - ipv6-link-local address?

[Reshad Rahman]

 Jeff, I agree. On the previous thread no-one on NETMOD showed interest in a 
common type, I should have CCed a few routing WGs...
Regards,Reshad.
On Thursday, January 6, 2022, 05:07:07 PM EST, Jeffrey Haas 
 wrote:  
 
 Reshad,
Thanks for drawing my attention to this older thread.
It seems the method for addressing the need is understood.  I guess my request 
is to urge Jürgen and the WG to reconsider its avoidance of providing us a 
common type.  Not having multiple people reinvent this particular thing each 
time seems productive.
-- Jeff


On Jan 6, 2022, at 5:02 PM, Reshad Rahman  wrote:
 Jeff, this was brought up a few months ago (see Juergen's response): 
https://mailarchive.ietf.org/arch/msg/netmod/cRmDwqarkW2fNc2nS25zrkycQWs/




On Thursday, January 6, 2022, 04:54:22 PM EST, Jeffrey Haas 
 wrote:  
 
 Mahesh suggested I send this suggestion here.

Several IPv6 routing protocols have circumstances where the only acceptable 
address is an ipv6 link-local address.

The YANG type we have for ipv6 can accommodate ipv6 link local addresses, 
however it's overly permissive for some use cases.

Has the Working Group considered adding a typedef for ipv6 link-local?

FWIW, the current use case under consideration is operational state for BGP 
IPv6 routes conforming to RFC 2545 and related work under consideration in IDR 
for link-local only BGP peering.  In such circumstances, the BGP nexthop will 
contain a component that may only be ipv6 link-local.

For the BGP YANG module, the edits under consideration will currently use the 
ipv6 type.  Since the current use case is operational only state, the lack of 
the more restrictive type is not considered a blocker. For the future 
link-local-only work, configuration state will be needed.

-- Jeff

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
  

  ___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-rfc6991-bis - ipv6-link-local address?

[Reshad Rahman]

 Jeff, this was brought up a few months ago (see Juergen's response): 
https://mailarchive.ietf.org/arch/msg/netmod/cRmDwqarkW2fNc2nS25zrkycQWs/




On Thursday, January 6, 2022, 04:54:22 PM EST, Jeffrey Haas 
 wrote:  
 
 Mahesh suggested I send this suggestion here.

Several IPv6 routing protocols have circumstances where the only acceptable 
address is an ipv6 link-local address.

The YANG type we have for ipv6 can accommodate ipv6 link local addresses, 
however it's overly permissive for some use cases.

Has the Working Group considered adding a typedef for ipv6 link-local?

FWIW, the current use case under consideration is operational state for BGP 
IPv6 routes conforming to RFC 2545 and related work under consideration in IDR 
for link-local only BGP peering.  In such circumstances, the BGP nexthop will 
contain a component that may only be ipv6 link-local.

For the BGP YANG module, the edits under consideration will currently use the 
ipv6 type.  Since the current use case is operational only state, the lack of 
the more restrictive type is not considered a blocker. For the future 
link-local-only work, configuration state will be needed.

-- Jeff

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
  ___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Link-local address

[Reshad Rahman]

Hi,

 

Are there any defined types for V4 and V6 link-local addresses? Didn’t see a 
definition in ietf-inet-types.

 

Regards,

Reshad.

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] I-D Action: draft-ietf-netmod-yang-module-versioning-03.txt

[Reshad Rahman]

WG,

Here is a summary of the changes which went in since last rev:

1) BC/NBC rules for non config data 
(https://github.com/netmod-wg/yang-ver-dt/issues/15). We decided, based on WG 
feedback, that trying to (re)open BC/NBC for non-config nodes was out of scope 
for this document.
2) Whitespace changes in a YANG module 
(https://github.com/netmod-wg/yang-ver-dt/issues/8). See section 3.1.
3) BC/NBC impact of revision statements 
(https://github.com/netmod-wg/yang-ver-dt/issues/12). See section 3.1.1.
4) Renamed extension nbc-changes to non-backwards-compatible
5) Clarify when we can add non-backwards-compatible extension 
(https://github.com/netmod-wg/yang-ver-dt/issues/83). See section 7.
6) Mention submodules (instead of just modules) where appropriate: 
https://github.com/netmod-wg/yang-ver-dt/issues/95
7) Various editorial changes

Regards,
Reshad (on behalf of the authors/contributors).

On 2021-07-12, 2:08 PM, "netmod-boun...@ietf.org on behalf of 
internet-dra...@ietf.org"  wrote:


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Network Modeling WG of the IETF.

Title   : Updated YANG Module Revision Handling
Authors : Robert Wilton
      Reshad Rahman
  Balazs Lengyel
  Joe Clarke
  Jason Sterne
Filename: draft-ietf-netmod-yang-module-versioning-03.txt
Pages   : 40
Date: 2021-07-12

Abstract:
   This document specifies a new YANG module update procedure that can
   document when non-backwards-compatible changes have occurred during
   the evolution of a YANG module.  It extends the YANG import statement
   with an earliest revision filter to better represent inter-module
   dependencies.  It provides help and guidelines for managing the
   lifecycle of YANG modules and individual schema nodes.  It provides a
   mechanism, via the revision-label YANG extension, to specify a
   revision identifier for YANG modules and submodules.  This document
   updates RFC 7950, RFC 8407 and RFC 8525.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning/

There is also an htmlized version available at:

https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-03

A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-module-versioning-03


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Typedefs for bandwidth

[Reshad Rahman]

On 2021-05-13, 1:25 PM, "netmod on behalf of Juergen Schoenwaelder" 
 
wrote:

On Thu, May 13, 2021 at 11:57:26AM -0400, Reshad Rahman wrote:
> Hi,
> 
>  
> 
> Has there been any discussions wrt adding new  bandwidth types e.g. the 
bandwidth-xxx types in draft-ietf-teas-yang-te-types? I see RFC8294 has 
bandwidth-ieee-float32 but it doesn’t have units (Kbps/Mbps/Gbps).
> 

The description of bandwidth-ieee-float32 says:

  The units are octets per second.

Note that draft-ietf-teas-yang-te-types has been published as RFC 8776
in June 2020, it should be safe to use these definitions.

You are correct. I just wish that definition was in a "common" module instead 
of teas-te.

Regards,
Reshad.

/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/>

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Typedefs for bandwidth

[Reshad Rahman]

Hi,

 

Has there been any discussions wrt adding new  bandwidth types e.g. the 
bandwidth-xxx types in draft-ietf-teas-yang-te-types? I see RFC8294 has 
bandwidth-ieee-float32 but it doesn’t have units (Kbps/Mbps/Gbps).

 

Regards,

Reshad.

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Network Modeling (Concluded WG) ???

[Reshad Rahman]

And there I was thinking I’d have more spare time….

 

From: netmod  on behalf of "Rob Wilton (rwilton)" 

Date: Monday, April 26, 2021 at 4:31 AM
To: Balázs Lengyel , 
"'netmod@ietf.org'" 
Subject: Re: [netmod] Network Modeling (Concluded WG) ???

 

Hi Balazs,

 

I think that you can rest easy – Netmod has not been closed.

 

The link below looks fine now for me.  Are you still seeing the same page?

 

I presume that it was just a transient bug on the tools.ietf.org pages, and I 
would generally trust the datatracker pages over the “tools” ones.

 

Regards,

Rob

 

 

From: netmod  On Behalf Of Balázs Lengyel
Sent: 26 April 2021 07:47
To: 'netmod@ietf.org' 
Subject: [netmod] Network Modeling (Concluded WG) ???

 

Hello,

This is what I found today on the https://tools.ietf.org/wg/netmod/

 

Netmod Status Pages 

Network Modeling (Concluded WG)

 

What? Why ?

Regards Balazs

 

-- 

Balazs LengyelSenior Specialist   
Ericsson Hungary Ltd. 

Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

 

___ netmod mailing list 
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] draft-ietf-netmod-yang-module-versioning-02

[Reshad Rahman]

WG,

Here are the changes in this revision (various people have contributed to the 
changes after the discussions in the last 2 virtual interims).
1) Addition of backwards-compatibility rules for config false and output data 
(section 3.1.2)
2) Clarification on YANG module files: use of # in filename with revision-label 
(section 3) 
3) New text on impact of removing revisions from the revision history (section 
3.3.2)
4) New text on how adding/changing/removing "revision-xxx" sub-statements in 
import statements is considered BC (section 4)
5) Changed revision-label in the YANG module to match accepted characters
6) New text for IANA maintained YANG modules (section 11.2)

Please provide comments/feedback.

Regards,
Reshad.

On 2021-02-22, 5:30 PM, "internet-dra...@ietf.org"  
wrote:


A new version of I-D, draft-ietf-netmod-yang-module-versioning-02.txt
has been successfully submitted by Reshad Rahman and posted to the
IETF repository.

Name:   draft-ietf-netmod-yang-module-versioning
Revision:   02
Title:  Updated YANG Module Revision Handling
Document date:  2021-02-22
Group:  netmod
Pages:  40
URL:
https://www.ietf.org/archive/id/draft-ietf-netmod-yang-module-versioning-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning
Htmlized:   
https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-02
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-module-versioning-02

Abstract:
   This document specifies a new YANG module update procedure that can
   document when non-backwards-compatible changes have occurred during
   the evolution of a YANG module.  It extends the YANG import statement
   with an earliest revision filter to better represent inter-module
   dependencies.  It provides help and guidelines for managing the
   lifecycle of YANG modules and individual schema nodes.  It provides a
   mechanism, via the revision-label YANG extension, to specify a
   revision identifier for YANG modules.  This document updates RFC
   7950, RFC 8407 and RFC 8525.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-01-12

[Reshad Rahman]

Hi Joe,

 

The extra spaces are due to xml2rfc? Should we bump up the version because of 
extra white-space 😊

Section 3.3.2, good with me. Last sentence may need a small tweak, e.g s/may 
cause loss of visibility to when/may cause loss of visibility as to when/?

 

Yang-semver changes also good with me.

 

Regards,

Reshad.

 

From: netmod  on behalf of "Joe Clarke (jclarke)" 

Date: Wednesday, February 10, 2021 at 4:02 PM
To: "Sterne, Jason (Nokia - CA/Ottawa)" , 
"netmod@ietf.org" 
Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-01-12

 

On T4 (gaps in revision numbers and revision history), I have some proposed 
text for both draft-ietf-netmod-yang-module-versioning and 
draft-ietf-netmod-yang-semver.  See these diffs (some changes are due to 
xml2rfc changes, but you'll note the more substantive text additions).  
Thoughts:

module-versioning : 
https://tools.ietf.org/rfcdiff?url1=draft-ietf-netmod-yang-module-versioning&url2=https://namale.marcuscom.com/~jclarke/draft-ietf-netmod-yang-module-versioning.txt

yang-semver : 
https://tools.ietf.org/rfcdiff?url1=draft-ietf-netmod-yang-semver&url2=https://namale.marcuscom.com/~jclarke/draft-ietf-netmod-yang-semver.txt

Joe

On 1/12/21 13:43, Sterne, Jason (Nokia - CA/Ottawa) wrote:

YANG Versioning Weekly Call Minutes - 2021-01-12

 

Topics and owners for Feb virtual interim:

 

Reshad - editor for YANG versioning draft

Jason - coordinate virtual interim, agenda. Do introduction at VI.

 

T1) Definition/meaning of BC vs NBC for config false nodes

https://github.com/netmod-wg/yang-ver-dt/issues/15

- Balazs

 

T2) IANA considerations: how are final RFC revision labels assigned ?

https://github.com/netmod-wg/yang-ver-dt/issues/59

- Rob

 

T3) YANG file naming when revision labels are being used (symbolic links? 
@) ?

- Reshad to prepare material, TBD to present/lead at VI

 

T4) SemVer: gaps in history, removing revision statements

https://github.com/netmod-wg/yang-ver-dt/issues/61

- Joe

 

We spent most of the time discussing Balazs' rules for backwards compatibility 
of config false nodes (T1 above):

- clients SHOULD be able to deal with (not crash) unexpected output

- some changes to config false nodes should be BC (increasing value space 
within the same type), some will be NBC (e.g. removing mandatory, changing 
type) 

- the YANG author can mark a change that increases value space as NBC if they 
feel it is significant & breaks compatibility

 

We also talked briefly about Rob's proposal for IANA considerations (T2 above).

- we may also want some guidance for RFC editors (coordinate with authors on 
final SemVer for example)

 

Next week we'll continue focus on the four Virtual Interim topics.

 

Other topics we need to get back to at some point:

- whitespace

- github issues (left off at #15)

 

Jason

 


___ netmod mailing list 
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-02-02

[Reshad Rahman]

Tried pyang and yanglint.

pyang warns about filename: should consist of "[_A-Za-z][._\-A-Za-z0-9]*" (see 
warning below).  

yanglint warns about mismatch between filename and module name also.

Basically, both accept the characters we want to allow, they treat @ as 
delimiter for the module-name and don’t recognize # as such (as expected).

 

Regards,

Reshad 

$ pyang test#1.0.0.yang  
test#1.0.0.yang:1: warning: filename "test#1.0.0.yang" suggests invalid module 
name "test#1.0.0", should match "[_A-Za-z][._\-A-Za-z0-9]*"

$ pyang test#{1\,0\,\0}.yang 
test#{1,0,0}.yang:1: warning: filename "test#{1,0,0}.yang" suggests invalid 
module name "test#{1,0,0}", should match "[_A-Za-z][._\-A-Za-z0-9]*"

$ pyang test#{1.0.0}.yang
test#{1.0.0}.yang:1: warning: filename "test#{1.0.0}.yang" suggests invalid 
module name "test#{1.0.0}", should match "[_A-Za-z][._\-A-Za-z0-9]*"

$ pyang test#1.0.0+.yang
test#1.0.0+.yang:1: warning: filename "test#1.0.0+.yang" suggests invalid 
module name "test#1.0.0+", should match "[_A-Za-z][._\-A-Za-z0-9]*"

 

$ yanglint test#1.0.0.yang
libyang warn: File name "test#1.0.0.yang" does not match module name "test".

$ yanglint test#{1\,0\,0}.yang  
libyang warn: File name "test#{1,0,0}.yang" does not match module name "test".

$ yanglint test#{1.0.0}.yang   
libyang warn: File name "test#{1.0.0}.yang" does not match module name "test".

$ yanglint test#1.0.0+.yang  
libyang warn: File name "test#1.0.0+.yang" does not match module name "test".

 

Regards,

Reshad.

 

From: netmod  on behalf of Jan Lindblad 

Date: Wednesday, February 3, 2021 at 10:06 AM
To: "Sterne, Jason (Nokia - CA/Ottawa)" 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-02-02

 

Tried out confdc/yanger behavior with filenames containing quirky characters. 
In order to make this somewhat realistic, I used a Darwin/MacOS (utf-8 aware) 
command line invoked with "double quoted" filenames, and a Makefile to do the 
building.

 

Category 1: Characters that just work

ascii-alphabetic numerals period comma _ + - ~ @ # % ^ : { } [ ]

Anything behind the @ is not considered part of the module name

 

Category 2: Characters that need to be specifically \ escaped in the shell, but 
then work

( ) ; & *

 

Category 3: Characters that need to be doubly escaped or similar, but then work

backtick space singlequote doublequote \ | $ ! ? * < > =

 

Category 4: Characters that do not work

forwardtick slash

non-ascii alphabetical (e.g. swedish, german, japanese characters)

 

Best Regards,

/jan

 

 

 

 



On 2 Feb 2021, at 23:46, Sterne, Jason (Nokia - CA/Ottawa) 
 wrote:

 

YANG Versioning Weekly Call Minutes - 2021-02-02

 

Agenda bashing:

- quick recap on 4 topics

- status of topics from previous interim

- updates needed to yang versioning and yang semver drafts

- whitespace

- continue through Github issues

 

Deadline on draft sunmissions is 3 weeks from now.  Try to get first cut in 2 
weeks max.

 

Summary of where we left off yesterday on the Virtual Interim topics:

 

T3:

- get feedback from WG on acceptable chars (especially highlight new ones)

- no semicolon

- 2 sets of files is acceptable, but systems will work with one in general

- try with a few tools ( Reshad to try pyang and yanglint, Jan try confd which 
includes yanger,

- someone try Yuma?  (or ask Andy?)

- try google tools ?  maybe not worth it

- Reshad to update draft with weekly call group & send updated snippets to WG

 

T2:

- Lou asked to post comments on list. People happy with direction being 
proposed.

- try drafting text to indicate when IANA owns a module vs a WG

- Rob to propose text to WG

 

T1:

- nobody objected to defining NBC rules for config false

- mix of opinions still?

- deleting a leaf is NBC (to stay in sync with 7950 on this point, and likely 
more common expectations)

- decreasing value space on optional leafs is BC (but decreasing it on 
mandatory leafs is NBC ?)

- this should also be considered in YANG NEXT

- rules we define need to separate optional vs mandatory elements

- Balasz to propose specific text to weekly call group first

 

T4:

- mostly aligned with slides

- not recommended having gaps or removing history, but we won't disallow it

- Joe to propose text to WG 

 

First interim topics:

(A) import by revision or derived

- not using revision-or-derived-compatible

- impact of changing import statements: did we post back to the WG?  Said it 
was BC (but you can mark it NBC if you wanted to)

- Reshad the draft with the results

 

(B) Whitespace

 

>From the first virtual interim:

 

   JS: we need to decide if the version represents 

   the file or the underlying YANG statements

   JC: no matter what we do, we’ll need YANG-aware 

   tooling (to go to the next level of analysis to 

   see if what actually changed in the API)

   JL: time is almost up. Summary: no clear consensus

 

- got rid of

[netmod] Import issues discussed at interim on Dec 14th

[Reshad Rahman]

Thanks everyone for the feedback and comments on the mailing list and during 
the interim.

 
For the issue of revision-or-derived-compatible, there seems to be consensus 
that “revision-or-derived” is useful but compatibility constraints on imported 
modules  is better defined outside of the modules. So we will close 
https://github.com/netmod-wg/yang-ver-dt/issues/75, and open a new issue to 
look at how to define these constraints as meta-data elsewhere (e.g. in 
packages)
For https://github.com/netmod-wg/yang-ver-dt/issues/4, a change to the import 
statement is considered as backwards-compatible. There were some discussions as 
to whether there should be exceptions, but the semver draft already allows the 
major version to be bumped when all changed made are BC.
Under some circumstances (e.g., to avoid adding a "_compatible"

modifier) an artifact author MAY also update the MAJOR version

when the only changes are backwards-compatible.

 

Regards,

Reshad.

 

From: netmod  on behalf of "Sterne, Jason (Nokia - 
CA/Ottawa)" 
Date: Friday, December 11, 2020 at 2:17 PM
To: "netmod@ietf.org" 
Subject: [netmod] Materials for NETMOD Virtual Interim meeting (Monday)

 

Hi all,

 

Enclosed are the materials for the Virtual Interim on Monday.  Have a good 
weekend!

 

Rgds,

Jason

___ netmod mailing list 
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Follow-up: impact of changing an import statement

[Reshad Rahman (rrahman)]

Inline.

On 2020-08-01, 2:47 PM, "Reshad Rahman (rrahman)"  wrote:

On 2020-08-01, 1:39 AM, "Juergen Schoenwaelder" 
 wrote:

On Sat, Aug 01, 2020 at 02:51:54AM +, Reshad Rahman (rrahman) wrote:
> WG,
> 
> Following up from the discussions during NETMOD meeting on Thursday. 
One of the main open topics is what to do when an import stmt is changed, for 
example
> 
>   1.  Module A (1.0.0) imports module B using “2.0.0 or derived”. 
There is no version 3+ for module B so module A uses 2.Y.Z
>   2.  A new revision 3.0.0 of module B is created AND there is a 
change in module A to import module B using “3.0.0 or derived”.

What does "2.0.0 or derived" mean? Does it mean (i) any module >=
2.0.0 or does it mean (ii) any (module >= 2.0.0 && < 3.0.0)?
It currently means (i). Kent asked about this on slide 12 during the 
meeting stating he believes it should be (ii). My response was that this has 
been discussed among the authors and there's no  agreement among us right now. 
I think Rob W has an AI from the WG meeting on this.
 This is the email from Rob on this topic:
https://mailarchive.ietf.org/arch/msg/netmod/dGQX4jeQWjPT1TqPjk8_yjVJhFM/

Regards,
Reshad.

> Authors/contributors have discussed 2 options and right now we don’t 
have unanimity:
> 
>   1.  Option A: depending on the impact on the importing module A, 
the import-stmt is deemed BC or NBC. E.g. if the only NBC change in the  
imported module is  to a type which the importing module does NOT use, that’s a 
BC change for the importing module.
>   2.  Option B: consider the import-stmt change as a BC change and 
resolve this elsewhere e.g. YANG-Packages or YANG-Library.

Whether a change is BC or not always depends on which definitions have
changed, how they have changed, and how these definitions are used. So
the answer very likely must be option 1. Option 2 also seems to push
the problem elsewhere (packages, library) without providing the
details.
I agree.

We have discussed a bit how this would be done but that was right before 
the IETF. With YANG-Packages, the package version would be modified accordingly 
and a client would need to do schema comparison. 

Thanks for the input,
Reshad.

/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/>


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Follow-up: impact of changing an import statement

[Reshad Rahman (rrahman)]

Inline.

On 2020-08-01, 2:47 PM, "Reshad Rahman (rrahman)"  wrote:

On 2020-08-01, 1:39 AM, "Juergen Schoenwaelder" 
 wrote:

On Sat, Aug 01, 2020 at 02:51:54AM +, Reshad Rahman (rrahman) wrote:
> WG,
> 
> Following up from the discussions during NETMOD meeting on Thursday. 
One of the main open topics is what to do when an import stmt is changed, for 
example
> 
>   1.  Module A (1.0.0) imports module B using “2.0.0 or derived”. 
There is no version 3+ for module B so module A uses 2.Y.Z
>   2.  A new revision 3.0.0 of module B is created AND there is a 
change in module A to import module B using “3.0.0 or derived”.

What does "2.0.0 or derived" mean? Does it mean (i) any module >=
2.0.0 or does it mean (ii) any (module >= 2.0.0 && < 3.0.0)?
It currently means (i). Kent asked about this on slide 12 during the 
meeting stating he believes it should be (ii). My response was that this has 
been discussed among the authors and there's no  agreement among us right now. 
I think Rob W has an AI from the WG meeting on this.
This is the email from Rob on this topic.

Regards,
Reshad.

> Authors/contributors have discussed 2 options and right now we don’t 
have unanimity:
> 
>   1.  Option A: depending on the impact on the importing module A, 
the import-stmt is deemed BC or NBC. E.g. if the only NBC change in the  
imported module is  to a type which the importing module does NOT use, that’s a 
BC change for the importing module.
>   2.  Option B: consider the import-stmt change as a BC change and 
resolve this elsewhere e.g. YANG-Packages or YANG-Library.

Whether a change is BC or not always depends on which definitions have
changed, how they have changed, and how these definitions are used. So
the answer very likely must be option 1. Option 2 also seems to push
the problem elsewhere (packages, library) without providing the
details.
I agree.

We have discussed a bit how this would be done but that was right before 
the IETF. With YANG-Packages, the package version would be modified accordingly 
and a client would need to do schema comparison. 

Thanks for the input,
Reshad.

/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/>


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [yang-doctors] Yangdoctors last call review of draft-ietf-netmod-nmda-diff-04

[Reshad Rahman (rrahman)]

Looks good, no new issues.

Regards,
Reshad.

From: Yingzhen Qu 
Date: Friday, September 25, 2020 at 11:49 AM
To: "Reshad Rahman (rrahman)" , Alexander L Clemm 
, "yang-doct...@ietf.org" 
Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04

Hi Reshad,

Thanks for the link to verify JSON, it’s very helpful.

I’ve uploaded version -07. Please let me know if you have any comments.

Thanks,
Yingzhen

From: "Reshad Rahman (rrahman)" 
Date: Friday, September 25, 2020 at 8:34 AM
To: Yingzhen Qu , Alexander L Clemm 
, "yang-doct...@ietf.org" 
Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04

Hi Yingzhen,

The JSON example doesn’t seem ok because it only contains 1 edit entry. To 
confirm I went to 
https://jsonlint.com/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjsonlint.com%2F&data=02%7C01%7Cyingzhen.qu%40futurewei.com%7Ce9baa6c2aeee43ef078d08d8616872b9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637366448544225811&sdata=1MfsJLUqKllzfkYO6xAYy%2FZlOq5Prq6MHVXi1sa6VW4%3D&reserved=0>
 and it 1st complained about missing comma after the } for source-value and 
when I fixed that it complained about Duplicate key ‘edit-id’.

FYI, the JSON block below passed the lint check.

Regards,
Reshad.

  {
  "ietf-nmda-compare:output": {
"differences": {
  "ietf-yang-patch:yang-patch": {
"patch-id": "interface status",
"comment": "diff between intended (source) and 
operational",
"edit": [
 {
"edit-id": "1",
"operation": "replace",
"target": 
"/ietf-interfaces:interface=eth0/enabled",
"value": {
  "ietf-interfaces:interface/enabled": 
"false"
},
"source-value": {
  "ietf-interfaces:interface/enabled": 
"true",
  "@ietf-interfaces:interface/enabled": 
{
"ietf-origin:origin": 
"ietf-origin:learned"
  }
}
  },
  {
"edit-id": "2",
"operation": "create",
"target": 
"/ietf-interfaces:interface=eth0/description",
"value": {
  
"ietf-interface:interface/description": "ip interface"
}
  }
]
  }
}
  }
  }

From: Yingzhen Qu 
Date: Friday, September 25, 2020 at 10:47 AM
To: "Reshad Rahman (rrahman)" , Alexander L Clemm 
, "yang-doct...@ietf.org" 
Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04

Hi Reshad,

Thank you for the example. I modified the XML example as you suggested. The 
JSON example looks ok to me. Also fixed the nit to reference RFC 6991.

New generated txt file attached, please let me know if you see more issues.

Thanks,
Yingzhen

From: "Reshad Rahman (rrahman)" 
Date: Friday, September 25, 2020 at 4:58 AM
To: Yingzhen Qu , Alexander L Clemm 
, "yang-doct...@ietf.org" 
Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04

Hi Yingzhen,

Yes I believe this part is broken, since you have multiple edit-id elements for 
1 edit element, below is the YANG snippet from RFC8072.

     list edit {
   key edit-id;
   ordered-by user;

   leaf edit-id {
 type string;
 description
   "Arbitrary string index for the edit.
 

Re: [netmod] [yang-doctors] Yangdoctors last call review of draft-ietf-netmod-nmda-diff-04

[Reshad Rahman (rrahman)]

Hi Yingzhen,

The JSON example doesn’t seem ok because it only contains 1 edit entry. To 
confirm I went to https://jsonlint.com/ and it 1st complained about missing 
comma after the } for source-value and when I fixed that it complained about 
Duplicate key ‘edit-id’.

FYI, the JSON block below passed the lint check.

Regards,
Reshad.

  {
  "ietf-nmda-compare:output": {
"differences": {
  "ietf-yang-patch:yang-patch": {
"patch-id": "interface status",
"comment": "diff between intended (source) and 
operational",
"edit": [
 {
"edit-id": "1",
"operation": "replace",
"target": 
"/ietf-interfaces:interface=eth0/enabled",
"value": {
  "ietf-interfaces:interface/enabled": 
"false"
},
"source-value": {
  "ietf-interfaces:interface/enabled": 
"true",
  "@ietf-interfaces:interface/enabled": 
{
"ietf-origin:origin": 
"ietf-origin:learned"
  }
}
  },
  {
"edit-id": "2",
"operation": "create",
"target": 
"/ietf-interfaces:interface=eth0/description",
"value": {
          
"ietf-interface:interface/description": "ip interface"
}
  }
]
  }
}
  }
  }

From: Yingzhen Qu 
Date: Friday, September 25, 2020 at 10:47 AM
To: "Reshad Rahman (rrahman)" , Alexander L Clemm 
, "yang-doct...@ietf.org" 
Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04

Hi Reshad,

Thank you for the example. I modified the XML example as you suggested. The 
JSON example looks ok to me. Also fixed the nit to reference RFC 6991.

New generated txt file attached, please let me know if you see more issues.

Thanks,
Yingzhen

From: "Reshad Rahman (rrahman)" 
Date: Friday, September 25, 2020 at 4:58 AM
To: Yingzhen Qu , Alexander L Clemm 
, "yang-doct...@ietf.org" 
Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04

Hi Yingzhen,

Yes I believe this part is broken, since you have multiple edit-id elements for 
1 edit element, below is the YANG snippet from RFC8072.

 list edit {
   key edit-id;
   ordered-by user;

   leaf edit-id {
 type string;
 description
   "Arbitrary string index for the edit.
Error messages returned by the server that pertain
to a specific edit will be identified by this value.";
   }


If you take a look at A.1.1 of RFC8072, there is an example with multiple edit 
elements.

Regards,
Reshad.

From: Yingzhen Qu 
Date: Friday, September 25, 2020 at 1:07 AM
To: "Reshad Rahman (rrahman)" , Alexander L Clemm 
, "yang-doct...@ietf.org" 
Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04

Hi Reshad,

Thank you for your review.

About the example, in RFC 8072, in the list “edit”, each edit is identified by 
“edit-id”. So the example looks like:

   1
   …..
   2
  ….

Do you mean this part is broken?

Thanks,
Yingzhen

From: "Reshad Rahman (rrahman)" 
Date: Tuesday, September 22, 2020 at 6:07 AM
To: Alexander L Clemm , "yang-doct...@ietf.org" 

Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04
Resent-From: 
Resent-To:

Re: [netmod] [yang-doctors] Yangdoctors last call review of draft-ietf-netmod-nmda-diff-04

[Reshad Rahman (rrahman)]

Hi Yingzhen,

Yes I believe this part is broken, since you have multiple edit-id elements for 
1 edit element, below is the YANG snippet from RFC8072.

 list edit {
   key edit-id;
   ordered-by user;

   leaf edit-id {
 type string;
 description
   "Arbitrary string index for the edit.
Error messages returned by the server that pertain
to a specific edit will be identified by this value.";
   }


If you take a look at A.1.1 of RFC8072, there is an example with multiple edit 
elements.

Regards,
Reshad.

From: Yingzhen Qu 
Date: Friday, September 25, 2020 at 1:07 AM
To: "Reshad Rahman (rrahman)" , Alexander L Clemm 
, "yang-doct...@ietf.org" 
Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04

Hi Reshad,

Thank you for your review.

About the example, in RFC 8072, in the list “edit”, each edit is identified by 
“edit-id”. So the example looks like:

   1
   …..
   2
  ….

Do you mean this part is broken?

Thanks,
Yingzhen

From: "Reshad Rahman (rrahman)" 
Date: Tuesday, September 22, 2020 at 6:07 AM
To: Alexander L Clemm , "yang-doct...@ietf.org" 

Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04
Resent-From: 
Resent-To: , , , 
, , , 
, , , Joel Jaeggli 
, 
Resent-Date: Tuesday, September 22, 2020 at 6:07 AM

Hi Alex,

Thank you for addressing my comments.

I checked rev-06, and I believe the XML and JSON output in the example is 
broken: there is a single “edit” element with multiple “edit-id” elements. I 
believe there should be multiple “edit” elements.

The only “nit” is that leaf-xpath-filter references 6021 instead of 6991 (as 
you correctly pointed out in your response).
   leaf xpath-filter {
 if-feature nc:xpath;
 type yang:xpath1.0;
 description
   "This parameter contains an XPath expression
identifying the portions of the target
datastore to retrieve.";
 reference "RFC 6021: Common YANG Data Types";
   }

> Issues
> 1.YANG model P8, for “leaf xpath-filter”, add 
> reference to RFC6021. There should also be a normative reference to RFC6021 
> (as per RFC8407)
 Thanks.  Adding reference to 6991 (as 6021 is obsoleted). 

Regards,
Reshad.

From: Alexander L Clemm 
Date: Friday, September 18, 2020 at 3:48 PM
To: "Reshad Rahman (rrahman)" , "yang-doct...@ietf.org" 

Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff....@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04


Thank you!

I just uploaded rev -06.

--- Alex
On 9/18/2020 12:47 PM, Reshad Rahman (rrahman) wrote:
Hi Alex,

This addresses my comment/concern.

Regards,
Reshad.

From: Alexander L Clemm <mailto:lud...@clemm.org>
Date: Friday, September 18, 2020 at 3:43 PM
To: "Reshad Rahman (rrahman)" <mailto:rrah...@cisco.com>, 
"yang-doct...@ietf.org"<mailto:yang-doct...@ietf.org> 
<mailto:yang-doct...@ietf.org>
Cc: "last-c...@ietf.org"<mailto:last-c...@ietf.org> 
<mailto:last-c...@ietf.org>, 
"netmod@ietf.org"<mailto:netmod@ietf.org> 
<mailto:netmod@ietf.org>, 
"draft-ietf-netmod-nmda-diff@ietf.org"<mailto:draft-ietf-netmod-nmda-diff@ietf.org>
 
<mailto:draft-ietf-netmod-nmda-diff@ietf.org>
Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04


Hi Reshad,

okay, so let's add the following then to section 4, in the explanation of the 
"differences" output parameter:

"When a datastore node in the source of the comparison is not present in the 
target of the comparison, this can be indicated either as a "delete" or as a 
"remove" in the patch as there is no differentiation between those operations 
for the purposes of the comparison.  "

And update the description as follows:

 container differences {
  description
   "The list of differences, encoded per RFC8072 with an
 augmentation to include source values where
 applicable.  When a datastore node in the source is
 not present in the target, this can be indicated either
 as a 'delete' or as a 'remove' as there is no difference
 between them for the purposes of the comparison.&qu

Re: [netmod] [yang-doctors] Yangdoctors last call review of draft-ietf-netmod-nmda-diff-04

[Reshad Rahman (rrahman)]

Hi Alex,

Thank you for addressing my comments.

I checked rev-06, and I believe the XML and JSON output in the example is 
broken: there is a single “edit” element with multiple “edit-id” elements. I 
believe there should be multiple “edit” elements.

The only “nit” is that leaf-xpath-filter references 6021 instead of 6991 (as 
you correctly pointed out in your response).
   leaf xpath-filter {
 if-feature nc:xpath;
 type yang:xpath1.0;
 description
   "This parameter contains an XPath expression
identifying the portions of the target
datastore to retrieve.";
 reference "RFC 6021: Common YANG Data Types";
   }

> Issues
> 1.YANG model P8, for “leaf xpath-filter”, add 
> reference to RFC6021. There should also be a normative reference to RFC6021 
> (as per RFC8407)
 Thanks.  Adding reference to 6991 (as 6021 is obsoleted). 

Regards,
Reshad.

From: Alexander L Clemm 
Date: Friday, September 18, 2020 at 3:48 PM
To: "Reshad Rahman (rrahman)" , "yang-doct...@ietf.org" 

Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04


Thank you!

I just uploaded rev -06.

--- Alex
On 9/18/2020 12:47 PM, Reshad Rahman (rrahman) wrote:
Hi Alex,

This addresses my comment/concern.

Regards,
Reshad.

From: Alexander L Clemm <mailto:lud...@clemm.org>
Date: Friday, September 18, 2020 at 3:43 PM
To: "Reshad Rahman (rrahman)" <mailto:rrah...@cisco.com>, 
"yang-doct...@ietf.org"<mailto:yang-doct...@ietf.org> 
<mailto:yang-doct...@ietf.org>
Cc: "last-c...@ietf.org"<mailto:last-c...@ietf.org> 
<mailto:last-c...@ietf.org>, 
"netmod@ietf.org"<mailto:netmod@ietf.org> 
<mailto:netmod@ietf.org>, 
"draft-ietf-netmod-nmda-diff@ietf.org"<mailto:draft-ietf-netmod-nmda-diff@ietf.org>
 
<mailto:draft-ietf-netmod-nmda-diff@ietf.org>
Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04


Hi Reshad,

okay, so let's add the following then to section 4, in the explanation of the 
"differences" output parameter:

"When a datastore node in the source of the comparison is not present in the 
target of the comparison, this can be indicated either as a "delete" or as a 
"remove" in the patch as there is no differentiation between those operations 
for the purposes of the comparison.  "

And update the description as follows:

 container differences {
  description
   "The list of differences, encoded per RFC8072 with an
 augmentation to include source values where
 applicable.  When a datastore node in the source is
 not present in the target, this can be indicated either
 as a 'delete' or as a 'remove' as there is no difference
 between them for the purposes of the comparison.";
...

I will post this in a -06 shortly.  Please let us know if this addresses your 
concerns or if there is anything else.

Thanks!

--- Alex


On 9/18/2020 5:57 AM, Reshad Rahman (rrahman) wrote:
Hi Alex,

I think the only “problem” with using both “remove” and “delete” is that it 
could be confusing (when should one be used and not the other). Adding some 
text to say they’re the same for the diff operation is good enough for me.

Regards,
Reshad.

From: Alexander L Clemm <mailto:lud...@clemm.org>
Date: Tuesday, September 15, 2020 at 7:31 PM
To: "Reshad Rahman (rrahman)" <mailto:rrah...@cisco.com>, 
"yang-doct...@ietf.org"<mailto:yang-doct...@ietf.org> 
<mailto:yang-doct...@ietf.org>
Cc: "last-c...@ietf.org"<mailto:last-c...@ietf.org> 
<mailto:last-c...@ietf.org>, 
"netmod@ietf.org"<mailto:netmod@ietf.org> 
<mailto:netmod@ietf.org>, 
"draft-ietf-netmod-nmda-diff@ietf.org"<mailto:draft-ietf-netmod-nmda-diff@ietf.org>
 
<mailto:draft-ietf-netmod-nmda-diff@ietf.org>
Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04


Hi Reshad,

re: question 1: As you indicate, there may be no distinction between indicating 
a "remove" or a "delete" in the patch.  Right now it would be acceptable to 
return either.  If we want to eliminate this freedom, which one would you 
prefer be used?  Shall we remove the possibility for "delete" and just cover it 
using "remove"?

Note that the place where this is specified in the model is as part of a 
condition that specifies when the source value should b

Re: [netmod] [yang-doctors] Yangdoctors last call review of draft-ietf-netmod-nmda-diff-04

[Reshad Rahman (rrahman)]

Hi Alex,

This addresses my comment/concern.

Regards,
Reshad.

From: Alexander L Clemm 
Date: Friday, September 18, 2020 at 3:43 PM
To: "Reshad Rahman (rrahman)" , "yang-doct...@ietf.org" 

Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04


Hi Reshad,

okay, so let's add the following then to section 4, in the explanation of the 
"differences" output parameter:

"When a datastore node in the source of the comparison is not present in the 
target of the comparison, this can be indicated either as a "delete" or as a 
"remove" in the patch as there is no differentiation between those operations 
for the purposes of the comparison.  "

And update the description as follows:

 container differences {
  description
   "The list of differences, encoded per RFC8072 with an
 augmentation to include source values where
 applicable.  When a datastore node in the source is
 not present in the target, this can be indicated either
 as a 'delete' or as a 'remove' as there is no difference
 between them for the purposes of the comparison.";
...

I will post this in a -06 shortly.  Please let us know if this addresses your 
concerns or if there is anything else.

Thanks!

--- Alex


On 9/18/2020 5:57 AM, Reshad Rahman (rrahman) wrote:
Hi Alex,

I think the only “problem” with using both “remove” and “delete” is that it 
could be confusing (when should one be used and not the other). Adding some 
text to say they’re the same for the diff operation is good enough for me.

Regards,
Reshad.

From: Alexander L Clemm <mailto:lud...@clemm.org>
Date: Tuesday, September 15, 2020 at 7:31 PM
To: "Reshad Rahman (rrahman)" <mailto:rrah...@cisco.com>, 
"yang-doct...@ietf.org"<mailto:yang-doct...@ietf.org> 
<mailto:yang-doct...@ietf.org>
Cc: "last-c...@ietf.org"<mailto:last-c...@ietf.org> 
<mailto:last-c...@ietf.org>, 
"netmod@ietf.org"<mailto:netmod@ietf.org> 
<mailto:netmod@ietf.org>, 
"draft-ietf-netmod-nmda-diff@ietf.org"<mailto:draft-ietf-netmod-nmda-diff@ietf.org>
 
<mailto:draft-ietf-netmod-nmda-diff@ietf.org>
Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04


Hi Reshad,

re: question 1: As you indicate, there may be no distinction between indicating 
a "remove" or a "delete" in the patch.  Right now it would be acceptable to 
return either.  If we want to eliminate this freedom, which one would you 
prefer be used?  Shall we remove the possibility for "delete" and just cover it 
using "remove"?

Note that the place where this is specified in the model is as part of a 
condition that specifies when the source value should be included.   If we want 
to rule out that diff can return either "remove" or "delete" (indeed they are 
synonymous), we would need to add text to the container description that when a 
data object is present in the target of the comparison but not the source, that 
"remove" should be used to indicate that.

The model would be changed follows.  Please confirm if this looks good to you & 
we'll incorporate it.

OLD

   container differences {

 description

   "The list of differences, encoded per 
RFC8072<https://tools.ietf.org/html/rfc8072> with an

augmentation to include source values where

applicable.";

 uses ypatch:yang-patch {

   augment "yang-patch/edit" {

 description

   "Provide the value of the source of the patch,

respectively of the comparison, in addition to

the target value, where applicable.";

 anydata source-value {

   when "../operation = 'delete'"

 + "or ../operation = 'merge'"

 + "or ../operation = 'move'"

 + "or ../operation = 'replace'"

 + "or ../operation = 'remove'";

   description

 "The anydata 'value' is only used for 'delete',

  'move', 'merge', 'replace', and 'remove'

  operations.";

 }

 reference "RFC 8072<https://tools.ietf.org/html/rfc8072>: YANG 
Patch Media Type";

Re: [netmod] [yang-doctors] Yangdoctors last call review of draft-ietf-netmod-nmda-diff-04

[Reshad Rahman (rrahman)]

Hi Alex,

I think the only “problem” with using both “remove” and “delete” is that it 
could be confusing (when should one be used and not the other). Adding some 
text to say they’re the same for the diff operation is good enough for me.

Regards,
Reshad.

From: Alexander L Clemm 
Date: Tuesday, September 15, 2020 at 7:31 PM
To: "Reshad Rahman (rrahman)" , "yang-doct...@ietf.org" 

Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04


Hi Reshad,

re: question 1: As you indicate, there may be no distinction between indicating 
a "remove" or a "delete" in the patch.  Right now it would be acceptable to 
return either.  If we want to eliminate this freedom, which one would you 
prefer be used?  Shall we remove the possibility for "delete" and just cover it 
using "remove"?

Note that the place where this is specified in the model is as part of a 
condition that specifies when the source value should be included.   If we want 
to rule out that diff can return either "remove" or "delete" (indeed they are 
synonymous), we would need to add text to the container description that when a 
data object is present in the target of the comparison but not the source, that 
"remove" should be used to indicate that.

The model would be changed follows.  Please confirm if this looks good to you & 
we'll incorporate it.

OLD

   container differences {

 description

   "The list of differences, encoded per 
RFC8072<https://tools.ietf.org/html/rfc8072> with an

augmentation to include source values where

applicable.";

 uses ypatch:yang-patch {

   augment "yang-patch/edit" {

 description

   "Provide the value of the source of the patch,

respectively of the comparison, in addition to

the target value, where applicable.";

 anydata source-value {

   when "../operation = 'delete'"

 + "or ../operation = 'merge'"

 + "or ../operation = 'move'"

 + "or ../operation = 'replace'"

 + "or ../operation = 'remove'";

   description

 "The anydata 'value' is only used for 'delete',

  'move', 'merge', 'replace', and 'remove'

  operations.";

 }

 reference "RFC 8072<https://tools.ietf.org/html/rfc8072>: YANG 
Patch Media Type";

   }

 }

   }




NEW:

   container differences {

 description

   "The list of differences, encoded per 
RFC8072<https://tools.ietf.org/html/rfc8072> with an

augmentation to include source values where

applicable.  Where a difference include a data object

in the target that is not present in the source,

this shall be indicated as a 'remove' operation

in the patch, not as a 'delete' operation.";

 uses ypatch:yang-patch {

   augment "yang-patch/edit" {

 description

   "Provide the value of the source of the patch,

respectively of the comparison, in addition to

the target value, where applicable.";

 anydata source-value {

   when "../operation = 'merge'"

 + "or ../operation = 'move'"

 + "or ../operation = 'replace'"

 + "or ../operation = 'remove'";

   description

 "The anydata 'value' is only used for 'merge',

  'move','replace', and 'remove' operations.";

 }

 reference "RFC 8072<https://tools.ietf.org/html/rfc8072>: YANG 
Patch Media Type";

   }

 }

   }

Thanks
--- Alex

On 9/15/2020 4:04 PM, Reshad Rahman (rrahman) wrote:

Hi Alex,



I will review the latest version.



See below for questions/responses.



On 2020-09-15, 5:19 PM, "yang-doctors on behalf of Alexander L Clemm" 
<mailto:yang-doctors-bounces@ietf.orgonbehalfoflud...@clemm.org>
 wrote:

Re: [netmod] [yang-doctors] Yangdoctors last call review of draft-ietf-netmod-nmda-diff-04

[Reshad Rahman (rrahman)]

Hi Alex,

I will review the latest version.

See below for questions/responses.

On 2020-09-15, 5:19 PM, "yang-doctors on behalf of Alexander L Clemm" 
 wrote:

Hello Reshad, hello YANG Doctors,

thank you for your review!  Please find my replies inline, .  We
have also just posted -05 (thanks, Yingzhen, for doublechecking my
updates).   

--- Alex on behalf of coauthors

On 9/7/2020 7:06 AM, Reshad Rahman (rrahman) wrote:
> 
>
> Review of rev -04 by Reshad Rahman
>
> The document is clear and well-written. While some issues have been 
identified, they can be resolved quickly.
>


> Questions
>   1.  YANG model: does the operation “delete” make sense for a diff 
operation? If it is kept, it’d be good to have some text explaining that for a 
diff operation, “delete” and “replace” are the same? If they’re not the same, 
please also add some text….
 I actually meant "delete" and "remove".
 Here we are simply referring to the basic YANG-patch edit
operations per https://tools.ietf.org/html/rfc8072#page-11.  Those are
in turn derived from  operations per
https://tools.ietf.org/html/rfc6241#page-37.  I am not sure we need add
to explain those, as we are directly referring to YANG-patch. 


 The operations are indeed well defined in RFC8072 (copied below), but they 
are defined from the perspective of YANG-Patch. So for YANG-Patch "delete" and 
"remove" are different operations, but from a diff comparison I believe they 
are the same (the resource must exist since it's being returned in a diff)

   
+---+-+
   | delete| delete a data resource if it already exists; if it|
   || does not exist, return an error   
|
   ||   
   |
   | remove | remove a data resource if it already exists   |
   
+---+-+

>   3.  YANG model P9, for the “uses path:yang-patch”, why not have a  
reference to RFC8072 (is it because the description above mentions RFC8072)?
 We are clearly referencing RFC 8072; are you suggesting to put a
reference substatement below the uses statement?   It looks a little
strange to me but sure, we will add it.   
 Not needed. 

>   4.  Section 7 mentions rate limiting requests per client. Should 
there be a “global” rate-limiting too, i.e not client-specific?

 I am not sure this is really needed as I think the number of
management clients will in general be fairly limited to begin with, but
we can certainly add it.  How about the following text:

OLD:

One possibility for an implementation to mitigate against such a
possibility is to limit the number of requests that is served to a
client in any one time interval, rejecting requests made at a higher
frequency than the implementation can reasonably sustain.

NEW:

One possibility for an implementation to mitigate against such a
possibility is to limit the number of requests that is served to a
client, or to any number of clients, in any one time interval, rejecting
requests made at a higher frequency than the implementation can
reasonably sustain.
 Good with me.



>   5.  Wondering if section 8 should be in an Appendix (or even 
removed)? Also, the method suggested doesn’t seem to guarantee that the 
difference persisted for the “dampening” time.

 Personally, I do think it makes sense to include a brief
discussion of possible further extensions.  I suggest to keep the
section if it's okay with you, or perhaps leave it to the chair whether
they have a preference to remove it.  


Whatever the WG/chairs decide is fine with me.

Regards,
Reshad.


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Choice for filtering YANG imports

[Reshad Rahman (rrahman)]

Hi Rob, all,

My concern with "rev:revision-or-derived" is that an NBC change to an imported 
module can "break" the importing module without any action on the part of the 
owner of the importing module.

So yes I would want to use "rev:revision-or-compatible-derived", despite the 
coupling described below.

Regards,
Reshad.

On 2020-09-02, 7:25 AM, "netmod on behalf of Rob Wilton (rwilton)" 
 wrote:

Hi,

My second email on imports ...

RFC 7950 supports two variants of import: The default choice is import any 
revision of a module, but the revision-date substatement may be used to 
restrict the import to a single specific revision.  The "import specific 
revision" has been found to be less useful than expected and potentially 
harmful by creating tight coupling between modules and hence 
draft-ietf-netmod-yang-module-versioning-01 states that the "revision-date" 
substatement SHOULD NOT be used.


Instead, draft-ietf-netmod-yang-module-versioning-01 introduces the 
extension statement "rev:revision-or-derived -BB-CC" that specifies an 
earliest revision that may be imported.  Any module revision that included 
revision -BB-CC in the module's revision history would satisfy the import, 
regardless of whether the revision history includes non-backwards-compatible 
changes.

There have also been discussions between the authors whether to also 
introduce a separate (perhaps rev:revision-or-compatible-derived -BB-CC) 
statement that would only allow a revision to be imported if it was 
backwards-compatible with the selected earliest revision.  Specifically, during 
the import, the module would check the imported modules history to ensure that 
the "rev:nbc-changes" extension statement isn't present in the history between 
the latest revision of the module and revision -BB-CC.

Abstractly, you can consider these 4 revision options are gradually more 
restrictive subsets of revisions that could satisfy an import:
 (i) default import allows any published revision of an imported module,
 (ii) "revision-or-derived -BB-CC" reduces set (i) to only those that 
include -BB-CC in their revision history,
 (iii) "rev:revision-or-compatible-derived -BB-CC" reduces set (ii) to 
only include those that are backwards-compatible with -BB-CC,
 (iv) revision-date reduces (iii) to the set containing only the specified 
revision.

The question to the WG is whether we should also define 
"rev:revision-or-compatible-derived" now, or initially just go with 
"rev:revision-or-derived"?

The authors seem to be somewhat split on this issue.

My personal concern regarding rev:revision-or-compatible-derived is that it 
may appear to have desirable properties for module authors but still result in 
too tight coupling between modules in practice, making it harder to release NBC 
fixes, although that could presumably be mitigated by having some guideline 
text warning of the potential risks.  This extension could be defined in future 
if it turns out to be useful.

Conversely, some authors believe that this statement would be useful now to 
help more tightly constrain import dependencies, and arguably defining it now 
doesn't seem to do any real harm, and means it is available if required.

Input from the WG on this issue is welcome and desired.

Regards,
Rob

[As an individual contributor]

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [yang-doctors] Yangdoctors last call review of draft-ietf-netmod-nmda-diff-04

[Reshad Rahman (rrahman)]

Review of rev -04 by Reshad Rahman

The document is clear and well-written. While some issues have been identified, 
they can be resolved quickly.

Issues
1.  YANG model P8, for “leaf xpath-filter”, add reference to 
RFC6021. There should also be a normative reference to RFC6021 (as per RFC8407)
2.  Example P10, 
3.  Example P10, last paragraph talks about preference and 
explicit-router-id. This seems to be leftover from when the example was based 
on OSPF model.
4.  Example P12 and P13. The RPC operation has “operational” as 
source (enabled is true)  and “intended” as target (enabled is false). The 
differences shown (in RPC output) have “value true” and “source-value false”. 
But I thought value came from target datastore and source-value from source 
datastore, so the values are reversed, i.e.. it should be “value false” and 
“source-value true” instead? Looking at the origin in the output I am wondering 
if the intent is to have “intended” as source and ”operational” as target. Or 
am I misunderstanding this?

Questions
1.  YANG model: does the operation “delete” make sense for a diff 
operation? If it is kept, it’d be good to have some text explaining that for a 
diff operation, “delete” and “replace” are the same? If they’re not the same, 
please also add some text….
2.  YANG model: prefix “cp” doesn’t seem to be a great choice since 
cp is associated with copying. I realize that there is some preference for 
2-letter prefixes, but to me “cp” is not a great choice. What about “cmp”? 
WG/chairs should have a word to say about this.
3.  YANG model P9, for the “uses path:yang-patch”, why not have a  
reference to RFC8072 (is it because the description above mentions RFC8072)?
4.  Section 7 mentions rate limiting requests per client. Should 
there be a “global” rate-limiting too, i.e not client-specific?
5.  Wondering if section 8 should be in an Appendix (or even 
removed)? Also, the method suggested doesn’t seem to guarantee that the 
difference persisted for the “dampening” time.

Nits:
1.  P11 replace 

On 2020-09-06, 4:42 PM, "yang-doctors on behalf of Reshad Rahman via 
Datatracker"  
wrote:

Reviewer: Reshad Rahman
Review result: Ready with Issues

Review of rev -04 by Reshad Rahman

The document is clear and well-written. While some issues have been 
identified,
they can be resolved quickly.

Issues
1.  YANG model P8, for “leaf xpath-filter”, add reference to
RFC6021. There should also be a normative reference to RFC6021 (as 
per
RFC8407) 2.  Example P10,  3.  
   
Example P10, last paragraph talks about preference and
explicit-router-id. This seems to be leftover from when the example 
was
based on OSPF model. 4.  Example P12 and P13. The RPC operation 
has
“operational” as source (enabled is true)  and “intended” as target
(enabled is false). The differences shown (in RPC output) have 
“value
true” and “source-value false”. But I thought value came from target
datastore and source-value from source datastore, so the values are
reversed, i.e.. it should be “value false” and “source-value true”
instead? Looking at the origin in the output I am wondering if the
intent is to have “intended” as source and ”operational” as target. 
Or
am I misunderstanding this?

Questions
1.  YANG model: does the operation “delete” make sense for a 
diff
operation? If it is kept, it’d be good to have some text explaining
that for a diff operation, “delete” and “replace” are the same? If
they’re not the same, please also add some text…. 2.  YANG 
model:
prefix “cp” doesn’t seem to be a great choice since cp is associated
with copying. I realize that there is some preference for 2-letter
prefixes, but to me “cp” is not a great choice. What about “cmp”?
WG/chairs should have a word to say about this. 3.  YANG model 
P9,
for the “uses path:yang-patch”, why not have a  reference to RFC8072
(is it because the description above mentions RFC8072)? 4.  
Section
7 mentions rate limiting requests per client. Should there be a
“global” rate-limiting too, i.e not client-specific? 5.  
Wondering
if section 8 should be in an Appendix (or even removed)? Also, the
method suggested doesn’t seem to guarantee that the difference
persisted for the “dampening” time.

Nits:
1.  P11 replace 



___
yang-doctors mailing list
yang-doct...@ietf.org
https://www.ietf.org/mailman/listinfo/ya

[netmod] Yangdoctors last call review of draft-ietf-netmod-nmda-diff-04

[Reshad Rahman via Datatracker]

Reviewer: Reshad Rahman
Review result: Ready with Issues

Review of rev -04 by Reshad Rahman

The document is clear and well-written. While some issues have been identified,
they can be resolved quickly.

Issues
1.  YANG model P8, for “leaf xpath-filter”, add reference to
RFC6021. There should also be a normative reference to RFC6021 (as per
RFC8407) 2.  Example P10,  3. 
Example P10, last paragraph talks about preference and
explicit-router-id. This seems to be leftover from when the example was
based on OSPF model. 4.  Example P12 and P13. The RPC operation has
“operational” as source (enabled is true)  and “intended” as target
(enabled is false). The differences shown (in RPC output) have “value
true” and “source-value false”. But I thought value came from target
datastore and source-value from source datastore, so the values are
reversed, i.e.. it should be “value false” and “source-value true”
instead? Looking at the origin in the output I am wondering if the
intent is to have “intended” as source and ”operational” as target. Or
am I misunderstanding this?

Questions
1.  YANG model: does the operation “delete” make sense for a diff
operation? If it is kept, it’d be good to have some text explaining
that for a diff operation, “delete” and “replace” are the same? If
they’re not the same, please also add some text…. 2.  YANG model:
prefix “cp” doesn’t seem to be a great choice since cp is associated
with copying. I realize that there is some preference for 2-letter
prefixes, but to me “cp” is not a great choice. What about “cmp”?
WG/chairs should have a word to say about this. 3.  YANG model P9,
for the “uses path:yang-patch”, why not have a  reference to RFC8072
(is it because the description above mentions RFC8072)? 4.  Section
7 mentions rate limiting requests per client. Should there be a
“global” rate-limiting too, i.e not client-specific? 5.  Wondering
if section 8 should be in an Appendix (or even removed)? Also, the
method suggested doesn’t seem to guarantee that the difference
persisted for the “dampening” time.

Nits:
1.  P11 replace 



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] submodules the hidden benefits

[Reshad Rahman (rrahman)]

Indeed
https://github.com/netmod-wg/yang-next/issues/26

On 2020-08-05, 5:22 PM, "netmod on behalf of Vladimir Vassilev" 
 wrote:

On 05/08/2020 18.48, Juergen Schoenwaelder wrote:

> I personally meanwhile believe that sub-modules add complexity with
> little extra value but this view surely is not shared by others.

+1. IMO removing sub-modules from YANG 2.0 should be on the list of 
proposed changes.

/Vladimir

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Follow-up: impact of changing an import statement

[Reshad Rahman (rrahman)]

On 2020-08-01, 1:39 AM, "Juergen Schoenwaelder" 
 wrote:

On Sat, Aug 01, 2020 at 02:51:54AM +0000, Reshad Rahman (rrahman) wrote:
> WG,
> 
> Following up from the discussions during NETMOD meeting on Thursday. One 
of the main open topics is what to do when an import stmt is changed, for 
example
> 
>   1.  Module A (1.0.0) imports module B using “2.0.0 or derived”. There 
is no version 3+ for module B so module A uses 2.Y.Z
>   2.  A new revision 3.0.0 of module B is created AND there is a change 
in module A to import module B using “3.0.0 or derived”.

What does "2.0.0 or derived" mean? Does it mean (i) any module >=
2.0.0 or does it mean (ii) any (module >= 2.0.0 && < 3.0.0)?
It currently means (i). Kent asked about this on slide 12 during the meeting 
stating he believes it should be (ii). My response was that this has been 
discussed among the authors and there's no  agreement among us right now. I 
think Rob W has an AI from the WG meeting on this.
 
> Authors/contributors have discussed 2 options and right now we don’t have 
unanimity:
> 
>   1.  Option A: depending on the impact on the importing module A, the 
import-stmt is deemed BC or NBC. E.g. if the only NBC change in the  imported 
module is  to a type which the importing module does NOT use, that’s a BC 
change for the importing module.
>   2.  Option B: consider the import-stmt change as a BC change and 
resolve this elsewhere e.g. YANG-Packages or YANG-Library.

Whether a change is BC or not always depends on which definitions have
changed, how they have changed, and how these definitions are used. So
the answer very likely must be option 1. Option 2 also seems to push
the problem elsewhere (packages, library) without providing the
details.
I agree.

We have discussed a bit how this would be done but that was right before the 
IETF. With YANG-Packages, the package version would be modified accordingly and 
a client would need to do schema comparison. 

Thanks for the input,
Reshad.

/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/>

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Follow-up: impact of changing an import statement

[Reshad Rahman (rrahman)]

WG,

Following up from the discussions during NETMOD meeting on Thursday. One of the 
main open topics is what to do when an import stmt is changed, for example

  1.  Module A (1.0.0) imports module B using “2.0.0 or derived”. There is no 
version 3+ for module B so module A uses 2.Y.Z
  2.  A new revision 3.0.0 of module B is created AND there is a change in 
module A to import module B using “3.0.0 or derived”.

Authors/contributors have discussed 2 options and right now we don’t have 
unanimity:

  1.  Option A: depending on the impact on the importing module A, the 
import-stmt is deemed BC or NBC. E.g. if the only NBC change in the  imported 
module is  to a type which the importing module does NOT use, that’s a BC 
change for the importing module.
  2.  Option B: consider the import-stmt change as a BC change and resolve this 
elsewhere e.g. YANG-Packages or YANG-Library.

This was in slides 13-14 of the presentation.

Fire away….

Regards,
Reshad.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, yang:postal-code, yang:country-code

[Reshad Rahman (rrahman)]

+1



On 2020-07-30, 10:04 AM, "netmod on behalf of Juergen Schoenwaelder" 
 
wrote:

But then perhaps draft-ietf-netmod-geo-location-05 needs to be updated
or you need to use a grouping. I think we should not have overlapping
work in different documents.

/js

On Thu, Jul 30, 2020 at 01:54:43PM +, Qin Wu wrote:
> That is a good option, but draft-ietf-netmod-geo-location-05 only define 
grouping, there is typedef for longitude and latitude, altitude. 
> 
> -Qin
> -邮件原件-
> 发件人: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
> 发送时间: 2020年7月30日 21:32
> 收件人: Qin Wu 
> 抄送: netmod@ietf.org
> 主题: Re: [netmod] rfc6991bis: yang:longitude, yang:latitude, 
yang:postal-code, yang:country-code
> 
> But there is draft-ietf-netmod-geo-location-05... What about using the 
types defined in there?
> 
> /js
> 
> On Thu, Jul 30, 2020 at 01:28:17PM +, Qin Wu wrote:
> > See geolocation definition in draft-ietf-teas-yang-te-topo-22 which 
defines longitude and latitude, altitude.
> > I know it is beneficial for future document to import these types from 
rfc6991bis instead of from te topo model.
> > 
> > -Qin
> > -邮件原件-
> > 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Juergen Schoenwaelder
> > 发送时间: 2020年7月18日 3:16
> > 收件人: netmod@ietf.org
> > 主题: [netmod] rfc6991bis: yang:longitude, yang:latitude, 
> > yang:postal-code, yang:country-code
> > 
> >   - It was suggested to add types for longitude, latitude, postal
> > code, country-code. Do we go there or do we leave these for other
> > modules to define? It seems such definitions should go into
> > draft-ietf-netmod-geo-location.
> > 
> >   - Geo location is covered by draft-ietf-netmod-geo-location
> > (so do nothing).
> > 
> >   - For country codes, there is ISO 3166, which defines two-letter,
> > three-letter, and numeric country codes. I assume people wanted
> > two-letter codes (as used in the DNS), i.e. they want DE and not
> > DEU. But note that it is GB and not UK, i.e., what we commonly
> > use in the DNS may not be exactly ISO 3166. (The devil is always
> > in the details.)
> > 
> >   - For postal codes, it is unclear what the requirements are or what
> > a proper definition for postal codes is. It is not entirely clear
> > what the authoritative definition of the format of postal codes
> > is, perhaps the Universal Postal Union.
> > 
> >   - Options: (i) do nothing or (ii) add a country code definition
> > only or (iii) add both a country code definition and a postal
> > code definition (which might be to some extend vague)
> > 
> >   - Proposal: do nothing
> >   
> > -- 
> > Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103 
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] rfc6991bis: loopback addresses

[Reshad Rahman (rrahman)]

Hi,

I think what you're referring to is the use of "loopback interfaces". The 
loopback addresses Juergen was referring to do not belong to loopback 
interfaces. 

Regards,
Reshad.


On 2020-07-20, 11:30 AM, "tom petch"  wrote:

From: Reshad Rahman (rrahman) 
Sent: 20 July 2020 14:39

I don't understand the comment "...implementation choice of one 
manufacturer."


Go back to the early specifications of IPv4 routers and routing protocols, 
which are still the ones we use today, and loopback was a state into which an 
interface could be put, with a loop back in hardware or software, often used 
for testing.  A router had a router id, a 32 bit number with no syntax.  One 
major manufacturer conflated parts of this and created a virtual address  or 
addresses which could be used to send and receive packets for the router, as 
opposed to an interface on the router, which had no physical manifestation; 
fine until they called it the loopback address(es) which, sadly, caught on and 
many people, included those writing IETF I-D think that the router id can only 
be such a routable address.  Some even think that there can only be one such 
address on a box, as opposed to one for network management, one for the control 
plane and so on.  Not so.

Tom Petch.

As for the details, see 
https://tools.ietf.org/html/draft-nainar-mpls-lsp-ping-yang-00

Regards,
Reshad.


On 2020-07-20, 4:47 AM, "netmod on behalf of tom petch" 
 wrote:

I am not a fan of loopback seeing it as the implementation choice of 
one manufacturer.  On the other hand, the IETF has defined documentation 
addresses which many if not most writers of examples for YANG modules seem 
unaware of so if we add anything, I would add those.

Tom Petch

From: netmod  on behalf of Juergen 
Schoenwaelder 
Sent: 17 July 2020 20:25

  - There was a request to add types for loopback addresses
(127.0.0.0/8 and ::1/128).

  - This is related to an effort to define a YANG module for MPLS LSP
Ping (RFC 8029) but the details are unclear, i.e., what is exactly
needed and how such a type will be used and whether there is a
common need for types for loopback addresses.

  - Proposal: do not add such types at this point in time

--
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/>

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] rfc6991bis: loopback addresses

[Reshad Rahman (rrahman)]

Hi Erik,

You are correct, for IPV6 RFC8029 mentions 0:0:0:0:0::7F00:0/104.

Regards,
Reshad.

On 2020-07-20, 10:30 AM, "Erik Auerswald"  wrote:

Hello Reshad,

while the I-D draft-nainar-mpls-lsp-ping-yang-00 only specifies ::1/128
as IPv6 loopback address, RFC 8029 sections 2.1., 3.4.1.1.1., and 4.3.
specify to use the IPv4 loopback range as IP4-mapped IPv6 addresses for
IPv6 MPLS echo request UDP packets, not the IPv6 loopback address ::1/128.

This seems to be inconsistent to me.

Best regards,
Erik

On Mon, Jul 20, 2020 at 01:39:02PM +0000, Reshad Rahman (rrahman) wrote:
> I don't understand the comment "...implementation choice of one 
manufacturer."
> 
> As for the details, see 
https://tools.ietf.org/html/draft-nainar-mpls-lsp-ping-yang-00
> 
> Regards,
> Reshad.
> 
> 
> On 2020-07-20, 4:47 AM, "netmod on behalf of tom petch" 
 wrote:
> 
> I am not a fan of loopback seeing it as the implementation choice of 
one manufacturer.  On the other hand, the IETF has defined documentation 
addresses which many if not most writers of examples for YANG modules seem 
unaware of so if we add anything, I would add those.
> 
> Tom Petch
> 
> From: netmod  on behalf of Juergen 
Schoenwaelder 
> Sent: 17 July 2020 20:25
> 
>   - There was a request to add types for loopback addresses
> (127.0.0.0/8 and ::1/128).
> 
>   - This is related to an effort to define a YANG module for MPLS LSP
> Ping (RFC 8029) but the details are unclear, i.e., what is exactly
> needed and how such a type will be used and whether there is a
> common need for types for loopback addresses.
> 
>   - Proposal: do not add such types at this point in time
> 
> --
> 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/>

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] rfc6991bis: loopback addresses

[Reshad Rahman (rrahman)]

I don't understand the comment "...implementation choice of one manufacturer."

As for the details, see 
https://tools.ietf.org/html/draft-nainar-mpls-lsp-ping-yang-00

Regards,
Reshad.


On 2020-07-20, 4:47 AM, "netmod on behalf of tom petch" 
 wrote:

I am not a fan of loopback seeing it as the implementation choice of one 
manufacturer.  On the other hand, the IETF has defined documentation addresses 
which many if not most writers of examples for YANG modules seem unaware of so 
if we add anything, I would add those.

Tom Petch

From: netmod  on behalf of Juergen Schoenwaelder 

Sent: 17 July 2020 20:25

  - There was a request to add types for loopback addresses
(127.0.0.0/8 and ::1/128).

  - This is related to an effort to define a YANG module for MPLS LSP
Ping (RFC 8029) but the details are unclear, i.e., what is exactly
needed and how such a type will be used and whether there is a
common need for types for loopback addresses.

  - Proposal: do not add such types at this point in time

--
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] I-D Action: draft-ietf-netmod-yang-module-versioning-01.txt

[Reshad Rahman (rrahman)]

WG,

This revision addesses many of the comments which were provided at WG adoption. 
Of note:
- Including sub-modules by revision-date is now a SHOULD
- Clarifications on use of revision-label by submodules
- Added a revision-label-scheme extension
- Use of # in filenames with revision-label (@ for dates as currently used)
- status-description has been removed

Regards,
Reshad.

On 2020-07-10, 4:06 PM, "netmod on behalf of internet-dra...@ietf.org" 
 wrote:


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Network Modeling WG of the IETF.

Title   : Updated YANG Module Revision Handling
Authors : Robert Wilton
      Reshad Rahman
  Balazs Lengyel
  Joe Clarke
  Jason Sterne
  Benoit Claise
  Kevin D'Souza
Filename: draft-ietf-netmod-yang-module-versioning-01.txt
Pages   : 35
Date: 2020-07-10

Abstract:
   This document specifies a new YANG module update procedure that can
   document when non-backwards-compatible changes have occurred during
   the evolution of a YANG module.  It extends the YANG import statement
   with an earliest revision filter to better represent inter-module
   dependencies.  It provides help and guidelines for managing the
   lifecycle of YANG modules and individual schema nodes.  It provides a
   mechanism, via the revision-label YANG extension, to specify a
   revision identifier for YANG modules.  This document updates RFC
   7950, RFC 8407 and RFC 8525.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-01

https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-01

A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-module-versioning-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Impact of changing an import statement on YANG versioning (https://github.com/netmod-wg/yang-ver-dt/issues/4)

[Reshad Rahman (rrahman)]

Hi,

We’ve been having discussions on the impact of changing an import statement and 
would like to get thoughts from the WG.

Consider module A which imports module B.

  1.  Module A revision 1.0.0 has “revision-or-derived 1.0.0” for import of 
module B.
import moduleB {
  rev:revision-or-derived 1.0.0;
}
  2.  An update to module A so that it needs to import at least 2.0.0 of module 
B
import moduleB {
  rev:revision-or-derived 2.0.0;
}

When module’s A import is updated in step b, we’ve discussed 3 options:

  1.  Always consider the change as BC (new revision 1.1.0 for module A) and 
let the client figure out the impact on its use of module A
  2.  Always consider the change as NBC (new revision 2.0.0 for module A, tag 
the import as NBC using nbc-change extension) and let the client figure out the 
impact on its use of module A
  3.  Handle this conditionally. So if the impact on module A is NBC (depending 
on whether module A’s namespace has been impacted in NBC way),  do as in 2 
(this can have ripple effect on importing module hierarchy, e.g. module C uses 
module A, module D uses module C etc). If the impact on module A is BC, do as 
in 1

Regards,
Reshad.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Revision labels for submodules

[Reshad Rahman (rrahman)]

WG, we're in the process of updating the various drafts. So comments/ack/nack 
sooner rather than later would be very appreciated.

Regards,
Reshad.


On 2020-06-05, 3:06 PM, "Reshad Rahman (rrahman)"  wrote:

We (authors/contributors) have discussed this issue in the last couple of 
weekly meetings and come up with the following. We'd like to hear back from the 
WG before updating the draft.

For sub-modules:
1) No revision-label is OK
2) Same revision-label scheme as including module is OK, but different 
revision-label space for submodules
3) Sub-modules can use different scheme as including module. By default (no 
revision-label scheme extension statement), submodules use same scheme as 
including module. Different submodules could use different schemes.

3)  is not unanimous. Why would submodules use a different scheme as 
including module? But since allowing this seems to have a small cost, it 
doesn't seem to do any harm.

Here's the proposed text:

i) Replace MUST by SHOULD for include of submodules by revision-date.


https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-00#section-3,
 replaced MUST by SHOULD below and added some text:
   A module's name and revision date identifies a specific immutable
   definition of that module within its revision history.  Hence, if a
   module includes submodules then the module's "include" statements
   SHOULD use "revision-date" substatements to specify the exact revision
   date of each included submodule.

ADDED TEXT:
When a module does not include its submodules by revision-date,  the 
revision of submodules used cannot be derived from the including module. If the 
revision of submodules is needed, mechanisms such as YANG packages and YANG 
library can be used.


https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-00#section-7.1,
 replaced MUST by SHOULD and modified existing text as suggested in email 
discussion.
OLD TEXT:
   A module that includes submodules MUST use the "revision-date"
   substatement to include specific submodule revisions.  Changing a
   module's include statements to include different submodule revisions
   requires a new revision of the module.
NEW TEXT:
   A module that includes submodules SHOULD use the "revision-date"
   substatement to include specific submodule revisions.  The revision of 
the including
   module MUST be updated when any included submodule has changed. The
   revision-label substatement used in the new module revision MUST 
indicate the nature
   of the change, i.e. NBC, BC or editorial, to the module's schema tree.

ii) Change text which talks about revision-labels for submodules, 
https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-00#section-3.3:
OLD TEXT:
   The revision date and revision label within a submodule's revision
   history have no effect on the including module's revision.
   Submodules MUST NOT use revision label schemes that could be confused
   with the including module's revision label scheme.
NEW TEXT:
  Submodules MAY use a revision label scheme. When they use a revision
  label scheme, submodules MAY use a revision label scheme that is 
different from
  the one used in the including module.
  The revision label space of submodules is separate from the revision 
label space of the including module.
  A change in one submodule MUST result in a new revision label of that 
submodule and the including module,
  but the actual values of the revision labels in the module and submodule  
could be completely different. A
  change in one submodule does not result in a new revision label in 
another submodule. A change in a module
  revision label does not necessarily mean a change to the revision label 
in all included submodules.

Regards,
Reshad (on behalf of the group).

On 2020-05-13, 5:25 PM, "Sterne, Jason (Nokia - CA/Ottawa)" 
 wrote:

The example we've been using to discuss this is an editorial type 
change in 2 submodules (moving a leaf between them with no changes to their 
definition or the schema). 

But if we consider an example where schema actually changes (in a part 
that is defined in a submodule), then it does seem reasonable that the module 
version should also change.

So (A) is probably the right answer here.  But it does have a 
potentially confusing consequence: two YANG files could be identical except for 
an extra revision statement. It may appear that someone incorrectly bumped a 
version when there was no change, until you notice that "oh, this module 
includes submodules - one of those must have changed".

Jason

> -Original Message-
>

Re: [netmod] YANG versioning issue #48 (interpreting revision labels)

[Reshad Rahman (rrahman)]

From: "Sterne, Jason (Nokia - CA/Ottawa)" 
Date: Monday, June 22, 2020 at 2:04 PM
To: "Reshad Rahman (rrahman)" , "Joe Clarke (jclarke)" 
, "netmod@ietf.org" 
Subject: RE: YANG versioning issue #48 (interpreting revision labels)

forgot to add NETMOD…

From: Sterne, Jason (Nokia - CA/Ottawa)
Sent: Monday, June 22, 2020 2:03 PM
To: Reshad Rahman (rrahman) ; Joe Clarke (jclarke) 

Subject: YANG versioning issue #48 (interpreting revision labels)

Hi all (and particularly Reshad and Joe),

wrt github issue #48:
https://github.com/netmod-wg/yang-ver-dt/issues/48

module-versioning says this:

   All revision labels that match the pattern for the "version"
   typedef in the ietf-yang-semver YANG module MUST be interpreted as
   YANG semantic version numbers.

 Yes we had agreed to remove the above.

yang-semver says this:

   Other version schemes MUST NOT use version strings that match this
   same pattern.  For example, they may choose to use leading characters
   to distinguish themselves from YANG semver.

I'd propose we remove that text from both documents. We've decided to use an 
extension to identify the revision-label scheme in use by a module.

But we should probably add this to module-versioning:

Although an extension is used to identify which revision-label scheme is in use 
by a YANG module, any new YANG revision-label schemes being proposed SHOULD try 
to avoid patterns that are very similar to other previously existing 
standardized schemes. Being able to identify a YANG revision-label scheme by 
looking at the revision-label value is a useful property.
 Let’s discuss in tomorrow’s weekly meeting. Not sure yet this is the right 
recommendation.

Regards,
Reshad.

Jason
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] optional char in yang-semver

[Reshad Rahman (rrahman)]

I'm fine with either J1 or J2.

Regards,
Reshad.

On 2020-06-10, 5:36 PM, "netmod on behalf of Joe Clarke (jclarke)" 
 wrote:


>> 
>> ###
>> Option J1
>> ###
>> use the following suffixes:
>> _non_compatible  (instead of the old "M", for an NBC change)
>> _compatible (instead of the old "m", for a BC change)
>> 
>> e.g. for NBC:
>> 1.1.0 -> 1.1.1_non_compatible
>> e.g. for BC:
>> 1.1.0 -> 1.1.1_compatible
> 
> I like this.  It clearly shows what is meant.  No special context or
> knowledge is needed to understand the meaning, or at least to understand
> that trouble might lie ahead.

I like this, too, but I like J2 a bit better as I don’t like the double 
‘_’.  That said, I see your point about what the eye distinguishes.

Still, I can live with both, but I prefer J2.

> 
>> ###
>> Option J2
>> ###
>> - same as J1, just one fewer underscore
>> 
>> e.g. for NBC:
>> 1.1.0 -> 1.1.1_noncompatible
>> e.g. for BC:
>> 1.1.0 -> 1.1.1_compatible
> 
> I like this a little bit less than J1, because it is a little bit less
> easy to distinguish between the two words.

Joe

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Revision label in filename

[Reshad Rahman (rrahman)]

On 2020-06-11, 4:21 AM, "netmod on behalf of Jan Lindblad" 
 wrote:

Hi,

> I understand the requirement to not break what's currently working for 
date in the filename. However we do need something similar to work for 
revision-label. Having another file with the revision-label embedded in the 
filename should work. 
> 
> We discussed this issue in yesterday's weekly meeting and a proposal was 
made to use '@@' as delimiter for revision-label. # was turned down because of 
its impact on bash.

I did a quick check, and # is only treated as a comment character by bash 
when preceded by whitespace, i.e. not when used in the middle of a filename => 
I think we can drop the comment above.
Glad # works as delimiter.
If we want a filename to include multiple kinds of revision markings while 
keeping the existing tools afloat, implementing the @ notation, that might be 
achievable by picking some delimiter that is treated as a filename character by 
existing tools and placing the version label before the @. I.e. with # as the 
delimiter:

module-or-submodule-name['#'revision-label]['@'date].yang
When we discussed this on Tuesday, there was concern that some tools would 
interpret the module/submodule name as 
"module-or-submodule-name['#'revision-label]". 
My preference right now is to have 2 filenames (I realize this could also 
impact some tools), but I'll be content with any workable solution.

Regards,
Reshad.

Many other (combinations of) symbols could work, but they all run the risk 
of interfering with some tool or vendor internal CI/CD convention. A few 
examples: double underscore __, tripple dots ..., _ver_, ~, :

/jan


> So:
> module-or-submodule-name['@'date].yang (unchanged)
> module-or-submodule-name['@@'revision-label].yang
> 
> A symlink could be used, or we could have duplicate file contents.
> 
> Regards,
> Reshad.

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Revision label in filename

[Reshad Rahman (rrahman)]

Hi,

I understand the requirement to not break what's currently working for date in 
the filename. However we do need something similar to work for revision-label. 
Having another file with the revision-label embedded in the filename should 
work. 

We discussed this issue in yesterday's weekly meeting and a proposal was made 
to use '@@' as delimiter for revision-label. # was turned down because of its 
impact on bash.
So:
module-or-submodule-name['@'date].yang (unchanged)
module-or-submodule-name['@@'revision-label].yang

A symlink could be used, or we could have duplicate file contents.

Regards,
Reshad.

On 2020-05-09, 7:06 AM, "tom petch"  wrote:

From: netmod  on behalf of Reshad Rahman (rrahman) 

Sent: 08 May 2020 15:13

Hi,

We discussed using something along the lines of 
module-or-submodule-name['@'date]['#'revision-label].yang. Questions to the WG:
1) Is there a need for both date and revision-label or is one of them 
enough?


One of them is quite enough and since the date is embedded in many systems 
it would be wrong to change it.  The module name is the primary identifier of 
this bundle of definitions but it was decided that as and when there was a 
change therein then the date would provide a unique identifier for a particular 
version; nothing more is needed.  Arguably the date is more complex than is 
warranted but it has worked.  Indeed that format is now used and understood by 
such as IANA and the RFC Editor.

If you want to record more detailed semantics of the relationships between 
different versions, then put it somewhere else and leave the identifier alone, 
let the identifier be an identifier and not be overloaded with semantics.

Tom Petch








2) If we have both, what's the impact of having "#revision-label" on 
implementations which search by date?

    Regards,
Reshad.

On 2020-03-27, 5:44 PM, "netmod on behalf of Reshad Rahman (rrahman)" 
 wrote:

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/50

o  3.3

  In the filename of a YANG module, where it takes the 
form: module-
  or-submodule-name ['@' revision-label] ( '.yang' / '.yin' 
)

  Should this section update 5.2 of RFC 7950?  I know that 5.2 
just
  says "SHOULD".  But existing tools implement this SHOULD, and 
they
  need to be updated to handle this new convention.

  But I wonder if this a good idea.  It means that a tool that 
looks
  for a module with a certain revision date cannot simply check 
the
  filenames, but need to parse all available modules (wijust to 
find the

We agree that there is an impact on searching by date. We put this in 
to have the ability to search by revision-label, otherwise we can search just 
by date for a module which uses revision-label.
We had also discussed using different limiter for the label and have 
something along the lines of: 
module-or-submodule-name['@'date]['#'revision-label].yang
It'd seem that updating 7950 would be a good idea whichever way we go.

Regards,
Reshad.


On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)" 
 wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will 
kick off separate therads for each issue.


https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund" 
 wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.



o  3.1.1

o  In statements that have any data definition statements as
   substatements, those data definition substatements MAY be
   reordered, as long as they do not change the ordering or 
any "rpc"
   "input" substatements.

  I think this needs to capture that no descendant statements to
  "input" can be reordered.  Same for "output" (note, "input" 
and
  "output" in both "rpc" and "action").


o  3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be 
interpreted as
YANG semantic version numbers.

  I don't think this is a good idea.  Seems like a layer 
vi

Re: [netmod] Revision labels for submodules

[Reshad Rahman (rrahman)]

We (authors/contributors) have discussed this issue in the last couple of 
weekly meetings and come up with the following. We'd like to hear back from the 
WG before updating the draft.

For sub-modules:
1) No revision-label is OK
2) Same revision-label scheme as including module is OK, but different 
revision-label space for submodules
3) Sub-modules can use different scheme as including module. By default (no 
revision-label scheme extension statement), submodules use same scheme as 
including module. Different submodules could use different schemes.

3)  is not unanimous. Why would submodules use a different scheme as including 
module? But since allowing this seems to have a small cost, it doesn't seem to 
do any harm.

Here's the proposed text:

i) Replace MUST by SHOULD for include of submodules by revision-date.

https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-00#section-3,
 replaced MUST by SHOULD below and added some text:
   A module's name and revision date identifies a specific immutable
   definition of that module within its revision history.  Hence, if a
   module includes submodules then the module's "include" statements
   SHOULD use "revision-date" substatements to specify the exact revision
   date of each included submodule.

ADDED TEXT:
When a module does not include its submodules by revision-date,  the revision 
of submodules used cannot be derived from the including module. If the revision 
of submodules is needed, mechanisms such as YANG packages and YANG library can 
be used.

https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-00#section-7.1,
 replaced MUST by SHOULD and modified existing text as suggested in email 
discussion.
OLD TEXT:
   A module that includes submodules MUST use the "revision-date"
   substatement to include specific submodule revisions.  Changing a
   module's include statements to include different submodule revisions
   requires a new revision of the module.
NEW TEXT:
   A module that includes submodules SHOULD use the "revision-date"
   substatement to include specific submodule revisions.  The revision of the 
including
   module MUST be updated when any included submodule has changed. The
   revision-label substatement used in the new module revision MUST indicate 
the nature
   of the change, i.e. NBC, BC or editorial, to the module's schema tree.

ii) Change text which talks about revision-labels for submodules, 
https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-00#section-3.3:
OLD TEXT:
   The revision date and revision label within a submodule's revision
   history have no effect on the including module's revision.
   Submodules MUST NOT use revision label schemes that could be confused
   with the including module's revision label scheme.
NEW TEXT:
  Submodules MAY use a revision label scheme. When they use a revision
  label scheme, submodules MAY use a revision label scheme that is different 
from
  the one used in the including module.
  The revision label space of submodules is separate from the revision label 
space of the including module.
  A change in one submodule MUST result in a new revision label of that 
submodule and the including module,
  but the actual values of the revision labels in the module and submodule  
could be completely different. A
  change in one submodule does not result in a new revision label in another 
submodule. A change in a module
  revision label does not necessarily mean a change to the revision label in 
all included submodules.

Regards,
Reshad (on behalf of the group).

On 2020-05-13, 5:25 PM, "Sterne, Jason (Nokia - CA/Ottawa)" 
 wrote:

The example we've been using to discuss this is an editorial type change in 
2 submodules (moving a leaf between them with no changes to their definition or 
the schema). 

But if we consider an example where schema actually changes (in a part that 
is defined in a submodule), then it does seem reasonable that the module 
version should also change.

So (A) is probably the right answer here.  But it does have a potentially 
confusing consequence: two YANG files could be identical except for an extra 
revision statement. It may appear that someone incorrectly bumped a version 
when there was no change, until you notice that "oh, this module includes 
submodules - one of those must have changed".

Jason

> -Original Message-
> From: Reshad Rahman (rrahman) 
> Sent: Wednesday, May 13, 2020 4:52 PM
> To: Sterne, Jason (Nokia - CA/Ottawa) ; Martin
> Björklund 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Revision labels for submodules
> 
> Hi Jason,
> 
> Is your question of option A v/s B just for the case where the schema
> represented by the module does not change?
> 
> If the schema 

Re: [netmod] Revision labels for submodules

[Reshad Rahman (rrahman)]

Hi Jason,

Is your question of option A v/s B just for the case where the schema 
represented by the module does not change?

If the schema changes, even if the module didn't change, the revision-label has 
to be updated to indicate the change.
If the schema didn't change, I'd go with editorial revision-label update as (I 
think) Martin suggested.

Regards,
Reshad.

On 2020-05-13, 1:30 PM, "Sterne, Jason (Nokia - CA/Ottawa)" 
 wrote:

So that's the part I'm not sure of.

If a leaf moves between submodules, and the module file doesn't change in 
any way (as we've said is possible and should be allowed), do we mandate that 
the module version changes?  This is up to us to define IMO

(A) the module version has a scope that includes the module and all 
submodules
(B) the module version has a scope that is just the module file contents

I'm on the fence between those two. (A) could make sense but it does mean 
that someone comparing two versions of the just the module file itself may see 
no difference whatsoever between them except the addition of a new version 
statement.

Jason

    > -Original Message-
> From: Reshad Rahman (rrahman) 
> Sent: Wednesday, May 13, 2020 12:46 PM
> To: Sterne, Jason (Nokia - CA/Ottawa) ; Martin
> Björklund 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Revision labels for submodules
> 
> Hi Jason,
> 
> 
> On 2020-05-13, 11:50 AM, "Sterne, Jason (Nokia - CA/Ottawa)"
>  wrote:
> 
> Hi guys,
> 
> As someone who is heavily involved in the development of an extensive
> YANG model comprised of submodules, I'm not a fan of mandating that
> include by revision is mandatory for submodules. It may indeed be a good
> idea (so perhaps SHOULD is fine) but I can see it causing problems on the
> implementation side.
> 
> The primary development of a data model may be distributed out to
> submodules and the main module may only be a top level container for the
> submodules (and rarely touched). This would suddenly create an ordering
> dependency in the release process that requires the main module file to
> systematically be updated after all development of the submodules is 
halted.
> Then the results of the submodules has to be used to then go update the
> module. Solvable - yes, but folks who work on large scale projects will 
know
> that suddenly requiring that type of development process change isn't as
> easy as it may sound on paper.
>  I can see why you wouldn't want to modify all your include 
by-revision
> statements. But you would still need to update the module revision-label
> based on changes done in the included submodules.
> 
> Regards,
> Reshad.
> 
> It is possible to manage the "packaging" of submodules and modules out
> of band or other mechanisms.
> 
> OpenConfig, for example, uses submodules but does not currently 
include
    > by version. I'm not proposing this is ideal. But I think we should leave 
it as
> acceptable.
> 
> Rgds,
> Jason
> 
> > -Original Message-
> > From: Reshad Rahman (rrahman) 
> > Sent: Tuesday, May 12, 2020 9:46 AM
> > To: Sterne, Jason (Nokia - CA/Ottawa) ;
> Martin
> > Björklund 
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] Revision labels for submodules
> >
> > Hi Jason,
> >
> > On 2020-05-09, 12:52 PM, "Sterne, Jason (Nokia - CA/Ottawa)"
> >  wrote:
> >
> > Hi Martin,
> >
> > Your approach sounds good to me. I was forgetting about the
> "editorial"
> > level of change (e.g. the 3rd part of SemVer).  So I agree that 
moving a
> leaf
> > would be an editorial change in both submodules.
> >
> > But what if a module is not doing include by revision? It may 
indeed
> make
> > sense to include by revision but it isn't mandated. For sake of 
argument
> here
> > what if the module itself didn't change at all in this case?
> > It is now mandated in section 3 of draft-ietf-netmod-yang-module-
> > versioning-00.
> >
> >
> > It *feels* like the right thing to do here is to consider the 
module
> overall
> > to have an editorial change.
> >
> > The revi

Re: [netmod] Revision labels for submodules

[Reshad Rahman (rrahman)]

Hi Jason,


On 2020-05-13, 11:50 AM, "Sterne, Jason (Nokia - CA/Ottawa)" 
 wrote:

Hi guys,

As someone who is heavily involved in the development of an extensive YANG 
model comprised of submodules, I'm not a fan of mandating that include by 
revision is mandatory for submodules. It may indeed be a good idea (so perhaps 
SHOULD is fine) but I can see it causing problems on the implementation side. 

The primary development of a data model may be distributed out to 
submodules and the main module may only be a top level container for the 
submodules (and rarely touched). This would suddenly create an ordering 
dependency in the release process that requires the main module file to 
systematically be updated after all development of the submodules is halted. 
Then the results of the submodules has to be used to then go update the module. 
Solvable - yes, but folks who work on large scale projects will know that 
suddenly requiring that type of development process change isn't as easy as it 
may sound on paper.
 I can see why you wouldn't want to modify all your include by-revision 
statements. But you would still need to update the module revision-label based 
on changes done in the included submodules.

Regards,
Reshad.

It is possible to manage the "packaging" of submodules and modules out of 
band or other mechanisms.

OpenConfig, for example, uses submodules but does not currently include by 
version. I'm not proposing this is ideal. But I think we should leave it as 
acceptable.

Rgds,
Jason

> -----Original Message-
> From: Reshad Rahman (rrahman) 
> Sent: Tuesday, May 12, 2020 9:46 AM
> To: Sterne, Jason (Nokia - CA/Ottawa) ; Martin
> Björklund 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Revision labels for submodules
> 
> Hi Jason,
> 
> On 2020-05-09, 12:52 PM, "Sterne, Jason (Nokia - CA/Ottawa)"
>  wrote:
> 
> Hi Martin,
> 
> Your approach sounds good to me. I was forgetting about the 
"editorial"
> level of change (e.g. the 3rd part of SemVer).  So I agree that moving a 
leaf
> would be an editorial change in both submodules.
> 
> But what if a module is not doing include by revision? It may indeed 
make
> sense to include by revision but it isn't mandated. For sake of argument 
here
> what if the module itself didn't change at all in this case?
> It is now mandated in section 3 of draft-ietf-netmod-yang-module-
> versioning-00.
> 
> 
> It *feels* like the right thing to do here is to consider the module 
overall
> to have an editorial change.
> 
> The revision statement of sub-modules has a scope of the file (the 
sub-
> module). It isn't clear to me whether the revision of a *module* has a 
scope
> that includes all sub-modules or if it is just a scope of the module 
file. But we
> could clarify that as part of this work.
> Because of include by revision, the module would have to change to include
> a different revision of a sub-module.
> 
> Regards,
> Reshad.
> 
> Jason
> 
> > -Original Message-
> > From: Martin Björklund 
> > Sent: Saturday, May 9, 2020 11:54 AM
    > > To: rrah...@cisco.com
> > Cc: netmod@ietf.org; Sterne, Jason (Nokia - CA/Ottawa)
> > 
> > Subject: Re: [netmod] Revision labels for submodules
    > >
> > "Reshad Rahman (rrahman)"  wrote:
> > > Hi,
> > >
> > > On 2020-05-08, 5:12 PM, "Martin Björklund" 
> wrote:
> > >
> > > Hi,
> > >
> > > "Reshad Rahman (rrahman)"  wrote:
> > > > Hi,
> > > >
> > > > This came up during this week's meeting. We briefly 
discussed
> whether
> > > > there's a need to version sub-modules or can we restrict 
versioning
> to
> > > > modules only. We would like to hear from the WG on this,
> especially
> > > > those with experience managing sub-modules.
> > >
> > > Yes I think this is needed.  At tail-f, there are several 
modules with
> > > many submodules.  These modules always use include by 
revision,
> and
> > > always the main module is always uddated when any submodule is
> > > updated.  It doens't make much sense IMO to not use includ

Re: [netmod] Proposed YANG semver revision-label guidelines (draft-ietf-netmod-yang-semver)

[Reshad Rahman (rrahman)]

Jan, do you have an issue with the choice of the letter or its semantics? It 
has been mentioned that it's confusing to have 'm' and 'M'.

Regards,
Reshad.


On 2020-05-13, 10:45 AM, "netmod on behalf of Joe Clarke (jclarke)" 
 wrote:



> On May 13, 2020, at 10:04, Jan Lindblad  wrote:
> 
> Joe,
> 
> Thanks for sending this out to a wider audience. Sorry I missed the 
meeting yesterday. That particular time of week is very popular.
> 
> I think the text you propose below is good; I have no issues. For the 
record, I do have some issue relating to other pieces, especially around the 
use of the letter 'm'.

Thanks, Jan.  I missed the call yesterday, too, but I understand m|M is 
still being debated and there isn’t strong support of those letters 
specifically.

Joe

> 
> /jan
> 
> 
> 
>> On 12 May 2020, at 21:55, Joe Clarke (jclarke) 
 wrote:
>> 
>> There has been recent discussion about how to handle applying versions 
to new modules, modules in development, and revisions to modules that 
previously did not have a revision-label.  Below is proposed text to offer both 
general and IETF-specific guidelines for this.  The intent is to place this 
text in draft-ietf-netmod-yang-semver either as a new section 5 or a 
sub-section under section 3.  Before folding it in to the document, I wanted to 
get more WG eyes on this.
>> 
>> ===
>> 
>> X. Guidelines for Module Development
>> 
>> When developing a brand new module using YANG semver as its 
revision-label scheme SHOULD begin using a 0 for the MAJOR version component.  
This allows the module to disregard strict semver rules with respect to 
non-backwards-compatible changes during its initial development.  However, 
module developers MAY choose to use the semver pre-release syntax instead with 
a 1 for the MAJOR version component.  For example, an initial module 
revision-label might be 1.0.0-dev1.  If the authors choose to use the 0 MAJOR 
version component scheme, they MAY switch to the pre-release scheme with a 
MAJOR version component of 1 when the module is nearing initial release (e.g., 
a module's revision label may transition from 0.3.0 to 1.0.0-beta1 to indicate 
it is more mature and ready for testing).
>> 
>> When developing a new revision of an existing module using the YANG 
semver revision-label scheme, the intended target semver version MUST be used 
along with pre-release notation.  For example, if a released module which has a 
current revision-label of 1.0.0 is being modified and the intent is to make 
non-backwards-compatible changes, the first development MAJOR version component 
must be 2 with some pre-release notation such as -dev1, making the version 
2.0.0-dev1.  That said, every publicly available release of a module MUST have 
a unique YANG semver revision-label.  Therefore, it may be prudent to include 
the year or year and month development began (e.g., 2.0.0-201907-dev1).  As a 
module undegoes development, it is possible that the original intent changes.  
For example, a 1.0.0 version of a module that was destined to become 2.0.0 
after a development cycle may have had a scope change such that the final 
version has no non-backwards-compatible changes and becomes 1.1.0 instead.  Th
>> is change is acceptable to make during the development phase so long as 
pre-release notation is present in both versions (e.g., 2.0.0-dev3 becomes 
1.1.0-alpha1).  However, on the next development cycle, if again the new target 
release is 2.0.0, new pre-release components must be used such that every 
revision-label for a given module MUST be unique throughout its entire 
lifecycle (e.g., the first pre-release version might be 2.0.0-202005-dev1 if 
keeping the same year and month notation mentioned above).
>> 
>> When an existing IETF module is being revised, it MUST use the target 
version for the revision-label with a pre-release string that includes the 
current RFC number plus the string "bis".  For example, if the module defined 
in RFC at version 1.0.0 is being revised to include 
non-backwards-compatible changes, its development revision-labels MUST include 
2.0.0-bis.  Since they MUST also be unique, additional alphanumeric 
identifiers MUST be used (e.g., 2.0.0-bis-dev1).  Since each new bis will 
work off a new RFC number, this nomenclature ensures uniqueness for the module 
throughout its lifecycle.
>> 
>> If a module is being revised and the original module never had a 
revision-label (i.e., you wish to start using YANG semver in future module 
revisions), choose a semver value that makes the most sense based on the 
module's history.  For example, if a module started out in the pre-NMDA world 
and then had NMDA support added without removing any legacy "state" branches, 
and you are looking to add additional new features, a sensible choice for the 
target YANG semver would be 1.2.0 (s

Re: [netmod] Revision labels for submodules

[Reshad Rahman (rrahman)]

Hi,

On 2020-05-09, 11:57 AM, "Martin Björklund"  wrote:

Martin Björklund  wrote:
    > "Reshad Rahman (rrahman)"  wrote:
> > Hi,
> > 
> > On 2020-05-08, 5:12 PM, "Martin Björklund"  wrote:
> > 
> > Hi,
> > 
> > "Reshad Rahman (rrahman)"  wrote:
> > > Hi,
> > > 
> > > This came up during this week's meeting. We briefly discussed 
whether
> > > there's a need to version sub-modules or can we restrict 
versioning to
> > > modules only. We would like to hear from the WG on this, 
especially
> > > those with experience managing sub-modules.
> > 
> > Yes I think this is needed.  At tail-f, there are several modules 
with
> > many submodules.  These modules always use include by revision, and
> > always the main module is always uddated when any submodule is
> > updated.  It doens't make much sense IMO to not use include by
> > revision.
> > 
> > > For completeness, below is an update from Jason in github:
> > > My initial reaction is that we should not preclude the use of 
revision
> > > label with a submodule. Submodules have their own version today. 
The
> > > trick is to define (or explicitly say it is out of scope) whether 
a
> > > module version must change if any underlying submodule versions
> > > change. That gets difficult if you consider simply moving a leaf 
from
> > > one sub-module to another (without changing anything else about 
it -
> > > its context, etc).
> > 
> > Why would this be difficult?  The revision date is updated on any
> > editorial change (see 7.1.9 of RFC 7950).  So if a leaf gets moved
> > from submodule A to submodule B, then their revisions are udpated, 
and
> > hence the module's include-by revision is udpated, and hence the
> > module's revision ois updated.
> > 
> > I think what Jason meant is that by moving a leaf between submodules,
> > it's possible the module's schema didn't change.
> > So yes revision date is updated, but you can't blindly update the
> > revision-label.
> 
> Why not?

Aha, I think I understand what you mean.  And in light of Tom's
comment in the other thread, I think that using 'revision-label' in
the module and not in sub-modules makes sense.  sub-modules can still
use the date, and be included by revision (date).
    
That works and simplifies things.

Regards,
Reshad.

/martin



> 
> 
> /martin
> 
> 
> > 
> > Regards,
> > Reshad.
> > 
> > /martin
> > 
> > 
> > 
> > > 
> > > Regards,
> > > Reshad.
> > > 
> > > On 2020-03-27, 5:44 PM, "netmod on behalf of Reshad Rahman 
(rrahman)"
> > >  > > rrahman=40cisco@dmarc.ietf.org> wrote:
> > > 
> > > Hi,
> > > 
> > > https://github.com/netmod-wg/yang-ver-dt/issues/49
> > > 
> > > o  3.3
> > > 
> > > Submodules MUST NOT use revision label schemes 
that could
> > > be
> > > confused
> > > with the including module's revision label scheme.
> > > 
> > >   Hmm, how do I ensure that this MUST NOT is handled
> > >   correctly?
> > >   What
> > >   exactly does "could be confused with" mean?
> > > 
> > > Good point. What was meant by that the label space for 
modules and
> > > sub-modules are orthogonal.  e.g. the sub-module and module 
both have
> > > the same label, it shouldn't be inferred that the 2 are 
related.
> > > We'll change/clarify the text.
> > > 
> > > Regards,
> > > Reshad.
> > > 
> > > On 2020-03-20, 5:08 PM, "netmod on b

Re: [netmod] Revision labels for submodules

[Reshad Rahman (rrahman)]

Hi Jason,

On 2020-05-09, 12:52 PM, "Sterne, Jason (Nokia - CA/Ottawa)" 
 wrote:

Hi Martin,

Your approach sounds good to me. I was forgetting about the "editorial" 
level of change (e.g. the 3rd part of SemVer).  So I agree that moving a leaf 
would be an editorial change in both submodules.

But what if a module is not doing include by revision? It may indeed make 
sense to include by revision but it isn't mandated. For sake of argument here 
what if the module itself didn't change at all in this case?
It is now mandated in section 3 of draft-ietf-netmod-yang-module-versioning-00.


It *feels* like the right thing to do here is to consider the module 
overall to have an editorial change.

The revision statement of sub-modules has a scope of the file (the 
sub-module). It isn't clear to me whether the revision of a *module* has a 
scope that includes all sub-modules or if it is just a scope of the module 
file. But we could clarify that as part of this work.
Because of include by revision, the module would have to change to include a 
different revision of a sub-module.

Regards,
Reshad.

Jason

> -Original Message-
> From: Martin Björklund 
> Sent: Saturday, May 9, 2020 11:54 AM
> To: rrah...@cisco.com
> Cc: netmod@ietf.org; Sterne, Jason (Nokia - CA/Ottawa)
> 
> Subject: Re: [netmod] Revision labels for submodules
> 
> "Reshad Rahman (rrahman)"  wrote:
> > Hi,
> >
> > On 2020-05-08, 5:12 PM, "Martin Björklund"  wrote:
> >
> > Hi,
> >
> > "Reshad Rahman (rrahman)"  wrote:
> > > Hi,
> > >
> > > This came up during this week's meeting. We briefly discussed 
whether
> > > there's a need to version sub-modules or can we restrict 
versioning to
> > > modules only. We would like to hear from the WG on this, 
especially
> > > those with experience managing sub-modules.
> >
> > Yes I think this is needed.  At tail-f, there are several modules 
with
> > many submodules.  These modules always use include by revision, and
> > always the main module is always uddated when any submodule is
> > updated.  It doens't make much sense IMO to not use include by
> > revision.
> >
> > > For completeness, below is an update from Jason in github:
> > > My initial reaction is that we should not preclude the use of 
revision
> > > label with a submodule. Submodules have their own version today. 
The
> > > trick is to define (or explicitly say it is out of scope) whether 
a
> > > module version must change if any underlying submodule versions
> > > change. That gets difficult if you consider simply moving a leaf 
from
> > > one sub-module to another (without changing anything else about 
it -
> > > its context, etc).
> >
> > Why would this be difficult?  The revision date is updated on any
> > editorial change (see 7.1.9 of RFC 7950).  So if a leaf gets moved
> > from submodule A to submodule B, then their revisions are udpated, 
and
> > hence the module's include-by revision is udpated, and hence the
> > module's revision ois updated.
> >
> > I think what Jason meant is that by moving a leaf between submodules,
> > it's possible the module's schema didn't change.
> > So yes revision date is updated, but you can't blindly update the
> > revision-label.
> 
> Why not?
> 
> 
> /martin
> 
> 
> >
> > Regards,
> > Reshad.
> >
> > /martin
> >
> >
> >
> > >
> > > Regards,
> > > Reshad.
> > >
> > > On 2020-03-27, 5:44 PM, "netmod on behalf of Reshad Rahman
> (rrahman)"
> > >  > > rrahman=40cisco@dmarc.ietf.org> wrote:
> > >
> > > Hi,
> > >
> > > https://github.com/netmod-wg/yang-ver-dt/issues/49
> > >
> > > o  3.3
> > >
> > > Submodules MUST NOT use revision label schemes 
that could
> > > be
> > > confused
> > > with the including modul

Re: [netmod] Revision labels for submodules

[Reshad Rahman (rrahman)]

Hi,

On 2020-05-08, 5:12 PM, "Martin Björklund"  wrote:

Hi,

    "Reshad Rahman (rrahman)"  wrote:
> Hi,
> 
> This came up during this week's meeting. We briefly discussed whether
> there's a need to version sub-modules or can we restrict versioning to
> modules only. We would like to hear from the WG on this, especially
> those with experience managing sub-modules.

Yes I think this is needed.  At tail-f, there are several modules with
many submodules.  These modules always use include by revision, and
always the main module is always uddated when any submodule is
updated.  It doens't make much sense IMO to not use include by
revision.

> For completeness, below is an update from Jason in github:
> My initial reaction is that we should not preclude the use of revision
> label with a submodule. Submodules have their own version today. The
> trick is to define (or explicitly say it is out of scope) whether a
> module version must change if any underlying submodule versions
> change. That gets difficult if you consider simply moving a leaf from
> one sub-module to another (without changing anything else about it -
> its context, etc).

Why would this be difficult?  The revision date is updated on any
editorial change (see 7.1.9 of RFC 7950).  So if a leaf gets moved
from submodule A to submodule B, then their revisions are udpated, and
hence the module's include-by revision is udpated, and hence the
module's revision ois updated.

I think what Jason meant is that by moving a leaf between submodules, it's 
possible the module's schema didn't change.
So yes revision date is updated, but you can't blindly update the 
revision-label.

Regards,
Reshad.

/martin
    
    

> 
> Regards,
> Reshad.
> 
> On 2020-03-27, 5:44 PM, "netmod on behalf of Reshad Rahman (rrahman)"
>  rrahman=40cisco@dmarc.ietf.org> wrote:
> 
> Hi,
> 
> https://github.com/netmod-wg/yang-ver-dt/issues/49
> 
> o  3.3
> 
> Submodules MUST NOT use revision label schemes that could 
be
> confused
> with the including module's revision label scheme.
> 
>   Hmm, how do I ensure that this MUST NOT is handled 
correctly?
>   What
>   exactly does "could be confused with" mean?
> 
> Good point. What was meant by that the label space for modules and
> sub-modules are orthogonal.  e.g. the sub-module and module both have
> the same label, it shouldn't be inferred that the 2 are related.
> We'll change/clarify the text.
> 
> Regards,
> Reshad.
> 
> On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)"
>  rrahman=40cisco@dmarc.ietf.org> wrote:
> 
> Hi Martin,
> 
> We've opened issues to track your review comments (see below). 
Will
> kick off separate therads for each issue.
> 
> 
https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling
> 
> Regards,
> Reshad.
> 
> On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund"
>  wrote:
> 
> Hi,
> 
> Here are my review comments of
> draft-verdt-netmod-yang-module-versioning-01.
> 
> 
> 
> o  3.1.1
> 
> o  In statements that have any data definition statements 
as
>substatements, those data definition substatements MAY 
be
>reordered, as long as they do not change the ordering 
or
>any "rpc"
>"input" substatements.
> 
>   I think this needs to capture that no descendant statements 
to
>   "input" can be reordered.  Same for "output" (note, "input" 
and
>   "output" in both "rpc" and "action").
> 
> 
> o  3.3
> 
> All revision labels that match the pattern for the 
"version"
>

Re: [netmod] Revision label in filename

[Reshad Rahman (rrahman)]

Hi,

We discussed using something along the lines of 
module-or-submodule-name['@'date]['#'revision-label].yang. Questions to the WG:
1) Is there a need for both date and revision-label or is one of them enough?
2) If we have both, what's the impact of having "#revision-label" on 
implementations which search by date?

Regards,
Reshad.

On 2020-03-27, 5:44 PM, "netmod on behalf of Reshad Rahman (rrahman)" 
 wrote:

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/50

o  3.3

  In the filename of a YANG module, where it takes the form: 
module-
  or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

  Should this section update 5.2 of RFC 7950?  I know that 5.2 just
  says "SHOULD".  But existing tools implement this SHOULD, and they
  need to be updated to handle this new convention.

  But I wonder if this a good idea.  It means that a tool that looks
  for a module with a certain revision date cannot simply check the
  filenames, but need to parse all available modules (wijust to 
find the

We agree that there is an impact on searching by date. We put this in to 
have the ability to search by revision-label, otherwise we can search just by 
date for a module which uses revision-label.
We had also discussed using different limiter for the label and have 
something along the lines of: 
module-or-submodule-name['@'date]['#'revision-label].yang
It'd seem that updating 7950 would be a good idea whichever way we go.

Regards,
Reshad.


On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)" 
 wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will 
kick off separate therads for each issue.


https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund" 
 wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.



o  3.1.1

o  In statements that have any data definition statements as
   substatements, those data definition substatements MAY be
   reordered, as long as they do not change the ordering or any 
"rpc"
   "input" substatements.

  I think this needs to capture that no descendant statements to
  "input" can be reordered.  Same for "output" (note, "input" and
  "output" in both "rpc" and "action").


o  3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted 
as
YANG semantic version numbers.

  I don't think this is a good idea.  Seems like a layer violation.
  What if my project use another dialect of semver, that wouldn't be
  possible with this rule.  I think this needs to be removed.


o  3.3

Submodules MUST NOT use revision label schemes that could be 
confused
with the including module's revision label scheme.

  Hmm, how do I ensure that this MUST NOT is handled correctly?  
What
  exactly does "could be confused with" mean?


o  3.3

  In the filename of a YANG module, where it takes the form: 
module-
  or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

  Should this section update 5.2 of RFC 7950?  I know that 5.2 just
  says "SHOULD".  But existing tools implement this SHOULD, and they
  need to be updated to handle this new convention.

  But I wonder if this a good idea.  It means that a tool that looks
  for a module with a certain revision date cannot simply check the
  filenames, but need to parse all available modules (wijust to 
find the 



o  3.4

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   sta

Re: [netmod] Revision labels for submodules

[Reshad Rahman (rrahman)]

Hi,

This came up during this week's meeting. We briefly discussed whether there's a 
need to version sub-modules or can we restrict versioning to modules only. We 
would like to hear from the WG on this, especially those with experience 
managing sub-modules.

For completeness, below is an update from Jason in github:
My initial reaction is that we should not preclude the use of revision label 
with a submodule. Submodules have their own version today. The trick is to 
define (or explicitly say it is out of scope) whether a module version must 
change if any underlying submodule versions change. That gets difficult if you 
consider simply moving a leaf from one sub-module to another (without changing 
anything else about it - its context, etc).

Regards,
Reshad.

On 2020-03-27, 5:44 PM, "netmod on behalf of Reshad Rahman (rrahman)" 
 wrote:

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/49

o  3.3

Submodules MUST NOT use revision label schemes that could be 
confused
with the including module's revision label scheme.

  Hmm, how do I ensure that this MUST NOT is handled correctly?  
What
  exactly does "could be confused with" mean?

Good point. What was meant by that the label space for modules and 
sub-modules are orthogonal.  e.g. the sub-module and module both have the same 
label, it shouldn't be inferred that the 2 are related. 
We'll change/clarify the text.

Regards,
Reshad.

On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)" 
 wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will 
kick off separate therads for each issue.


https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund" 
 wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.



o  3.1.1

o  In statements that have any data definition statements as
   substatements, those data definition substatements MAY be
   reordered, as long as they do not change the ordering or any 
"rpc"
   "input" substatements.

  I think this needs to capture that no descendant statements to
  "input" can be reordered.  Same for "output" (note, "input" and
  "output" in both "rpc" and "action").


o  3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted 
as
YANG semantic version numbers.

  I don't think this is a good idea.  Seems like a layer violation.
  What if my project use another dialect of semver, that wouldn't be
  possible with this rule.  I think this needs to be removed.


o  3.3

Submodules MUST NOT use revision label schemes that could be 
confused
with the including module's revision label scheme.

  Hmm, how do I ensure that this MUST NOT is handled correctly?  
What
  exactly does "could be confused with" mean?


o  3.3

  In the filename of a YANG module, where it takes the form: 
module-
  or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

  Should this section update 5.2 of RFC 7950?  I know that 5.2 just
  says "SHOULD".  But existing tools implement this SHOULD, and they
  need to be updated to handle this new convention.

  But I wonder if this a good idea.  It means that a tool that looks
  for a module with a certain revision date cannot simply check the
  filenames, but need to parse all available modules (wijust to 
find the 



o  3.4

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated {
 rev:status-description
   "Imperial measurements are being phased out in favor
of their metric eq

Re: [netmod] status-description

[Reshad Rahman (rrahman)]

What are your thoughts on having description statement under status in 
yang-next? Is it the same as what you’ve stated on status-description extension?

I believe the extension is useful, although I do see the point made that an 
extra statement leads to extra complexity. But using description statement in 
yang-next should not be an issue?

Regards,
Reshad.

From: 'Andy Bierman' 
Date: Monday, May 4, 2020 at 1:32 PM
To: Martin Björklund 
Cc: Balazs Lengyel , "Reshad Rahman (rrahman)" 
, NetMod WG 
Subject: Re: [netmod] status-description



On Mon, May 4, 2020 at 9:38 AM Martin Björklund 
mailto:mbj%2bi...@4668.se>> wrote:
Hi,

Balázs Lengyel 
mailto:balazs.leng...@ericsson.com>> wrote:
> Hello,
> While status-description is not a critical part of this work, it is
> still useful, does not harm and is such a small addition, I do not
> understand why Martin objects.

Every additional statement adds to the overall complexity.  As Jason
explained, this particular statement doesn't really help much.


+1

We should not start down the path of specialized description statements.

I was part of a design team many years ago that was trying to
figure out why engineers were having so much trouble writing MIB modules.
One significant finding: people disliked working on MIBs because there were so
many special little rules (CLRs) for every little detail in the module.

IMO we are starting to make the same mistake with YANG.


/martin

Andy


>
> So why is status-description good:
> Sometimes additional information is needed about deprecation,
> obsolescence:
> - is the item still fully functional?
> - when will its functionality be removed?
> - when will the schema node itself be removed?
> - is there a replacement or workaround that could/should be used instead
> - of deprecated/obsolete item?
> The text can be used by tools. Using a separate statement to provide
> this
> information is a method to separate the main description from this
> status specific description.
> In most cases both in the CLI and on NMS GUIs only the description is
> displayed.
> However there is a possibility  to display the status information too.
>
> In a way it is similar why we have separate description, contact,
> reference, organization statements under module.
> All these are just text, they could all be pushed under a single
> description statement. Tools can't act on these automatically, still
> it is good to separate them.
>
> Regards Balazs
>
> -Original Message-
> From: netmod mailto:netmod-boun...@ietf.org>> On 
> Behalf Of Sterne, Jason
> (Nokia - CA/Ottawa)
> Sent: 2020. április 29., szerda 23:38
> To: Reshad Rahman (rrahman) 
> mailto:40cisco@dmarc.ietf.org>>;
> Martin Björklund mailto:mbj%2bi...@4668.se>>; 
> netmod@ietf.org<mailto:netmod@ietf.org>
> Subject: Re: [netmod] status-description (WAS Re: mbj review of
> draft-verdt-netmod-yang-module-versioning-01)
>
> I think we could wait until YANG 2.0 to add a description to the
> status.
>
> Without a status description, an intelligent "YANG diff" of the models
> would produce this:
> a) new status deprecated statement
> b) change to a description
>
> With a status description we'd identify this:
> a) new status deprecated statement
> b) new status description
>
> In both cases it is (a) that identifies the most clear information.
>
> In both cases (b) provides no additional information that can be acted
> upon in an automated fashion. The tool could only flag that (b)
> occurred in both cases and a human would then have to go look at it.
>
> If the only change between two versions of a module was a status
> description change, then again a human would have to take a look. If
> we add some sort of "nbc" tag to the leaf for tooling, then it also
> doesn't matter which description changed.
>
> Jason
>
>
> > -Original Message-
> > From: netmod mailto:netmod-boun...@ietf.org>> On 
> > Behalf Of Reshad Rahman
> > (rrahman)
> > Sent: Friday, March 27, 2020 5:43 PM
> > To: Martin Björklund mailto:mbj%2bi...@4668.se>>; 
> > netmod@ietf.org<mailto:netmod@ietf.org>
> > Subject: [netmod] rev:status-description (WAS Re: mbj review of
> > draft-verdt-
> > netmod-yang-module-versioning-01)
> >
> > Hi,
> >
> > https://github.com/netmod-wg/yang-ver-dt/issues/51
> >
> > o  3.4
> >
> >  leaf imperial-temperature {
> >type int64;
> >units "degrees Fahrenheit";
> >status deprecated {
> >  rev:status-description
> >

Re: [netmod] YANG action not allowed at root?

[Reshad Rahman (rrahman)]

I don’t know the history on this but the intent is to have action tied to a 
data node.

https://tools.ietf.org/html/rfc7950#section-7.15
   The difference between an action and an rpc is that an action is tied
   to a node in the datastore, whereas an rpc is not.  When an action is
   invoked, the node in the datastore is specified along with the name
   of the action and the input parameters.

Regards,
Reshad.

From: netmod  on behalf of "Sterne, Jason (Nokia - 
CA/Ottawa)" 
Date: Thursday, April 30, 2020 at 11:08 AM
To: "netmod@ietf.org" 
Subject: [netmod] YANG action not allowed at root?

Hi all,

I was a bit surprised to find this in section 7.15 of 7950 recently:

   Since an action cannot be defined at the top level of a module or in
   a "case" statement, it is an error if a grouping that contains an
   action at the top of its node hierarchy is used at the top level of a
   module or in a case definition.

I realize that actions can be placed down in a schema tree (i.e. sit in the 
context of a container or list), but why is it phrased that they *must* be in a 
container?

RPCs are limited to being at the root. I would have thought actions could be 
anywhere (root or down in the tree).

Jason


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] yang-module-versioning: revision-label scheme

[Reshad Rahman (rrahman)]

The reason we're allowing for different versioning schemes is that no single 
versioning scheme has been unanimous.  The proposal is for IETF to use 
yang-semver. Some vendors and other publishers of YANG artifacts may use 
yang-semver, while some may define their own scheme.

While this in theory allows for an open ended number of versioning schemes, I 
don't believe this will be the case. No, I'm not taking over-under bets (

Regards,
Reshad.

On 2020-04-28, 12:02 PM, "Juergen Schoenwaelder" 
 wrote:

I may be naive and not understand things correctly but an open ended
set of versioning schemes scares me. I do not see how this leads to
interoperability.

Perhaps all the versioning work should be experimental until we know
what the winning solution is?

First semver was the solution, then we got semver plus extensions,
and now we move full speed ahead to support an open ended number of
versioning schemes?

/js (who probably should have kept silent)

On Mon, Apr 27, 2020 at 03:42:04PM +, Reshad Rahman (rrahman) wrote:
> Hi,
> 
> There was a 
discussion<https://mailarchive.ietf.org/arch/browse/netmod/?q=%22Interpreting%20revision%20labels%20as%20YANG%20semantic%20version%20numbers%22>
 on the need to have an extension which specifies which versioning scheme a 
module is using.
> 
> The authors have identified 2 options:
> 
>   1.  One extension statement with a parameter which specifies the scheme 
being used. E.g. revision-label-schema(ietf-yang-semver), 
revision-label-schema(sdoX-yang). We’d need the parameter to be registered with 
IANA.
>   2.  One extension statement per revision-scheme. E.g. 
revision-label-scheme-ietf-yang-semver, revision-label-scheme-sdoX-yang.
> 
> The authors have  a preference for option 1, we believe it makes things 
simpler. We would like to hear from the WG if there’s any concerns, suggestions 
etc.
> 
> Regards,
> Reshad.

> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


-- 
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/>


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] yang-module-versioning: revision-label scheme

[Reshad Rahman (rrahman)]

Hi,

On 2020-04-28, 11:25 AM, "netmod on behalf of Martin Björklund" 
 wrote:

Hi,

    "Reshad Rahman \(rrahman\)"  wrote:
> Hi,
> 
> There was a
> 
discussion<https://mailarchive.ietf.org/arch/browse/netmod/?q=%22Interpreting%20revision%20labels%20as%20YANG%20semantic%20version%20numbers%22>
> on the need to have an extension which specifies which versioning
> scheme a module is using.
> 
> The authors have identified 2 options:
> 
>   1.  One extension statement with a parameter which specifies the
>   scheme being used.

Ok, I understand what this means...

>   E.g. revision-label-schema(ietf-yang-semver),
>   revision-label-schema(sdoX-yang).

... but I don't understand these examples.   I expected something
like:

rev:revision-label-schema yang-semver;

rev:revision-label-schema semver-2.0;
You are correct. I was just using free-form, not the correct syntax.

>   We’d need the parameter to be
>   registered with IANA.

An alternative could be to use identities:

rev:revision-label-schema ysmever:yang-semver;

rev:revision-label-schema ex:semver-2.0;
Ack, identities also came up during our discussions also. I can't think of any 
reason not to use identities in this case.

>   2.  One extension statement per
>   revision-scheme. E.g. revision-label-scheme-ietf-yang-semver,
>   revision-label-scheme-sdoX-yang.

I prefer a single statement.
Good.

Regards,
Reshad.

> The authors have a preference for option 1, we believe it makes things
> simpler. We would like to hear from the WG if there’s any concerns,
> suggestions etc.


/martin
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] yang-module-versioning: revision-label scheme

[Reshad Rahman (rrahman)]

Hi,

There was a 
discussion
 on the need to have an extension which specifies which versioning scheme a 
module is using.

The authors have identified 2 options:

  1.  One extension statement with a parameter which specifies the scheme being 
used. E.g. revision-label-schema(ietf-yang-semver), 
revision-label-schema(sdoX-yang). We’d need the parameter to be registered with 
IANA.
  2.  One extension statement per revision-scheme. E.g. 
revision-label-scheme-ietf-yang-semver, revision-label-scheme-sdoX-yang.

The authors have  a preference for option 1, we believe it makes things 
simpler. We would like to hear from the WG if there’s any concerns, suggestions 
etc.

Regards,
Reshad.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

[Reshad Rahman (rrahman)]

Makes sense, it’s good with me.

Regards,
Reshad.

From: netmod  on behalf of "Rob Wilton (rwilton)" 

Date: Friday, April 24, 2020 at 3:34 PM
To: Kent Watsen , "netmod@ietf.org" 
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

Hi Kent,

Thanks for creating the issue.

I think that errata falls under section 7 of 
https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/, and 
could be classified as “Hold for Document Update”.  I.e. “Changes that modify 
the working of a protocol to something that might be different from the 
intended consensus when the document was approved should be either Hold for 
Document Update or Rejected. Deciding between these two depends on judgment. 
Changes that are clearly modifications to the intended consensus, or involve 
large textual changes, should be Rejected. In unclear situations, small changes 
can be Hold for Document Update.”

I think that the consensus of the long term fix (e.g. in YANG 1.2) is that 
“require-instance” should be allowed under typedefs that refined types that 
allow it.

Pragmatically, I think that we can mark this errata is a “Hold for Document 
Update”, with the accompanying errata notes (derived from Radek’s comments) 
changed to:

“The document does not specify whether the “require-instance” keyword is 
allowed in typedef refinements derived from the “leafref” or 
“instance-identifier” base types, but it is anticipated that a future revision 
of YANG would allow this.   It is suggested that modules using YANG language 
versions 1 [RFC 6020] and 1.1 [RFC 7950] avoid using this construct, YANG 
module validation tools flag a warning if this construct is used, but 
implementations allow this if possible.”

Does anyone object to this course of action (or wishes to refine my errata 
notes)?

Regards,
Rob


From: Kent Watsen 
Sent: 23 April 2020 17:59
To: Andy Bierman 
Cc: Radek Krejci ; Juergen Schoenwaelder 
; Martin Björklund ; 
netmod@ietf.org; Rob Wilton (rwilton) 
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

The consensus seems to be that:
  - the errata should be rejected
- Rob, do you agree?
  - YANG-next should fix it later
- I created https://github.com/netmod-wg/yang-next/issues/104
  - implementations should try to do the right thing now
- Radek’s suggestion below LGTM!


Tallies:
   - for reject: Andy, Martin, Juergen, and Kent
   - for accept: Radek, and Balazs
   - unclear: Lada, Rob, and Jason


Kent // as co-chair


On Apr 14, 2020, at 10:35 AM, Andy Bierman 
mailto:a...@yumaworks.com>> wrote:

Hi,

I agree with Juergen that this errata should be rejected and the issue resolved 
in yang-next.
No IETF module should use this construct. It is easy to convert to an 
equivalent form that is not under dispute.


Andy


On Tue, Apr 14, 2020 at 6:40 AM Radek Krejci 
mailto:rkre...@cesnet.cz>> wrote:
Hi,
Dne 09. 04. 20 v 17:26 Kent Watsen napsal(a):


On Apr 6, 2020, at 3:42 AM, Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de>>
 wrote:

The definition I found in RFC 8639 is this:

   leaf stream {
 type stream-ref {
   require-instance false;
 }
 mandatory true;
 description
   "Indicates the event stream to be considered for
this subscription.";
   }

This could be changed to:

   leaf stream {
 type leafref {
path "/sn:streams/sn:stream/sn:name";
   require-instance false;
 }
 mandatory true;
 description
   "Indicates the event stream to be considered for
this subscription.";
   }

I can confirm that `yanglint` validates the module cleanly after this change.



On Apr 6, 2020, at 7:38 AM, Martin Björklund 
mailto:mbj+i...@4668.se>> wrote:

I think the correct fix is to change the text so that
"require-instance" is not classified as a restriction and keep the
default.

Agreed.


Also, I think that it would be easiest (for backwards
compatibility w/ existing models) to allow "require-inetance" to be
changed in derived types.

However, this cannot imo be done in an errata.

While I appreciate Radek and Michal’s perspective, I also think that is would 
be best for the community for `yanglint` to support this, as they are published 
modules doing it.


I don't feel as an expert for IETF processes, so I don't know if this issue can 
be solved in errata or not (and I'm not sure there is a consensus on this in 
mailing list). For the implementation, I would appreciate at least a consensus 
on a solution. So far I saw opinions to allow it, to disallow and also to make 
it implementation-specific (which means in fact to disallow from the authors 
perspective, since there can be a tool disallowing it and we are saying that 
such a tool is ok). So, there is no clear way for implementors, which means 
problems for interoperability - there will be always someone unhappy and so far 
I don't know what is the major opinion 

Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

[Reshad Rahman (rrahman)]

I finally caught up to this thread. I agree with concerns raised by Radek and 
Balazs, but as others have mentioned an errata doesn’t seem to be the right 
medium for this. OTOH, yang-next might be too far away…. Could we do an update 
to RF7950 just for this? I realize it’s lots of work/overhead for “just” this 
issue.

Regards,
Reshad.

From: netmod  on behalf of Kent Watsen 

Date: Thursday, April 23, 2020 at 12:59 PM
To: 'Andy Bierman' 
Cc: "netmod@ietf.org" , "Rob Wilton (rwilton)" 

Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6031)

The consensus seems to be that:
  - the errata should be rejected
- Rob, do you agree?
  - YANG-next should fix it later
- I created https://github.com/netmod-wg/yang-next/issues/104
  - implementations should try to do the right thing now
- Radek’s suggestion below LGTM!


Tallies:
   - for reject: Andy, Martin, Juergen, and Kent
   - for accept: Radek, and Balazs
   - unclear: Lada, Rob, and Jason


Kent // as co-chair



On Apr 14, 2020, at 10:35 AM, Andy Bierman 
mailto:a...@yumaworks.com>> wrote:

Hi,

I agree with Juergen that this errata should be rejected and the issue resolved 
in yang-next.
No IETF module should use this construct. It is easy to convert to an 
equivalent form that is not under dispute.


Andy


On Tue, Apr 14, 2020 at 6:40 AM Radek Krejci 
mailto:rkre...@cesnet.cz>> wrote:
Hi,
Dne 09. 04. 20 v 17:26 Kent Watsen napsal(a):



On Apr 6, 2020, at 3:42 AM, Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de>>
 wrote:

The definition I found in RFC 8639 is this:

   leaf stream {
 type stream-ref {
   require-instance false;
 }
 mandatory true;
 description
   "Indicates the event stream to be considered for
this subscription.";
   }

This could be changed to:

   leaf stream {
 type leafref {
path "/sn:streams/sn:stream/sn:name";
   require-instance false;
 }
 mandatory true;
 description
   "Indicates the event stream to be considered for
this subscription.";
   }


I can confirm that `yanglint` validates the module cleanly after this change.



On Apr 6, 2020, at 7:38 AM, Martin Björklund 
mailto:mbj+i...@4668.se>> wrote:

I think the correct fix is to change the text so that
"require-instance" is not classified as a restriction and keep the
default.

Agreed.



Also, I think that it would be easiest (for backwards
compatibility w/ existing models) to allow "require-inetance" to be
changed in derived types.

However, this cannot imo be done in an errata.

While I appreciate Radek and Michal’s perspective, I also think that is would 
be best for the community for `yanglint` to support this, as they are published 
modules doing it.


I don't feel as an expert for IETF processes, so I don't know if this issue can 
be solved in errata or not (and I'm not sure there is a consensus on this in 
mailing list). For the implementation, I would appreciate at least a consensus 
on a solution. So far I saw opinions to allow it, to disallow and also to make 
it implementation-specific (which means in fact to disallow from the authors 
perspective, since there can be a tool disallowing it and we are saying that 
such a tool is ok). So, there is no clear way for implementors, which means 
problems for interoperability - there will be always someone unhappy and so far 
I don't know what is the major opinion to go.

So far, I tend to allow it (accept by libyang), but print warning to warn 
authors about possible problems (some tool can refuse such a module). Is it ok?

Radek



As an aside, I feel that all modules should be tested against all available 
validation tools during the publication process, but to find issues in the 
modules and well as possibly improve the tools.

Sadly, I only have `yanglint` and `yangson` available to me.  I just checked 
for the “yang validator” project, but both 
www.yangvalidator.com and 
https://www.yangcatalog.org/yangvalidator seem to be down.


Kent // contributor


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] versioning procedures (RFC vs. I-D)

[Reshad Rahman (rrahman)]

This is being tracked via https://github.com/netmod-wg/yang-ver-dt/issues/56

Regarding this:
The BC vs. NBC distinction is not relevant for a work-in-progress.
We have seen many times in this WG where a NBC change was made
and then later undone.  There is no value in tracking the module during 
development.

It might not be relevant/important during the multiple initial revisions. But 
when we reach (WG)LC, I think it’s an important piece of information.

Regards,
Reshad.

From: 'Andy Bierman' 
Date: Thursday, April 2, 2020 at 12:02 PM
To: "Reshad Rahman (rrahman)" 
Cc: Italo Busi , "Joe Clarke (jclarke)" 
, NetMod WG 
Subject: Re: [netmod] versioning procedures (RFC vs. I-D)

Hi,

I agree that a revision-label could be useful in an I-D but not to indicate NBC 
changes (because it doesn't).
The rules need to be clear and simple with no exceptions.

 1) Special version 0.x.y contains NO NBC information
 Major version = 0 means the module has no published version

 2) First published version is 1.0.0

 3) The revision-label in an unpublished module has a special form which simply 
identifies
  the source of the development and the iteration of the work-in-progress.
  You can't really pick the next published label until the module is ready.

From my example:

draft-00:   0.1.0
draft-01:   0.2.0
draft-02:   0.3.0
RFC-1:1.0.0
bis-draft-00:   1.0.0+1
bis-draft-01:   1.0.0+2
bis-draft-02:   1.0.0+3
[repeat NBC step bis-draft-02 10 times]  1.0.0+4 .. 1.0.0+13
RFC-2:  2.0.0   (in general: 1.0.1 or 1.1.0 or 2.0.0)

The BC vs. NBC distinction is not relevant for a work-in-progress.
We have seen many times in this WG where a NBC change was made
and then later undone.  There is no value in tracking the module during 
development.


Andy


On Thu, Apr 2, 2020 at 7:46 AM Reshad Rahman (rrahman) 
mailto:rrah...@cisco.com>> wrote:


From: 'Andy Bierman' mailto:a...@yumaworks.com>>
Date: Thursday, April 2, 2020 at 10:26 AM
To: "Reshad Rahman (rrahman)" mailto:rrah...@cisco.com>>
Cc: Italo Busi mailto:italo.b...@huawei.com>>, "Joe 
Clarke (jclarke)" mailto:jcla...@cisco.com>>, NetMod WG 
mailto:netmod@ietf.org>>
Subject: Re: [netmod] versioning procedures (RFC vs. I-D)



On Thu, Apr 2, 2020 at 4:11 AM Reshad Rahman (rrahman) 
mailto:rrah...@cisco.com>> wrote:
Hi,

From: Italo Busi mailto:italo.b...@huawei.com>>
Date: Thursday, April 2, 2020 at 5:06 AM
To: "Reshad Rahman (rrahman)" mailto:rrah...@cisco.com>>, 
'Andy Bierman' mailto:a...@yumaworks.com>>, "Joe Clarke 
(jclarke)" mailto:jcla...@cisco.com>>
Cc: NetMod WG mailto:netmod@ietf.org>>
Subject: RE: [netmod] versioning procedures (RFC vs. I-D)

Reshad,

My doubt and, if I understand well also Andy’s question, is about the fact that 
before publishing an RFC-bis with e.g., 1.1.0, we will have a set of 
Internet-Drafts updating the RFC with 1.0.0

What versions should be used in the YANG modules published in these 
Internet-Drafts?

Think about the following scenario: -00 version provide BC changes to the RFC 
module but the -01 version provide NBC changes to what has been added in the 
-00 module (thus the -01 version is BC with the RFC 1.0.0 module but NBC with 
the -00 version module)
 So bis 00 would be 1.1.0 (BC with RFC module).
Bis 01 should be updated according to its relationship to the RFC module (bis 
00 doesn’t matter anymore), when RFC bis is published it won’t have the full 
history.

Hope I correctly understood your question.


This semver plan is not very intuitive and not sure it works.

draft-00

   container the-container; version 0.1.0  OK

draft-01:
   container my-container; version 0.2.0;   rules violated; NBC 
should force 1.0.0

draft-02:

container my-container {   version 0.3.0; should be 1.1.0
leaf my-leaf { type int32; }
}

RFC-1:

container my-container {   version 1.0.0;  should be 2.0.0 
according to NBC rules
leaf my-leaf { type uint32; }
}

bis-draft-00:

   container my-container {   version 1.1.0; OK
leaf my-leaf { type uint32; }
leaf another-leaf { type int32; }
}

bis-draft-01:

  container my-container {  diff against RFC-1:  version 1.1.0 
but already used; use 1.2.0?
leaf my-leaf { type uint32; }
leaf another-leaf { type uint32; }
}

bis-draft-02:

  container example-my-container {  diff against RFC-1:  
version 2.0.0 but use 1.3.0 instead?
leaf my-leaf { type uint32; }
leaf another-leaf { type uint32; }
}

[repeat NBC step bis-draft-02 10 times now up to version 12.0.0 or is it 
1.13.0? something else?

RFC-2:   publish draft-12 as RFC-2: now change the label from 1.13.0 to 2.0.0? 
or leave it 12.0.0?

IMO it is very confusing that the stated rules are so inconsisten

Re: [netmod] versioning procedures (RFC vs. I-D)

[Reshad Rahman (rrahman)]

From: 'Andy Bierman' 
Date: Thursday, April 2, 2020 at 10:26 AM
To: "Reshad Rahman (rrahman)" 
Cc: Italo Busi , "Joe Clarke (jclarke)" 
, NetMod WG 
Subject: Re: [netmod] versioning procedures (RFC vs. I-D)



On Thu, Apr 2, 2020 at 4:11 AM Reshad Rahman (rrahman) 
mailto:rrah...@cisco.com>> wrote:
Hi,

From: Italo Busi mailto:italo.b...@huawei.com>>
Date: Thursday, April 2, 2020 at 5:06 AM
To: "Reshad Rahman (rrahman)" mailto:rrah...@cisco.com>>, 
'Andy Bierman' mailto:a...@yumaworks.com>>, "Joe Clarke 
(jclarke)" mailto:jcla...@cisco.com>>
Cc: NetMod WG mailto:netmod@ietf.org>>
Subject: RE: [netmod] versioning procedures (RFC vs. I-D)

Reshad,

My doubt and, if I understand well also Andy’s question, is about the fact that 
before publishing an RFC-bis with e.g., 1.1.0, we will have a set of 
Internet-Drafts updating the RFC with 1.0.0

What versions should be used in the YANG modules published in these 
Internet-Drafts?

Think about the following scenario: -00 version provide BC changes to the RFC 
module but the -01 version provide NBC changes to what has been added in the 
-00 module (thus the -01 version is BC with the RFC 1.0.0 module but NBC with 
the -00 version module)
 So bis 00 would be 1.1.0 (BC with RFC module).
Bis 01 should be updated according to its relationship to the RFC module (bis 
00 doesn’t matter anymore), when RFC bis is published it won’t have the full 
history.

Hope I correctly understood your question.


This semver plan is not very intuitive and not sure it works.

draft-00

   container the-container; version 0.1.0  OK

draft-01:
   container my-container; version 0.2.0;   rules violated; NBC 
should force 1.0.0

draft-02:

container my-container {   version 0.3.0; should be 1.1.0
leaf my-leaf { type int32; }
}

RFC-1:

container my-container {   version 1.0.0;  should be 2.0.0 
according to NBC rules
leaf my-leaf { type uint32; }
}

bis-draft-00:

   container my-container {   version 1.1.0; OK
leaf my-leaf { type uint32; }
leaf another-leaf { type int32; }
}

bis-draft-01:

  container my-container {  diff against RFC-1:  version 1.1.0 
but already used; use 1.2.0?
leaf my-leaf { type uint32; }
leaf another-leaf { type uint32; }
}

bis-draft-02:

  container example-my-container {  diff against RFC-1:  
version 2.0.0 but use 1.3.0 instead?
leaf my-leaf { type uint32; }
leaf another-leaf { type uint32; }
}

[repeat NBC step bis-draft-02 10 times now up to version 12.0.0 or is it 
1.13.0? something else?

RFC-2:   publish draft-12 as RFC-2: now change the label from 1.13.0 to 2.0.0? 
or leave it 12.0.0?

IMO it is very confusing that the stated rules are so inconsistent and are 
violated so many ways.
There should be no revision-label at all in Internet Drafts because these 
documents are unpublished.
They should only be added to the RFC version.

The semver procedures are not intended to work for unpublished modules that are 
only
meant for review, not for implementation. The revision-label provides only 
noise in Internet Drafts.
 I think it’s useful to have a revision label in a draft because it 
indicates nature of changes (BC v/s NBC) compared to the previous published 
revision (RFC).
But you are absolutely right that setting the version based on changes with the 
previous draft revision is useless and confusing.

Regards,
Reshad.


Regards,
Reshad.

Thanks, Italo


Andy


Italo Busi
Principal Optical Transport Network Research Engineer
Huawei Technologies Co., Ltd.
Tel : +39 345 4721946
Email : italo.b...@huawei.com<mailto:italo.b...@huawei.com>
[cid:image001.png@01D608DB.F2E089F0]

This e-mail and its attachments contain confidential information from HUAWEI, 
which is intended only for the person or entity whose address is listed above. 
Any use of the information contained herein in any way (including, but not 
limited to, total or partial disclosure, reproduction, or dissemination) by 
persons other than the intended recipient(s) is prohibited. If you receive this 
e-mail in error, please notify the sender by phone or email immediately and 
delete it!

From: Reshad Rahman (rrahman) 
[mailto:rrah...@cisco.com<mailto:rrah...@cisco.com>]
Sent: mercoledì 1 aprile 2020 20:13
To: Andy Bierman mailto:a...@yumaworks.com>>; Joe Clarke 
(jclarke) mailto:jcla...@cisco.com>>
Cc: NetMod WG mailto:netmod@ietf.org>>
Subject: Re: [netmod] versioning procedures (RFC vs. I-D)


From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of 'Andy Bierman' mailto:a...@yumaworks.com>>
Date: Wednesday, April 1, 2020 at 2:07 PM
To: "Joe Clarke (jclarke)" mailto:jcla...@cisco.com>>
Cc: NetMod WG mailto:netmod@ietf.org>>
Subject: Re: [netmod]

Re: [netmod] versioning procedures (RFC vs. I-D)

[Reshad Rahman (rrahman)]

Hi,

From: Italo Busi 
Date: Thursday, April 2, 2020 at 5:06 AM
To: "Reshad Rahman (rrahman)" , 'Andy Bierman' 
, "Joe Clarke (jclarke)" 
Cc: NetMod WG 
Subject: RE: [netmod] versioning procedures (RFC vs. I-D)

Reshad,

My doubt and, if I understand well also Andy’s question, is about the fact that 
before publishing an RFC-bis with e.g., 1.1.0, we will have a set of 
Internet-Drafts updating the RFC with 1.0.0

What versions should be used in the YANG modules published in these 
Internet-Drafts?

Think about the following scenario: -00 version provide BC changes to the RFC 
module but the -01 version provide NBC changes to what has been added in the 
-00 module (thus the -01 version is BC with the RFC 1.0.0 module but NBC with 
the -00 version module)
 So bis 00 would be 1.1.0 (BC with RFC module).
Bis 01 should be updated according to its relationship to the RFC module (bis 
00 doesn’t matter anymore), when RFC bis is published it won’t have the full 
history.

Hope I correctly understood your question.

Regards,
Reshad.

Thanks, Italo

Italo Busi
Principal Optical Transport Network Research Engineer
Huawei Technologies Co., Ltd.
Tel : +39 345 4721946
Email : italo.b...@huawei.com
[cid:image001.png@01D608BD.F401D410]

This e-mail and its attachments contain confidential information from HUAWEI, 
which is intended only for the person or entity whose address is listed above. 
Any use of the information contained herein in any way (including, but not 
limited to, total or partial disclosure, reproduction, or dissemination) by 
persons other than the intended recipient(s) is prohibited. If you receive this 
e-mail in error, please notify the sender by phone or email immediately and 
delete it!

From: Reshad Rahman (rrahman) [mailto:rrah...@cisco.com]
Sent: mercoledì 1 aprile 2020 20:13
To: Andy Bierman ; Joe Clarke (jclarke) 
Cc: NetMod WG 
Subject: Re: [netmod] versioning procedures (RFC vs. I-D)


From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of 'Andy Bierman' mailto:a...@yumaworks.com>>
Date: Wednesday, April 1, 2020 at 2:07 PM
To: "Joe Clarke (jclarke)" mailto:jcla...@cisco.com>>
Cc: NetMod WG mailto:netmod@ietf.org>>
Subject: Re: [netmod] versioning procedures (RFC vs. I-D)



On Wed, Apr 1, 2020 at 10:39 AM Joe Clarke (jclarke) 
mailto:jcla...@cisco.com>> wrote:


> On Apr 1, 2020, at 13:28, Andy Bierman 
> mailto:a...@yumaworks.com>> wrote:
>
> Hi,
>
> I just want to confirm that all the proposed documentation procedures
> using new extensions are limited in scope to published modules only,
> and not applied to unpublished modules (terms defined in RFC 8407).
>
> IMO it would be harmful to module usability to assign revision-labels or
> include revision-related extensions in unpublished modules (e.g., Internet 
> Drafts).
> Consider how cluttered and confusing the client-server modules would be
> if the 50+ NBC changes and versions were tracked through all the I-Ds.
>
> For IETF modules, the first usage of the revision-label
> should be in the initial RFC, and be set to 1.0.0.
>
> If the RFC is ever republished then one can expect to find an updated
> revision-label and possibly extensions tracking NBC changes.

The semver scheme allocates a major version of 0 for pre-releases where the 
BC/NBC rules do not apply.  I agree that a first official RFC release should be 
1.0.0 (from a semver revision-label standpoint).  From a design team 
standpoint, I know we mentioned the 0 versioning early on, but I don’t think we 
spent much time talking about modules under development overall.


IMO it is confusing to ignore the semver rules for the special 0.x.y releases.
There are many NBC changes made at this point which are treated as minor or 
patch changes.
The procedure is really broken once you consider a WG developing any RFC-bis 
module.
Now the major version is not 0 and all updates look like real releases.
 I don’t think that’s needed. Initial module in RFC has 1.0.0, module in 
(released) RFC-bis can go to 1.0.1, 1.1.0 or 2.0.0 depending on the change.

Regards,
Reshad.

My take would align to yours that we wouldn’t clutter a module with development 
NBC tracking.

Joe

Andy

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] versioning procedures (RFC vs. I-D)

[Reshad Rahman (rrahman)]

From: netmod  on behalf of 'Andy Bierman' 

Date: Wednesday, April 1, 2020 at 2:07 PM
To: "Joe Clarke (jclarke)" 
Cc: NetMod WG 
Subject: Re: [netmod] versioning procedures (RFC vs. I-D)



On Wed, Apr 1, 2020 at 10:39 AM Joe Clarke (jclarke) 
mailto:jcla...@cisco.com>> wrote:


> On Apr 1, 2020, at 13:28, Andy Bierman 
> mailto:a...@yumaworks.com>> wrote:
>
> Hi,
>
> I just want to confirm that all the proposed documentation procedures
> using new extensions are limited in scope to published modules only,
> and not applied to unpublished modules (terms defined in RFC 8407).
>
> IMO it would be harmful to module usability to assign revision-labels or
> include revision-related extensions in unpublished modules (e.g., Internet 
> Drafts).
> Consider how cluttered and confusing the client-server modules would be
> if the 50+ NBC changes and versions were tracked through all the I-Ds.
>
> For IETF modules, the first usage of the revision-label
> should be in the initial RFC, and be set to 1.0.0.
>
> If the RFC is ever republished then one can expect to find an updated
> revision-label and possibly extensions tracking NBC changes.

The semver scheme allocates a major version of 0 for pre-releases where the 
BC/NBC rules do not apply.  I agree that a first official RFC release should be 
1.0.0 (from a semver revision-label standpoint).  From a design team 
standpoint, I know we mentioned the 0 versioning early on, but I don’t think we 
spent much time talking about modules under development overall.


IMO it is confusing to ignore the semver rules for the special 0.x.y releases.
There are many NBC changes made at this point which are treated as minor or 
patch changes.
The procedure is really broken once you consider a WG developing any RFC-bis 
module.
Now the major version is not 0 and all updates look like real releases.
 I don’t think that’s needed. Initial module in RFC has 1.0.0, module in 
(released) RFC-bis can go to 1.0.1, 1.1.0 or 2.0.0 depending on the change.

Regards,
Reshad.

My take would align to yours that we wouldn’t clutter a module with development 
NBC tracking.

Joe

Andy

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] All IETF YANG modules MUST include revision-label statements

[Reshad Rahman (rrahman)]

Hi,

Thanks for the suggestion.

This was discussed, I think the reason we didn’t go with that solution is that 
(as you mentioned) you need the module contents with all the previous version 
labels. Does anyone from the design team recall any other details?

Regards,
Reshad.

From: "Ivory, William" 
Date: Tuesday, March 31, 2020 at 3:40 AM
To: "mbj+i...@4668.se" , "jason.ste...@nokia.com" 
, "Reshad Rahman (rrahman)" 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] All IETF YANG modules MUST include revision-label 
statements

Apologies if this has already been suggested and deemed unworkable, but if you 
have access to all previous version labels for a branch then you can add 'M' 
only to the versions that are NBC with the previous version, and subsequent 
versions could drop the M until the next NBC change, ie:

1.0.0 -> 1.0.1 -> 1.0.2 > 1.0.3M -> 1.0.4 -> 1.0.5M ...

Here 1.04 is BC with 1.03 but not 1.0.0 - 1.0.2; 1.0.5 is NBC with 1.0.4 and 
previous versions etc.

The revision statements contain the revision-labels so you should have all the 
previous revision-labels present in the file, and you have all the data you 
need. Now you don't have the problem of the branch being poisoned as soon as 
the first M is added.

William

On Mon, 2020-03-30 at 22:11 +, Reshad Rahman (rrahman) wrote:

On 2020-03-30, 5:51 PM, "Martin Björklund" 
mailto:mbj+i...@4668.se>> wrote:



"Sterne, Jason (Nokia - CA/Ottawa)" 
mailto:jason.ste...@nokia.com>> wrote:

> > But it is not true.  What happened between 1.0.2M and 1.0.3M?

>

> It tells you there is an NBC change between 1.0.2M and 1.0.3M.



No.  As you note below it says that all bets are off.  The change

between these two could be a spelling error fix.  Hence, Reshad's

statement that "The revision label allows a user to easily figure out

whether 2 revisions are (N)BC." is not correct.

You are correct that once a branch is poisoned with an 'M', the information 
provided is not as rich.

Even though you don't know whether 1.0.3M is BC/NBC with 1.0.2M, you still know 
that

- 1.0.2M is NBC with 1.0.1 and 1.0.0

- 1.0.3M is NBC with 1.0.1 and 1.0.0

- 1.0.1 is BC with 1.0.0



Still useful IMO.



Regards,

Reshad.



> The M gives an indication that a branch has been "poisoned" by an

> NBC change and that all bets are off from that point onwards in that

> branch.





/martin





>

> > -Original Message-

> > From: netmod mailto:netmod-boun...@ietf.org>> 
On Behalf Of Martin Björklund

> > Sent: Monday, March 30, 2020 4:40 PM

> > To: rrah...@cisco.com<mailto:rrah...@cisco.com>

> > Cc: netmod@ietf.org<mailto:netmod@ietf.org>

> > Subject: Re: [netmod] All IETF YANG modules MUST include revision-label

    > > statements

> >

> > "Reshad Rahman (rrahman)" mailto:rrah...@cisco.com>> 
wrote:

> > >

> > > On 2020-03-30, 2:20 PM, "Martin Björklund" 
mailto:mbj+i...@4668.se>> wrote:

> > >

> > > "Reshad Rahman (rrahman)" 
mailto:rrah...@cisco.com>> wrote:

> > > > On 2020-03-28, 4:41 AM, "Martin Björklund" 
mailto:mbj+i...@4668.se>> wrote:

> > > >

> > > > "Reshad Rahman (rrahman)" 
mailto:rrah...@cisco.com>> wrote:

> > > > > Hi,

> > > > >

> > > > > 
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netmod-2Dwg_yang-2Dver-2Ddt_issues_45&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=ffH268c0xOd0DSFLQzZ2JHAmCHjVzPJVJtGPNxiiJcs&s=nyxzbv7ZWMgcXuMEW8MqjeT3oVxla6qFiF96M8SaMUY&e=

> > > > >

> > > > > o  7.1

> > > > >

> > > > >   The text says:

> > > > >

> > > > > All IETF YANG modules MUST include 
revision-label statements

> > for

> > > > > all

> > > > > newly published YANG modules, and all newly 
published

> > revisions of

> > > > > existing YANG modules.  The revision-label 
MUST take the form

> > of a

> > > > > YANG semantic version number 
[I-D.verdt-netmod-yang-

> > semver].

> > > > >

> > > > >

Re: [netmod] All IETF YANG modules MUST include revision-label statements

[Reshad Rahman (rrahman)]

On 2020-03-30, 7:22 PM, "Kent Watsen"  wrote:
> Even though we are debating/discussing whether iETF moduels should use 
YANG semver (aka modified semver), please note that there is interest from 
other publishers of YANG modules to use semver or YANG semver.

Details?

I was referring to vendors, not SDOs.

Regards,
Reshad.

> Regarding your comment below, is it specific to IETF modules or more 
general?
>  
> "I don’t think the “semver" label has been fully justified relative to 
the disruption I perceive it may cause.”

I was thinking in general.  YMMV.


Kent // contributor



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] All IETF YANG modules MUST include revision-label statements

[Reshad Rahman (rrahman)]

Hi Kent,

Even though we are debating/discussing whether iETF moduels should use YANG 
semver (aka modified semver), please note that there is interest from other 
publishers of YANG modules to use semver or YANG semver.

Regarding your comment below, is it specific to IETF modules or more general?
I don’t think the “semver" label has been fully justified relative to the 
disruption I perceive it may cause.

Regards,
Reshad.

From: Kent Watsen 
Date: Monday, March 30, 2020 at 6:49 PM
To: Martin Björklund 
Cc: "Reshad Rahman (rrahman)" , "netmod@ietf.org" 

Subject: Re: [netmod] All IETF YANG modules MUST include revision-label 
statements

[I’ve scanned the entire thread before circling back to respond to this message]



Martin writes:
I can reluctantly accept that modified smever is published as
Experimental.  But that doesn't mean that IETF modules should use it.

I assume Martin’s reference to Experimental follows my adoption-call comment 
here: https://mailarchive.ietf.org/arch/msg/netmod/uZZqBs1yK0EpbXgRJRFQihHWo5s/

Changing the "Intended Status” for an adopted document is easily done at any 
time before publication.

PS: Andy didn’t participate in the call, though he appears to be coming in 
strong now...

Kent

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] All IETF YANG modules MUST include revision-label statements

[Reshad Rahman (rrahman)]

On 2020-03-30, 5:51 PM, "Martin Björklund"  wrote:

"Sterne, Jason (Nokia - CA/Ottawa)"  wrote:
> > But it is not true.  What happened between 1.0.2M and 1.0.3M?
> 
> It tells you there is an NBC change between 1.0.2M and 1.0.3M.

No.  As you note below it says that all bets are off.  The change
between these two could be a spelling error fix.  Hence, Reshad's
statement that "The revision label allows a user to easily figure out
whether 2 revisions are (N)BC." is not correct.
You are correct that once a branch is poisoned with an 'M', the information 
provided is not as rich.
Even though you don't know whether 1.0.3M is BC/NBC with 1.0.2M, you still know 
that
- 1.0.2M is NBC with 1.0.1 and 1.0.0
- 1.0.3M is NBC with 1.0.1 and 1.0.0
- 1.0.1 is BC with 1.0.0

Still useful IMO.

Regards,
Reshad.

> The M gives an indication that a branch has been "poisoned" by an
> NBC change and that all bets are off from that point onwards in that
> branch.


/martin


> 
> > -Original Message-
> > From: netmod  On Behalf Of Martin Björklund
> > Sent: Monday, March 30, 2020 4:40 PM
> > To: rrah...@cisco.com
> > Cc: netmod@ietf.org
    > > Subject: Re: [netmod] All IETF YANG modules MUST include revision-label
> > statements
> > 
> > "Reshad Rahman (rrahman)"  wrote:
> > >
> > > On 2020-03-30, 2:20 PM, "Martin Björklund"  wrote:
> > >
> > > "Reshad Rahman (rrahman)"  wrote:
> > > > On 2020-03-28, 4:41 AM, "Martin Björklund"  
wrote:
> > > >
> > > > "Reshad Rahman (rrahman)"  wrote:
> > > > > Hi,
> > > > >
> > > > > https://github.com/netmod-wg/yang-ver-dt/issues/45
> > > > >
> > > > > o  7.1
> > > > >
> > > > >   The text says:
> > > > >
> > > > > All IETF YANG modules MUST include 
revision-label statements
> > for
> > > > > all
> > > > > newly published YANG modules, and all newly 
published
> > revisions of
> > > > > existing YANG modules.  The revision-label 
MUST take the form
> > of a
> > > > > YANG semantic version number 
[I-D.verdt-netmod-yang-
> > semver].
> > > > >
> > > > >   I strongly disagree with this new rule.  IETF 
modules use a linear
> > > > >   history, so there are no reasons to use 
"modified semver".
> > > > >
> > > > >   It is ok to use rev:nbc-changes if needed, 
though.
> > > > >
> > > > > We believe some IETF models may not follow linear 
history, this was
> > > > > brought up (I think) for IDR. Modified semver allows for 
non-linear
> > > > > history and also doesn't preclude linear history. So even 
if we end up
> > > > > having no IETF modules using branching, modified semver 
still works.
> > > >
> > > > With the clarifiactions and updates in
> > > > draft-verdt-netmod-yang-module-versioning, non-linear 
versioning
> > > > works without modified semver.  So there is no technical 
reason to use
> > > > modified semver in IETF modules.
> > > >
> > > > So are you proposing we use some other revision-label scheme 
(e.g.
> > semver 2.0.0) for IETF modules?
> > > >
> > > > Or that IETF modules shouldn't use revision-labels?
> > >
> > > That IETF shouldn't use revision labels.
> > >
> > > The revision label allows a user to easily figure out whether 2
> > > revisions are (N)BC.
> > 
> > I think you meant "modified semver as revision label allows ..."
> > 
> > But it is not true.  What happened between 1.0.2M and 1.0.3M?
> > 
> > 
> > /martin
> > 
> > 
> > > Without the label, you always have to use tooling.
> >

Re: [netmod] All IETF YANG modules MUST include revision-label statements

[Reshad Rahman (rrahman)]

From: 'Andy Bierman' 
Date: Monday, March 30, 2020 at 2:51 PM
To: Martin Björklund 
Cc: "Reshad Rahman (rrahman)" , NetMod WG 
Subject: Re: [netmod] All IETF YANG modules MUST include revision-label 
statements



On Mon, Mar 30, 2020 at 11:20 AM Martin Björklund 
mailto:mbj%2bi...@4668.se>> wrote:
"Reshad Rahman (rrahman)" mailto:rrah...@cisco.com>> wrote:
> On 2020-03-28, 4:41 AM, "Martin Björklund" 
> mailto:mbj%2bi...@4668.se>> wrote:
>
> "Reshad Rahman (rrahman)" mailto:rrah...@cisco.com>> 
> wrote:
> > Hi,
> >
> > https://github.com/netmod-wg/yang-ver-dt/issues/45
> >
> > o  7.1
> >
> >   The text says:
> >
> > All IETF YANG modules MUST include revision-label 
> statements for
> > all
> > newly published YANG modules, and all newly published 
> revisions of
> > existing YANG modules.  The revision-label MUST take the 
> form of a
> > YANG semantic version number [I-D.verdt-netmod-yang-semver].
> >
> >   I strongly disagree with this new rule.  IETF modules use a 
> linear
> >   history, so there are no reasons to use "modified semver".
> >
> >   It is ok to use rev:nbc-changes if needed, though.
> >
> > We believe some IETF models may not follow linear history, this was
> > brought up (I think) for IDR. Modified semver allows for non-linear
> > history and also doesn't preclude linear history. So even if we end up
> > having no IETF modules using branching, modified semver still works.
>
> With the clarifiactions and updates in
> draft-verdt-netmod-yang-module-versioning, non-linear versioning
> works without modified semver.  So there is no technical reason to use
> modified semver in IETF modules.
>
> So are you proposing we use some other revision-label scheme (e.g. semver 
> 2.0.0) for IETF modules?
>
> Or that IETF modules shouldn't use revision-labels?

That IETF shouldn't use revision labels.

I do not like modified semver because it will cause confusion with the real 
semver
introduced by OpenConfig.

Sometimes multiple release trains are needed, and the revision label (in 
addition to revision-date)
can help distinguish revisions from each release train, so plain semver that is 
introduced over time
would be OK.

It is possible to introduce only BC changes on each release train.
The BC vs. NBC issue has nothing to do with multiple release trains.



I am all for using rev:nbc-changes or rev:editorial-changes (which I
think should be added) in IETF modules.

I agree that this is sufficient and modified semver provides no added value, 
only confusion.
 There are 2 questions here:

  1.  Is revision-label useful? We believe it is useful since it allows a user 
to easily figure out whether 2 revisions are (N)BC
  2.  If it is useful, what’s the best scheme to use? Semver, modified semver, 
…?

You’re not keen on modified semver just because of the name, or are there other 
reasons?

Regards,
Reshad.

Regards,
Reshad.



/martin


Andy


>
> Or do you have something else in mind?
>
> Regards,
> Reshad.
>
> I can reluctantly accept that modified smever is published as
> Experimental.  But that doesn't mean that IETF modules should use it.
>
>
> /martin
>
>
> >
> > Regards,
> > Reshad.
> >
> >
> > On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)"
> > mailto:netmod-boun...@ietf.org> on behalf of
> > rrahman=40cisco@dmarc.ietf.org<mailto:40cisco@dmarc.ietf.org>> 
> wrote:
> >
> > Hi Martin,
> >
> > We've opened issues to track your review comments (see below). Will
> > kick off separate therads for each issue.
> >
> > 
> https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling
> >
> > Regards,
> > Reshad.
> >
> > On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund"
> > mailto:netmod-boun...@ietf.org> on behalf 
> of mbj+i...@4668.se<mailto:mbj%2bi...@4668.se>> wrote:
> >
> > Hi,
> >
> > Here are my review comments of
> > draft-verdt-netmod-yang-module-versioning-01.
> >
> >
> >
> > o  3.1.1
> >
> > o  In statements

Re: [netmod] All IETF YANG modules MUST include revision-label statements

[Reshad Rahman (rrahman)]

On 2020-03-30, 2:20 PM, "Martin Björklund"  wrote:

    "Reshad Rahman (rrahman)"  wrote:
> On 2020-03-28, 4:41 AM, "Martin Björklund"  wrote:
> 
> "Reshad Rahman (rrahman)"  wrote:
> > Hi,
> > 
> > https://github.com/netmod-wg/yang-ver-dt/issues/45
> > 
> > o  7.1
> > 
> >   The text says:
> > 
> > All IETF YANG modules MUST include revision-label 
statements for
> > all
> > newly published YANG modules, and all newly published 
revisions of
> > existing YANG modules.  The revision-label MUST take 
the form of a
> > YANG semantic version number 
[I-D.verdt-netmod-yang-semver].
> > 
> >   I strongly disagree with this new rule.  IETF modules use 
a linear
> >   history, so there are no reasons to use "modified semver".
> > 
> >   It is ok to use rev:nbc-changes if needed, though.
> > 
> > We believe some IETF models may not follow linear history, this was
> > brought up (I think) for IDR. Modified semver allows for non-linear
> > history and also doesn't preclude linear history. So even if we end 
up
> > having no IETF modules using branching, modified semver still works.
> 
> With the clarifiactions and updates in
> draft-verdt-netmod-yang-module-versioning, non-linear versioning
> works without modified semver.  So there is no technical reason to use
> modified semver in IETF modules.
> 
> So are you proposing we use some other revision-label scheme (e.g. semver 
2.0.0) for IETF modules?
> 
> Or that IETF modules shouldn't use revision-labels?

That IETF shouldn't use revision labels.

The revision label allows a user to easily figure out whether 2 revisions are 
(N)BC. Without the label, you always have to use tooling.

Regards,
Reshad.

I am all for using rev:nbc-changes or rev:editorial-changes (which I
think should be added) in IETF modules.


/martin


> 
> Or do you have something else in mind?
> 
> Regards,
> Reshad.
> 
> I can reluctantly accept that modified smever is published as
> Experimental.  But that doesn't mean that IETF modules should use it.
> 
> 
> /martin
> 
> 
> > 
> > Regards,
> > Reshad.
> > 
> > 
> > On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman 
(rrahman)"
> >  > rrahman=40cisco@dmarc.ietf.org> wrote:
> > 
> > Hi Martin,
> > 
> > We've opened issues to track your review comments (see below). 
Will
> > kick off separate therads for each issue.
> > 
> > 
https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling
> > 
> > Regards,
> > Reshad.
> > 
> > On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund"
> >  wrote:
> > 
> > Hi,
> > 
> > Here are my review comments of
> > draft-verdt-netmod-yang-module-versioning-01.
> > 
> > 
> > 
> > o  3.1.1
> > 
> > o  In statements that have any data definition 
statements as
> >substatements, those data definition substatements 
MAY be
> >reordered, as long as they do not change the 
ordering or any
> >"rpc"
> >"input" substatements.
> > 
> >   I think this needs to capture that no descendant 
statements to
> >   "input" can be reordered.  Same for "output" (note, 
"input" and
> >   "output" in both "rpc" and "action").
> > 
> > 
> > o  3.3
> > 
> > All revision labels that match the pattern

Re: [netmod] All IETF YANG modules MUST include revision-label statements

[Reshad Rahman (rrahman)]

On 2020-03-28, 4:41 AM, "Martin Björklund"  wrote:

    "Reshad Rahman (rrahman)"  wrote:
> Hi,
> 
> https://github.com/netmod-wg/yang-ver-dt/issues/45
> 
> o  7.1
> 
>   The text says:
> 
> All IETF YANG modules MUST include revision-label statements 
for
> all
> newly published YANG modules, and all newly published 
revisions of
> existing YANG modules.  The revision-label MUST take the form 
of a
> YANG semantic version number [I-D.verdt-netmod-yang-semver].
> 
>   I strongly disagree with this new rule.  IETF modules use a 
linear
>   history, so there are no reasons to use "modified semver".
> 
>   It is ok to use rev:nbc-changes if needed, though.
> 
> We believe some IETF models may not follow linear history, this was
> brought up (I think) for IDR. Modified semver allows for non-linear
> history and also doesn't preclude linear history. So even if we end up
> having no IETF modules using branching, modified semver still works.

With the clarifiactions and updates in
draft-verdt-netmod-yang-module-versioning, non-linear versioning
works without modified semver.  So there is no technical reason to use
modified semver in IETF modules.

So are you proposing we use some other revision-label scheme (e.g. semver 
2.0.0) for IETF modules?

Or that IETF modules shouldn't use revision-labels?

Or do you have something else in mind?

Regards,
Reshad.

I can reluctantly accept that modified smever is published as
Experimental.  But that doesn't mean that IETF modules should use it.


/martin
    

> 
> Regards,
> Reshad.
> 
> 
> On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)"
>  rrahman=40cisco@dmarc.ietf.org> wrote:
> 
> Hi Martin,
> 
> We've opened issues to track your review comments (see below). Will
> kick off separate therads for each issue.
> 
> 
https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling
> 
> Regards,
> Reshad.
> 
> On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund"
>  wrote:
> 
> Hi,
> 
> Here are my review comments of
> draft-verdt-netmod-yang-module-versioning-01.
> 
> 
> 
> o  3.1.1
> 
> o  In statements that have any data definition statements as
>substatements, those data definition substatements MAY be
>reordered, as long as they do not change the ordering or 
any
>"rpc"
>"input" substatements.
> 
>   I think this needs to capture that no descendant statements to
>   "input" can be reordered.  Same for "output" (note, "input" and
>   "output" in both "rpc" and "action").
> 
> 
> o  3.3
> 
> All revision labels that match the pattern for the "version"
> typedef in the ietf-yang-semver YANG module MUST be 
interpreted as
> YANG semantic version numbers.
> 
>   I don't think this is a good idea.  Seems like a layer 
violation.
>   What if my project use another dialect of semver, that wouldn't 
be
>   possible with this rule.  I think this needs to be removed.
> 
> 
> o  3.3
> 
> Submodules MUST NOT use revision label schemes that could be
> confused
> with the including module's revision label scheme.
> 
>   Hmm, how do I ensure that this MUST NOT is handled correctly?  
What
>   exactly does "could be confused with" mean?
> 
> 
> o  3.3
> 
>   In the filename of a YANG module, where it takes the form:
>   module-
>   or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )
> 
>   Should this section update 5.2 of RFC 7950?  I know that 5.2 
just
>

[netmod] Grammar for new extensions (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

[Reshad Rahman (rrahman)]

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/54

o Both YANG modules

  All extensions should specify the grammar; i.e., in which statements
  they can be present and which substatements they can have.

Ack.

1st part (statements) is clear.

For substatements, isn't this specified in 
https://tools.ietf.org/html/rfc7950#section-7.19.1? Can you clarify if that's 
not what you're looking for?

Regards,
Reshad.


On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)" 
 wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will kick 
off separate therads for each issue.


https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund" 
 wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.



o  3.1.1

o  In statements that have any data definition statements as
   substatements, those data definition substatements MAY be
   reordered, as long as they do not change the ordering or any 
"rpc"
   "input" substatements.

  I think this needs to capture that no descendant statements to
  "input" can be reordered.  Same for "output" (note, "input" and
  "output" in both "rpc" and "action").


o  3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted as
YANG semantic version numbers.

  I don't think this is a good idea.  Seems like a layer violation.
  What if my project use another dialect of semver, that wouldn't be
  possible with this rule.  I think this needs to be removed.


o  3.3

Submodules MUST NOT use revision label schemes that could be 
confused
with the including module's revision label scheme.

  Hmm, how do I ensure that this MUST NOT is handled correctly?  What
  exactly does "could be confused with" mean?


o  3.3

  In the filename of a YANG module, where it takes the form: module-
  or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

  Should this section update 5.2 of RFC 7950?  I know that 5.2 just
  says "SHOULD".  But existing tools implement this SHOULD, and they
  need to be updated to handle this new convention.

  But I wonder if this a good idea.  It means that a tool that looks
  for a module with a certain revision date cannot simply check the
  filenames, but need to parse all available modules (wijust to find 
the 



o  3.4

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated {
 rev:status-description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.";
   }
   description
 "Temperature in degrees Fahrenheit.";
 }

  I don't think rev:status-description is necessary / worth it.  This
  can easily be written with the normal description statement instead:

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated;
   description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.

Temperature in degrees Fahrenheit.";
 }


o  3.5

  The example modules should be legal YANG modules.  Use e.g. 
  "urn:example:module" as namespace.

  Also, the modules are missing the last "}", which confuses the
  "rfcstrip" tool.


o 4.1.1

Alternatively, the first example could have used the revision label
"1.0.0" instead, which selects the same set of revisions/versions.

import example-module {
  rev:revision-or-derived 1.0.0;
 

[netmod] Typos and smaller issues (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

[Reshad Rahman (rrahman)]

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/53

We'll make changes/fixes as per the comments below. All good.

o  3.5

  The example modules should be legal YANG modules.  Use e.g. 
  "urn:example:module" as namespace.

  Also, the modules are missing the last "}", which confuses the
  "rfcstrip" tool.


o 4.1.1

Alternatively, the first example could have used the revision label
"1.0.0" instead, which selects the same set of revisions/versions.

import example-module {
  rev:revision-or-derived 1.0.0;
}

  Shouldn't this be s/1.0.0/2.0.0/g ?


o  5

  I think the module name "ietf-yl-revisions" should be changed to
  "ietf-yang-library-revisions".   "yl" is not a well-known acronym.

o 7.1.1

  There is a missing " in:

   4.  For status "obsolete", it is RECOMMENDED to keep the "status-
   description" information, from when the node had status
   "deprecated, which is still relevant.
 HERE  ---^


o  8

  s/CODE ENDS>//

Regards,
Reshad.



On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)" 
 wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will kick 
off separate therads for each issue.


https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund" 
 wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.



o  3.1.1

o  In statements that have any data definition statements as
   substatements, those data definition substatements MAY be
   reordered, as long as they do not change the ordering or any 
"rpc"
   "input" substatements.

  I think this needs to capture that no descendant statements to
  "input" can be reordered.  Same for "output" (note, "input" and
  "output" in both "rpc" and "action").


o  3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted as
YANG semantic version numbers.

  I don't think this is a good idea.  Seems like a layer violation.
  What if my project use another dialect of semver, that wouldn't be
  possible with this rule.  I think this needs to be removed.


o  3.3

Submodules MUST NOT use revision label schemes that could be 
confused
with the including module's revision label scheme.

  Hmm, how do I ensure that this MUST NOT is handled correctly?  What
  exactly does "could be confused with" mean?


o  3.3

  In the filename of a YANG module, where it takes the form: module-
  or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

  Should this section update 5.2 of RFC 7950?  I know that 5.2 just
  says "SHOULD".  But existing tools implement this SHOULD, and they
  need to be updated to handle this new convention.

  But I wonder if this a good idea.  It means that a tool that looks
  for a module with a certain revision date cannot simply check the
  filenames, but need to parse all available modules (wijust to find 
the 



o  3.4

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated {
 rev:status-description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.";
   }
   description
 "Temperature in degrees Fahrenheit.";
 }

  I don't think rev:status-description is necessary / worth it.  This
  can easily be written with the normal description statement instead:

 leaf imperial-temperature {
   type int64;

[netmod] bool v/s empty for new leafs deprecated-nodes and obsolete-nodes (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

[Reshad Rahman (rrahman)]

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/52

o  5.2.2

  Wouldn't it be better if the leaf "deprecated-nodes-implemented" and
  "obsolete-nodes-absent" were of type "boolean" rather than type
  "empty"?

The bool v/s empty philosophical battle. I'm ok with boolean, I don't know if 
others have strong opinions on this.
If we go with boolean, if the leaf nodes are absent then the behaviour would be 
unspecified.

Regards,
Reshad.


On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)" 
 wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will kick 
off separate therads for each issue.


https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund" 
 wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.



o  3.1.1

o  In statements that have any data definition statements as
   substatements, those data definition substatements MAY be
   reordered, as long as they do not change the ordering or any 
"rpc"
   "input" substatements.

  I think this needs to capture that no descendant statements to
  "input" can be reordered.  Same for "output" (note, "input" and
  "output" in both "rpc" and "action").


o  3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted as
YANG semantic version numbers.

  I don't think this is a good idea.  Seems like a layer violation.
  What if my project use another dialect of semver, that wouldn't be
  possible with this rule.  I think this needs to be removed.


o  3.3

Submodules MUST NOT use revision label schemes that could be 
confused
with the including module's revision label scheme.

  Hmm, how do I ensure that this MUST NOT is handled correctly?  What
  exactly does "could be confused with" mean?


o  3.3

  In the filename of a YANG module, where it takes the form: module-
  or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

  Should this section update 5.2 of RFC 7950?  I know that 5.2 just
  says "SHOULD".  But existing tools implement this SHOULD, and they
  need to be updated to handle this new convention.

  But I wonder if this a good idea.  It means that a tool that looks
  for a module with a certain revision date cannot simply check the
  filenames, but need to parse all available modules (wijust to find 
the 



o  3.4

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated {
 rev:status-description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.";
   }
   description
 "Temperature in degrees Fahrenheit.";
 }

  I don't think rev:status-description is necessary / worth it.  This
  can easily be written with the normal description statement instead:

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated;
   description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.

Temperature in degrees Fahrenheit.";
 }


o  3.5

  The example modules should be legal YANG modules.  Use e.g. 
  "urn:example:module" as namespace.

  Also, the modules are missing the last "}", which confuses the
  "rfcstrip" tool.


o 4.1.1

Alternatively, the first example could have used the revision label
"1.0.0" instead, which selects the same set of revisions/versions.

  

[netmod] Revision label in filename (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

[Reshad Rahman (rrahman)]

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/50

o  3.3

  In the filename of a YANG module, where it takes the form: module-
  or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

  Should this section update 5.2 of RFC 7950?  I know that 5.2 just
  says "SHOULD".  But existing tools implement this SHOULD, and they
  need to be updated to handle this new convention.

  But I wonder if this a good idea.  It means that a tool that looks
  for a module with a certain revision date cannot simply check the
  filenames, but need to parse all available modules (wijust to find the

We agree that there is an impact on searching by date. We put this in to have 
the ability to search by revision-label, otherwise we can search just by date 
for a module which uses revision-label.
We had also discussed using different limiter for the label and have something 
along the lines of: module-or-submodule-name['@'date]['#'revision-label].yang
It'd seem that updating 7950 would be a good idea whichever way we go.

Regards,
Reshad.


On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)" 
 wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will kick 
off separate therads for each issue.


https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund" 
 wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.



o  3.1.1

o  In statements that have any data definition statements as
   substatements, those data definition substatements MAY be
   reordered, as long as they do not change the ordering or any 
"rpc"
   "input" substatements.

  I think this needs to capture that no descendant statements to
  "input" can be reordered.  Same for "output" (note, "input" and
  "output" in both "rpc" and "action").


o  3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted as
YANG semantic version numbers.

  I don't think this is a good idea.  Seems like a layer violation.
  What if my project use another dialect of semver, that wouldn't be
  possible with this rule.  I think this needs to be removed.


o  3.3

Submodules MUST NOT use revision label schemes that could be 
confused
with the including module's revision label scheme.

  Hmm, how do I ensure that this MUST NOT is handled correctly?  What
  exactly does "could be confused with" mean?


o  3.3

  In the filename of a YANG module, where it takes the form: module-
  or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

  Should this section update 5.2 of RFC 7950?  I know that 5.2 just
  says "SHOULD".  But existing tools implement this SHOULD, and they
  need to be updated to handle this new convention.

  But I wonder if this a good idea.  It means that a tool that looks
  for a module with a certain revision date cannot simply check the
  filenames, but need to parse all available modules (wijust to find 
the 



o  3.4

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated {
 rev:status-description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.";
   }
   description
 "Temperature in degrees Fahrenheit.";
 }

  I don't think rev:status-description is necessary / worth it.  This
  can easily be written with the normal description statement instead:

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated;
   description
   "Imperial measurements are being phased out in favor
of their metric equivale

[netmod] rev:status-description (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

[Reshad Rahman (rrahman)]

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/51

o  3.4

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated {
 rev:status-description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.";
   }
   description
 "Temperature in degrees Fahrenheit.";
 }

  I don't think rev:status-description is necessary / worth it.  This
  can easily be written with the normal description statement instead:

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated;
   description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.

Temperature in degrees Fahrenheit.";
 }

While rev:status-description isn't strictly necessary, without it we'd have to 
modify the node's description as you pointed out. That'd make tooling more 
difficult: is the description change BC or NBC? Also, a user looking at a diff 
would need to go through the description change. Use of  rev:status-description 
makes this easier to handle.

Regards,
Reshad.



On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)" 
 wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will kick 
off separate therads for each issue.


https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund" 
 wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.



o  3.1.1

o  In statements that have any data definition statements as
   substatements, those data definition substatements MAY be
   reordered, as long as they do not change the ordering or any 
"rpc"
   "input" substatements.

  I think this needs to capture that no descendant statements to
  "input" can be reordered.  Same for "output" (note, "input" and
  "output" in both "rpc" and "action").


o  3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted as
YANG semantic version numbers.

  I don't think this is a good idea.  Seems like a layer violation.
  What if my project use another dialect of semver, that wouldn't be
  possible with this rule.  I think this needs to be removed.


o  3.3

Submodules MUST NOT use revision label schemes that could be 
confused
with the including module's revision label scheme.

  Hmm, how do I ensure that this MUST NOT is handled correctly?  What
  exactly does "could be confused with" mean?


o  3.3

  In the filename of a YANG module, where it takes the form: module-
  or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

  Should this section update 5.2 of RFC 7950?  I know that 5.2 just
  says "SHOULD".  But existing tools implement this SHOULD, and they
  need to be updated to handle this new convention.

  But I wonder if this a good idea.  It means that a tool that looks
  for a module with a certain revision date cannot simply check the
  filenames, but need to parse all available modules (wijust to find 
the 



o  3.4

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated {
 rev:status-description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.";
   }
   description
 "Temperature in degrees Fahrenheit.";
 }

  I don't think rev:status-description is necessary / worth it.  This
  can easily 

[netmod] Interpreting revision labels as YANG semantic version numbers (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

[Reshad Rahman (rrahman)]

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/48

o  3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted as
YANG semantic version numbers.

  I don't think this is a good idea.  Seems like a layer violation.
  What if my project use another dialect of semver, that wouldn't be
  possible with this rule.  I think this needs to be removed.

Without this, applications cannot know what versioning scheme is being used, or 
they have to guess, or the module would need another statement to declare what 
versioning scheme is being used. Maybe we should go with the latter.

Regards,
Reshad.

On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)" 
 wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will kick 
off separate therads for each issue.


https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund" 
 wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.



o  3.1.1

o  In statements that have any data definition statements as
   substatements, those data definition substatements MAY be
   reordered, as long as they do not change the ordering or any 
"rpc"
   "input" substatements.

  I think this needs to capture that no descendant statements to
  "input" can be reordered.  Same for "output" (note, "input" and
  "output" in both "rpc" and "action").


o  3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted as
YANG semantic version numbers.

  I don't think this is a good idea.  Seems like a layer violation.
  What if my project use another dialect of semver, that wouldn't be
  possible with this rule.  I think this needs to be removed.


o  3.3

Submodules MUST NOT use revision label schemes that could be 
confused
with the including module's revision label scheme.

  Hmm, how do I ensure that this MUST NOT is handled correctly?  What
  exactly does "could be confused with" mean?


o  3.3

  In the filename of a YANG module, where it takes the form: module-
  or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

  Should this section update 5.2 of RFC 7950?  I know that 5.2 just
  says "SHOULD".  But existing tools implement this SHOULD, and they
  need to be updated to handle this new convention.

  But I wonder if this a good idea.  It means that a tool that looks
  for a module with a certain revision date cannot simply check the
  filenames, but need to parse all available modules (wijust to find 
the 



o  3.4

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated {
 rev:status-description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.";
   }
   description
 "Temperature in degrees Fahrenheit.";
 }

  I don't think rev:status-description is necessary / worth it.  This
  can easily be written with the normal description statement instead:

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated;
   description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.

Temperature in degrees Fahrenheit.";
 }


o  3.5

  The example modules should be legal YANG modules.  Use e.g. 
  "urn:example:module" as namespace.

  Also, the modules are missing the last "}", which confuses the
  "rfcstrip" tool.
 

[netmod] No descendent statements to input/output can be reordered (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

[Reshad Rahman (rrahman)]

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/47

o  3.1.1

o  In statements that have any data definition statements as
   substatements, those data definition substatements MAY be
   reordered, as long as they do not change the ordering or any 
"rpc"
   "input" substatements.

  I think this needs to capture that no descendant statements to
  "input" can be reordered.  Same for "output" (note, "input" and
  "output" in both "rpc" and "action").


Sounds good. JTBC, by descendent you're referring to data nodes (children, 
grandchildren etc) and not to statements like type and description?

Also, could you refresh our memory why the decision was made to preserve order 
of input/output data nodes?

Regards,
Reshad.

On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)" 
 wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will kick 
off separate therads for each issue.


https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund" 
 wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.



o  3.1.1

o  In statements that have any data definition statements as
   substatements, those data definition substatements MAY be
   reordered, as long as they do not change the ordering or any 
"rpc"
   "input" substatements.

  I think this needs to capture that no descendant statements to
  "input" can be reordered.  Same for "output" (note, "input" and
  "output" in both "rpc" and "action").


o  3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted as
YANG semantic version numbers.

  I don't think this is a good idea.  Seems like a layer violation.
  What if my project use another dialect of semver, that wouldn't be
  possible with this rule.  I think this needs to be removed.


o  3.3

Submodules MUST NOT use revision label schemes that could be 
confused
with the including module's revision label scheme.

  Hmm, how do I ensure that this MUST NOT is handled correctly?  What
  exactly does "could be confused with" mean?


o  3.3

  In the filename of a YANG module, where it takes the form: module-
  or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

  Should this section update 5.2 of RFC 7950?  I know that 5.2 just
  says "SHOULD".  But existing tools implement this SHOULD, and they
  need to be updated to handle this new convention.

  But I wonder if this a good idea.  It means that a tool that looks
  for a module with a certain revision date cannot simply check the
  filenames, but need to parse all available modules (wijust to find 
the 



o  3.4

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated {
 rev:status-description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.";
   }
   description
 "Temperature in degrees Fahrenheit.";
 }

  I don't think rev:status-description is necessary / worth it.  This
  can easily be written with the normal description statement instead:

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated;
   description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.

Temperature in degrees Fahrenheit.";
 }


o  3.5

  The example modules should be legal YANG modules.  Use e.g. 
  "urn:example:module

[netmod] Revision labels for submodules (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

[Reshad Rahman (rrahman)]

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/49

o  3.3

Submodules MUST NOT use revision label schemes that could be 
confused
with the including module's revision label scheme.

  Hmm, how do I ensure that this MUST NOT is handled correctly?  What
  exactly does "could be confused with" mean?

Good point. What was meant by that the label space for modules and sub-modules 
are orthogonal.  e.g. the sub-module and module both have the same label, it 
shouldn't be inferred that the 2 are related. 
We'll change/clarify the text.

Regards,
Reshad.

On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)" 
 wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will kick 
off separate therads for each issue.


https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund" 
 wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.



o  3.1.1

o  In statements that have any data definition statements as
   substatements, those data definition substatements MAY be
   reordered, as long as they do not change the ordering or any 
"rpc"
   "input" substatements.

  I think this needs to capture that no descendant statements to
  "input" can be reordered.  Same for "output" (note, "input" and
  "output" in both "rpc" and "action").


o  3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted as
YANG semantic version numbers.

  I don't think this is a good idea.  Seems like a layer violation.
  What if my project use another dialect of semver, that wouldn't be
  possible with this rule.  I think this needs to be removed.


o  3.3

Submodules MUST NOT use revision label schemes that could be 
confused
with the including module's revision label scheme.

  Hmm, how do I ensure that this MUST NOT is handled correctly?  What
  exactly does "could be confused with" mean?


o  3.3

  In the filename of a YANG module, where it takes the form: module-
  or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

  Should this section update 5.2 of RFC 7950?  I know that 5.2 just
  says "SHOULD".  But existing tools implement this SHOULD, and they
  need to be updated to handle this new convention.

  But I wonder if this a good idea.  It means that a tool that looks
  for a module with a certain revision date cannot simply check the
  filenames, but need to parse all available modules (wijust to find 
the 



o  3.4

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated {
 rev:status-description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.";
   }
   description
 "Temperature in degrees Fahrenheit.";
 }

  I don't think rev:status-description is necessary / worth it.  This
  can easily be written with the normal description statement instead:

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated;
   description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.

Temperature in degrees Fahrenheit.";
 }


o  3.5

  The example modules should be legal YANG modules.  Use e.g. 
  "urn:example:module" as namespace.

  Also, the modules are missing the last "}", which confuses the
  "rfcstrip" tool.


o 4.1.1

Alternatively, the first example could have used the revision label
&quo

[netmod] All IETF YANG modules MUST include revision-label statements (WAS Re: mbj review of draft-verdt-netmod-yang-module-versioning-01)

[Reshad Rahman (rrahman)]

Hi,

https://github.com/netmod-wg/yang-ver-dt/issues/45

o  7.1

  The text says:

All IETF YANG modules MUST include revision-label statements for all
newly published YANG modules, and all newly published revisions of
existing YANG modules.  The revision-label MUST take the form of a
YANG semantic version number [I-D.verdt-netmod-yang-semver].

  I strongly disagree with this new rule.  IETF modules use a linear
  history, so there are no reasons to use "modified semver".

  It is ok to use rev:nbc-changes if needed, though.

We believe some IETF models may not follow linear history, this was brought up 
(I think) for IDR. Modified semver allows for non-linear history and also 
doesn't preclude linear history. So even if we end up having no IETF modules 
using branching, modified semver still works.

Regards,
Reshad.


On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)" 
 wrote:

Hi Martin,

We've opened issues to track your review comments (see below). Will kick 
off separate therads for each issue.


https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund" 
 wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.



o  3.1.1

o  In statements that have any data definition statements as
   substatements, those data definition substatements MAY be
   reordered, as long as they do not change the ordering or any 
"rpc"
   "input" substatements.

  I think this needs to capture that no descendant statements to
  "input" can be reordered.  Same for "output" (note, "input" and
  "output" in both "rpc" and "action").


o  3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted as
YANG semantic version numbers.

  I don't think this is a good idea.  Seems like a layer violation.
  What if my project use another dialect of semver, that wouldn't be
  possible with this rule.  I think this needs to be removed.


o  3.3

Submodules MUST NOT use revision label schemes that could be 
confused
with the including module's revision label scheme.

  Hmm, how do I ensure that this MUST NOT is handled correctly?  What
  exactly does "could be confused with" mean?


o  3.3

  In the filename of a YANG module, where it takes the form: module-
  or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

  Should this section update 5.2 of RFC 7950?  I know that 5.2 just
  says "SHOULD".  But existing tools implement this SHOULD, and they
  need to be updated to handle this new convention.

  But I wonder if this a good idea.  It means that a tool that looks
  for a module with a certain revision date cannot simply check the
  filenames, but need to parse all available modules (wijust to find 
the 



o  3.4

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated {
 rev:status-description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.";
   }
   description
 "Temperature in degrees Fahrenheit.";
 }

  I don't think rev:status-description is necessary / worth it.  This
  can easily be written with the normal description statement instead:

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated;
   description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.

Temperature in degrees Fahrenheit.";
 }


o  3.5

  The example modules should be legal YANG modules.  Use e.g. 
   

Re: [netmod] mbj review of draft-verdt-netmod-yang-module-versioning-01

[Reshad Rahman (rrahman)]

Hi Martin,

We've opened issues to track your review comments (see below). Will kick off 
separate therads for each issue.

https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling

Regards,
Reshad.

On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund" 
 wrote:

Hi,

Here are my review comments of
draft-verdt-netmod-yang-module-versioning-01.



o  3.1.1

o  In statements that have any data definition statements as
   substatements, those data definition substatements MAY be
   reordered, as long as they do not change the ordering or any "rpc"
   "input" substatements.

  I think this needs to capture that no descendant statements to
  "input" can be reordered.  Same for "output" (note, "input" and
  "output" in both "rpc" and "action").


o  3.3

All revision labels that match the pattern for the "version"
typedef in the ietf-yang-semver YANG module MUST be interpreted as
YANG semantic version numbers.

  I don't think this is a good idea.  Seems like a layer violation.
  What if my project use another dialect of semver, that wouldn't be
  possible with this rule.  I think this needs to be removed.


o  3.3

Submodules MUST NOT use revision label schemes that could be confused
with the including module's revision label scheme.

  Hmm, how do I ensure that this MUST NOT is handled correctly?  What
  exactly does "could be confused with" mean?


o  3.3

  In the filename of a YANG module, where it takes the form: module-
  or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

  Should this section update 5.2 of RFC 7950?  I know that 5.2 just
  says "SHOULD".  But existing tools implement this SHOULD, and they
  need to be updated to handle this new convention.

  But I wonder if this a good idea.  It means that a tool that looks
  for a module with a certain revision date cannot simply check the
  filenames, but need to parse all available modules (wijust to find the 



o  3.4

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated {
 rev:status-description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.";
   }
   description
 "Temperature in degrees Fahrenheit.";
 }

  I don't think rev:status-description is necessary / worth it.  This
  can easily be written with the normal description statement instead:

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated;
   description
   "Imperial measurements are being phased out in favor
of their metric equivalents.  Use metric-temperature
instead.

Temperature in degrees Fahrenheit.";
 }


o  3.5

  The example modules should be legal YANG modules.  Use e.g. 
  "urn:example:module" as namespace.

  Also, the modules are missing the last "}", which confuses the
  "rfcstrip" tool.


o 4.1.1

Alternatively, the first example could have used the revision label
"1.0.0" instead, which selects the same set of revisions/versions.

import example-module {
  rev:revision-or-derived 1.0.0;
}

  Shouldn't this be s/1.0.0/2.0.0/g ?


o  5

  I think the module name "ietf-yl-revisions" should be changed to
  "ietf-yang-library-revisions".   "yl" is not a well-known acronym.


o  5.2.2

  Wouldn't it be better if the leaf "deprecated-nodes-implemented" and
  "obsolete-nodes-absent" were of type "boolean" rather than type
  "empty"?


o  7.1

  The text says:

All IETF YANG modules MUST include revision-label statements for all
newly published YANG modules, and all newly published revisions of
existing YANG modules.  The revision-label MUST take the form of a
YANG semantic version number [I-D.verdt-netmod-yang-semver].

  I strongly disagree with this new rule.  IETF modules use a linear
  history, so there are no reasons to use "modified semver".

  It is ok to use rev:nbc-changes if needed, though.


o 7.1.1

  There is a missing " in:

   4.  For status "obsolete", it is RECOMMENDED to keep the "status-
   description" information, from when the node had status
   "deprecated, which is still relevant.
 HERE  ---^


o  8

  s/CODE ENDS>//