Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Kent Watsen]

WG,

The chairs want to follow up on this Last Call. 

We had some excellent discussion and wanted to ensure that that discussion had 
time to play out.  We think think that there is still a path forward for "rough 
consensus" on the these drafts.  To help move the discussion to closure and aid 
in judging overall WG consensus (beyond just those who have already voiced an 
opinion on the list), we have asked the draft authors to put together a summary 
of key open issues/questions, to send their summary  to the list, and then to 
lead a discussion on these issues during our meeting at IETF 117.  Please do 
feel free to continue the discussion on the list. We are particularly 
interested in hearing from those who have not yet voiced their opinions - both 
on list, and in the meeting.

We appreciate all who have contributed over this extended effort - notably 
those who have spent many hours in the regular working meetings.

Thank you,
Lou and Kent




> On May 8, 2023, at 6:49 PM, Kent Watsen  wrote:
> 
> Dear NETMOD WG,
> 
> This message begins a joint two-week WGLC for 
> draft-ietf-netmod-yang-semver-11 and 
> draft-ietf-netmod-yang-module-versioning-09
> ending on Monday, May 22nd.  Neither draft has IPR declared.  Here are the 
> direct links to the HTML version for these drafts:
> 
>   - https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver-11
>   - 
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-09
> 
> 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 and Lou (chairs)
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> 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] Joint WGLC on "semver" and "module-versioning" drafts

[Robert Varga]

On 13/06/2023 17.21, Ladislav Lhotka wrote:

Dne 13. 06. 23 v 17:07 Robert Varga napsal(a):

On 05/06/2023 11.46, Martin Björklund wrote:
   - introduce new instance-identifier data type based on RFC 7951 
definition

   - introduce new identityref data type based on RFC 7951 definition

... but I do agree with these!


I am not sure I follow... is this about providing 
instance-identifier/identityref encoding which does not rely on XML 
namespaces, or something else?


Yes, it's about using module name as the namespace identifier (prefix).


Ah, okay. Can we do this without introducing new data types, please?

After all this is essentially just how those datatypes are encoded -- 
and hence a revised media-type (for RESTCONF et al.) and protocol 
negotiation (for NETCONF) should be sufficient.


I don't think we need two data types for each of those in the language 
metamodel just to deal with how they are encoded after all.


Regards,
Robert


OpenPGP_signature
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Rob Wilton (rwilton)]

> -Original Message-
> From: tom petch 
> Sent: 26 June 2023 16:41
> To: Rob Wilton (rwilton) ; Martin Björklund
> 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts
> 
> From: Rob Wilton (rwilton) 
> Sent: 26 June 2023 13:01
> 
> Hi Tom,
> 
> > -Original Message-
> > From: tom petch 
> > Sent: 26 June 2023 12:57
> >
> > From: netmod  on behalf of Rob Wilton (rwilton)
> > 
> > Sent: 13 June 2023 17:25
> >
> > Hi Martin,
> >
> > > -Original Message-
> > > From: netmod  On Behalf Of Martin Björklund
> > > Sent: 07 June 2023 08:22
> > >
> > > But the two drafts go way beyond fixing the problem your three
> > > examples illustrate.
> > [Rob Wilton (rwilton)]
> >
> > The actual goals of this work (i.e., the set of drafts) is aiming to 
> > address the
> > requirements stated here: https://datatracker.ietf.org/doc/html/draft-ietf-
> > netmod-yang-versioning-reqs-07.  Although never taken to RFC, I believe was
> > effectively last called and achieved WG consensus for the NETMOD WG.
> > Hopefully the chairs can chime in and keep me honest if I'm wrong on this
> > point.
> >
> > 
> > May be or may be not but there is no such I-D in the datatracker for NETMOD
> > nor can it be downloaded from the FTP site so effectively there are no
> > requirements to justify this substantial change.  Based on what I can 
> > access,
> the
> > module versioning I-D does not look like a good idea.
> [Rob Wilton (rwilton)]
> 
> Are you saying that you are unable to access the link above, i.e.,
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-versioning-reqs-
> 07
> 
> Or are you saying that because this is currently an expired draft it isn't 
> valid, in
> which case, that would seem to be trivial to fix?
> 
> 
> I am saying that to review a draft, I download it in plain text and edit it 
> and my
> first choice is to look for it in
> https://www.ietf.org/ietf-ftp/internet-drafts/]
> and this draft is not there.
> My second choice is the datatracker for the WG, NETMOD in this case, under
> Active Internet Drafts and again it is not there.  At that point, I do not 
> look
> further, at least not during WGLC
[Rob Wilton (rwilton)] 

Okay.  In this particular case, I don't think that the fact that it isn't an 
active draft should prevent you from considering its contents as having achieve 
WG consensus.  But Joe Clarke, the editor for that document, is in the process 
of republishing it as -08.

Regards,
Rob


> 
> Tom Petch
> 
> Regards,
> Rob
> 
> 
> >
> > Tom Petch
> >
> > The shape/structure/content of the drafts is very similar to when these
> > documents were adopted in March 2020:
> >
> > Your comments on these document at adoption time are here
> >
> (https://mailarchive.ietf.org/arch/msg/netmod/r5TD0NDNgUbtX9EHZfB5hJJctN
> > 8/).  From that email, it is clear that you didn't support the YANG Semver
> > scheme, but my reading is that you were broadly supportive of the YANG
> > module versioning draft.
> >
> > Here are your review comments of the YANG module versioning draft at
> > adoption time:
> >
> https://mailarchive.ietf.org/arch/msg/netmod/MTGomxcdyNOmB7mgsFhItLKN
> > Jgk/
> >
> > Here is a thread where you are discussing supporting different revision 
> > label
> > schemes:
> >
> https://mailarchive.ietf.org/arch/msg/netmod/cEBiZKUSk0n7BeFwdiyaejc_Tsg/
> >
> > I appreciate that everyone has the right to change their mind at any point,
> but
> > as stated previously, I don't think that the shape of the solution has 
> > really
> > changed substantially since they were adopted.
> >
> >
> >   If the goal is to indicate that non-backwards
> > > compatible changes have occured, a single new extension statement
> > > could solve that.  (As I probably have stated before, personally I
> > > don't think this is necessary).
> >
> > That is one goal.  Another is to acknowledge that non-backwards-compatible
> > changes will occur, potentially even on branches.  Another is to align with 
> > the
> > versioning scheme that is being broadly used by the industry (but with
> > extensions to support a branched history).
> >
> >
> > >
> > > Apart from the updates to RFC 7950 section 11, I am mostly concerned
> > > about the additional complexity the "pluggable" revision-label scheme
> > > brings

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[tom petch]

nterested individuals
> > > working on this area has presented updated drafts and updates to the
> > > work at every IETF meeting for the last, 4+ years.  Feedback at the
> > > various stages/reviews/etc has always been considered, the authors
> > > meetings have always been open, and I don't believe that the solution
> > > drafts being taken to WG LC are architecturally significantly
> > > different from the direction agreed during WG adoption of the
> > > documents, although I do think that the documents are much improved
> > > based on the feedback received.
> > >
> > > I also appreciate that Juergen has always publicly stated that this
> > > work should be done as an update to the YANG language, but my
> > > recollection was that he was in the rough on this issue, i.e., during
> > > WG adoption, and since, at least until this IETF WG LC review.
> > >
> > > Hence, my concern, as an AD, is that if, after 5 years, the WG now
> > > wants to take a fundamentally different path to standardizing this
> > > work then I have concerns that the NETMOD WG isn't really functioning
> > > properly and cohesively as a WG, and I'm very concerned that we won't
> > > find any viable way forward for this work.  I doubt that it will be
> > > possible to get any quick consensus by opening up RFC 7950.  We may
> > > also find that the individuals who have invested a significant amount
> > > of time and effort on this work don't have the desire or energy to
> > > start from scratch again, when they have a solution that is good
> > > enough for their needs.
> > >
> > > If I understand correctly, the fundamental objection to the module
> > > versioning draft is around the updates to section 11 of RFC 7950,
> > > which effectively state that changes MUST be backwards compatible,
> > > whereas this draft states SHOULD be backwards compatible, without a
> > > change to the YANG version number.  Is that correct?
> > >
> > > If the existing deployment and evolution of YANG modules among
> > > vendors, OpenConfig, IETF, and other SDOs strictly followed the rules
> > > in RFC 7950 then I would probably agree that an update from YANG 1.1
> > > to YANG 1.2 is needed.  But I think that the reality is that tools
> > > must handle non-backwards compatible changes frequently happening in
> > > YANG 1.0 (OpenConfig) and YANG 1.1 YANG modules anyway.  I.e., I don't
> > > believe that the "YANG 1.1 no breaking change contract" is being
> > > widely honoured anyway, and instead is being treated as a goal or
> > > aspiration.  What these documents attempt to do is to move YANG module
> > > evolution from what we currently have now where clients don't have any
> > > way of really knowing how a module has evolved and whether they are
> > > impacted to one that they do, and as part of that process they are
> > > aiming to update the YANG versioning rules to better reflect how is it
> > > being deployed and used.
> > >
> > > Hence, as am author, I still of the opinion that the best pragmatic
> > > path forward is to try and get these documents to a shape where they
> > > achieve rough consensus and are acceptable to the WG to be published
> > > now, in the short term, as a good enough solution.  After that point,
> > > then I think that it would be great for some folks to form an idea on
> > > a what YANG 1.2/2.0 could look like, but I think that coupling these
> > > goals together would be a mistake.
> > >
> > > Regards,
> > > Rob
> > >
> > > // Who doesn't really know which hat he is wearing for this comment,
> > > but is only trying to do the right thing for the wider industry ...
> > >
> > >
> > > > -Original Message-
> > > > From: netmod  On Behalf Of Jürgen
> > Schönwälder
> > > > Sent: 06 June 2023 06:07
> > > > To: Martin Björklund 
> > > > Cc: netmod@ietf.org
> > > > Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning"
> > > > drafts
> > > >
> > > > On Mon, Jun 05, 2023 at 10:32:51PM +0200, Martin Björklund wrote:
> > > > > >
> > > > > > If the goal is to produce YANG 1.2 which (i) integrates semantic
> > > > > > versioning into YANG and (ii) fixes known bugs in YANG 1.1 and (iii)
> > > > > > does not add any other new features, then having agreement on such
> a
> > > > > > statement will help to steer the process.
> > > > >
> > > > > I hope that (i) doesn't happen.  I think it is the proposed changes in
> > > > > draft-ietf-netmod-yang-module-versioning that require a new YANG
> > > > > version.  If this new YANG version allows for other versioning schemes
> > > > > than revision-date, then we can keep the modified semver scheme
> > > > > outside the core document.
> > > > >
> > > >
> > > > I consider the module update rules a part of a versioning model. The
> > > > current update rules were written to support the current versioning
> > > > model. If we want to support multiple versioning models, then we have
> > > > to refactor the update rules out of the YANG language specification
> > > > into separate versioning specifications, i.e., traditional YANG
> > > > versioning and the new semver versioning. There are some language
> > > > mechanisms (like the import statement), that have to be flexible
> > > > enough to support multiple versioning schemes.
> > > >
> > > > Is it worth factoring the versioning model out of the language? I
> > > > guess the opinions vary widely on this, depending on the dynamics of
> > > > the software environment people are working in.
> > > >
> > > > /js
> > > >
> > > > --
> > > > 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 <https://constructor.university/>
> > > >
> > > > ___
> > > > 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
> ___
> 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] Joint WGLC on "semver" and "module-versioning" drafts

[Rob Wilton (rwilton)]

Hi Tom,

> -Original Message-
> From: tom petch 
> Sent: 26 June 2023 12:57
> To: Rob Wilton (rwilton) ; Martin Björklund
> 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts
> 
> From: netmod  on behalf of Rob Wilton (rwilton)
> 
> Sent: 13 June 2023 17:25
> 
> Hi Martin,
> 
> > -Original Message-
> > From: netmod  On Behalf Of Martin Björklund
> > Sent: 07 June 2023 08:22
> >
> > But the two drafts go way beyond fixing the problem your three
> > examples illustrate.
> [Rob Wilton (rwilton)]
> 
> The actual goals of this work (i.e., the set of drafts) is aiming to address 
> the
> requirements stated here: https://datatracker.ietf.org/doc/html/draft-ietf-
> netmod-yang-versioning-reqs-07.  Although never taken to RFC, I believe was
> effectively last called and achieved WG consensus for the NETMOD WG.
> Hopefully the chairs can chime in and keep me honest if I'm wrong on this
> point.
> 
> 
> May be or may be not but there is no such I-D in the datatracker for NETMOD
> nor can it be downloaded from the FTP site so effectively there are no
> requirements to justify this substantial change.  Based on what I can access, 
> the
> module versioning I-D does not look like a good idea.
[Rob Wilton (rwilton)] 

Are you saying that you are unable to access the link above, i.e., 
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-versioning-reqs-07

Or are you saying that because this is currently an expired draft it isn't 
valid, in which case, that would seem to be trivial to fix?

Regards,
Rob


> 
> Tom Petch
> 
> The shape/structure/content of the drafts is very similar to when these
> documents were adopted in March 2020:
> 
> Your comments on these document at adoption time are here
> (https://mailarchive.ietf.org/arch/msg/netmod/r5TD0NDNgUbtX9EHZfB5hJJctN
> 8/).  From that email, it is clear that you didn't support the YANG Semver
> scheme, but my reading is that you were broadly supportive of the YANG
> module versioning draft.
> 
> Here are your review comments of the YANG module versioning draft at
> adoption time:
> https://mailarchive.ietf.org/arch/msg/netmod/MTGomxcdyNOmB7mgsFhItLKN
> Jgk/
> 
> Here is a thread where you are discussing supporting different revision label
> schemes:
> https://mailarchive.ietf.org/arch/msg/netmod/cEBiZKUSk0n7BeFwdiyaejc_Tsg/
> 
> I appreciate that everyone has the right to change their mind at any point, 
> but
> as stated previously, I don't think that the shape of the solution has really
> changed substantially since they were adopted.
> 
> 
>   If the goal is to indicate that non-backwards
> > compatible changes have occured, a single new extension statement
> > could solve that.  (As I probably have stated before, personally I
> > don't think this is necessary).
> 
> That is one goal.  Another is to acknowledge that non-backwards-compatible
> changes will occur, potentially even on branches.  Another is to align with 
> the
> versioning scheme that is being broadly used by the industry (but with
> extensions to support a branched history).
> 
> 
> >
> > Apart from the updates to RFC 7950 section 11, I am mostly concerned
> > about the additional complexity the "pluggable" revision-label scheme
> > brings.
> [Rob Wilton (rwilton)]
> 
> It feels like we are somewhat going in circles:
> 
> 1.The original proposal was to embed regular Semver 2.0.0 for the version
> numbers.
> 
> 2. That scheme was extended to what is being labelled as "Yang Semver"
> because regular Semver didn't support some level of branching that the
> vendors require to support customers on older releases over a much longer
> time period.  Semver 2.0.0 works best when the updates are always committed
> to the head of a linear sequence of versions, and if a bug needs to be fixed 
> in
> an older version then the user is forced to migrate to the latest version.
> 
> 3. If I recall correctly, you didn't like YANG Semver (and possibly not even
> Semver), and if I also recall correctly from a conversation then I think that 
> it is
> because you envisaged more advanced branching schemes and perhaps a
> version number scheme that follows branch history (and hence cannot also
> contain semantic meaning).  Based on that feedback, and an in-person side
> meeting, we moved to a revision label scheme, an nbc-marker, and
> standardizing a versioning scheme to fit into the revision-label scheme
> separately.  This was all in place when these documents were adopted.
> 
> Based on those who are or have participated in the weekly calls, I also 
>

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[tom petch]

YANG modules among
> > vendors, OpenConfig, IETF, and other SDOs strictly followed the rules
> > in RFC 7950 then I would probably agree that an update from YANG 1.1
> > to YANG 1.2 is needed.  But I think that the reality is that tools
> > must handle non-backwards compatible changes frequently happening in
> > YANG 1.0 (OpenConfig) and YANG 1.1 YANG modules anyway.  I.e., I don't
> > believe that the "YANG 1.1 no breaking change contract" is being
> > widely honoured anyway, and instead is being treated as a goal or
> > aspiration.  What these documents attempt to do is to move YANG module
> > evolution from what we currently have now where clients don't have any
> > way of really knowing how a module has evolved and whether they are
> > impacted to one that they do, and as part of that process they are
> > aiming to update the YANG versioning rules to better reflect how is it
> > being deployed and used.
> >
> > Hence, as am author, I still of the opinion that the best pragmatic
> > path forward is to try and get these documents to a shape where they
> > achieve rough consensus and are acceptable to the WG to be published
> > now, in the short term, as a good enough solution.  After that point,
> > then I think that it would be great for some folks to form an idea on
> > a what YANG 1.2/2.0 could look like, but I think that coupling these
> > goals together would be a mistake.
> >
> > Regards,
> > Rob
> >
> > // Who doesn't really know which hat he is wearing for this comment,
> > but is only trying to do the right thing for the wider industry ...
> >
> >
> > > -Original Message-
> > > From: netmod  On Behalf Of Jürgen
> Schönwälder
> > > Sent: 06 June 2023 06:07
> > > To: Martin Björklund 
> > > Cc: netmod@ietf.org
> > > Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning"
> > > drafts
> > >
> > > On Mon, Jun 05, 2023 at 10:32:51PM +0200, Martin Björklund wrote:
> > > > >
> > > > > If the goal is to produce YANG 1.2 which (i) integrates semantic
> > > > > versioning into YANG and (ii) fixes known bugs in YANG 1.1 and (iii)
> > > > > does not add any other new features, then having agreement on such a
> > > > > statement will help to steer the process.
> > > >
> > > > I hope that (i) doesn't happen.  I think it is the proposed changes in
> > > > draft-ietf-netmod-yang-module-versioning that require a new YANG
> > > > version.  If this new YANG version allows for other versioning schemes
> > > > than revision-date, then we can keep the modified semver scheme
> > > > outside the core document.
> > > >
> > >
> > > I consider the module update rules a part of a versioning model. The
> > > current update rules were written to support the current versioning
> > > model. If we want to support multiple versioning models, then we have
> > > to refactor the update rules out of the YANG language specification
> > > into separate versioning specifications, i.e., traditional YANG
> > > versioning and the new semver versioning. There are some language
> > > mechanisms (like the import statement), that have to be flexible
> > > enough to support multiple versioning schemes.
> > >
> > > Is it worth factoring the versioning model out of the language? I
> > > guess the opinions vary widely on this, depending on the dynamics of
> > > the software environment people are working in.
> > >
> > > /js
> > >
> > > --
> > > 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 <https://constructor.university/>
> > >
> > > ___
> > > 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
___
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] Joint WGLC on "semver" and "module-versioning" drafts

[Andy Bierman]

On Wed, Jun 14, 2023 at 3:00 AM Martin Björklund  wrote:

> "Rob Wilton (rwilton)"  wrote:
> > Hi Martin,
> >
> > > -Original Message-
> > > From: netmod  On Behalf Of Martin Björklund
> > > Sent: 07 June 2023 08:22
> > > To: rwilton=40cisco@dmarc.ietf.org
> > > Cc: netmod@ietf.org
> > > Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning"
> > > drafts
> > >
> > > Hi,
> > >
> > > But the two drafts go way beyond fixing the problem your three
> > > examples illustrate.
> > [Rob Wilton (rwilton)]
> >
> > The actual goals of this work (i.e., the set of drafts) is aiming to
> > address the requirements stated here:
> >
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-versioning-reqs-07
> .
> > Although never taken to RFC, I believe was effectively last called and
> > achieved WG consensus for the NETMOD WG.  Hopefully the chairs can
> > chime in and keep me honest if I'm wrong on this point.
> >
> > The shape/structure/content of the drafts is very similar to when
> > these documents were adopted in March 2020:
> >
> > Your comments on these document at adoption time are here
> > (
> https://mailarchive.ietf.org/arch/msg/netmod/r5TD0NDNgUbtX9EHZfB5hJJctN8/
> ).
> > From that email, it is clear that you didn't support the YANG Semver
> > scheme, but my reading is that you were broadly supportive of the YANG
> > module versioning draft.
> >
> > Here are your review comments of the YANG module versioning draft at
> > adoption time:
> >
> https://mailarchive.ietf.org/arch/msg/netmod/MTGomxcdyNOmB7mgsFhItLKNJgk/
> >
> > Here is a thread where you are discussing supporting different
> > revision label schemes:
> >
> https://mailarchive.ietf.org/arch/msg/netmod/cEBiZKUSk0n7BeFwdiyaejc_Tsg/
> >
> > I appreciate that everyone has the right to change their mind at any
> > point, but as stated previously, I don't think that the shape of the
> > solution has really changed substantially since they were adopted.
>
> I'm not sure that I have changed my mind on this topic (but if I have
> I view that as a good thing; it means I'm open to new technical
> arguments ;-)
>
> I don't think I have ever said that this is important work.  I can
> live with optional extension statements that indicate nbc changes, and
> even that another optional revision label scheme is used, but I do
> think it adds unnecessary complexity.  I do not like "modified
> semver", and I see no reason why the current revision-date based
> scheme doesn't work for IETF modules.
>
>
>
I supported the adoption of OpenConfig SemVer when this work started.
Now there are 2 SemVers.  Not impossible to support
both the openconfig-version and label extensions.
Except 'label' is not fixed to a single semantic version system.
It supposedly supports any syntax and its associated semantics.

  3.4.2. Revision label scheme extension statement

  The optional "rev:revision-label-scheme" extension statement is used
to indicate which revision label scheme a module or submodule uses.
  There MUST NOT be more than one revision label scheme in a module or
submodule. The mandatory argument to this extension statement:

rev:revision-label-scheme "yangver:yang-semver";



I do not support this revision-label-scheme "framework".
IMO it actually harms interoperability instead of improving it, by allowing
any and every vendor to create their own semantic versioning system.

New issue with the actual YANG definitions:

The contents of the 'label' are confusing.
The semver draft says the label will contain a string matching the
"version" typedef.


  identity yang-semver {
base rev:revision-label-scheme-base;
description
  "The revision-label scheme corresponds to the YANG Semver
   scheme which is defined by the pattern in the 'version'
   typedef below. The rules governing this revision-label
   scheme are defined in the reference for this identity.";



The 'label' extension says something else

   The format of the revision label argument MUST conform to the
   pattern defined for the revision label typedef in this module.


The 'revision-label' typedef and 'version' typedef are different.



> /martin
>


Andy


>
>
>
> >   If the goal is to indicate that non-backwards
> > > compatible changes have occured, a single new extension statement
> > > could solve that.  (As I probably have stated before, personally I
> > > don't think this is necessary).
> >
> > That is one goal.  Another is to a

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Martin Björklund]

"Rob Wilton (rwilton)"  wrote:
> Hi Martin,
> 
> > -Original Message-
> > From: netmod  On Behalf Of Martin Björklund
> > Sent: 07 June 2023 08:22
> > To: rwilton=40cisco@dmarc.ietf.org
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning"
> > drafts
> > 
> > Hi,
> > 
> > But the two drafts go way beyond fixing the problem your three
> > examples illustrate.
> [Rob Wilton (rwilton)] 
> 
> The actual goals of this work (i.e., the set of drafts) is aiming to
> address the requirements stated here:
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-versioning-reqs-07.
> Although never taken to RFC, I believe was effectively last called and
> achieved WG consensus for the NETMOD WG.  Hopefully the chairs can
> chime in and keep me honest if I'm wrong on this point.
> 
> The shape/structure/content of the drafts is very similar to when
> these documents were adopted in March 2020:
> 
> Your comments on these document at adoption time are here
> (https://mailarchive.ietf.org/arch/msg/netmod/r5TD0NDNgUbtX9EHZfB5hJJctN8/).
> From that email, it is clear that you didn't support the YANG Semver
> scheme, but my reading is that you were broadly supportive of the YANG
> module versioning draft.
> 
> Here are your review comments of the YANG module versioning draft at
> adoption time:
> https://mailarchive.ietf.org/arch/msg/netmod/MTGomxcdyNOmB7mgsFhItLKNJgk/
> 
> Here is a thread where you are discussing supporting different
> revision label schemes:
> https://mailarchive.ietf.org/arch/msg/netmod/cEBiZKUSk0n7BeFwdiyaejc_Tsg/
> 
> I appreciate that everyone has the right to change their mind at any
> point, but as stated previously, I don't think that the shape of the
> solution has really changed substantially since they were adopted.

I'm not sure that I have changed my mind on this topic (but if I have
I view that as a good thing; it means I'm open to new technical
arguments ;-)

I don't think I have ever said that this is important work.  I can
live with optional extension statements that indicate nbc changes, and
even that another optional revision label scheme is used, but I do
think it adds unnecessary complexity.  I do not like "modified
semver", and I see no reason why the current revision-date based
scheme doesn't work for IETF modules.



/martin



>   If the goal is to indicate that non-backwards
> > compatible changes have occured, a single new extension statement
> > could solve that.  (As I probably have stated before, personally I
> > don't think this is necessary).
> 
> That is one goal.  Another is to acknowledge that
> non-backwards-compatible changes will occur, potentially even on
> branches.  Another is to align with the versioning scheme that is
> being broadly used by the industry (but with extensions to support a
> branched history).
>
> >
> > Apart from the updates to RFC 7950 section 11, I am mostly concerned
> > about the additional complexity the "pluggable" revision-label scheme
> > brings.
> [Rob Wilton (rwilton)] 
> 
> It feels like we are somewhat going in circles:
> 
> 1.The original proposal was to embed regular Semver 2.0.0 for the
> version numbers.
> 
> 2. That scheme was extended to what is being labelled as "Yang Semver"
> because regular Semver didn't support some level of branching that the
> vendors require to support customers on older releases over a much
> longer time period.  Semver 2.0.0 works best when the updates are
> always committed to the head of a linear sequence of versions, and if
> a bug needs to be fixed in an older version then the user is forced to
> migrate to the latest version.
> 
> 3. If I recall correctly, you didn't like YANG Semver (and possibly
> not even Semver), and if I also recall correctly from a conversation
> then I think that it is because you envisaged more advanced branching
> schemes and perhaps a version number scheme that follows branch
> history (and hence cannot also contain semantic meaning).  Based on
> that feedback, and an in-person side meeting, we moved to a revision
> label scheme, an nbc-marker, and standardizing a versioning scheme to
> fit into the revision-label scheme separately.  This was all in place
> when these documents were adopted.
> 
> Based on those who are or have participated in the weekly calls, I
> also believe that the solution has reasonable industry support:
>  - Representatives from Cisco, Ericsson, Huawei, Juniper, Nokia have all
>  - participated in the calls at various stages.
>  - Other SDOs (3GPP at least, and ITU?) are waiting for this work.

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Jürgen Schönwälder]

On Tue, Jun 13, 2023 at 05:54:40PM +, Joe Clarke (jclarke) wrote:

> > - I prefer to have non-backwards compatible changes marked and
> >   explained in the modules instead of relying on some schema
> >   comparison algorithm.
> >
> > [JMC] IMHO, the algorithm is useful in addition to any per-module notation 
> > as the tooling can provide a clear, consolidated report of the overall 
> > compatibility.
> >
> 
> Sure, years ago I implemented smidiff, but then assuming that every
> reader has the proper tools is likely wrong. And while tools can spot
> differences, they lack the ability to give explanations or advice how
> to adapt to changes. NBC changes deserve to be documented where they
> take place. Tooling can spot missing documentation.
> 
> [JMC] We have per-module notation, and we discussed general per-node tags 
> (though they were moved to schema comparison as you point out).  Part of this 
> oscillation is due to changes in feedback over time, and I am unclear the 
> best path forward on this issue.  Myself, personally, I would be okay 
> bringing back the per-node tags as I agree with your point above.
> 

The module revision derives from the changes, hence hiding the changes
behind a module revision label and suggesting tools to find the
details is really backwards.

It is relatively pointless whether a module is at revision a.b.c or
d.e.f, as long as the definitions imported and used from that module
have no NBC changes, the module revision label does not matter for
this particular import. If Rob's story is true that NBC changes are
rare, then marking them where they occur seems the simplest and most
effective solution.

/js

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

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Jürgen Schönwälder]

On Tue, Jun 13, 2023 at 05:31:26PM +, Jason Sterne (Nokia) wrote:
> Its too late. The industry is already ignoring parts of 7950 in cases where 
> many people agree that is the most practical thing to do.
> 
> This work gives a common format for an author to explicitly indicate “hey – 
> look out, we made an NBC change – take a look and see how it impacts you”.
>

The documents do way more than providing a simple nbc annotation.

/js

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

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Joe Clarke (jclarke)]

> As for the discussion on YANG artifact “equivalence” I recall we discussed 
> this a bit in meetings and amongst the authors.  I don’t remember all the 
> points but it boiled down to when the revision changes, the revision-label 
> changes.  So if, for example, a module is extracted or produced with extra 
> newlines that module is still equivalent to another module with the same 
> revision/revision-label.  Text in Section 1 states that when a new revision 
> of a module… changes; however, the text in Section 3 might be adding 
> ambiguity here, and we could make that clearer with respect to modules.  The 
> same attention can be applied to the versioning draft.
>

You need to settle what you want. The mailing list discussion is not
consistent with what you wrote and what the document says.

[JMC] In terms of the drafts, I believe the authors have settled on a revision 
update comes with a revision-label update.  Text may need some more clarity 
here.


> Comments on draft-ietf-netmod-yang-semver-11:
>
> - Is the end of the introduction telling me that the SemVer 2.0.0
>   rules change in non-backwards compatible ways without the version
>   number changing?
>
> [JMC] Yes.  We raised this a few meetings back when we learned that the 
> SemVer 2.0.0 spec (using git to look at history) had changed in NBC ways.  We 
> therefore anchored to a revision in time that corresponded to the rules at 
> the time on their web site.
>

What good is SemVer is the SemVer people do not follow it?

[JMC] SemVer is generally understood in the industry, and we anchored to 
something as a starting point for YANG Semver that made sense.  Their approach 
to their own spec is outside our control.


> - The term 'YANG artifact' is imported from the packages draft, which
>   has expired. I pulled out the expired version 03, I could not find a
>   definition in there either.
>
> [JMC] YANG artifact is “defined” in the YANG Semver draft, but uses packages 
> as a type of artifact to go along with modules and submodules.  I admit that 
> the definition here is weak (definition by example only), and I can improve 
> that.
>

You need to import it from where it is defined.

[JMC] Yes.  I have made some changes in GH to clarify that.


> - SemVer and YANG Semver look very similar and perhaps too similar or
>   not similar enough. I do not have a good proposal, just noting a
>   possible writing issue that we will have with Semver and SemVer.
>   Why does 'Semver' and  'YANG SemVer' not do the job?
>
> [JMC] There are clear differences in YANG Semver when compared to the SemVer 
> 2.0.0 spec that the document references.  The difference in case is because 
> SemVer 2.0.0 refers to itself that way, and using “YANG Semver” (without the 
> camel case) seemed like enough of a textual differentiator when reading the 
> document.

For me, this is too obscure. I fear people will mess this detail up.

[JMC] There is text explicitly about the camel case difference, and this whole 
doc is based on YANG Semver with a reference to where it started in SemVer 
2.0.0.  I’d like to hear from others as to whether this is too ambiguous.


> - Section 3.1 starts with a statement that SemVer and YANG Semver are
>   'completely compatible'. While I started wondering what the
>   difference between 'compatible' and 'completely compatible' might
>   be, I was more confused to read this statement upfront, i.e., before
>   I even get told what YANG Semver is. Perhaps first define what YANG
>   Semver is and then discuss its relationship to SemVer?
>
> [JMC] Fair enough.  The adverb there is also unneeded.

But did you not just explain that they are not the same?

[JMC] YANG Semver is based on the rules of SemVer and is compatible with 
SemVer.  The opposite is not true, so they are not the same.  For example, 
2.0.0 is a valid SemVer and a valid YANG Semver.  However, 2.0.1_COMPATIBLE, 
while a valid YANG Semver is not a valid SemVer.


> - As already mentioned above, my take is that a 'versioning scheme'
>   should use exactly one 'revision label scheme' and it should have
>   specific 'module update rules' supporting the "versioning scheme".
>   This does not seem to be the model that the draft authors use and I
>   am a bit confused what their model is. In other words, I see
>
>   YANG Semantic Versioning consists of
>-> YANG Semantic Version Module Update Rules
>-> YANG Semantic Version Revision Label Scheme
>-> YANG Semantic Version Import Rules
>-> NC/RC/... version selection protocol mechanisms needed
>
>   YANG Traditional Versioning consists of
>-> YANG's Traditional Module Update Rules
>-> YANG's Traditional Module Label Scheme (revision dates)
>-> YANG's Traditional Module Import Rules (lacking import by min 
> revision)
>-> no specific protocol mechanisms needed to support transitions
>
>   It seems we have not factored out an interface for plugging
>   additional versioning models 

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Andy Bierman]

On Tue, Jun 13, 2023 at 10:31 AM Jason Sterne (Nokia) <
jason.ste...@nokia.com> wrote:

> Its too late. The industry is already ignoring parts of 7950 in cases
> where many people agree that is the most practical thing to do.
>
>
>
> This work gives a common format for an author to explicitly indicate “hey
> – look out, we made an NBC change – take a look and see how it impacts you”.
>
>
>

The parts of the drafts that provide this feature are not the problem.
Adding some YANG extensions to help manage NBC changes is fine.
The changes are still NBC in YANG 1.1.

Changing the rules for YANG Module Updates requires a new YANG version
number.
Breaking the rules for YANG Module Updates does not. I object to
changing the rules
without a new yang-version number.  The industry just needs the YANG
extensions
and everyone can keep on breaking the rules.

If YANG 1.2 is ever developed then the module update rules can officially
change.



Jason
>
>
>

Andy


> *From:* Andy Bierman 
> *Sent:* Tuesday, June 13, 2023 12:45 PM
> *To:* Jason Sterne (Nokia) 
> *Cc:* Martin Björklund ; rwilton=
> 40cisco....@dmarc.ietf.org; netmod@ietf.org
> *Subject:* Re: [netmod] Joint WGLC on "semver" and "module-versioning"
> drafts
>
>
>
>
>
> *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.
>
>
>
>
>
>
>
> On Tue, Jun 13, 2023 at 9:00 AM Jason Sterne (Nokia) <
> jason.ste...@nokia.com> wrote:
>
> Hi all,
>
>
>
> I don’t think requiring a new YANG 1.2 (or 2.0) is a practical way to
> introduce this much-needed enhancement to YANG (indicating NBC changes and
> clearly alerting users of YANG modules to the fact that there is an NBC
> change). NBC changes are happening (IETF, vendors, other standard bodies)
> because sometimes they are the most pragmatic way to evolve a model in some
> cases.
>
>
>
>
>
>
>
> I do not agree that parts of RFC 7950 can be ignored.
>
> If the yang-version is "1.1" then RFC 7950 applies to the YANG module.
>
> The module update draft has no authority to rewrite YANG 1.1.
>
> All the text that updates RFC 7950 should be removed.
>
>
>
>
>
> Andy
>
>
>
>
>
> If a YANG authoring entity (IETF, vendor) suddenly marked their latest
> YANG modules as 1.2 and those modules contained some new language keywords,
> it would immediately impacts dozens/hundreds of users of those modules.
> Tool chains will break.
>
>
>
> Using extensions allows a smooth and gradual deployment of the
> rev:non-backwards-compatible functionality/indicator. It won’t break tool
> chains. It is useful additive metadata immediately available at minimum for
> human readers, and over time tools can be upgraded to recognize and act on
> the extension. In the meantime, no client/user is worse off than today.
>
>
>
> Many YANG authoring organizations haven’t even moved to YANG 1.1 yet.
> Pyang doesn’t yet support the full set of YANG 1.1 changes (e.g. submodule
> scoping changes). I think it would be a mistake to only put this new YANG
> versioning work into a YANG 1.2 (which would be cumulative of YANG 1.1 +
> additional changes). The extensions are useful to YANG 1.0 and YANG 1.1
> modules.
>
>
>
> I still feel the work is a good practical step forward for the YANG
> ecosystem.
>
>
>
> Jason
>
>
>
> *From:* netmod  *On Behalf Of *Andy Bierman
> *Sent:* Wednesday, June 7, 2023 4:49 PM
> *To:* Martin Björklund 
> *Cc:* rwilton=40cisco@dmarc.ietf.org; netmod@ietf.org
> *Subject:* Re: [netmod] Joint WGLC on "semver" and "module-versioning"
> drafts
>
>
>
>
>
> *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.
>
>
>
>
>
>
>
> On Wed, Jun 7, 2023 at 12:22 AM Martin Björklund  wrote:
>
> Hi,
>
> But the two drafts go way beyond fixing the problem your three
> examples illustrate.  If the goal is to indicate that non-backwards
> compatible changes have occured, a single new extension statement
> could solve that.  (As I probably have stated before, personally I
> don't think this is necessary).
>
>
>
> Problem 1)
>
>
>
> We started out with the "grouping drift" problem.
>
> That led to "import-by-revision" in YANG 1.1.
>
> These drafts attempt to fix that.
>
> The "min-revision" for an import is an improvement over "exact revision".
>
>
>
> Problem 2)
>
>
>
> So

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Jason Sterne (Nokia)]

Its too late. The industry is already ignoring parts of 7950 in cases where 
many people agree that is the most practical thing to do.

This work gives a common format for an author to explicitly indicate “hey – 
look out, we made an NBC change – take a look and see how it impacts you”.

Jason

From: Andy Bierman 
Sent: Tuesday, June 13, 2023 12:45 PM
To: Jason Sterne (Nokia) 
Cc: Martin Björklund ; rwilton=40cisco@dmarc.ietf.org; 
netmod@ietf.org
Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts


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.




On Tue, Jun 13, 2023 at 9:00 AM Jason Sterne (Nokia) 
mailto:jason.ste...@nokia.com>> wrote:
Hi all,

I don’t think requiring a new YANG 1.2 (or 2.0) is a practical way to introduce 
this much-needed enhancement to YANG (indicating NBC changes and clearly 
alerting users of YANG modules to the fact that there is an NBC change). NBC 
changes are happening (IETF, vendors, other standard bodies) because sometimes 
they are the most pragmatic way to evolve a model in some cases.



I do not agree that parts of RFC 7950 can be ignored.
If the yang-version is "1.1" then RFC 7950 applies to the YANG module.
The module update draft has no authority to rewrite YANG 1.1.
All the text that updates RFC 7950 should be removed.


Andy


If a YANG authoring entity (IETF, vendor) suddenly marked their latest YANG 
modules as 1.2 and those modules contained some new language keywords, it would 
immediately impacts dozens/hundreds of users of those modules. Tool chains will 
break.

Using extensions allows a smooth and gradual deployment of the 
rev:non-backwards-compatible functionality/indicator. It won’t break tool 
chains. It is useful additive metadata immediately available at minimum for 
human readers, and over time tools can be upgraded to recognize and act on the 
extension. In the meantime, no client/user is worse off than today.

Many YANG authoring organizations haven’t even moved to YANG 1.1 yet. Pyang 
doesn’t yet support the full set of YANG 1.1 changes (e.g. submodule scoping 
changes). I think it would be a mistake to only put this new YANG versioning 
work into a YANG 1.2 (which would be cumulative of YANG 1.1 + additional 
changes). The extensions are useful to YANG 1.0 and YANG 1.1 modules.

I still feel the work is a good practical step forward for the YANG ecosystem.

Jason

From: netmod mailto:netmod-boun...@ietf.org>> On 
Behalf Of Andy Bierman
Sent: Wednesday, June 7, 2023 4:49 PM
To: Martin Björklund mailto:mbj%2bi...@4668.se>>
Cc: rwilton=40cisco@dmarc.ietf.org<mailto:40cisco@dmarc.ietf.org>; 
netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts


CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext<http://nok.it/ext> for 
additional information.




On Wed, Jun 7, 2023 at 12:22 AM Martin Björklund 
mailto:mbj%2bi...@4668.se>> wrote:
Hi,

But the two drafts go way beyond fixing the problem your three
examples illustrate.  If the goal is to indicate that non-backwards
compatible changes have occured, a single new extension statement
could solve that.  (As I probably have stated before, personally I
don't think this is necessary).

Problem 1)

We started out with the "grouping drift" problem.
That led to "import-by-revision" in YANG 1.1.
These drafts attempt to fix that.
The "min-revision" for an import is an improvement over "exact revision".

Problem 2)

Sometimes, after considering all options, breaking YANG Update rules is
the least bad option. The versioning draft attempts to fix that problem,

Problem with Problem 1)

Attempting to solve the "max revision" problem is much harder than 
"min-version".
A revision-label for every identifier in every module would be impossible to 
manage or use.
A single revision-label for the entire module is usually way too simple and not 
useful.
Importing the latest release without incrementing the major-release number
sounds like it helps, but most of the time, using the real 'latest' will work 
even better.

IMO complex lifecycle issues require resource-level support (like HTTP has)
built into the protocol. For starters, NETCONF needs to support warnings.
This would allow the server to send deprecation (and other) warnings
and other metadata at the resource level.


Problem with Problem 2)

RFC 7950 is quite clear that extensions MAY be ignored
and the yang-version field determines which specification is used for the 
module.
Any tool that supports YANG 1.1 is not expected
to handle module changes that the RFC says MUST NOT be done.

Updating the rules to say that the MUST NOT 

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Andy Bierman]

On Tue, Jun 13, 2023 at 9:00 AM Jason Sterne (Nokia) 
wrote:

> Hi all,
>
>
>
> I don’t think requiring a new YANG 1.2 (or 2.0) is a practical way to
> introduce this much-needed enhancement to YANG (indicating NBC changes and
> clearly alerting users of YANG modules to the fact that there is an NBC
> change). NBC changes are happening (IETF, vendors, other standard bodies)
> because sometimes they are the most pragmatic way to evolve a model in some
> cases.
>
>
>


I do not agree that parts of RFC 7950 can be ignored.
If the yang-version is "1.1" then RFC 7950 applies to the YANG module.
The module update draft has no authority to rewrite YANG 1.1.
All the text that updates RFC 7950 should be removed.


Andy


If a YANG authoring entity (IETF, vendor) suddenly marked their latest YANG
> modules as 1.2 and those modules contained some new language keywords, it
> would immediately impacts dozens/hundreds of users of those modules. Tool
> chains will break.
>
>
>
> Using extensions allows a smooth and gradual deployment of the
> rev:non-backwards-compatible functionality/indicator. It won’t break tool
> chains. It is useful additive metadata immediately available at minimum for
> human readers, and over time tools can be upgraded to recognize and act on
> the extension. In the meantime, no client/user is worse off than today.
>
>
>
> Many YANG authoring organizations haven’t even moved to YANG 1.1 yet.
> Pyang doesn’t yet support the full set of YANG 1.1 changes (e.g. submodule
> scoping changes). I think it would be a mistake to only put this new YANG
> versioning work into a YANG 1.2 (which would be cumulative of YANG 1.1 +
> additional changes). The extensions are useful to YANG 1.0 and YANG 1.1
> modules.
>
>
>
> I still feel the work is a good practical step forward for the YANG
> ecosystem.
>
>
>
> Jason
>
>
>
> *From:* netmod  *On Behalf Of *Andy Bierman
> *Sent:* Wednesday, June 7, 2023 4:49 PM
> *To:* Martin Björklund 
> *Cc:* rwilton=40cisco@dmarc.ietf.org; netmod@ietf.org
> *Subject:* Re: [netmod] Joint WGLC on "semver" and "module-versioning"
> drafts
>
>
>
>
>
> *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.
>
>
>
>
>
>
>
> On Wed, Jun 7, 2023 at 12:22 AM Martin Björklund  wrote:
>
> Hi,
>
> But the two drafts go way beyond fixing the problem your three
> examples illustrate.  If the goal is to indicate that non-backwards
> compatible changes have occured, a single new extension statement
> could solve that.  (As I probably have stated before, personally I
> don't think this is necessary).
>
>
>
> Problem 1)
>
>
>
> We started out with the "grouping drift" problem.
>
> That led to "import-by-revision" in YANG 1.1.
>
> These drafts attempt to fix that.
>
> The "min-revision" for an import is an improvement over "exact revision".
>
>
>
> Problem 2)
>
>
>
> Sometimes, after considering all options, breaking YANG Update rules is
>
> the least bad option. The versioning draft attempts to fix that problem,
>
>
>
> Problem with Problem 1)
>
>
>
> Attempting to solve the "max revision" problem is much harder than
> "min-version".
>
> A revision-label for every identifier in every module would be impossible
> to manage or use.
>
> A single revision-label for the entire module is usually way too simple
> and not useful.
>
> Importing the latest release without incrementing the major-release number
>
> sounds like it helps, but most of the time, using the real 'latest' will
> work even better.
>
>
>
> IMO complex lifecycle issues require resource-level support (like HTTP has)
>
> built into the protocol. For starters, NETCONF needs to support warnings.
>
> This would allow the server to send deprecation (and other) warnings
>
> and other metadata at the resource level.
>
>
>
>
> Problem with Problem 2)
>
>
>
> RFC 7950 is quite clear that extensions MAY be ignored
>
> and the yang-version field determines which specification is used for the
> module.
>
> Any tool that supports YANG 1.1 is not expected
>
> to handle module changes that the RFC says MUST NOT be done.
>
>
>
> Updating the rules to say that the MUST NOT is replaced with MAY means
>
> that all YANG 1.1 tools MUST support NBC changes.  This is a big change
>
> that should require a new yang-version.
>
>
>
> IMO changing the official module update rules is not really

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Rob Wilton (rwilton)]

Hi Martin,

> -Original Message-
> From: netmod  On Behalf Of Martin Björklund
> Sent: 07 June 2023 08:22
> To: rwilton=40cisco@dmarc.ietf.org
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts
> 
> Hi,
> 
> But the two drafts go way beyond fixing the problem your three
> examples illustrate.
[Rob Wilton (rwilton)] 

The actual goals of this work (i.e., the set of drafts) is aiming to address 
the requirements stated here: 
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-versioning-reqs-07.
  Although never taken to RFC, I believe was effectively last called and 
achieved WG consensus for the NETMOD WG.  Hopefully the chairs can chime in and 
keep me honest if I'm wrong on this point.

The shape/structure/content of the drafts is very similar to when these 
documents were adopted in March 2020:

Your comments on these document at adoption time are here 
(https://mailarchive.ietf.org/arch/msg/netmod/r5TD0NDNgUbtX9EHZfB5hJJctN8/).  
From that email, it is clear that you didn't support the YANG Semver scheme, 
but my reading is that you were broadly supportive of the YANG module 
versioning draft.

Here are your review comments of the YANG module versioning draft at adoption 
time:
https://mailarchive.ietf.org/arch/msg/netmod/MTGomxcdyNOmB7mgsFhItLKNJgk/

Here is a thread where you are discussing supporting different revision label 
schemes:
https://mailarchive.ietf.org/arch/msg/netmod/cEBiZKUSk0n7BeFwdiyaejc_Tsg/

I appreciate that everyone has the right to change their mind at any point, but 
as stated previously, I don't think that the shape of the solution has really 
changed substantially since they were adopted.


  If the goal is to indicate that non-backwards
> compatible changes have occured, a single new extension statement
> could solve that.  (As I probably have stated before, personally I
> don't think this is necessary).

That is one goal.  Another is to acknowledge that non-backwards-compatible 
changes will occur, potentially even on branches.  Another is to align with the 
versioning scheme that is being broadly used by the industry (but with 
extensions to support a branched history).


> 
> Apart from the updates to RFC 7950 section 11, I am mostly concerned
> about the additional complexity the "pluggable" revision-label scheme
> brings.
[Rob Wilton (rwilton)] 

It feels like we are somewhat going in circles:

1.The original proposal was to embed regular Semver 2.0.0 for the version 
numbers.

2. That scheme was extended to what is being labelled as "Yang Semver" because 
regular Semver didn't support some level of branching that the vendors require 
to support customers on older releases over a much longer time period.  Semver 
2.0.0 works best when the updates are always committed to the head of a linear 
sequence of versions, and if a bug needs to be fixed in an older version then 
the user is forced to migrate to the latest version.

3. If I recall correctly, you didn't like YANG Semver (and possibly not even 
Semver), and if I also recall correctly from a conversation then I think that 
it is because you envisaged more advanced branching schemes and perhaps a 
version number scheme that follows branch history (and hence cannot also 
contain semantic meaning).  Based on that feedback, and an in-person side 
meeting, we moved to a revision label scheme, an nbc-marker, and standardizing 
a versioning scheme to fit into the revision-label scheme separately.  This was 
all in place when these documents were adopted. 

Based on those who are or have participated in the weekly calls, I also believe 
that the solution has reasonable industry support:
 - Representatives from Cisco, Ericsson, Huawei, Juniper, Nokia have all 
participated in the calls at various stages.
 - Other SDOs (3GPP at least, and ITU?) are waiting for this work.
 - OpenConfig is using Semver and has been for years.  I don't know if they 
will adopt IETF's particular solution, but I do think that we would at least be 
fairly aligned. 

I want to find a way that we can just get this work finished and published so 
that the authors and WG can move on to other, hopefully more interesting, stuff.

Is the solution perfect?  No, but engineering solutions never are.

Is the solution good enough?  I believe so, yes.

Regards,
Rob

// As an author and participant in this work for 5+ years.


> 
> 
> 
> 
> /martin
> 
> 
> 
> 
> "Rob Wilton \(rwilton\)"  wrote:
> > I'm wondering whether we are in the realm of missing the bigger
> > picture here, or perfection being the enemy of good enough.
> >
> > My first example:
> >
> > The sedate WG (https://datatracker.ietf.org/wg/sedate/about/) has
> > recently been rechartered to respecify the meaning of the date string
> > in a non-ba

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Jason Sterne (Nokia)]

Hi all,

I don’t think requiring a new YANG 1.2 (or 2.0) is a practical way to introduce 
this much-needed enhancement to YANG (indicating NBC changes and clearly 
alerting users of YANG modules to the fact that there is an NBC change). NBC 
changes are happening (IETF, vendors, other standard bodies) because sometimes 
they are the most pragmatic way to evolve a model in some cases.

If a YANG authoring entity (IETF, vendor) suddenly marked their latest YANG 
modules as 1.2 and those modules contained some new language keywords, it would 
immediately impacts dozens/hundreds of users of those modules. Tool chains will 
break.

Using extensions allows a smooth and gradual deployment of the 
rev:non-backwards-compatible functionality/indicator. It won’t break tool 
chains. It is useful additive metadata immediately available at minimum for 
human readers, and over time tools can be upgraded to recognize and act on the 
extension. In the meantime, no client/user is worse off than today.

Many YANG authoring organizations haven’t even moved to YANG 1.1 yet. Pyang 
doesn’t yet support the full set of YANG 1.1 changes (e.g. submodule scoping 
changes). I think it would be a mistake to only put this new YANG versioning 
work into a YANG 1.2 (which would be cumulative of YANG 1.1 + additional 
changes). The extensions are useful to YANG 1.0 and YANG 1.1 modules.

I still feel the work is a good practical step forward for the YANG ecosystem.

Jason

From: netmod  On Behalf Of Andy Bierman
Sent: Wednesday, June 7, 2023 4:49 PM
To: Martin Björklund 
Cc: rwilton=40cisco@dmarc.ietf.org; netmod@ietf.org
Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts


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.




On Wed, Jun 7, 2023 at 12:22 AM Martin Björklund 
mailto:mbj%2bi...@4668.se>> wrote:
Hi,

But the two drafts go way beyond fixing the problem your three
examples illustrate.  If the goal is to indicate that non-backwards
compatible changes have occured, a single new extension statement
could solve that.  (As I probably have stated before, personally I
don't think this is necessary).

Problem 1)

We started out with the "grouping drift" problem.
That led to "import-by-revision" in YANG 1.1.
These drafts attempt to fix that.
The "min-revision" for an import is an improvement over "exact revision".

Problem 2)

Sometimes, after considering all options, breaking YANG Update rules is
the least bad option. The versioning draft attempts to fix that problem,

Problem with Problem 1)

Attempting to solve the "max revision" problem is much harder than 
"min-version".
A revision-label for every identifier in every module would be impossible to 
manage or use.
A single revision-label for the entire module is usually way too simple and not 
useful.
Importing the latest release without incrementing the major-release number
sounds like it helps, but most of the time, using the real 'latest' will work 
even better.

IMO complex lifecycle issues require resource-level support (like HTTP has)
built into the protocol. For starters, NETCONF needs to support warnings.
This would allow the server to send deprecation (and other) warnings
and other metadata at the resource level.


Problem with Problem 2)

RFC 7950 is quite clear that extensions MAY be ignored
and the yang-version field determines which specification is used for the 
module.
Any tool that supports YANG 1.1 is not expected
to handle module changes that the RFC says MUST NOT be done.

Updating the rules to say that the MUST NOT is replaced with MAY means
that all YANG 1.1 tools MUST support NBC changes.  This is a big change
that should require a new yang-version.

IMO changing the official module update rules is not really needed.
It should be OK for a WG to make an NBC change to a published module,
if the consensus is that this is the least bad solution and better than
starting over with a new identifier, then just document that and allow the NBC 
change.

This would be an interim solution until YANG 1.2 is done in the future.



Apart from the updates to RFC 7950 section 11, I am mostly concerned
about the additional complexity the "pluggable" revision-label scheme
brings.


Agreed.  Why isn't YANG Semver good enough for now?






/martin


Andy





"Rob Wilton \(rwilton\)" 
mailto:40cisco@dmarc.ietf.org>> wrote:
> I'm wondering whether we are in the realm of missing the bigger
> picture here, or perfection being the enemy of good enough.
>
> My first example:
>
> The sedate WG (https://datatracker.ietf.org/wg/sedate/about/) has
> recently been rechartered to respecify the meaning of the date string
> in a non-backwards compatible way.  Yes, this same date string format
> that is very widel

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Ladislav Lhotka]

Dne 13. 06. 23 v 17:07 Robert Varga napsal(a):

On 05/06/2023 11.46, Martin Björklund wrote:
   - introduce new instance-identifier data type based on RFC 7951 
definition

   - introduce new identityref data type based on RFC 7951 definition

... but I do agree with these!


I am not sure I follow... is this about providing 
instance-identifier/identityref encoding which does not rely on XML 
namespaces, or something else?


Yes, it's about using module name as the namespace identifier (prefix).

Lada



Thanks,
Robert

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


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

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

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Robert Varga]

On 05/06/2023 11.46, Martin Björklund wrote:

   - introduce new instance-identifier data type based on RFC 7951 definition
   - introduce new identityref data type based on RFC 7951 definition

... but I do agree with these!


I am not sure I follow... is this about providing 
instance-identifier/identityref encoding which does not rely on XML 
namespaces, or something else?


Thanks,
Robert


OpenPGP_signature
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Jürgen Schönwälder]

On Mon, Jun 12, 2023 at 03:45:41PM +, Joe Clarke (jclarke) wrote:
> Thanks for the detailed review, Jürgen.  See below on responses concerning 
> YANG Semver.
> 
> As for the discussion on YANG artifact “equivalence” I recall we discussed 
> this a bit in meetings and amongst the authors.  I don’t remember all the 
> points but it boiled down to when the revision changes, the revision-label 
> changes.  So if, for example, a module is extracted or produced with extra 
> newlines that module is still equivalent to another module with the same 
> revision/revision-label.  Text in Section 1 states that when a new revision 
> of a module… changes; however, the text in Section 3 might be adding 
> ambiguity here, and we could make that clearer with respect to modules.  The 
> same attention can be applied to the versioning draft.
>

You need to settle what you want. The mailing list discussion is not
consistent with what you wrote and what the document says.

> Comments on draft-ietf-netmod-yang-semver-11:
> 
> - Is the end of the introduction telling me that the SemVer 2.0.0
>   rules change in non-backwards compatible ways without the version
>   number changing?
> 
> [JMC] Yes.  We raised this a few meetings back when we learned that the 
> SemVer 2.0.0 spec (using git to look at history) had changed in NBC ways.  We 
> therefore anchored to a revision in time that corresponded to the rules at 
> the time on their web site.
>

What good is SemVer is the SemVer people do not follow it?
 
> - The term 'YANG artifact' is imported from the packages draft, which
>   has expired. I pulled out the expired version 03, I could not find a
>   definition in there either.
> 
> [JMC] YANG artifact is “defined” in the YANG Semver draft, but uses packages 
> as a type of artifact to go along with modules and submodules.  I admit that 
> the definition here is weak (definition by example only), and I can improve 
> that.
>

You need to import it from where it is defined.

> - SemVer and YANG Semver look very similar and perhaps too similar or
>   not similar enough. I do not have a good proposal, just noting a
>   possible writing issue that we will have with Semver and SemVer.
>   Why does 'Semver' and  'YANG SemVer' not do the job?
> 
> [JMC] There are clear differences in YANG Semver when compared to the SemVer 
> 2.0.0 spec that the document references.  The difference in case is because 
> SemVer 2.0.0 refers to itself that way, and using “YANG Semver” (without the 
> camel case) seemed like enough of a textual differentiator when reading the 
> document.

For me, this is too obscure. I fear people will mess this detail up.
 
> - Section 3.1 starts with a statement that SemVer and YANG Semver are
>   'completely compatible'. While I started wondering what the
>   difference between 'compatible' and 'completely compatible' might
>   be, I was more confused to read this statement upfront, i.e., before
>   I even get told what YANG Semver is. Perhaps first define what YANG
>   Semver is and then discuss its relationship to SemVer?
> 
> [JMC] Fair enough.  The adverb there is also unneeded.

But did you not just explain that they are not the same?
 
> - As already mentioned above, my take is that a 'versioning scheme'
>   should use exactly one 'revision label scheme' and it should have
>   specific 'module update rules' supporting the "versioning scheme".
>   This does not seem to be the model that the draft authors use and I
>   am a bit confused what their model is. In other words, I see
> 
>   YANG Semantic Versioning consists of
>-> YANG Semantic Version Module Update Rules
>-> YANG Semantic Version Revision Label Scheme
>-> YANG Semantic Version Import Rules
>-> NC/RC/... version selection protocol mechanisms needed
> 
>   YANG Traditional Versioning consists of
>-> YANG's Traditional Module Update Rules
>-> YANG's Traditional Module Label Scheme (revision dates)
>-> YANG's Traditional Module Import Rules (lacking import by min 
> revision)
>-> no specific protocol mechanisms needed to support transitions
> 
>   It seems we have not factored out an interface for plugging
>   additional versioning models into YANG and the protocols providing
>   access to YANG-defined data.
> 
> [JMC] The original intent was that different YANG artifact producers might 
> want different schemes.  Admittedly, examples other than YANG Semver were 
> mainly vendor-centric (e.g., codenames or software revisions).  I think it’s 
> reasonable to have the conversation as to whether or not this flexibility is 
> really needed.
>

Do you want multiple versioning models or multiple writing styles for
labels of the same versioning model? This is a fundamental difference.

> - Why do we need the _COMPATIBLE extension of SemVer? It would be nice
>   to explain this more clearly, the best bit of explanation I found
>   seems to be in situations where the next major version number 

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Joe Clarke (jclarke)]

Thanks for the detailed review, Jürgen.  See below on responses concerning YANG 
Semver.

As for the discussion on YANG artifact “equivalence” I recall we discussed this 
a bit in meetings and amongst the authors.  I don’t remember all the points but 
it boiled down to when the revision changes, the revision-label changes.  So 
if, for example, a module is extracted or produced with extra newlines that 
module is still equivalent to another module with the same 
revision/revision-label.  Text in Section 1 states that when a new revision of 
a module… changes; however, the text in Section 3 might be adding ambiguity 
here, and we could make that clearer with respect to modules.  The same 
attention can be applied to the versioning draft.

Comments on draft-ietf-netmod-yang-semver-11:

- Is the end of the introduction telling me that the SemVer 2.0.0
  rules change in non-backwards compatible ways without the version
  number changing?

[JMC] Yes.  We raised this a few meetings back when we learned that the SemVer 
2.0.0 spec (using git to look at history) had changed in NBC ways.  We 
therefore anchored to a revision in time that corresponded to the rules at the 
time on their web site.


- The term 'YANG artifact' is imported from the packages draft, which
  has expired. I pulled out the expired version 03, I could not find a
  definition in there either.

[JMC] YANG artifact is “defined” in the YANG Semver draft, but uses packages as 
a type of artifact to go along with modules and submodules.  I admit that the 
definition here is weak (definition by example only), and I can improve that.


- SemVer and YANG Semver look very similar and perhaps too similar or
  not similar enough. I do not have a good proposal, just noting a
  possible writing issue that we will have with Semver and SemVer.
  Why does 'Semver' and  'YANG SemVer' not do the job?

[JMC] There are clear differences in YANG Semver when compared to the SemVer 
2.0.0 spec that the document references.  The difference in case is because 
SemVer 2.0.0 refers to itself that way, and using “YANG Semver” (without the 
camel case) seemed like enough of a textual differentiator when reading the 
document.


- Section 3.1 starts with a statement that SemVer and YANG Semver are
  'completely compatible'. While I started wondering what the
  difference between 'compatible' and 'completely compatible' might
  be, I was more confused to read this statement upfront, i.e., before
  I even get told what YANG Semver is. Perhaps first define what YANG
  Semver is and then discuss its relationship to SemVer?

[JMC] Fair enough.  The adverb there is also unneeded.


- As already mentioned above, my take is that a 'versioning scheme'
  should use exactly one 'revision label scheme' and it should have
  specific 'module update rules' supporting the "versioning scheme".
  This does not seem to be the model that the draft authors use and I
  am a bit confused what their model is. In other words, I see

  YANG Semantic Versioning consists of
   -> YANG Semantic Version Module Update Rules
   -> YANG Semantic Version Revision Label Scheme
   -> YANG Semantic Version Import Rules
   -> NC/RC/... version selection protocol mechanisms needed

  YANG Traditional Versioning consists of
   -> YANG's Traditional Module Update Rules
   -> YANG's Traditional Module Label Scheme (revision dates)
   -> YANG's Traditional Module Import Rules (lacking import by min 
revision)
   -> no specific protocol mechanisms needed to support transitions

  It seems we have not factored out an interface for plugging
  additional versioning models into YANG and the protocols providing
  access to YANG-defined data.

[JMC] The original intent was that different YANG artifact producers might want 
different schemes.  Admittedly, examples other than YANG Semver were mainly 
vendor-centric (e.g., codenames or software revisions).  I think it’s 
reasonable to have the conversation as to whether or not this flexibility is 
really needed.


- Why do we need the _COMPATIBLE extension of SemVer? It would be nice
  to explain this more clearly, the best bit of explanation I found
  seems to be in situations where the next major version number has
  already been taken. But then SemVer does not support branching in
  general, why do we need a bit of this via the _COMPATIBLE extension?
  Did anyone suggest this addition to the SemVer people and what was
  their reaction, something they would consider adding to SemVer or
  more reservation about this being a proper solution?

[JMC] We need _COMPATIBLE for the reason you point out: e.g., an author has 
produced a module with 1.0.0 and 2.0.0 revision-labels, and a consumer needs a 
new feature ported to the 1.X branch.  In this case the author would release 
1.0.1_COMPATIBLE.

[JMC] To my knowledge we did not raise this to the SemVer people explicitly, 
though someone from that camp did review this draft.  He admitted to being 

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[tom petch]

From: netmod  on behalf of Jürgen Schönwälder 

Sent: 06 June 2023 06:06

On Mon, Jun 05, 2023 at 10:32:51PM +0200, Martin Björklund wrote:
> >
> > If the goal is to produce YANG 1.2 which (i) integrates semantic
> > versioning into YANG and (ii) fixes known bugs in YANG 1.1 and (iii)
> > does not add any other new features, then having agreement on such a
> > statement will help to steer the process.
>
> I hope that (i) doesn't happen.  I think it is the proposed changes in
> draft-ietf-netmod-yang-module-versioning that require a new YANG
> version.  If this new YANG version allows for other versioning schemes
> than revision-date, then we can keep the modified semver scheme
> outside the core document.
>

I consider the module update rules a part of a versioning model. The
current update rules were written to support the current versioning
model. If we want to support multiple versioning models, then we have
to refactor the update rules out of the YANG language specification
into separate versioning specifications, i.e., traditional YANG
versioning and the new semver versioning. There are some language
mechanisms (like the import statement), that have to be flexible
enough to support multiple versioning schemes.


I am not sure that I understand.  Authors of a compiler need to know what they 
might  encounter in future and so I see module update rules as a part of the 
language, what updates are permitted and what are not so that authors can allow 
for such changes.  As to which updates then become a new version, level or 
revision, how they are packaged, I see as a separate question.

Tom Petch
.
Is it worth factoring the versioning model out of the language? I
guess the opinions vary widely on this, depending on the dynamics of
the software environment people are working in.

/js

--
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.org/mailman/listinfo/netmod

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Martin Björklund]

r SDOs strictly followed the rules
> in RFC 7950 then I would probably agree that an update from YANG 1.1
> to YANG 1.2 is needed.  But I think that the reality is that tools
> must handle non-backwards compatible changes frequently happening in
> YANG 1.0 (OpenConfig) and YANG 1.1 YANG modules anyway.  I.e., I don't
> believe that the "YANG 1.1 no breaking change contract" is being
> widely honoured anyway, and instead is being treated as a goal or
> aspiration.  What these documents attempt to do is to move YANG module
> evolution from what we currently have now where clients don't have any
> way of really knowing how a module has evolved and whether they are
> impacted to one that they do, and as part of that process they are
> aiming to update the YANG versioning rules to better reflect how is it
> being deployed and used.
> 
> Hence, as am author, I still of the opinion that the best pragmatic
> path forward is to try and get these documents to a shape where they
> achieve rough consensus and are acceptable to the WG to be published
> now, in the short term, as a good enough solution.  After that point,
> then I think that it would be great for some folks to form an idea on
> a what YANG 1.2/2.0 could look like, but I think that coupling these
> goals together would be a mistake.
> 
> Regards,
> Rob
> 
> // Who doesn't really know which hat he is wearing for this comment,
> but is only trying to do the right thing for the wider industry ...
> 
> 
> > -Original Message-
> > From: netmod  On Behalf Of Jürgen Schönwälder
> > Sent: 06 June 2023 06:07
> > To: Martin Björklund 
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning"
> > drafts
> > 
> > On Mon, Jun 05, 2023 at 10:32:51PM +0200, Martin Björklund wrote:
> > > >
> > > > If the goal is to produce YANG 1.2 which (i) integrates semantic
> > > > versioning into YANG and (ii) fixes known bugs in YANG 1.1 and (iii)
> > > > does not add any other new features, then having agreement on such a
> > > > statement will help to steer the process.
> > >
> > > I hope that (i) doesn't happen.  I think it is the proposed changes in
> > > draft-ietf-netmod-yang-module-versioning that require a new YANG
> > > version.  If this new YANG version allows for other versioning schemes
> > > than revision-date, then we can keep the modified semver scheme
> > > outside the core document.
> > >
> > 
> > I consider the module update rules a part of a versioning model. The
> > current update rules were written to support the current versioning
> > model. If we want to support multiple versioning models, then we have
> > to refactor the update rules out of the YANG language specification
> > into separate versioning specifications, i.e., traditional YANG
> > versioning and the new semver versioning. There are some language
> > mechanisms (like the import statement), that have to be flexible
> > enough to support multiple versioning schemes.
> > 
> > Is it worth factoring the versioning model out of the language? I
> > guess the opinions vary widely on this, depending on the dynamics of
> > the software environment people are working in.
> > 
> > /js
> > 
> > --
> > 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 <https://constructor.university/>
> > 
> > ___
> > 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] Joint WGLC on "semver" and "module-versioning" drafts

[Rob Wilton (rwilton)]

could look like, 
but I think that coupling these goals together would be a mistake.

Regards,
Rob

// Who doesn't really know which hat he is wearing for this comment, but is 
only trying to do the right thing for the wider industry ...


> -Original Message-
> From: netmod  On Behalf Of Jürgen Schönwälder
> Sent: 06 June 2023 06:07
> To: Martin Björklund 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts
> 
> On Mon, Jun 05, 2023 at 10:32:51PM +0200, Martin Björklund wrote:
> > >
> > > If the goal is to produce YANG 1.2 which (i) integrates semantic
> > > versioning into YANG and (ii) fixes known bugs in YANG 1.1 and (iii)
> > > does not add any other new features, then having agreement on such a
> > > statement will help to steer the process.
> >
> > I hope that (i) doesn't happen.  I think it is the proposed changes in
> > draft-ietf-netmod-yang-module-versioning that require a new YANG
> > version.  If this new YANG version allows for other versioning schemes
> > than revision-date, then we can keep the modified semver scheme
> > outside the core document.
> >
> 
> I consider the module update rules a part of a versioning model. The
> current update rules were written to support the current versioning
> model. If we want to support multiple versioning models, then we have
> to refactor the update rules out of the YANG language specification
> into separate versioning specifications, i.e., traditional YANG
> versioning and the new semver versioning. There are some language
> mechanisms (like the import statement), that have to be flexible
> enough to support multiple versioning schemes.
> 
> Is it worth factoring the versioning model out of the language? I
> guess the opinions vary widely on this, depending on the dynamics of
> the software environment people are working in.
> 
> /js
> 
> --
> 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 <https://constructor.university/>
> 
> ___
> 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] Joint WGLC on "semver" and "module-versioning" drafts

[Jürgen Schönwälder]

On Mon, Jun 05, 2023 at 10:32:51PM +0200, Martin Björklund wrote:
> > 
> > If the goal is to produce YANG 1.2 which (i) integrates semantic
> > versioning into YANG and (ii) fixes known bugs in YANG 1.1 and (iii)
> > does not add any other new features, then having agreement on such a
> > statement will help to steer the process.
> 
> I hope that (i) doesn't happen.  I think it is the proposed changes in
> draft-ietf-netmod-yang-module-versioning that require a new YANG
> version.  If this new YANG version allows for other versioning schemes
> than revision-date, then we can keep the modified semver scheme
> outside the core document.
>

I consider the module update rules a part of a versioning model. The
current update rules were written to support the current versioning
model. If we want to support multiple versioning models, then we have
to refactor the update rules out of the YANG language specification
into separate versioning specifications, i.e., traditional YANG
versioning and the new semver versioning. There are some language
mechanisms (like the import statement), that have to be flexible
enough to support multiple versioning schemes.

Is it worth factoring the versioning model out of the language? I
guess the opinions vary widely on this, depending on the dynamics of
the software environment people are working in.

/js

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

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Martin Björklund]

Jürgen Schönwälder  wrote:
> On Mon, Jun 05, 2023 at 12:07:49PM +, Kent Watsen wrote:
> > 
> > Whilst the chairs haven't closed this WGLC yet, I propose a YANG-next 
> > design team, asked to produce a limited-scope I-D they think best.  
> > WG-objections of the form "my pet-issue isn't picked-up" should not be used 
> > to fail adoption (or, later, the WGLC).  Of course, objections to how the 
> > specific-issues picked-up were resolved are valid.  The goal being to most 
> > expediently (<1yr) forward the versioning work in a correct 
> > (contract-compliant) manner.  Support?
> >
> 
> I believe the WG chairs should guide more actively here. Back in a
> day, the IETF used WG charters to define the scope of work items and a
> project to produce lets say YANG 1.2 would have been a WG charter
> update. For the charter update, the WG chairs would organize a
> discussion to agree on the scope of the work. While bureaucratic, I
> believe it was useful to work this way since it helped to get
> agreement on the scope of work.
> 
> If the goal is to produce YANG 1.2 which (i) integrates semantic
> versioning into YANG and (ii) fixes known bugs in YANG 1.1 and (iii)
> does not add any other new features, then having agreement on such a
> statement will help to steer the process.

I hope that (i) doesn't happen.  I think it is the proposed changes in
draft-ietf-netmod-yang-module-versioning that require a new YANG
version.  If this new YANG version allows for other versioning schemes
than revision-date, then we can keep the modified semver scheme
outside the core document.  (I don't like the name "YANG semver",
since it sort of implies that this is something that is required by
YANG the language.)


/martin


> Yes, we will still have to
> sort out what is a bug fix and what is a new feature, but this is
> easier if there is upfront guidance on the scope of the work.
> 
> And the second incredient is a dedicated team to work on such a
> project, which ideally brings the major stakeholders together.
> 
> /js
> 
> -- 
> 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

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Andy Bierman]

On Mon, Jun 5, 2023 at 5:32 AM Jürgen Schönwälder
 wrote:

> On Mon, Jun 05, 2023 at 12:07:49PM +, Kent Watsen wrote:
> >
> > Whilst the chairs haven't closed this WGLC yet, I propose a YANG-next
> design team, asked to produce a limited-scope I-D they think best.
> WG-objections of the form "my pet-issue isn't picked-up" should not be used
> to fail adoption (or, later, the WGLC).  Of course, objections to how the
> specific-issues picked-up were resolved are valid.  The goal being to most
> expediently (<1yr) forward the versioning work in a correct
> (contract-compliant) manner.  Support?
> >
>
> I believe the WG chairs should guide more actively here. Back in a
> day, the IETF used WG charters to define the scope of work items and a
> project to produce lets say YANG 1.2 would have been a WG charter
> update. For the charter update, the WG chairs would organize a
> discussion to agree on the scope of the work. While bureaucratic, I
> believe it was useful to work this way since it helped to get
> agreement on the scope of work.
>
> If the goal is to produce YANG 1.2 which (i) integrates semantic
> versioning into YANG and (ii) fixes known bugs in YANG 1.1 and (iii)
> does not add any other new features, then having agreement on such a
> statement will help to steer the process. Yes, we will still have to
> sort out what is a bug fix and what is a new feature, but this is
> easier if there is upfront guidance on the scope of the work.
>
> And the second incredient is a dedicated team to work on such a
> project, which ideally brings the major stakeholders together.
>
>
https://github.com/netmod-wg/yang-next/issues

There are 100 issues collected in this list.
Perhaps if people picked their top 3 issues, there might be a chance for
consensus
on some "must have bugfixes".  2 of my issues could actually be solved
without a new language version.
Maybe there are few if any critical bugfixes that require a new language
version to accomplish.

Another option is to drop the Module Updates draft for now and just publish
SemVer,
or just remove all the text that updates RFC 7950.



> /js
>

Andy


>
> --
> 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.org/mailman/listinfo/netmod

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Jürgen Schönwälder]

On Mon, Jun 05, 2023 at 12:07:49PM +, Kent Watsen wrote:
> 
> Whilst the chairs haven't closed this WGLC yet, I propose a YANG-next design 
> team, asked to produce a limited-scope I-D they think best.  WG-objections of 
> the form "my pet-issue isn't picked-up" should not be used to fail adoption 
> (or, later, the WGLC).  Of course, objections to how the specific-issues 
> picked-up were resolved are valid.  The goal being to most expediently (<1yr) 
> forward the versioning work in a correct (contract-compliant) manner.  
> Support?
>

I believe the WG chairs should guide more actively here. Back in a
day, the IETF used WG charters to define the scope of work items and a
project to produce lets say YANG 1.2 would have been a WG charter
update. For the charter update, the WG chairs would organize a
discussion to agree on the scope of the work. While bureaucratic, I
believe it was useful to work this way since it helped to get
agreement on the scope of work.

If the goal is to produce YANG 1.2 which (i) integrates semantic
versioning into YANG and (ii) fixes known bugs in YANG 1.1 and (iii)
does not add any other new features, then having agreement on such a
statement will help to steer the process. Yes, we will still have to
sort out what is a bug fix and what is a new feature, but this is
easier if there is upfront guidance on the scope of the work.

And the second incredient is a dedicated team to work on such a
project, which ideally brings the major stakeholders together.

/js

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

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Kent Watsen]

Hi Martin!


> I think you meant https://github.com/netmod-wg/yang-next/issues/49.

Yes but, in spirit of the idea, I suppose both would be in play, if at all.


>> IMO the parsing of YANG files to produce a conceptual data model
>> is a critical component of the language itself.  Any statements that
>> affect this conversion step MUST be regular statements.
>> An extension is (by definition) an external statement that is not part of
>> the YANG language.
>> Critical extensions are not a good design choice.
> 
> I strongly agree.  Allowing the language to drastically change (like
> in this example) by just defining a critical extension is not a good
> idea.  Basically, anyone can define their own extension that changes
> YANG to whatever, and still claim conformance.

I also agree, for this issue (versioning), but there may be other places where 
a "critical" flag would help (wit the conversation that issue generated).  That 
said, for a limited-scope rfc7950-bis, it would be fine to not pick up either 
of these issues.


>> Just add real statements
>> instead.
>> 
>> IMO most of the yang-next issues are not interesting or valuable,
>> so a long WG process to go through this entire list is a non-starter.
>> 
> 
> The problem is that everyone will have their own pet-issues that they
> think are critical...
> 
> 
>> There are 3 critical changes that need to be made.
>>  - change "status" so deprecated and obsolete definitions are
>>correct
> 
> ... for example I don't think this is critical ...
> 
>>  - introduce new instance-identifier data type based on RFC 7951 definition
>>  - introduce new identityref data type based on RFC 7951 definition
> 
> ... but I do agree with these!
> 
> 
> /martin


Whilst the chairs haven't closed this WGLC yet, I propose a YANG-next design 
team, asked to produce a limited-scope I-D they think best.  WG-objections of 
the form "my pet-issue isn't picked-up" should not be used to fail adoption 
(or, later, the WGLC).  Of course, objections to how the specific-issues 
picked-up were resolved are valid.  The goal being to most expediently (<1yr) 
forward the versioning work in a correct (contract-compliant) manner.  Support?

Kent




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

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Martin Björklund]

Andy Bierman  wrote:
> On Sun, Jun 4, 2023 at 7:01 AM Kent Watsen  wrote:
> 
> > As an individual contributor and faithful YANG custodian, I cannot
> > support work that changes YANG-semantics without versioning YANG itself.
> > As Andy wrote before:
> >
> > The only correct way to remove MUST/MUST NOT from the "YANG contract"
> > is to introduce a new YANG language version (1.2), and make a new
> > contract.
> >
> > I want this work to move forward in the form of a quick (limited-scope)
> > rfc7950-bis.  One idea would to support just this YANG-next issue
> > 

I think you meant https://github.com/netmod-wg/yang-next/issues/49.

> > and then mark the
> > versioning extension as "critical".  That said, I believe that an even
> > better versioning-solution can be had if integrated into the YANG-language
> > directly.
> >
> 
> 
> IMO the parsing of YANG files to produce a conceptual data model
> is a critical component of the language itself.  Any statements that
> affect this conversion step MUST be regular statements.
> An extension is (by definition) an external statement that is not part of
> the YANG language.
> Critical extensions are not a good design choice.

I strongly agree.  Allowing the language to drastically change (like
in this example) by just defining a critical extension is not a good
idea.  Basically, anyone can define their own extension that changes
YANG to whatever, and still claim conformance.


> Just add real statements
> instead.
> 
> IMO most of the yang-next issues are not interesting or valuable,
> so a long WG process to go through this entire list is a non-starter.
> 

The problem is that everyone will have their own pet-issues that they
think are critical...


> There are 3 critical changes that need to be made.
>   - change "status" so deprecated and obsolete definitions are
> correct

... for example I don't think this is critical ...

>   - introduce new instance-identifier data type based on RFC 7951 definition
>   - introduce new identityref data type based on RFC 7951 definition

... but I do agree with these!


/martin




> 
> 
> 
> 
> > Kent
> >
> 
> 
> Andy
> 
> 
> >
> >
> > On May 22, 2023, at 6:20 PM, Kent Watsen  wrote:
> >
> > NETMOD WG,
> >
> > The chairs are extending this WGLC by two weeks (now ending June 5) in
> > order to ensure adequate review, since this is important work, and a solid
> > consensus is needed.
> >
> > Kent and Lou
> >
> >
> >
> > On May 8, 2023, at 6:49 PM, Kent Watsen  wrote:
> >
> > Dear NETMOD WG,
> >
> > This message begins a joint two-week WGLC for
> > draft-ietf-netmod-yang-semver-11 and
> > draft-ietf-netmod-yang-module-versioning-09
> > ending on Monday, May 22nd.  Neither draft has IPR declared.  Here are the
> > direct links to the HTML version for these drafts:
> >
> >  - https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver-11
> >  -
> > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-09
> >
> > 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 and Lou (chairs)
> >
> >
> >
> >
> >
> >
> >
> >
> > ___
> > 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
> >
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Carsten Bormann]

On 2023-06-04, at 19:42, Jürgen Schönwälder 
 wrote:
> 
>> 
>> I’m not sure I understand the current discussion, but wouldn't
>> 
>> curl -s https://www.rfc-editor.org/rfc/rfc9127.xml | xmlstarlet sel -T -t -v 
>> "//sourcecode[@name='ietf-bfd-ty...@2021-10-21.yang']/text()”
>> 
>> be considered an authoritative source for that YANG file in that RFC?
>> 
> 
> There are many ways to extract YANG modules from RFCs and the results
> they produce are not necessarily byte-level identical.

Thanks.  This particular method only works for RFC 8650 onwards, but could be 
considered canonical for those.  As XML is neutral with respect to the bytes 
that constitute a line break, if byte level determinism is required, the 
canonical form of a line break (#xA, i.e. a bare LF) should be assumed.  There 
also is https://github.com/ietf-tools/xml2rfc/issues/986 (YANG files extracted 
this way typically start with an empty line).

> So far this was
> not considered necessary. Before people go and try to engineer a
> solution, it may be useful to understand why solving this problem is
> relevant or important.

Right.  I wasn’t about to engineer a solution, but more interested in finding 
out what people consider the authoritative solution today, and I now have a 
useful answer.

Grüße, Carsten

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

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[tom petch]

From: netmod  on behalf of Jürgen Schönwälder 

Sent: 04 June 2023 18:42

On Sun, Jun 04, 2023 at 07:01:16PM +0200, Carsten Bormann wrote:
> On 2023-06-02, at 18:37, Jürgen Schönwälder 
>  wrote:
> >
> > I am not aware of an official authoritative source of YANG files.
>
> I’m not sure I understand the current discussion, but wouldn't
>
> curl -s https://www.rfc-editor.org/rfc/rfc9127.xml | xmlstarlet sel -T -t -v 
> "//sourcecode[@name='ietf-bfd-ty...@2021-10-21.yang']/text()”
>
> be considered an authoritative source for that YANG file in that RFC?

There are many ways to extract YANG modules from RFCs and the results
they produce are not necessarily byte-level identical. So far this was
not considered necessary. Before people go and try to engineer a
solution, it may be useful to understand why solving this problem is
relevant or important.


One (hypothetical) requirement would be to have a canonical form for checking 
for any changes, for producing a signature file for ease of such checks.  .doc 
with its thousands of ways of producing the same visual output was deemed 
adequate by many until .pdf came along and now the latter would be the one I 
would expect to be regarded as indispensable.

True the RFC provides that in a sense but with hundreds of pages of YANG in 
some RFC of hundreds of pages, and with a YANG module having a life way outside 
the IETF, then there could be a case for a canonical form of just the YANG.  A 
canonical tool to strip the YANG from the RFC could do that but at present I 
cannot see any one tool being given such  status.

Tom Petch

/js

--
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.org/mailman/listinfo/netmod

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Jürgen Schönwälder]

On Sun, Jun 04, 2023 at 07:01:16PM +0200, Carsten Bormann wrote:
> On 2023-06-02, at 18:37, Jürgen Schönwälder 
>  wrote:
> > 
> > I am not aware of an official authoritative source of YANG files.
> 
> I’m not sure I understand the current discussion, but wouldn't
> 
> curl -s https://www.rfc-editor.org/rfc/rfc9127.xml | xmlstarlet sel -T -t -v 
> "//sourcecode[@name='ietf-bfd-ty...@2021-10-21.yang']/text()”
> 
> be considered an authoritative source for that YANG file in that RFC?
>

There are many ways to extract YANG modules from RFCs and the results
they produce are not necessarily byte-level identical. So far this was
not considered necessary. Before people go and try to engineer a
solution, it may be useful to understand why solving this problem is
relevant or important.

/js

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

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Carsten Bormann]

On 2023-06-02, at 18:37, Jürgen Schönwälder 
 wrote:
> 
> I am not aware of an official authoritative source of YANG files.

I’m not sure I understand the current discussion, but wouldn't

curl -s https://www.rfc-editor.org/rfc/rfc9127.xml | xmlstarlet sel -T -t -v 
"//sourcecode[@name='ietf-bfd-ty...@2021-10-21.yang']/text()”

be considered an authoritative source for that YANG file in that RFC?

Grüße, Carsten


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

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Andy Bierman]

On Sun, Jun 4, 2023 at 7:01 AM Kent Watsen  wrote:

> As an individual contributor and faithful YANG custodian, I cannot
> support work that changes YANG-semantics without versioning YANG itself.
> As Andy wrote before:
>
> The only correct way to remove MUST/MUST NOT from the "YANG contract"
> is to introduce a new YANG language version (1.2), and make a new
> contract.
>
> I want this work to move forward in the form of a quick (limited-scope)
> rfc7950-bis.  One idea would to support just this YANG-next issue
>  and then mark the
> versioning extension as "critical".  That said, I believe that an even
> better versioning-solution can be had if integrated into the YANG-language
> directly.
>


IMO the parsing of YANG files to produce a conceptual data model
is a critical component of the language itself.  Any statements that
affect this conversion step MUST be regular statements.
An extension is (by definition) an external statement that is not part of
the YANG language.
Critical extensions are not a good design choice.  Just add real statements
instead.

IMO most of the yang-next issues are not interesting or valuable,
so a long WG process to go through this entire list is a non-starter.

There are 3 critical changes that need to be made.
  - change "status" so deprecated and obsolete definitions are correct
  - introduce new instance-identifier data type based on RFC 7951 definition
  - introduce new identityref data type based on RFC 7951 definition




> Kent
>


Andy


>
>
> On May 22, 2023, at 6:20 PM, Kent Watsen  wrote:
>
> NETMOD WG,
>
> The chairs are extending this WGLC by two weeks (now ending June 5) in
> order to ensure adequate review, since this is important work, and a solid
> consensus is needed.
>
> Kent and Lou
>
>
>
> On May 8, 2023, at 6:49 PM, Kent Watsen  wrote:
>
> Dear NETMOD WG,
>
> This message begins a joint two-week WGLC for
> draft-ietf-netmod-yang-semver-11 and
> draft-ietf-netmod-yang-module-versioning-09
> ending on Monday, May 22nd.  Neither draft has IPR declared.  Here are the
> direct links to the HTML version for these drafts:
>
>  - https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver-11
>  -
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-09
>
> 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 and Lou (chairs)
>
>
>
>
>
>
>
>
> ___
> 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
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Kent Watsen]

As an individual contributor and faithful YANG custodian, I cannot support work 
that changes YANG-semantics without versioning YANG itself.  As Andy wrote 
before:

The only correct way to remove MUST/MUST NOT from the "YANG contract" 
is to introduce a new YANG language version (1.2), and make a new contract.

I want this work to move forward in the form of a quick (limited-scope) 
rfc7950-bis.  One idea would to support just this YANG-next issue 
 and then mark the versioning 
extension as "critical".  That said, I believe that an even better 
versioning-solution can be had if integrated into the YANG-language directly.   

Kent


> On May 22, 2023, at 6:20 PM, Kent Watsen  wrote:
> 
> NETMOD WG,
> 
> The chairs are extending this WGLC by two weeks (now ending June 5) in order 
> to ensure adequate review, since this is important work, and a solid 
> consensus is needed.
> 
> Kent and Lou
> 
> 
> 
>> On May 8, 2023, at 6:49 PM, Kent Watsen  wrote:
>> 
>> Dear NETMOD WG,
>> 
>> This message begins a joint two-week WGLC for 
>> draft-ietf-netmod-yang-semver-11 and 
>> draft-ietf-netmod-yang-module-versioning-09
>> ending on Monday, May 22nd.  Neither draft has IPR declared.  Here are the 
>> direct links to the HTML version for these drafts:
>> 
>>  - https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver-11
>>  - 
>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-09
>> 
>> 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 and Lou (chairs)
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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] Joint WGLC on "semver" and "module-versioning" drafts

[Jürgen Schönwälder]

On Fri, Jun 02, 2023 at 06:13:08PM +0200, Robert Varga wrote:
> On 31/05/2023 09.50, Jürgen Schönwälder wrote:
> > On Wed, May 31, 2023 at 02:13:11AM +0200, Robert Varga wrote:
> > > On 30/05/2023 20.28, Jürgen Schönwälder wrote:
> > > > It is unclear what "identical" means here. If two people extract a
> > > > module from an RFC, they may not end up with identical byte
> > > > sequences. So does white space matter when we talk about MUST be
> > > > identical? What about comments? The problem is that the IETF still
> > > > publishes YANG modules in RFCs instead of files.
> > > 
> > > As for RFC vs. files, the mechanics of extracting of files from RFCs seems
> > > to be well established, plus it is an IETF-owned cron job which updates
> > > https://github.com/YangModels/yang/tree/main/standard/ietf/RFC -- so I 
> > > would
> > > (and I actually do) assume that is the normative source of byte-exact 
> > > files.
> > 
> > I have YANG modules that were extracted years ago using some version
> > of smistrip of the past. Do you believe my files extracted back then
> > are byte-by-byte equivalent to what some cron job produces on some
> > github repo somewhere today?
> 
> smistrip tries to be smart with whitespace and the version I looked up does
> not actually refer to any specification. Also arriving at YANG files would
> then imply RFC6643 processing, right? If that is the case, I would say the
> chances of the files being byte-exact equivalents are close to, but not
> equal, to zero.
> 
> I do not quite understand how the problem of IETF still not publishing files
> should be solved, or whether in fact it is being solved. Do you have any
> references I could use to read up on the current state of affairs, please?

I am not aware of an official authoritative source of YANG files. The
IETF sends documents to the RFC editor for publishing and the RFC
editor meanwhile publishes multiple formats. The discussion that we
should have an official archival repository of data model definitions
is likely more than 20 years old, it surely predates YANG. I have
given up on this but perhaps fresh blood can resolve roadblocks.

>  Do you guarantee that the software behind
> > the cron job will never ever be updated causing it to produce
> > something where white space may differ?
> 
> No, obviously not. But there is a public ledger of all changes made to those
> files. So:
> 
> a) the cron job's results can feasibly be guarded against accidental
> overwrite
> 
> b) if that ever happens, there is a clear indication that it happened, when
> it happened and who has done it.
> 
> On the other hand those guarantees do not hold for RFCs either -- we have
> errata and the associated process.

It would be more useful to explain why byte-level equivalence is now
necessary. So far, we did fine without requiring this.

/js

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

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Robert Varga]

On 31/05/2023 17.22, Andy Bierman wrote:
I checked some recent YANG modules, and the extra newline problem has 
been fixed.


Great :)

I am finding a different issue where trailing whitespace in the author's 
YANG file on github
is removed from the YangModels repo version.  E.g. 
ietf-netconf-server@2023-04-17


Thanks, unfortunately I can't seem to find where the original whitespace 
is in the draft. Can you point me to towards a page/section or line, please?


Thanks,
Robert


OpenPGP_signature
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Robert Varga]

On 31/05/2023 09.50, Jürgen Schönwälder wrote:

On Wed, May 31, 2023 at 02:13:11AM +0200, Robert Varga wrote:

On 30/05/2023 20.28, Jürgen Schönwälder wrote:

It is unclear what "identical" means here. If two people extract a
module from an RFC, they may not end up with identical byte
sequences. So does white space matter when we talk about MUST be
identical? What about comments? The problem is that the IETF still
publishes YANG modules in RFCs instead of files.


As for RFC vs. files, the mechanics of extracting of files from RFCs seems
to be well established, plus it is an IETF-owned cron job which updates
https://github.com/YangModels/yang/tree/main/standard/ietf/RFC -- so I would
(and I actually do) assume that is the normative source of byte-exact files.


I have YANG modules that were extracted years ago using some version
of smistrip of the past. Do you believe my files extracted back then
are byte-by-byte equivalent to what some cron job produces on some
github repo somewhere today?


smistrip tries to be smart with whitespace and the version I looked up 
does not actually refer to any specification. Also arriving at YANG 
files would then imply RFC6643 processing, right? If that is the case, I 
would say the chances of the files being byte-exact equivalents are 
close to, but not equal, to zero.


I do not quite understand how the problem of IETF still not publishing 
files should be solved, or whether in fact it is being solved. Do you 
have any references I could use to read up on the current state of 
affairs, please?


 Do you guarantee that the software behind

the cron job will never ever be updated causing it to produce
something where white space may differ?


No, obviously not. But there is a public ledger of all changes made to 
those files. So:


a) the cron job's results can feasibly be guarded against accidental 
overwrite


b) if that ever happens, there is a clear indication that it happened, 
when it happened and who has done it.


On the other hand those guarantees do not hold for RFCs either -- we 
have errata and the associated process.


Regards,
Robert


OpenPGP_signature
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Andy Bierman]

On Wed, May 31, 2023 at 3:12 AM Andy Bierman  wrote:

>
>
> On Wed, May 31, 2023 at 12:50 AM Jürgen Schönwälder
>  wrote:
>
>> On Wed, May 31, 2023 at 02:13:11AM +0200, Robert Varga wrote:
>> > On 30/05/2023 20.28, Jürgen Schönwälder wrote:
>> > >It is unclear what "identical" means here. If two people extract a
>> > >module from an RFC, they may not end up with identical byte
>> > >sequences. So does white space matter when we talk about MUST be
>> > >identical? What about comments? The problem is that the IETF still
>> > >publishes YANG modules in RFCs instead of files.
>> >
>> > As for RFC vs. files, the mechanics of extracting of files from RFCs
>> seems
>> > to be well established, plus it is an IETF-owned cron job which updates
>> > https://github.com/YangModels/yang/tree/main/standard/ietf/RFC -- so I
>> would
>> > (and I actually do) assume that is the normative source of byte-exact
>> files.
>>
>> I have YANG modules that were extracted years ago using some version
>> of smistrip of the past. Do you believe my files extracted back then
>> are byte-by-byte equivalent to what some cron job produces on some
>> github repo somewhere today? Do you guarantee that the software behind
>> the cron job will never ever be updated causing it to produce
>> something where white space may differ?
>>
>>
> The rfcstrip tool has been adding extra '\n' characters to YANG modules
> for years.
> In fact, there is not even one YANG module on a repo somewhere that is a
> byte-exact copy of the RFC version.
>
>
I checked some recent YANG modules, and the extra newline problem has been
fixed.
I am finding a different issue where trailing whitespace in the author's
YANG file on github
is removed from the YangModels repo version.  E.g.
ietf-netconf-server@2023-04-17

This should be a normal non-issue, but the new proposal requires a new
revision date
every time a meaningless space is added or removed from the file. Not sure
what problem
that is trying to solve.


/js
>>
>>
> Andy
>
>
>
>> --
>> 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.org/mailman/listinfo/netmod

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Andy Bierman]

On Wed, May 31, 2023 at 12:50 AM Jürgen Schönwälder
 wrote:

> On Wed, May 31, 2023 at 02:13:11AM +0200, Robert Varga wrote:
> > On 30/05/2023 20.28, Jürgen Schönwälder wrote:
> > >It is unclear what "identical" means here. If two people extract a
> > >module from an RFC, they may not end up with identical byte
> > >sequences. So does white space matter when we talk about MUST be
> > >identical? What about comments? The problem is that the IETF still
> > >publishes YANG modules in RFCs instead of files.
> >
> > As for RFC vs. files, the mechanics of extracting of files from RFCs
> seems
> > to be well established, plus it is an IETF-owned cron job which updates
> > https://github.com/YangModels/yang/tree/main/standard/ietf/RFC -- so I
> would
> > (and I actually do) assume that is the normative source of byte-exact
> files.
>
> I have YANG modules that were extracted years ago using some version
> of smistrip of the past. Do you believe my files extracted back then
> are byte-by-byte equivalent to what some cron job produces on some
> github repo somewhere today? Do you guarantee that the software behind
> the cron job will never ever be updated causing it to produce
> something where white space may differ?
>
>
The rfcstrip tool has been adding extra '\n' characters to YANG modules for
years.
In fact, there is not even one YANG module on a repo somewhere that is a
byte-exact copy of the RFC version.

/js
>
>
Andy



> --
> 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.org/mailman/listinfo/netmod

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Jürgen Schönwälder]

On Wed, May 31, 2023 at 02:13:11AM +0200, Robert Varga wrote:
> On 30/05/2023 20.28, Jürgen Schönwälder wrote:
> >It is unclear what "identical" means here. If two people extract a
> >module from an RFC, they may not end up with identical byte
> >sequences. So does white space matter when we talk about MUST be
> >identical? What about comments? The problem is that the IETF still
> >publishes YANG modules in RFCs instead of files.
> 
> As for RFC vs. files, the mechanics of extracting of files from RFCs seems
> to be well established, plus it is an IETF-owned cron job which updates
> https://github.com/YangModels/yang/tree/main/standard/ietf/RFC -- so I would
> (and I actually do) assume that is the normative source of byte-exact files.

I have YANG modules that were extracted years ago using some version
of smistrip of the past. Do you believe my files extracted back then
are byte-by-byte equivalent to what some cron job produces on some
github repo somewhere today? Do you guarantee that the software behind
the cron job will never ever be updated causing it to produce
something where white space may differ?

/js

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

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Andy Bierman]

On Tue, May 30, 2023 at 5:13 PM Robert Varga  wrote:

> On 30/05/2023 20.28, Jürgen Schönwälder wrote:
> >It is unclear what "identical" means here. If two people extract a
> >module from an RFC, they may not end up with identical byte
> >sequences. So does white space matter when we talk about MUST be
> >identical? What about comments? The problem is that the IETF still
> >publishes YANG modules in RFCs instead of files.
>
> As for RFC vs. files, the mechanics of extracting of files from RFCs
> seems to be well established, plus it is an IETF-owned cron job which
> updates https://github.com/YangModels/yang/tree/main/standard/ietf/RFC
> -- so I would (and I actually do) assume that is the normative source of
> byte-exact files.
>
> In my opinion "identical" leaves little room for interpretation: it is
> byte-exact, i.e. md5sum (and everything else of that kind) returning the
> same value.
>
> If we were to say "equivalent", now that would be a whole another kettle
> of fish.
>
> I stand to be corrected, but I do not believe there is a single
> normative statement about handling equivalent Unicode encodings. As a
> tool author, I believe having that is a hard prerequisite to be solved
> before we ever embark on pulling in YANG semantics into the conversation.
>
> I do have opinions around that, in particular the equivalence of
> - description "foo"
> - description 'foo'
> - description foo
> and the order of preference of those (which may contradict best current
> practice), but I certainly do not have the cycles to engage in that
> discussion to a reasonable depth :(
>
>

There are many ways to maintain semantic equivalence with vastly different
language syntax.
That is a separate issue I think.

As per [RFC7950 ] and [RFC6020
], all published revisions of a
module are given a new unique revision date. This applies even for module
revisions containing (in the module or included submodules) only changes to
any whitespace, formatting, comments or line endings (e.g., DOS vs UNIX).¶


I disagree with this proposed module update rule.
This includes insignificant whitespace that is ignored in the YANG
language.

Your example description-stmt should count as a change since each string
form has different rules.

Changing any characters, even changing the newline (dos2unix) or trimming
trailing whitespace on a line, requires a new module revision.

IMO this is a bad idea since it is too fragile.
E.g., tools might change the end-of-line chars so they are correct
for the operating system used to store the file. Module authors should not
need to
track insignificant whitespace changes that are ignored in YANG.



> Regards,
> Robert
>

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

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Robert Varga]

On 30/05/2023 20.28, Jürgen Schönwälder wrote:

   It is unclear what "identical" means here. If two people extract a
   module from an RFC, they may not end up with identical byte
   sequences. So does white space matter when we talk about MUST be
   identical? What about comments? The problem is that the IETF still
   publishes YANG modules in RFCs instead of files.


As for RFC vs. files, the mechanics of extracting of files from RFCs 
seems to be well established, plus it is an IETF-owned cron job which 
updates https://github.com/YangModels/yang/tree/main/standard/ietf/RFC 
-- so I would (and I actually do) assume that is the normative source of 
byte-exact files.


In my opinion "identical" leaves little room for interpretation: it is 
byte-exact, i.e. md5sum (and everything else of that kind) returning the 
same value.


If we were to say "equivalent", now that would be a whole another kettle 
of fish.


I stand to be corrected, but I do not believe there is a single 
normative statement about handling equivalent Unicode encodings. As a 
tool author, I believe having that is a hard prerequisite to be solved 
before we ever embark on pulling in YANG semantics into the conversation.


I do have opinions around that, in particular the equivalence of
- description "foo"
- description 'foo'
- description foo
and the order of preference of those (which may contradict best current 
practice), but I certainly do not have the cycles to engage in that 
discussion to a reasonable depth :(


Regards,
Robert


OpenPGP_signature
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Jürgen Schönwälder]

On Mon, May 08, 2023 at 10:49:15PM +, Kent Watsen wrote:
> Dear NETMOD WG,
> 
> This message begins a joint two-week WGLC for 
> draft-ietf-netmod-yang-semver-11 and 
> draft-ietf-netmod-yang-module-versioning-09
>  ending on Monday, May 22nd.  Neither draft has IPR declared.  Here are the 
> direct links to the HTML version for these drafts:
> 
>- https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver-11
>- 
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-09
> 
> 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.
>

Comments on draft-ietf-netmod-yang-module-versioning-09.txt:

- My opinion about changing YANG 1.1 rules without bumping the YANG
  version number is likely clear to everyone so I won't repeat it
  here.

- YANG 1.1 does not have an import by minimum revision, which clearly
  is a bug in YANG 1.1. This document now introduces a "soft" version
  of an import by minimum revision but the sad story is that this
  remains again incomplete from the perspective of the new versioning
  scheme. If we allow NBC changes, then it is necessary to express
  revision ranges since the definitions a module depends on can appear
  at revision a.b.c and disappear at revision e.f.g (and perhaps even
  reappear in revision h.i.j). Hence, we again have an incomplete
  solution.

- Do we really need to support multiple 'revision label schemes'? If
  so, we have to work out more details. What kind of order properties
  do we expect from revision label schemes? And what is the
  relationship between a versioning scheme and a revision label
  scheme? Can you mix and match revision label schemes? What happens
  to revision labels encoded in file names, can there be collisions
  between different revision label schemes?  Perhaps we are
  over-engineering here and one 'revision label scheme' that people
  can agree on is sufficient and simplifies things?

- Instead of multiple 'revision label schemes' for the same
  'versioning scheme', I think it makes sense to consider support of
  multiple 'versioning schemes' (not just different label schemes, for
  me different labels expressing the same information are pointless).
  Can we design a solution where the original 'linear order always
  backwards compatible versioning scheme' of RFC 7950 becomes just one
  of several versioning schemes we have? This would essentially mean
  that the update rules become a property of a versioning scheme
  instead of being a hardwired property of the language. Perhaps there
  could even be space for a third 'null versioning scheme' that defers
  all versioning to a package solution where the package definitions
  define which modules work together, i.e., we focus on versioning
  packages instead of individual modules.

- I suggested (long time ago) to maintain versioning constraints
  outside of the modules. This allows to update import constraints
  without having to edit and republish modules. (And versioning
  packages of modules may be more practical than versioning each and
  every module once a data model reach a certain size.) I guess I
  rather have semantic version numbers on packages of modules than on
  each and every module itself. The beginning of section 4 seems to be
  spot on but then we fall back doing the wrong thing.

- The document seems to be silent about how different versions can be
  supported. In the old world, having foo and foo2 coexist was easy,
  clients could gradually be updated to use foo2 instead of foo. In
  the new versioning world, this becomes more complex and may require
  protocol work. It remains unclear to me where and when this protocol
  work will be done.

- More specific comments follow. Concerning this:

   *  Any change made to the "revision-date" or "recommended-min"
  substatements of an "import" statement, including adding new
  "revision-date" or "recommended-min" substatements, changing the
  argument of any "revision-date" or "recommended-min"
  substatetements, or removing any "revision-date" or "recommended-
  min" substatements, is classified as backwards-compatible.

  Why is that? If I add/change recommended-min to a module revision
  that has NBC changes affecting the current module, then how can this
  be considered backwards compatible?

- Why do we tag modules with rev:non-backwards-compatible? Why do we
  not tag the concrete definitions that have non-backwards-compatible
  changes and then the rev:non-backwards-compatible is implied?

- What are the order rules for revision labels? A statement like
  rev:recommended-min only makes sense if there is a certain order
  defined.

- Concerning this:

A specific revision label identifies a specific revision of the
module.  If two YANG modules contain the same 

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Joe Clarke (jclarke)]

Thank you for the review, Alex.  A big thanks for catching the sync issue with 
yang-module-versioning.  I have updated the text in GitHub pending the end of 
WGLC to make sure we capture all of the feedback.

The diff can be found at 
https://github.com/netmod-wg/yang-ver-dt/commit/5081c8af42a3d93a6e25d0106bf80e483c960c08.

Joe

From: netmod  on behalf of Alex Huang Feng 

Date: Monday, May 22, 2023 at 12:58
To: netmod@ietf.org 
Subject: Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts
Dear NETMOD,

I have read both draft and they look good. One minor comment.
On the last iterations of the versioning draft, the "revision-or-derived” 
extension was changed to “recommended-min”.
Though, in the semver draft, "revision-or-derived” is still being used. Can you 
change that to remain consistent?


Thanks,
Alex




On 9 May 2023, at 00:49, Kent Watsen 
mailto:kent+i...@watsen.net>> wrote:

Dear NETMOD WG,

This message begins a joint two-week WGLC for draft-ietf-netmod-yang-semver-11 
and draft-ietf-netmod-yang-module-versioning-09
ending on Monday, May 22nd.  Neither draft has IPR declared.  Here are the 
direct links to the HTML version for these drafts:

  - https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver-11
  - 
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-09

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 and Lou (chairs)








___
netmod mailing list
netmod@ietf.org<mailto: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] Joint WGLC on "semver" and "module-versioning" drafts

[Andy Bierman]

On Tue, May 16, 2023 at 11:10 AM Robert Varga  wrote:

> On 09/05/2023 00.49, Kent Watsen wrote:
> > Dear NETMOD WG,
> >
> > This message begins a joint two-week WGLC for
> draft-ietf-netmod-yang-semver-11 and
> draft-ietf-netmod-yang-module-versioning-09
> >   ending on Monday, May 22nd.  Neither draft has IPR declared.  Here are
> the direct links to the HTML version for these drafts:
> >
> > -
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver-11
> > -
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-09
> >
> > 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.
>
> Hello, I have reviewed the module-versioning draft and overall it looks
> fine (well, aside from the incoming pain :), but we'll cope with that in
> due time).
>
> One concern I have is with
>
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-09#name-file-names,
>
> which changes file naming.
>
> Previously the canonical file name included revision -- and now that
> information is lost. While I understand the desire for descriptive
> names, which are a boon for humans, the until the entire ecosystem
> adopts labels, this change is either-or -- and hence tools have to pick
> which metadata is more important: label or revision.
>
> Would it be possible to define a format which contains *both* the label
> and revision, so as not to pick favorites?
>
>

This is an example of an important detail that could be solved differently
if a new YANG language version was used.  In YANG 1.1 the revision-date is
optional.
In YANG 1.2, both the revision-date and label could be mandatory.

It is common practice to release YANG changes in multiple release trains
on the same day.  So the {date, label} is the unique identifier for the
YANG file,
not some combination of optional parts.  IMO the file name you suggest
should
be the mandatory-to-implement canonical file name format for YANG 1.2.

I understand it could be a bad idea to start over with the yang-next list
and "work on YANG 1.2".
IMO there are only a small number of must-haves on that list, and most
issues
could be deferred. YANG 1.2 could be derived from these 2 drafts + a small
number of yang-next issues.

In the current form, I do not agree that the YANG module revision update
rules
should be updated without changing the yang-version value.


Thanks,
> Robert
>


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

Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Kent Watsen]

NETMOD WG,

The chairs are extending this WGLC by two weeks (now ending June 5) in order to 
ensure adequate review, since this is important work, and a solid consensus is 
needed.

Kent and Lou



> On May 8, 2023, at 6:49 PM, Kent Watsen  wrote:
> 
> Dear NETMOD WG,
> 
> This message begins a joint two-week WGLC for 
> draft-ietf-netmod-yang-semver-11 and 
> draft-ietf-netmod-yang-module-versioning-09
> ending on Monday, May 22nd.  Neither draft has IPR declared.  Here are the 
> direct links to the HTML version for these drafts:
> 
>   - https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver-11
>   - 
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-09
> 
> 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 and Lou (chairs)
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> 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] Joint WGLC on "semver" and "module-versioning" drafts

[Alex Huang Feng]

Dear NETMOD,

I have read both draft and they look good. One minor comment.
On the last iterations of the versioning draft, the "revision-or-derived” 
extension was changed to “recommended-min”. 
Though, in the semver draft, "revision-or-derived” is still being used. Can you 
change that to remain consistent?

Thanks,
Alex


> On 9 May 2023, at 00:49, Kent Watsen  wrote:
> 
> Dear NETMOD WG,
> 
> This message begins a joint two-week WGLC for 
> draft-ietf-netmod-yang-semver-11 and 
> draft-ietf-netmod-yang-module-versioning-09
> ending on Monday, May 22nd.  Neither draft has IPR declared.  Here are the 
> direct links to the HTML version for these drafts:
> 
>   - https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver-11
>   - 
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-09
> 
> 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 and Lou (chairs)
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> 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] Joint WGLC on "semver" and "module-versioning" drafts

[Robert Varga]

On 09/05/2023 00.49, Kent Watsen wrote:

Dear NETMOD WG,

This message begins a joint two-week WGLC for draft-ietf-netmod-yang-semver-11 
and draft-ietf-netmod-yang-module-versioning-09
  ending on Monday, May 22nd.  Neither draft has IPR declared.  Here are the 
direct links to the HTML version for these drafts:

- https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver-11
- 
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-09

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.


Hello, I have reviewed the module-versioning draft and overall it looks 
fine (well, aside from the incoming pain :), but we'll cope with that in 
due time).


One concern I have is with 
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-09#name-file-names, 
which changes file naming.


Previously the canonical file name included revision -- and now that 
information is lost. While I understand the desire for descriptive 
names, which are a boon for humans, the until the entire ecosystem 
adopts labels, this change is either-or -- and hence tools have to pick 
which metadata is more important: label or revision.


Would it be possible to define a format which contains *both* the label 
and revision, so as not to pick favorites?


Thanks,
Robert


OpenPGP_signature
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Kent Watsen]

Dear NETMOD WG,

This message begins a joint two-week WGLC for draft-ietf-netmod-yang-semver-11 
and draft-ietf-netmod-yang-module-versioning-09
 ending on Monday, May 22nd.  Neither draft has IPR declared.  Here are the 
direct links to the HTML version for these drafts:

   - https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver-11
   - 
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-09

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 and Lou (chairs)








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