Re: [netmod] Poll on YANG Versioning NBC Approach

[Lou Berger]

WG,

Based on the very good discussion on list and the opinions recorded on 
the poll, the Chairs want to state that the WG has agreed to:


"OPTION 1. Publish an RFC based on 
draft-ietf-netmod-yang-module-versioning that updates both YANG 1.0 (RFC 
6020) and YANG 1.1 (RFC 7950) to allow YANG modules to be modified with 
non-backwards-compatible changes – This option does not change the YANG 
version number."


There remain open issues from the last call and there continues to be be 
good discussion on the poll and related to the document. We look to the 
document Editors to continue to move the document to address the open 
issues and gauge their understanding of WG position on this document. 
Once the document is ready, there will be an additional, and hopefully 
final, WG LC.


Kent and Lou

On 9/11/2023 6:39 PM, Kent Watsen wrote:

WG,

Please help the YANG-versioning effort move forward by participating 
in the following poll:


  - https://notes.ietf.org/netmod-2023-sept-poll (Datatracker login 
required)


Kent and Lou


___
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] Poll on YANG Versioning NBC Approach

[Per Andersson (perander)]

Hi!

> Andy Bierman  on Thursday, September 14, 2023 18:40:
>> On Thu, Sep 14, 2023 at 9:05 AM Acee Lindem 
>> mailto:acee.i...@gmail.com>> wrote:
>>> On Sep 13, 2023, at 10:36, Ladislav Lhotka 
>>> mailto:40nic...@dmarc.ietf.org>> 
>>> wrote:
(...)
>>> We have already seen cases that the update rules prevented fixing problems 
>>> in YANG modules in a straightforward way, and backward-compatible fixes 
>>> negatively affected module readability. This is inevitable until the 
>>> ecosystem of YANG modules stabilizes. That's why I think changing update 
>>> rules from MUST to SHOULD is appropriate - it should have been so from the 
>>> beginning.
>>
>> I wholeheartedly agree. We need to be able to fix YANG modules with NBC 
>> changes. I know of at least one implementation that support NBC changes for 
>> proprietary models with node-specific translation
>
> Some of us do not think a bugfix counts as an NBC change.
> If the YANG definition is wrong and has been wrong from the start, then BC is 
> not important.
> Fixing the YANG module so the definitions match the intent of the authors is 
> important.

I don't understand why the motivation for a particular change should come into 
play.
Either the change is NBC or BC, whether it being a bugfix or not, and the text 
in RFC 7950
states how it should be handled.

Although I am on the vendor side in this context, as a user I find it important 
to be notified
if a change is NBC even if it is a bugfix. It is also important to be able to 
both publish and
consume compatibility levels on dependencies and imports, e.g. recommended-min.


> IMO this new draft is not really needed at all, since bugfix exceptions 
> should be allowed
> and should have always been allowed.

I was not involved when YANG was defined, so I know little to nothing of these 
discussions.
What I follow is the actual text in the standard, and it does not discern 
between classes of
motivation for changes (e.g. bugfix, feature) and how they should be allowed or 
not.


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

Re: [netmod] Poll on YANG Versioning NBC Approach

[Robert Varga]

On 13/09/2023 16.36, Ladislav Lhotka wrote:



Dne 13. 09. 23 v 16:06 Jernej Tuljak napsal(a):


If you are asking whether I'd like to see a new version of YANG for 
the sole purpose of changing those MUST and MUST NOTs - no, I would 
not. However, a change like this mandates a yang-version bump, IMHO.


Right, so we have two ugly options, but bumping YANG version really 
makes no sense, so breaking those few tools that check update rules 
looks like a better choice to me.


We have already seen cases that the update rules prevented fixing 
problems in YANG modules in a straightforward way, and 
backward-compatible fixes negatively affected module readability. This 
is inevitable until the ecosystem of YANG modules stabilizes. That's why 
I think changing update rules from MUST to SHOULD is appropriate - it 
should have been so from the beginning.


+1.

Regards,
Robert


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

Re: [netmod] Poll on YANG Versioning NBC Approach

[Andy Bierman]

On Thu, Sep 14, 2023 at 11:46 AM Jürgen Schönwälder
 wrote:

> If the poll does not say what you want it to say, then the poll is
> broken.
>
> Right now, I see the following solution proposals floating around:
>
> 1) We change a single sentence in RFC 7950 and put an end to a
>multi-year effort that causes the AD to block other work from
>moving forward.
>

OK.
It would be useful to identify the specific text in RFC 7950
that is causing all these problems for the IETF.

 IMO, nobody is objecting to the MUST or MUST NOT text in sec 11, para 2,
3, 4, and 7.

There is only 1 paragraph in the entire RFC that needs to change (sec 11,
para 6)

OLD:

   Otherwise, if the semantics of any previous definition are changed
   (i.e., if a non-editorial change is made to any definition other than
   those specifically allowed above), then this MUST be achieved by a
   new definition with a new identifier.


NEW:

   Otherwise, if the semantics of any previous definition are changed
   (i.e., if a non-editorial change is made to any definition other than
   those specifically allowed above), then this SHOULD be achieved by a
   new definition with a new identifier.

My preferred solution path:

 1) Issue Errata for RFC 7950 and Hold for Update or Verify.
 Either way, allow IETF modules to use the NEW text
 2) Remove updates to RFC 7950 from the versioning draft
 3) fix the other issues raised with the versioning draft and publish it

Andy



> 2) We make changes to YANG but we pretend that they are not real
>changes to YANG and we leave it to developers and operators to
>figure out differences in implementation behaviour one can create.
>
> 3) We make some minimal changes to YANG and we create clarity which
>rules apply and what what implementations support by giving the
>result a new version number.
>
> Are there others? Lets talk about solutions and their properties, lets
> stop standing on our heads. Guess what my acceptable and non-acceptable
> solutions are.
>
> /js
>
> On Thu, Sep 14, 2023 at 03:42:43PM +, Jason Sterne (Nokia) wrote:
> > I think it has been mentioned, but maybe worth repeating: this poll is
> *NOT* about accepting the entire Module Versioning + YANG Semver content as
> it currently stands.
> >
> > We separated out the first of several key issues to try and make
> progress. This is just the basic fundamental decision of whether we will
> allow (as a "SHOULD NOT") NBC changes in in YANG 1.0/YANG1.1  (option 1),
> or we are going to mandate that can only happen in a YANG 1.2 (option 2).
> >
> > After this poll settles out (hoping we'll get rough concensus), then
> we'll get back to chipping away at the other key issues (e.g. see email
> "YANG Versioning: Key Issues #2 and #3 - revision labels" from back in
> July, but there will be several other such debates & discussions).
> >
> > Jason
> >
> > > -Original Message-
> > > From: netmod  On Behalf Of Jürgen Schönwälder
> > > Sent: Thursday, September 14, 2023 5:35 AM
> > > To: Rob Wilton (rwilton) 
> > > Cc: Jan Lindblad (jlindbla) ; netmod@ietf.org
> > > Subject: Re: [netmod] Poll on YANG Versioning NBC Approach
> > >
> > >
> > > 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, Sep 12, 2023 at 01:42:57PM +, Rob Wilton (rwilton) wrote:
> > > >
> > > > I think that for this first poll this is the question that we should
> initially focus on.
> > > I.e., at a starting point, do you agree to updating RFC 6020, RFC
> 7950, to allow
> > > changing the MUST to a SHOULD without a new YANG 1.2?
> > > >
> > >
> > > There are many options, one is to just change a single sentence. But
> > > the poll fails to sort the options out.
> > >
> > > > If we can get consensus on this part, then I think that we can try
> and tackle
> > > getting consensus on the other updates in
> draft-ietf-netmod-yang-module-
> > > versioning to decide whether to include those in a document that
> updates existing
> > > versions of YANG without a change in the YANG versioning number, or
> whether
> > > those changes should be deferred to a new version of YANG (which I
> hope that
> > > the WG starts after this versioning work completes - but I'll no
> longer be an AD at
> > > that stage).
> > >
> > > This work is going on for years, the WG has failed so far to enumerate
> > > the options and come to

Re: [netmod] Poll on YANG Versioning NBC Approach

[Andy Bierman]

On Thu, Sep 14, 2023 at 10:09 AM Acee Lindem  wrote:

>
>
> On Sep 14, 2023, at 12:40, Andy Bierman  wrote:
>
>
>
> On Thu, Sep 14, 2023 at 9:05 AM Acee Lindem  wrote:
>
>>
>>
>> > On Sep 13, 2023, at 10:36, Ladislav Lhotka > 40nic...@dmarc.ietf.org> wrote:
>> >
>> >
>> >
>> > Dne 13. 09. 23 v 16:06 Jernej Tuljak napsal(a):
>> >> On 13/09/2023 14:26, Jan Lindblad (jlindbla) wrote:
>> >>> Jernej,
>> >>>
>> >>> Hat off for the tools (and tool vendors!) that assist authors to stay
>> true to YANG RFC sections 10 and 11 also. Well done. :-)
>> >>>
>> >>> I intentionally used "compiler" rather than "toolchain", "IDE" or
>> something more open ended, because a compiler is what I have and can speak
>> for.
>> >>>
>> >>> Even so, I have a hard time thinking the customers of even the best
>> YANG IDEs would be interested to pay the effort for distinguishing between
>> YANG 1.1 and YANG 1.2 solely on the proposed RFC wording difference. Since
>> a BC verification capability apparently already exists in some IDEs, I
>> think it would make sense for their vendors to turn the checks it into a
>> warnings (if they aren't already), regardless of which yang-version
>> statement is found in the module header.
>> >>>
>> >>> This might mean a non-zero implementation effort for a few YANG
>> toolchain implementors. While this is a good point, it does not really sway
>> my opinion about what the pragmatic choice for IETF is. Or Jernej, do you
>> think the users of those good IDEs would prefer a new YANG version? If so,
>> why?
>> >> If you are asking whether I'd like to see a new version of YANG for
>> the sole purpose of changing those MUST and MUST NOTs - no, I would not.
>> However, a change like this mandates a yang-version bump, IMHO.
>> >
>> > Right, so we have two ugly options, but bumping YANG version really
>> makes no sense, so breaking those few tools that check update rules looks
>> like a better choice to me.
>> >
>> > We have already seen cases that the update rules prevented fixing
>> problems in YANG modules in a straightforward way, and backward-compatible
>> fixes negatively affected module readability. This is inevitable until the
>> ecosystem of YANG modules stabilizes. That's why I think changing update
>> rules from MUST to SHOULD is appropriate - it should have been so from the
>> beginning.
>>
>> I wholeheartedly agree. We need to be able to fix YANG modules with NBC
>> changes. I know of at least one implementation that support NBC changes for
>> proprietary models with node-specific translation
>>
>>
> Some of us do not think a bugfix counts as an NBC change.
> If the YANG definition is wrong and has been wrong from the start, then BC
> is not important.
> Fixing the YANG module so the definitions match the intent of the authors
> is important.
>
> IMO this new draft is not really needed at all, since bugfix exceptions
> should be allowed
> and should have always been allowed.
>
>
> What about models that are not functionally broken but need to be fixed
> for other reasons? For example, to adhere to IETF inclusive language?
>
> Would you still require a years long publication process for deprecation
> followed by another years long cycle to remove the deprecated nodes? For
> example:
>
> https://datatracker.ietf.org/doc/draft-acee-rtgwg-vrrp-rfc8347bis/
>
>
Years long process is not written anywhere in RFC 7950.  ;-)

I am OK with treating NBC changes as SHOULD NOT.

  SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that

   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.


I don't care about the details of each YANG object.
That is for reviewers to decide.



Thanks,
> Acee
>

Andy


>
>
>
>
> Thanks,
>> Acee
>>
>>
> Andy
>
>
>>
>>
>>
>> >
>> > Lada
>> >
>> >> Jernej
>> >>>
>> >>> Best Regards,
>> >>> /jan
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>>  On 13 Sep 2023, at 10:57, Jernej Tuljak 
>> wrote:
>> 
>>  On 12/09/2023 14:43, Jan Lindblad (jlindbla) wrote:
>> > Jürgen, all,
>> >
>> > I see the irony in changing the YANG RFC(s) without updating the
>> YANG language version number, but digging a bit deeper, I think the
>> question is not as clear-cut as it might seem at first.
>> >
>> > Altering the contents of the backwards-compatibility section of RFC
>> 6020 (sec 10) and RFC 7950 (sec 11) clearly implies changes in YANG module
>> authors' behavior.
>> >
>> > Speaking as a YANG compiler implementor, however, I don't see any
>> changes that have to made to the compiler because of this RFC change. There
>> are no new keywords, none are removed. There is no change in the meaning of
>> existing keywords. There is no difference in the output the compiler needs
>> to generate.
>> >
>> > So while there are changes to the YANG 

Re: [netmod] Poll on YANG Versioning NBC Approach

[Jürgen Schönwälder]

If the poll does not say what you want it to say, then the poll is
broken.

Right now, I see the following solution proposals floating around:

1) We change a single sentence in RFC 7950 and put an end to a
   multi-year effort that causes the AD to block other work from
   moving forward.

2) We make changes to YANG but we pretend that they are not real
   changes to YANG and we leave it to developers and operators to
   figure out differences in implementation behaviour one can create.

3) We make some minimal changes to YANG and we create clarity which
   rules apply and what what implementations support by giving the
   result a new version number.

Are there others? Lets talk about solutions and their properties, lets
stop standing on our heads. Guess what my acceptable and non-acceptable
solutions are.

/js

On Thu, Sep 14, 2023 at 03:42:43PM +, Jason Sterne (Nokia) wrote:
> I think it has been mentioned, but maybe worth repeating: this poll is *NOT* 
> about accepting the entire Module Versioning + YANG Semver content as it 
> currently stands.
> 
> We separated out the first of several key issues to try and make progress. 
> This is just the basic fundamental decision of whether we will allow (as a 
> "SHOULD NOT") NBC changes in in YANG 1.0/YANG1.1  (option 1), or we are going 
> to mandate that can only happen in a YANG 1.2 (option 2).
> 
> After this poll settles out (hoping we'll get rough concensus), then we'll 
> get back to chipping away at the other key issues (e.g. see email "YANG 
> Versioning: Key Issues #2 and #3 - revision labels" from back in July, but 
> there will be several other such debates & discussions).
> 
> Jason
> 
> > -Original Message-
> > From: netmod  On Behalf Of Jürgen Schönwälder
> > Sent: Thursday, September 14, 2023 5:35 AM
> > To: Rob Wilton (rwilton) 
> > Cc: Jan Lindblad (jlindbla) ; netmod@ietf.org
> > Subject: Re: [netmod] Poll on YANG Versioning NBC Approach
> > 
> > 
> > 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, Sep 12, 2023 at 01:42:57PM +, Rob Wilton (rwilton) wrote:
> > >
> > > I think that for this first poll this is the question that we should 
> > > initially focus on.
> > I.e., at a starting point, do you agree to updating RFC 6020, RFC 7950, to 
> > allow
> > changing the MUST to a SHOULD without a new YANG 1.2?
> > >
> > 
> > There are many options, one is to just change a single sentence. But
> > the poll fails to sort the options out.
> > 
> > > If we can get consensus on this part, then I think that we can try and 
> > > tackle
> > getting consensus on the other updates in draft-ietf-netmod-yang-module-
> > versioning to decide whether to include those in a document that updates 
> > existing
> > versions of YANG without a change in the YANG versioning number, or whether
> > those changes should be deferred to a new version of YANG (which I hope that
> > the WG starts after this versioning work completes - but I'll no longer be 
> > an AD at
> > that stage).
> > 
> > This work is going on for years, the WG has failed so far to enumerate
> > the options and come to a conclusion.
> > 
> > > > There are features in draft-ietf-netmod-yang-module-versioning that
> > > > you can use only with new tools that implement the features. I am not
> > > > sure why tools that support different variants of YANG 1 and YANG 1.1
> > > > are any easier in practice than a tool that says clearly what it
> > > > implements.
> > > [Rob Wilton (rwilton)]
> > >
> > > I hear two concerns:
> > > (1) Existing tooling handling YANG 1 and YANG 1.1 modules must handle NBC
> > changes anyway because they see them in the wild and that won't change.  
> > E.g.,
> > it is 99% likely that OpenConfig will still continue to use Yang 1 modules.
> > > (2) All existing tooling won't be able to handle YANG 1.2 without tooling
> > changes.
> > 
> > If you do not need YANG 1.2 features, YANG 1 just works fine. The
> > assumption that once can use YANG 1.2 features with YANG 1 modules by
> > simply not calling the features YANG 1.2 is what puts me off.
> > 
> > > > I continue to believe the questions are badly phrased. Instead of
> > > > discussing properties and trade-offs of solutions, we discuss the
> > > > version number. And we accept that bumping the version number is
> > > > considered too cost

Re: [netmod] Poll on YANG Versioning NBC Approach

[Acee Lindem]

> On Sep 14, 2023, at 12:40, Andy Bierman  wrote:
> 
> 
> 
> On Thu, Sep 14, 2023 at 9:05 AM Acee Lindem  > wrote:
>> 
>> 
>> > On Sep 13, 2023, at 10:36, Ladislav Lhotka 
>> > mailto:40nic...@dmarc.ietf.org>> 
>> > wrote:
>> > 
>> > 
>> > 
>> > Dne 13. 09. 23 v 16:06 Jernej Tuljak napsal(a):
>> >> On 13/09/2023 14:26, Jan Lindblad (jlindbla) wrote:
>> >>> Jernej,
>> >>> 
>> >>> Hat off for the tools (and tool vendors!) that assist authors to stay 
>> >>> true to YANG RFC sections 10 and 11 also. Well done. :-)
>> >>> 
>> >>> I intentionally used "compiler" rather than "toolchain", "IDE" or 
>> >>> something more open ended, because a compiler is what I have and can 
>> >>> speak for.
>> >>> 
>> >>> Even so, I have a hard time thinking the customers of even the best YANG 
>> >>> IDEs would be interested to pay the effort for distinguishing between 
>> >>> YANG 1.1 and YANG 1.2 solely on the proposed RFC wording difference. 
>> >>> Since a BC verification capability apparently already exists in some 
>> >>> IDEs, I think it would make sense for their vendors to turn the checks 
>> >>> it into a warnings (if they aren't already), regardless of which 
>> >>> yang-version statement is found in the module header.
>> >>> 
>> >>> This might mean a non-zero implementation effort for a few YANG 
>> >>> toolchain implementors. While this is a good point, it does not really 
>> >>> sway my opinion about what the pragmatic choice for IETF is. Or Jernej, 
>> >>> do you think the users of those good IDEs would prefer a new YANG 
>> >>> version? If so, why?
>> >> If you are asking whether I'd like to see a new version of YANG for the 
>> >> sole purpose of changing those MUST and MUST NOTs - no, I would not. 
>> >> However, a change like this mandates a yang-version bump, IMHO.
>> > 
>> > Right, so we have two ugly options, but bumping YANG version really makes 
>> > no sense, so breaking those few tools that check update rules looks like a 
>> > better choice to me.
>> > 
>> > We have already seen cases that the update rules prevented fixing problems 
>> > in YANG modules in a straightforward way, and backward-compatible fixes 
>> > negatively affected module readability. This is inevitable until the 
>> > ecosystem of YANG modules stabilizes. That's why I think changing update 
>> > rules from MUST to SHOULD is appropriate - it should have been so from the 
>> > beginning.
>> 
>> I wholeheartedly agree. We need to be able to fix YANG modules with NBC 
>> changes. I know of at least one implementation that support NBC changes for 
>> proprietary models with node-specific translation
>> 
> 
> Some of us do not think a bugfix counts as an NBC change.
> If the YANG definition is wrong and has been wrong from the start, then BC is 
> not important.
> Fixing the YANG module so the definitions match the intent of the authors is 
> important.
> 
> IMO this new draft is not really needed at all, since bugfix exceptions 
> should be allowed
> and should have always been allowed. 

What about models that are not functionally broken but need to be fixed for 
other reasons? For example, to adhere to IETF inclusive language? 

Would you still require a years long publication process for deprecation 
followed by another years long cycle to remove the deprecated nodes? For 
example:

https://datatracker.ietf.org/doc/draft-acee-rtgwg-vrrp-rfc8347bis/

Thanks,
Acee 


> 
> 
>> Thanks,
>> Acee 
>> 
> 
> Andy
>  
>> 
>> 
>> 
>> > 
>> > Lada
>> > 
>> >> Jernej
>> >>> 
>> >>> Best Regards,
>> >>> /jan
>> >>> 
>> >>> 
>> >>> 
>> >>> 
>> >>> 
>>  On 13 Sep 2023, at 10:57, Jernej Tuljak >  > wrote:
>>  
>>  On 12/09/2023 14:43, Jan Lindblad (jlindbla) wrote:
>> > Jürgen, all,
>> > 
>> > I see the irony in changing the YANG RFC(s) without updating the YANG 
>> > language version number, but digging a bit deeper, I think the 
>> > question is not as clear-cut as it might seem at first.
>> > 
>> > Altering the contents of the backwards-compatibility section of RFC 
>> > 6020 (sec 10) and RFC 7950 (sec 11) clearly implies changes in YANG 
>> > module authors' behavior.
>> > 
>> > Speaking as a YANG compiler implementor, however, I don't see any 
>> > changes that have to made to the compiler because of this RFC change. 
>> > There are no new keywords, none are removed. There is no change in the 
>> > meaning of existing keywords. There is no difference in the output the 
>> > compiler needs to generate.
>> > 
>> > So while there are changes to the YANG *standard* (meaning RFCs) there 
>> > is no actual change to the YANG *language*. If we require user's to 
>> > mark their modules with version 1.2 (or 2.0), from the compiler's pov, 
>> > that would just be an alias for YANG 1.1. It means a fair amount of 
>> > trouble to update all the tools out there to accept "yang-version 1.2" 

Re: [netmod] Poll on YANG Versioning NBC Approach

[Andy Bierman]

On Thu, Sep 14, 2023 at 9:05 AM Acee Lindem  wrote:

>
>
> > On Sep 13, 2023, at 10:36, Ladislav Lhotka  40nic...@dmarc.ietf.org> wrote:
> >
> >
> >
> > Dne 13. 09. 23 v 16:06 Jernej Tuljak napsal(a):
> >> On 13/09/2023 14:26, Jan Lindblad (jlindbla) wrote:
> >>> Jernej,
> >>>
> >>> Hat off for the tools (and tool vendors!) that assist authors to stay
> true to YANG RFC sections 10 and 11 also. Well done. :-)
> >>>
> >>> I intentionally used "compiler" rather than "toolchain", "IDE" or
> something more open ended, because a compiler is what I have and can speak
> for.
> >>>
> >>> Even so, I have a hard time thinking the customers of even the best
> YANG IDEs would be interested to pay the effort for distinguishing between
> YANG 1.1 and YANG 1.2 solely on the proposed RFC wording difference. Since
> a BC verification capability apparently already exists in some IDEs, I
> think it would make sense for their vendors to turn the checks it into a
> warnings (if they aren't already), regardless of which yang-version
> statement is found in the module header.
> >>>
> >>> This might mean a non-zero implementation effort for a few YANG
> toolchain implementors. While this is a good point, it does not really sway
> my opinion about what the pragmatic choice for IETF is. Or Jernej, do you
> think the users of those good IDEs would prefer a new YANG version? If so,
> why?
> >> If you are asking whether I'd like to see a new version of YANG for the
> sole purpose of changing those MUST and MUST NOTs - no, I would not.
> However, a change like this mandates a yang-version bump, IMHO.
> >
> > Right, so we have two ugly options, but bumping YANG version really
> makes no sense, so breaking those few tools that check update rules looks
> like a better choice to me.
> >
> > We have already seen cases that the update rules prevented fixing
> problems in YANG modules in a straightforward way, and backward-compatible
> fixes negatively affected module readability. This is inevitable until the
> ecosystem of YANG modules stabilizes. That's why I think changing update
> rules from MUST to SHOULD is appropriate - it should have been so from the
> beginning.
>
> I wholeheartedly agree. We need to be able to fix YANG modules with NBC
> changes. I know of at least one implementation that support NBC changes for
> proprietary models with node-specific translation
>
>
Some of us do not think a bugfix counts as an NBC change.
If the YANG definition is wrong and has been wrong from the start, then BC
is not important.
Fixing the YANG module so the definitions match the intent of the authors
is important.

IMO this new draft is not really needed at all, since bugfix exceptions
should be allowed
and should have always been allowed.


Thanks,
> Acee
>
>
Andy


>
>
>
> >
> > Lada
> >
> >> Jernej
> >>>
> >>> Best Regards,
> >>> /jan
> >>>
> >>>
> >>>
> >>>
> >>>
>  On 13 Sep 2023, at 10:57, Jernej Tuljak 
> wrote:
> 
>  On 12/09/2023 14:43, Jan Lindblad (jlindbla) wrote:
> > Jürgen, all,
> >
> > I see the irony in changing the YANG RFC(s) without updating the
> YANG language version number, but digging a bit deeper, I think the
> question is not as clear-cut as it might seem at first.
> >
> > Altering the contents of the backwards-compatibility section of RFC
> 6020 (sec 10) and RFC 7950 (sec 11) clearly implies changes in YANG module
> authors' behavior.
> >
> > Speaking as a YANG compiler implementor, however, I don't see any
> changes that have to made to the compiler because of this RFC change. There
> are no new keywords, none are removed. There is no change in the meaning of
> existing keywords. There is no difference in the output the compiler needs
> to generate.
> >
> > So while there are changes to the YANG *standard* (meaning RFCs)
> there is no actual change to the YANG *language*. If we require user's to
> mark their modules with version 1.2 (or 2.0), from the compiler's pov, that
> would just be an alias for YANG 1.1. It means a fair amount of trouble to
> update all the tools out there to accept "yang-version 1.2" but do nothing
> new. It also adds a burden to YANG module implementors, since they would
> have to go through all YANG 1.1 modules and mark them 1.2, for no change in
> meaning. For organizations with some modules still on YANG 1.0, the bar is
> even higher.
> >
> > I think the most pragmatic approach in this case would be to change
> the RFC text in the backwards-compatibility sections and not update the
> yang-version number as long as no change is required in the compilers. If
> anyone can point to actual things the compiler needs to do differently, I'd
> be interested to hear.
> 
>  You will first have to define what a YANG compiler is before you can
> make such assumptions. YANG code validation rules may be implemented in
> several ways, depending on what the tool that utilizes them is used for. I
> choose to call that a "validation engine" - 

Re: [netmod] Poll on YANG Versioning NBC Approach

[Acee Lindem]

> On Sep 13, 2023, at 10:36, Ladislav Lhotka 
>  wrote:
> 
> 
> 
> Dne 13. 09. 23 v 16:06 Jernej Tuljak napsal(a):
>> On 13/09/2023 14:26, Jan Lindblad (jlindbla) wrote:
>>> Jernej,
>>> 
>>> Hat off for the tools (and tool vendors!) that assist authors to stay true 
>>> to YANG RFC sections 10 and 11 also. Well done. :-)
>>> 
>>> I intentionally used "compiler" rather than "toolchain", "IDE" or something 
>>> more open ended, because a compiler is what I have and can speak for.
>>> 
>>> Even so, I have a hard time thinking the customers of even the best YANG 
>>> IDEs would be interested to pay the effort for distinguishing between YANG 
>>> 1.1 and YANG 1.2 solely on the proposed RFC wording difference. Since a BC 
>>> verification capability apparently already exists in some IDEs, I think it 
>>> would make sense for their vendors to turn the checks it into a warnings 
>>> (if they aren't already), regardless of which yang-version statement is 
>>> found in the module header.
>>> 
>>> This might mean a non-zero implementation effort for a few YANG toolchain 
>>> implementors. While this is a good point, it does not really sway my 
>>> opinion about what the pragmatic choice for IETF is. Or Jernej, do you 
>>> think the users of those good IDEs would prefer a new YANG version? If so, 
>>> why?
>> If you are asking whether I'd like to see a new version of YANG for the sole 
>> purpose of changing those MUST and MUST NOTs - no, I would not. However, a 
>> change like this mandates a yang-version bump, IMHO.
> 
> Right, so we have two ugly options, but bumping YANG version really makes no 
> sense, so breaking those few tools that check update rules looks like a 
> better choice to me.
> 
> We have already seen cases that the update rules prevented fixing problems in 
> YANG modules in a straightforward way, and backward-compatible fixes 
> negatively affected module readability. This is inevitable until the 
> ecosystem of YANG modules stabilizes. That's why I think changing update 
> rules from MUST to SHOULD is appropriate - it should have been so from the 
> beginning.

I wholeheartedly agree. We need to be able to fix YANG modules with NBC 
changes. I know of at least one implementation that support NBC changes for 
proprietary models with node-specific translation

Thanks,
Acee 




> 
> Lada
> 
>> Jernej
>>> 
>>> Best Regards,
>>> /jan
>>> 
>>> 
>>> 
>>> 
>>> 
 On 13 Sep 2023, at 10:57, Jernej Tuljak  wrote:
 
 On 12/09/2023 14:43, Jan Lindblad (jlindbla) wrote:
> Jürgen, all,
> 
> I see the irony in changing the YANG RFC(s) without updating the YANG 
> language version number, but digging a bit deeper, I think the question 
> is not as clear-cut as it might seem at first.
> 
> Altering the contents of the backwards-compatibility section of RFC 6020 
> (sec 10) and RFC 7950 (sec 11) clearly implies changes in YANG module 
> authors' behavior.
> 
> Speaking as a YANG compiler implementor, however, I don't see any changes 
> that have to made to the compiler because of this RFC change. There are 
> no new keywords, none are removed. There is no change in the meaning of 
> existing keywords. There is no difference in the output the compiler 
> needs to generate.
> 
> So while there are changes to the YANG *standard* (meaning RFCs) there is 
> no actual change to the YANG *language*. If we require user's to mark 
> their modules with version 1.2 (or 2.0), from the compiler's pov, that 
> would just be an alias for YANG 1.1. It means a fair amount of trouble to 
> update all the tools out there to accept "yang-version 1.2" but do 
> nothing new. It also adds a burden to YANG module implementors, since 
> they would have to go through all YANG 1.1 modules and mark them 1.2, for 
> no change in meaning. For organizations with some modules still on YANG 
> 1.0, the bar is even higher.
> 
> I think the most pragmatic approach in this case would be to change the 
> RFC text in the backwards-compatibility sections and not update the 
> yang-version number as long as no change is required in the compilers. If 
> anyone can point to actual things the compiler needs to do differently, 
> I'd be interested to hear.
 
 You will first have to define what a YANG compiler is before you can make 
 such assumptions. YANG code validation rules may be implemented in several 
 ways, depending on what the tool that utilizes them is used for. I choose 
 to call that a "validation engine" - "compiler" implies translation into a 
 lower level language in my world and not all tools require that. I know of 
 at least one tool that utilizes a validation engine that performs the 
 checks in Updating a Module sections of RFC 6020 and RFC 7950, when 
 requested. And I would expect a YANG authoring tool to do the same if it 
 claims full RFC compliance. Those 

Re: [netmod] Poll on YANG Versioning NBC Approach

[Jason Sterne (Nokia)]

I think it has been mentioned, but maybe worth repeating: this poll is *NOT* 
about accepting the entire Module Versioning + YANG Semver content as it 
currently stands.

We separated out the first of several key issues to try and make progress. This 
is just the basic fundamental decision of whether we will allow (as a "SHOULD 
NOT") NBC changes in in YANG 1.0/YANG1.1  (option 1), or we are going to 
mandate that can only happen in a YANG 1.2 (option 2).

After this poll settles out (hoping we'll get rough concensus), then we'll get 
back to chipping away at the other key issues (e.g. see email "YANG Versioning: 
Key Issues #2 and #3 - revision labels" from back in July, but there will be 
several other such debates & discussions).

Jason

> -Original Message-
> From: netmod  On Behalf Of Jürgen Schönwälder
> Sent: Thursday, September 14, 2023 5:35 AM
> To: Rob Wilton (rwilton) 
> Cc: Jan Lindblad (jlindbla) ; netmod@ietf.org
> Subject: Re: [netmod] Poll on YANG Versioning NBC Approach
> 
> 
> 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, Sep 12, 2023 at 01:42:57PM +, Rob Wilton (rwilton) wrote:
> >
> > I think that for this first poll this is the question that we should 
> > initially focus on.
> I.e., at a starting point, do you agree to updating RFC 6020, RFC 7950, to 
> allow
> changing the MUST to a SHOULD without a new YANG 1.2?
> >
> 
> There are many options, one is to just change a single sentence. But
> the poll fails to sort the options out.
> 
> > If we can get consensus on this part, then I think that we can try and 
> > tackle
> getting consensus on the other updates in draft-ietf-netmod-yang-module-
> versioning to decide whether to include those in a document that updates 
> existing
> versions of YANG without a change in the YANG versioning number, or whether
> those changes should be deferred to a new version of YANG (which I hope that
> the WG starts after this versioning work completes - but I'll no longer be an 
> AD at
> that stage).
> 
> This work is going on for years, the WG has failed so far to enumerate
> the options and come to a conclusion.
> 
> > > There are features in draft-ietf-netmod-yang-module-versioning that
> > > you can use only with new tools that implement the features. I am not
> > > sure why tools that support different variants of YANG 1 and YANG 1.1
> > > are any easier in practice than a tool that says clearly what it
> > > implements.
> > [Rob Wilton (rwilton)]
> >
> > I hear two concerns:
> > (1) Existing tooling handling YANG 1 and YANG 1.1 modules must handle NBC
> changes anyway because they see them in the wild and that won't change.  E.g.,
> it is 99% likely that OpenConfig will still continue to use Yang 1 modules.
> > (2) All existing tooling won't be able to handle YANG 1.2 without tooling
> changes.
> 
> If you do not need YANG 1.2 features, YANG 1 just works fine. The
> assumption that once can use YANG 1.2 features with YANG 1 modules by
> simply not calling the features YANG 1.2 is what puts me off.
> 
> > > I continue to believe the questions are badly phrased. Instead of
> > > discussing properties and trade-offs of solutions, we discuss the
> > > version number. And we accept that bumping the version number is
> > > considered too costly but at the same time the entire work is about
> > > introducing version numbers to data models (where the same logic will
> > > sooner of later apply). Yes, for me, this is real-world irony.
> > [Rob Wilton (rwilton)]
> >
> > I see this as: What are we able to do now without changing the YANG 
> > versioning
> number, and without breaking existing tools, to help solve real world issues
> today?  I.e., the aim is to bound our solution by what we are pragmatically 
> able to
> support in YANG 1/YANG 1.1 without breaking existing tooling (which should
> already ignore existing statements that they don't understand).
> >
> > Yang 1.2/2 should be worked on, but that will probably include other 
> > changes as
> well and involve some level of effort from tool vendors to support.  It will 
> also
> probably also take many years.
> >
> 
> A one line sentence change replacing MUST with SHOULD Not is one
> thing, the ID on the table a different thing.
> 
> /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] Poll on YANG Versioning NBC Approach

[Jürgen Schönwälder]

On Tue, Sep 12, 2023 at 01:42:57PM +, Rob Wilton (rwilton) wrote:
> 
> I think that for this first poll this is the question that we should 
> initially focus on.  I.e., at a starting point, do you agree to updating RFC 
> 6020, RFC 7950, to allow changing the MUST to a SHOULD without a new YANG 1.2?
>

There are many options, one is to just change a single sentence. But
the poll fails to sort the options out.

> If we can get consensus on this part, then I think that we can try and tackle 
> getting consensus on the other updates in 
> draft-ietf-netmod-yang-module-versioning to decide whether to include those 
> in a document that updates existing versions of YANG without a change in the 
> YANG versioning number, or whether those changes should be deferred to a new 
> version of YANG (which I hope that the WG starts after this versioning work 
> completes - but I'll no longer be an AD at that stage).

This work is going on for years, the WG has failed so far to enumerate
the options and come to a conclusion.

> > There are features in draft-ietf-netmod-yang-module-versioning that
> > you can use only with new tools that implement the features. I am not
> > sure why tools that support different variants of YANG 1 and YANG 1.1
> > are any easier in practice than a tool that says clearly what it
> > implements.
> [Rob Wilton (rwilton)] 
> 
> I hear two concerns:
> (1) Existing tooling handling YANG 1 and YANG 1.1 modules must handle NBC 
> changes anyway because they see them in the wild and that won't change.  
> E.g., it is 99% likely that OpenConfig will still continue to use Yang 1 
> modules.
> (2) All existing tooling won't be able to handle YANG 1.2 without tooling 
> changes. 

If you do not need YANG 1.2 features, YANG 1 just works fine. The
assumption that once can use YANG 1.2 features with YANG 1 modules by
simply not calling the features YANG 1.2 is what puts me off.

> > I continue to believe the questions are badly phrased. Instead of
> > discussing properties and trade-offs of solutions, we discuss the
> > version number. And we accept that bumping the version number is
> > considered too costly but at the same time the entire work is about
> > introducing version numbers to data models (where the same logic will
> > sooner of later apply). Yes, for me, this is real-world irony.
> [Rob Wilton (rwilton)] 
> 
> I see this as: What are we able to do now without changing the YANG 
> versioning number, and without breaking existing tools, to help solve real 
> world issues today?  I.e., the aim is to bound our solution by what we are 
> pragmatically able to support in YANG 1/YANG 1.1 without breaking existing 
> tooling (which should already ignore existing statements that they don't 
> understand).
> 
> Yang 1.2/2 should be worked on, but that will probably include other changes 
> as well and involve some level of effort from tool vendors to support.  It 
> will also probably also take many years.
>

A one line sentence change replacing MUST with SHOULD Not is one
thing, the ID on the table a different thing.

/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] Poll on YANG Versioning NBC Approach

[Benoit Claise]

On 9/13/2023 4:36 PM, Ladislav Lhotka wrote:



Dne 13. 09. 23 v 16:06 Jernej Tuljak napsal(a):

On 13/09/2023 14:26, Jan Lindblad (jlindbla) wrote:

Jernej,

Hat off for the tools (and tool vendors!) that assist authors to 
stay true to YANG RFC sections 10 and 11 also. Well done. :-)


I intentionally used "compiler" rather than "toolchain", "IDE" or 
something more open ended, because a compiler is what I have and can 
speak for.


Even so, I have a hard time thinking the customers of even the best 
YANG IDEs would be interested to pay the effort for distinguishing 
between YANG 1.1 and YANG 1.2 solely on the proposed RFC wording 
difference. Since a BC verification capability apparently already 
exists in some IDEs, I think it would make sense for their vendors 
to turn the checks it into a warnings (if they aren't already), 
regardless of which yang-version statement is found in the module 
header.


This might mean a non-zero implementation effort for a few YANG 
toolchain implementors. While this is a good point, it does not 
really sway my opinion about what the pragmatic choice for IETF is. 
Or Jernej, do you think the users of those good IDEs would prefer a 
new YANG version? If so, why?


If you are asking whether I'd like to see a new version of YANG for 
the sole purpose of changing those MUST and MUST NOTs - no, I would 
not. However, a change like this mandates a yang-version bump, IMHO.


Right, so we have two ugly options, but bumping YANG version really 
makes no sense, so breaking those few tools that check update rules 
looks like a better choice to me.


We have already seen cases that the update rules prevented fixing 
problems in YANG modules in a straightforward way, and 
backward-compatible fixes negatively affected module readability. This 
is inevitable until the ecosystem of YANG modules stabilizes. That's 
why I think changing update rules from MUST to SHOULD is appropriate - 
it should have been so from the beginning.

Well said Lada.

Regards, Benoit



Lada



Jernej



Best Regards,
/jan





On 13 Sep 2023, at 10:57, Jernej Tuljak  
wrote:


On 12/09/2023 14:43, Jan Lindblad (jlindbla) wrote:

Jürgen, all,

I see the irony in changing the YANG RFC(s) without updating the 
YANG language version number, but digging a bit deeper, I think 
the question is not as clear-cut as it might seem at first.


Altering the contents of the backwards-compatibility section of 
RFC 6020 (sec 10) and RFC 7950 (sec 11) clearly implies changes in 
YANG module authors' behavior.


Speaking as a YANG compiler implementor, however, I don't see any 
changes that have to made to the compiler because of this RFC 
change. There are no new keywords, none are removed. There is no 
change in the meaning of existing keywords. There is no difference 
in the output the compiler needs to generate.


So while there are changes to the YANG *standard* (meaning RFCs) 
there is no actual change to the YANG *language*. If we require 
user's to mark their modules with version 1.2 (or 2.0), from the 
compiler's pov, that would just be an alias for YANG 1.1. It means 
a fair amount of trouble to update all the tools out there to 
accept "yang-version 1.2" but do nothing new. It also adds a 
burden to YANG module implementors, since they would have to go 
through all YANG 1.1 modules and mark them 1.2, for no change in 
meaning. For organizations with some modules still on YANG 1.0, 
the bar is even higher.


I think the most pragmatic approach in this case would be to 
change the RFC text in the backwards-compatibility sections and 
not update the yang-version number as long as no change is 
required in the compilers. If anyone can point to actual things 
the compiler needs to do differently, I'd be interested to hear.


You will first have to define what a YANG compiler is before you 
can make such assumptions. YANG code validation rules may be 
implemented in several ways, depending on what the tool that 
utilizes them is used for. I choose to call that a "validation 
engine" - "compiler" implies translation into a lower level 
language in my world and not all tools require that. I know of at 
least one tool that utilizes a validation engine that performs the 
checks in Updating a Module sections of RFC 6020 and RFC 7950, when 
requested. And I would expect a YANG authoring tool to do the same 
if it claims full RFC compliance. Those are not optional guidelines 
intended just for humans. It is true that some of the rules can 
only be reliably checked by a human, but not all (or even most) of 
them. Point being - there are implementations out there that rely 
on the text of this Section to remain unchanged. I would imagine 
that they represent a drop in the sea compared to implementations 
that have chosen to completely ignore the spec (forking YANG into 
YANG' in the process), but they do exist.


I disagree that changing those sections does not change the 
language. Of course it does. It makes combinations of 

Re: [netmod] Poll on YANG Versioning NBC Approach

[Andy Bierman]

On Tue, Sep 12, 2023 at 4:09 PM Kent Watsen  wrote:

> [All, don’t forget to vote, discussion here doesn’t count!
> https://notes.ietf.org/netmod-2023-sept-poll]
>
>
> On Sep 12, 2023, at 12:06 PM, Andy Bierman  wrote:
>
> So there is choice between:
>
>   (A) YANG 1.1 and SHOULD NOT
>   (B) YANG 1.2 and SHOULD NOT
>
>
> Thanks Andy, this is a succinct way to frame it.
>
>
>
> (A) is acceptable.
> YANG 1.2 would create a false expectation in the user community that the
> IETF
> had improved the YANG language somehow.
>
>
> Agreed.
>
>
It would be a very disruptive and visible change to just 'bump the version'.
Someday, the WG should work on the yang-next list and produce a real YANG
1.2.



> Kent
>

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

Re: [netmod] Poll on YANG Versioning NBC Approach

[Ladislav Lhotka]

Dne 13. 09. 23 v 16:06 Jernej Tuljak napsal(a):

On 13/09/2023 14:26, Jan Lindblad (jlindbla) wrote:

Jernej,

Hat off for the tools (and tool vendors!) that assist authors to stay 
true to YANG RFC sections 10 and 11 also. Well done. :-)


I intentionally used "compiler" rather than "toolchain", "IDE" or 
something more open ended, because a compiler is what I have and can 
speak for.


Even so, I have a hard time thinking the customers of even the best 
YANG IDEs would be interested to pay the effort for distinguishing 
between YANG 1.1 and YANG 1.2 solely on the proposed RFC wording 
difference. Since a BC verification capability apparently already 
exists in some IDEs, I think it would make sense for their vendors to 
turn the checks it into a warnings (if they aren't already), 
regardless of which yang-version statement is found in the module header.


This might mean a non-zero implementation effort for a few YANG 
toolchain implementors. While this is a good point, it does not really 
sway my opinion about what the pragmatic choice for IETF is. Or 
Jernej, do you think the users of those good IDEs would prefer a new 
YANG version? If so, why?


If you are asking whether I'd like to see a new version of YANG for the 
sole purpose of changing those MUST and MUST NOTs - no, I would not. 
However, a change like this mandates a yang-version bump, IMHO.


Right, so we have two ugly options, but bumping YANG version really 
makes no sense, so breaking those few tools that check update rules 
looks like a better choice to me.


We have already seen cases that the update rules prevented fixing 
problems in YANG modules in a straightforward way, and 
backward-compatible fixes negatively affected module readability. This 
is inevitable until the ecosystem of YANG modules stabilizes. That's why 
I think changing update rules from MUST to SHOULD is appropriate - it 
should have been so from the beginning.


Lada



Jernej



Best Regards,
/jan






On 13 Sep 2023, at 10:57, Jernej Tuljak  wrote:

On 12/09/2023 14:43, Jan Lindblad (jlindbla) wrote:

Jürgen, all,

I see the irony in changing the YANG RFC(s) without updating the 
YANG language version number, but digging a bit deeper, I think the 
question is not as clear-cut as it might seem at first.


Altering the contents of the backwards-compatibility section of RFC 
6020 (sec 10) and RFC 7950 (sec 11) clearly implies changes in YANG 
module authors' behavior.


Speaking as a YANG compiler implementor, however, I don't see any 
changes that have to made to the compiler because of this RFC 
change. There are no new keywords, none are removed. There is no 
change in the meaning of existing keywords. There is no difference 
in the output the compiler needs to generate.


So while there are changes to the YANG *standard* (meaning RFCs) 
there is no actual change to the YANG *language*. If we require 
user's to mark their modules with version 1.2 (or 2.0), from the 
compiler's pov, that would just be an alias for YANG 1.1. It means a 
fair amount of trouble to update all the tools out there to accept 
"yang-version 1.2" but do nothing new. It also adds a burden to YANG 
module implementors, since they would have to go through all YANG 
1.1 modules and mark them 1.2, for no change in meaning. For 
organizations with some modules still on YANG 1.0, the bar is even 
higher.


I think the most pragmatic approach in this case would be to change 
the RFC text in the backwards-compatibility sections and not update 
the yang-version number as long as no change is required in the 
compilers. If anyone can point to actual things the compiler needs 
to do differently, I'd be interested to hear.


You will first have to define what a YANG compiler is before you can 
make such assumptions. YANG code validation rules may be implemented 
in several ways, depending on what the tool that utilizes them is 
used for. I choose to call that a "validation engine" - "compiler" 
implies translation into a lower level language in my world and not 
all tools require that. I know of at least one tool that utilizes a 
validation engine that performs the checks in Updating a Module 
sections of RFC 6020 and RFC 7950, when requested. And I would expect 
a YANG authoring tool to do the same if it claims full RFC 
compliance. Those are not optional guidelines intended just for 
humans. It is true that some of the rules can only be reliably 
checked by a human, but not all (or even most) of them. Point being - 
there are implementations out there that rely on the text of this 
Section to remain unchanged. I would imagine that they represent a 
drop in the sea compared to implementations that have chosen to 
completely ignore the spec (forking YANG into YANG' in the process), 
but they do exist.


I disagree that changing those sections does not change the language. 
Of course it does. It makes combinations of language constructs, that 
were previously not allowed, valid. This is no different 

Re: [netmod] Poll on YANG Versioning NBC Approach

[Jernej Tuljak]

On 13/09/2023 14:26, Jan Lindblad (jlindbla) wrote:

Jernej,

Hat off for the tools (and tool vendors!) that assist authors to stay 
true to YANG RFC sections 10 and 11 also. Well done. :-)


I intentionally used "compiler" rather than "toolchain", "IDE" or 
something more open ended, because a compiler is what I have and can 
speak for.


Even so, I have a hard time thinking the customers of even the best 
YANG IDEs would be interested to pay the effort for distinguishing 
between YANG 1.1 and YANG 1.2 solely on the proposed RFC wording 
difference. Since a BC verification capability apparently already 
exists in some IDEs, I think it would make sense for their vendors to 
turn the checks it into a warnings (if they aren't already), 
regardless of which yang-version statement is found in the module header.


This might mean a non-zero implementation effort for a few YANG 
toolchain implementors. While this is a good point, it does not really 
sway my opinion about what the pragmatic choice for IETF is. Or 
Jernej, do you think the users of those good IDEs would prefer a new 
YANG version? If so, why?


If you are asking whether I'd like to see a new version of YANG for the 
sole purpose of changing those MUST and MUST NOTs - no, I would not. 
However, a change like this mandates a yang-version bump, IMHO.


Jernej



Best Regards,
/jan






On 13 Sep 2023, at 10:57, Jernej Tuljak  wrote:

On 12/09/2023 14:43, Jan Lindblad (jlindbla) wrote:

Jürgen, all,

I see the irony in changing the YANG RFC(s) without updating the 
YANG language version number, but digging a bit deeper, I think the 
question is not as clear-cut as it might seem at first.


Altering the contents of the backwards-compatibility section of RFC 
6020 (sec 10) and RFC 7950 (sec 11) clearly implies changes in YANG 
module authors' behavior.


Speaking as a YANG compiler implementor, however, I don't see any 
changes that have to made to the compiler because of this RFC 
change. There are no new keywords, none are removed. There is no 
change in the meaning of existing keywords. There is no difference 
in the output the compiler needs to generate.


So while there are changes to the YANG *standard* (meaning RFCs) 
there is no actual change to the YANG *language*. If we require 
user's to mark their modules with version 1.2 (or 2.0), from the 
compiler's pov, that would just be an alias for YANG 1.1. It means a 
fair amount of trouble to update all the tools out there to accept 
"yang-version 1.2" but do nothing new. It also adds a burden to YANG 
module implementors, since they would have to go through all YANG 
1.1 modules and mark them 1.2, for no change in meaning. For 
organizations with some modules still on YANG 1.0, the bar is even 
higher.


I think the most pragmatic approach in this case would be to change 
the RFC text in the backwards-compatibility sections and not update 
the yang-version number as long as no change is required in the 
compilers. If anyone can point to actual things the compiler needs 
to do differently, I'd be interested to hear.


You will first have to define what a YANG compiler is before you can 
make such assumptions. YANG code validation rules may be implemented 
in several ways, depending on what the tool that utilizes them is 
used for. I choose to call that a "validation engine" - "compiler" 
implies translation into a lower level language in my world and not 
all tools require that. I know of at least one tool that utilizes a 
validation engine that performs the checks in Updating a Module 
sections of RFC 6020 and RFC 7950, when requested. And I would expect 
a YANG authoring tool to do the same if it claims full RFC 
compliance. Those are not optional guidelines intended just for 
humans. It is true that some of the rules can only be reliably 
checked by a human, but not all (or even most) of them. Point being - 
there are implementations out there that rely on the text of this 
Section to remain unchanged. I would imagine that they represent a 
drop in the sea compared to implementations that have chosen to 
completely ignore the spec (forking YANG into YANG' in the process), 
but they do exist.


I disagree that changing those sections does not change the language. 
Of course it does. It makes combinations of language constructs, that 
were previously not allowed, valid. This is no different to 
prescribing a mandatory-to-implement YANG extension.


File versioning is baked into YANG, a peculiarity of the language. 
There are many more such peculiarities. I'd like to know what other 
backward incompatible changes to the spec I can expect to occur in 
the future because there's now a precedent for it.


Jernej



Best Regards,
/jan



On 12 Sep 2023, at 07:55, Jürgen Schönwälder 
 wrote:


I disagree with the poll. There are important teachnigal differences
behind the two options that this polls tries to hide.

Updating YANG 1 and YANG 1.1 means creating YANG 1' and YANG
1.1'. There is no way 

Re: [netmod] Poll on YANG Versioning NBC Approach

[Jan Lindblad (jlindbla)]

Jernej,

Hat off for the tools (and tool vendors!) that assist authors to stay true to 
YANG RFC sections 10 and 11 also. Well done. :-)

I intentionally used "compiler" rather than "toolchain", "IDE" or something 
more open ended, because a compiler is what I have and can speak for.

Even so, I have a hard time thinking the customers of even the best YANG IDEs 
would be interested to pay the effort for distinguishing between YANG 1.1 and 
YANG 1.2 solely on the proposed RFC wording difference. Since a BC verification 
capability apparently already exists in some IDEs, I think it would make sense 
for their vendors to turn the checks it into a warnings (if they aren't 
already), regardless of which yang-version statement is found in the module 
header.

This might mean a non-zero implementation effort for a few YANG toolchain 
implementors. While this is a good point, it does not really sway my opinion 
about what the pragmatic choice for IETF is. Or Jernej, do you think the users 
of those good IDEs would prefer a new YANG version? If so, why?

Best Regards,
/jan





On 13 Sep 2023, at 10:57, Jernej Tuljak  wrote:

On 12/09/2023 14:43, Jan Lindblad (jlindbla) wrote:
Jürgen, all,

I see the irony in changing the YANG RFC(s) without updating the YANG language 
version number, but digging a bit deeper, I think the question is not as 
clear-cut as it might seem at first.

Altering the contents of the backwards-compatibility section of RFC 6020 (sec 
10) and RFC 7950 (sec 11) clearly implies changes in YANG module authors' 
behavior.

Speaking as a YANG compiler implementor, however, I don't see any changes that 
have to made to the compiler because of this RFC change. There are no new 
keywords, none are removed. There is no change in the meaning of existing 
keywords. There is no difference in the output the compiler needs to generate.

So while there are changes to the YANG *standard* (meaning RFCs) there is no 
actual change to the YANG *language*. If we require user's to mark their 
modules with version 1.2 (or 2.0), from the compiler's pov, that would just be 
an alias for YANG 1.1. It means a fair amount of trouble to update all the 
tools out there to accept "yang-version 1.2" but do nothing new. It also adds a 
burden to YANG module implementors, since they would have to go through all 
YANG 1.1 modules and mark them 1.2, for no change in meaning. For organizations 
with some modules still on YANG 1.0, the bar is even higher.

I think the most pragmatic approach in this case would be to change the RFC 
text in the backwards-compatibility sections and not update the yang-version 
number as long as no change is required in the compilers. If anyone can point 
to actual things the compiler needs to do differently, I'd be interested to 
hear.

You will first have to define what a YANG compiler is before you can make such 
assumptions. YANG code validation rules may be implemented in several ways, 
depending on what the tool that utilizes them is used for. I choose to call 
that a "validation engine" - "compiler" implies translation into a lower level 
language in my world and not all tools require that. I know of at least one 
tool that utilizes a validation engine that performs the checks in Updating a 
Module sections of RFC 6020 and RFC 7950, when requested. And I would expect a 
YANG authoring tool to do the same if it claims full RFC compliance. Those are 
not optional guidelines intended just for humans. It is true that some of the 
rules can only be reliably checked by a human, but not all (or even most) of 
them. Point being - there are implementations out there that rely on the text 
of this Section to remain unchanged. I would imagine that they represent a drop 
in the sea compared to implementations that have chosen to completely ignore 
the spec (forking YANG into YANG' in the process), but they do exist.

I disagree that changing those sections does not change the language. Of course 
it does. It makes combinations of language constructs, that were previously not 
allowed, valid. This is no different to prescribing a mandatory-to-implement 
YANG extension.

File versioning is baked into YANG, a peculiarity of the language. There are 
many more such peculiarities. I'd like to know what other backward incompatible 
changes to the spec I can expect to occur in the future because there's now a 
precedent for it.

Jernej


Best Regards,
/jan



On 12 Sep 2023, at 07:55, Jürgen Schönwälder 
 wrote:

I disagree with the poll. There are important teachnigal differences
behind the two options that this polls tries to hide.

Updating YANG 1 and YANG 1.1 means creating YANG 1' and YANG
1.1'. There is no way that a new versioning approach will be
understood by existing YANG tooling. That's an illusion.

/js

On Mon, Sep 11, 2023 at 10:39:39PM +, Kent Watsen wrote:
WG,

Please help the YANG-versioning effort move forward by participating in the 
following poll:

 - 

Re: [netmod] Poll on YANG Versioning NBC Approach

[Jernej Tuljak]

On 12/09/2023 14:43, Jan Lindblad (jlindbla) wrote:

Jürgen, all,

I see the irony in changing the YANG RFC(s) without updating the YANG language 
version number, but digging a bit deeper, I think the question is not as 
clear-cut as it might seem at first.

Altering the contents of the backwards-compatibility section of RFC 6020 (sec 
10) and RFC 7950 (sec 11) clearly implies changes in YANG module authors' 
behavior.

Speaking as a YANG compiler implementor, however, I don't see any changes that 
have to made to the compiler because of this RFC change. There are no new 
keywords, none are removed. There is no change in the meaning of existing 
keywords. There is no difference in the output the compiler needs to generate.

So while there are changes to the YANG *standard* (meaning RFCs) there is no actual 
change to the YANG *language*. If we require user's to mark their modules with version 
1.2 (or 2.0), from the compiler's pov, that would just be an alias for YANG 1.1. It means 
a fair amount of trouble to update all the tools out there to accept "yang-version 
1.2" but do nothing new. It also adds a burden to YANG module implementors, since 
they would have to go through all YANG 1.1 modules and mark them 1.2, for no change in 
meaning. For organizations with some modules still on YANG 1.0, the bar is even higher.

I think the most pragmatic approach in this case would be to change the RFC 
text in the backwards-compatibility sections and not update the yang-version 
number as long as no change is required in the compilers. If anyone can point 
to actual things the compiler needs to do differently, I'd be interested to 
hear.


You will first have to define what a YANG compiler is before you can 
make such assumptions. YANG code validation rules may be implemented in 
several ways, depending on what the tool that utilizes them is used for. 
I choose to call that a "validation engine" - "compiler" implies 
translation into a lower level language in my world and not all tools 
require that. I know of at least one tool that utilizes a validation 
engine that performs the checks in Updating a Module sections of RFC 
6020 and RFC 7950, when requested. And I would expect a YANG authoring 
tool to do the same if it claims full RFC compliance. Those are not 
optional guidelines intended just for humans. It is true that some of 
the rules can only be reliably checked by a human, but not all (or even 
most) of them. Point being - there are implementations out there that 
rely on the text of this Section to remain unchanged. I would imagine 
that they represent a drop in the sea compared to implementations that 
have chosen to completely ignore the spec (forking YANG into YANG' in 
the process), but they do exist.


I disagree that changing those sections does not change the language. Of 
course it does. It makes combinations of language constructs, that were 
previously not allowed, valid. This is no different to prescribing a 
mandatory-to-implement YANG extension.


File versioning is baked into YANG, a peculiarity of the language. There 
are many more such peculiarities. I'd like to know what other backward 
incompatible changes to the spec I can expect to occur in the future 
because there's now a precedent for it.


Jernej



Best Regards,
/jan




On 12 Sep 2023, at 07:55, Jürgen Schönwälder 
 wrote:

I disagree with the poll. There are important teachnigal differences
behind the two options that this polls tries to hide.

Updating YANG 1 and YANG 1.1 means creating YANG 1' and YANG
1.1'. There is no way that a new versioning approach will be
understood by existing YANG tooling. That's an illusion.

/js

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

WG,

Please help the YANG-versioning effort move forward by participating in the 
following poll:

  - https://notes.ietf.org/netmod-2023-sept-poll  (Datatracker login required)

Kent and Lou

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


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


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

Re: [netmod] Poll on YANG Versioning NBC Approach

[Kent Watsen]

[All, don’t forget to vote, discussion here doesn’t count!  
https://notes.ietf.org/netmod-2023-sept-poll]


> On Sep 12, 2023, at 12:06 PM, Andy Bierman  wrote:
> 
> So there is choice between:
> 
>   (A) YANG 1.1 and SHOULD NOT
>   (B) YANG 1.2 and SHOULD NOT

Thanks Andy, this is a succinct way to frame it.

  
> (A) is acceptable.
> YANG 1.2 would create a false expectation in the user community that the IETF
> had improved the YANG language somehow.

Agreed.


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

Re: [netmod] Poll on YANG Versioning NBC Approach

[Andy Bierman]

On Tue, Sep 12, 2023 at 8:54 AM Reshad Rahman  wrote:

>
>
> On Tuesday, September 12, 2023, 11:23:55 AM EDT, Andy Bierman <
> a...@yumaworks.com> wrote:
>
>
>
>
> On Mon, Sep 11, 2023 at 3:39 PM Kent Watsen  wrote:
>
> WG,
>
> Please help the YANG-versioning effort move forward by participating in
> the following poll:
>
>   - https://notes.ietf.org/netmod-2023-sept-poll  (Datatracker login
> required)
>
>
>
> The draft proposed to change many specific MUST and MUST NOT requirements
> to MAY ignore.
> It has been pointed out that the correct change would be SHOULD NOT and
> the use of MAY is inappropriate
> according to the definitions in RFC 2119.
>  I thought the authors had agreed on SHOULD NOT (instead of MAY), but
> I don't recall if this was just in the weekly calls or actually
> communicated to the wg alias.
>
>
So there is choice between:

  (A) YANG 1.1 and SHOULD NOT
  (B) YANG 1.2 and SHOULD NOT

(A) is acceptable.
YANG 1.2 would create a false expectation in the user community that the
IETF
had improved the YANG language somehow.


> Regards,
> Reshad.
>

Andy


>
> Yet the WG continues to propose that these rules in RFC 7950 are purely
> optional and can be ignored by
> any implementation that chooses to do so.
>
> Of course rules that affect backward compatibility and stability do not
> affect the code that compiles a module.
> They only affect the client code that attempts to use the unstable server
> code.
>
>
>
> Kent and Lou
>
>
> Andy
>
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Poll on YANG Versioning NBC Approach

[Reshad Rahman]

 

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

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

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



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



Kent and Lou

Andy 

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

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

Re: [netmod] Poll on YANG Versioning NBC Approach

[Andy Bierman]

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

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

The draft proposed to change many specific MUST and MUST NOT requirements
to MAY ignore.
It has been pointed out that the correct change would be SHOULD NOT and the
use of MAY is inappropriate
according to the definitions in RFC 2119.

Yet the WG continues to propose that these rules in RFC 7950 are purely
optional and can be ignored by
any implementation that chooses to do so.

Of course rules that affect backward compatibility and stability do not
affect the code that compiles a module.
They only affect the client code that attempts to use the unstable server
code.



Kent and Lou
>

Andy


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

Re: [netmod] Poll on YANG Versioning NBC Approach

[Ladislav Lhotka]

Dne 12. 09. 23 v 14:43 Jan Lindblad (jlindbla) napsal(a):

Jürgen, all,

I see the irony in changing the YANG RFC(s) without updating the YANG language 
version number, but digging a bit deeper, I think the question is not as 
clear-cut as it might seem at first.

Altering the contents of the backwards-compatibility section of RFC 6020 (sec 
10) and RFC 7950 (sec 11) clearly implies changes in YANG module authors' 
behavior.

Speaking as a YANG compiler implementor, however, I don't see any changes that 
have to made to the compiler because of this RFC change. There are no new 
keywords, none are removed. There is no change in the meaning of existing 
keywords. There is no difference in the output the compiler needs to generate.

So while there are changes to the YANG *standard* (meaning RFCs) there is no actual 
change to the YANG *language*. If we require user's to mark their modules with version 
1.2 (or 2.0), from the compiler's pov, that would just be an alias for YANG 1.1. It means 
a fair amount of trouble to update all the tools out there to accept "yang-version 
1.2" but do nothing new. It also adds a burden to YANG module implementors, since 
they would have to go through all YANG 1.1 modules and mark them 1.2, for no change in 
meaning. For organizations with some modules still on YANG 1.0, the bar is even higher.

I think the most pragmatic approach in this case would be to change the RFC 
text in the backwards-compatibility sections and not update the yang-version 
number as long as no change is required in the compilers. If anyone can point 
to actual things the compiler needs to do differently, I'd be interested to 
hear.


I agree with this. I have actually always thought that the section 
"Updating a Module" should never have become part of the YANG language 
definition. A sensible approach could IMO be to move this section to 
8407bis, and relax the requirements to SHOULD there.


Lada



Best Regards,
/jan




On 12 Sep 2023, at 07:55, Jürgen Schönwälder 
 wrote:

I disagree with the poll. There are important teachnigal differences
behind the two options that this polls tries to hide.

Updating YANG 1 and YANG 1.1 means creating YANG 1' and YANG
1.1'. There is no way that a new versioning approach will be
understood by existing YANG tooling. That's an illusion.

/js

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

WG,

Please help the YANG-versioning effort move forward by participating in the 
following poll:

  - https://notes.ietf.org/netmod-2023-sept-poll  (Datatracker login required)

Kent and Lou




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



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


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

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

Re: [netmod] Poll on YANG Versioning NBC Approach

[Rob Wilton (rwilton)]

Hi Jürgen,

Please see inline ...

> -Original Message-
> From: netmod  On Behalf Of Jürgen
> Schönwälder
> Sent: 12 September 2023 14:11
> To: Jan Lindblad (jlindbla) 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Poll on YANG Versioning NBC Approach
> 
> The two options mix things together. Option 1 says updating YANG 1 and
> YANG 1.1 to allow YANG modules to be modified _based on
> draft-ietf-netmod-yang-module-versioning_ but this document has much
> more in it than just changing a MUST to SHOULD.
[Rob Wilton (rwilton)] 

I think that for this first poll this is the question that we should initially 
focus on.  I.e., at a starting point, do you agree to updating RFC 6020, RFC 
7950, to allow changing the MUST to a SHOULD without a new YANG 1.2?

If we can get consensus on this part, then I think that we can try and tackle 
getting consensus on the other updates in 
draft-ietf-netmod-yang-module-versioning to decide whether to include those in 
a document that updates existing versions of YANG without a change in the YANG 
versioning number, or whether those changes should be deferred to a new version 
of YANG (which I hope that the WG starts after this versioning work completes - 
but I'll no longer be an AD at that stage).


> 
> There are features in draft-ietf-netmod-yang-module-versioning that
> you can use only with new tools that implement the features. I am not
> sure why tools that support different variants of YANG 1 and YANG 1.1
> are any easier in practice than a tool that says clearly what it
> implements.
[Rob Wilton (rwilton)] 

I hear two concerns:
(1) Existing tooling handling YANG 1 and YANG 1.1 modules must handle NBC 
changes anyway because they see them in the wild and that won't change.  E.g., 
it is 99% likely that OpenConfig will still continue to use Yang 1 modules.
(2) All existing tooling won't be able to handle YANG 1.2 without tooling 
changes. 

> 
> I continue to believe the questions are badly phrased. Instead of
> discussing properties and trade-offs of solutions, we discuss the
> version number. And we accept that bumping the version number is
> considered too costly but at the same time the entire work is about
> introducing version numbers to data models (where the same logic will
> sooner of later apply). Yes, for me, this is real-world irony.
[Rob Wilton (rwilton)] 

I see this as: What are we able to do now without changing the YANG versioning 
number, and without breaking existing tools, to help solve real world issues 
today?  I.e., the aim is to bound our solution by what we are pragmatically 
able to support in YANG 1/YANG 1.1 without breaking existing tooling (which 
should already ignore existing statements that they don't understand).

Yang 1.2/2 should be worked on, but that will probably include other changes as 
well and involve some level of effort from tool vendors to support.  It will 
also probably also take many years.

Regards,
Rob


> 
> /js
> 
> PS: There is no need to update YANG 1.1 modules to YANG 1.2 as long
> as you do not use YANG 1.2 rules and mechanism.
> 
> On Tue, Sep 12, 2023 at 12:43:56PM +, Jan Lindblad (jlindbla) wrote:
> > Jürgen, all,
> >
> > I see the irony in changing the YANG RFC(s) without updating the YANG
> language version number, but digging a bit deeper, I think the question is not
> as clear-cut as it might seem at first.
> >
> > Altering the contents of the backwards-compatibility section of RFC 6020
> (sec 10) and RFC 7950 (sec 11) clearly implies changes in YANG module
> authors' behavior.
> >
> > Speaking as a YANG compiler implementor, however, I don't see any
> changes that have to made to the compiler because of this RFC change. There
> are no new keywords, none are removed. There is no change in the meaning
> of existing keywords. There is no difference in the output the compiler needs
> to generate.
> >
> > So while there are changes to the YANG *standard* (meaning RFCs) there is
> no actual change to the YANG *language*. If we require user's to mark their
> modules with version 1.2 (or 2.0), from the compiler's pov, that would just
> be an alias for YANG 1.1. It means a fair amount of trouble to update all the
> tools out there to accept "yang-version 1.2" but do nothing new. It also adds
> a burden to YANG module implementors, since they would have to go
> through all YANG 1.1 modules and mark them 1.2, for no change in meaning.
> For organizations with some modules still on YANG 1.0, the bar is even
> higher.
> >
> > I think the most pragmatic approach in this case would be to change the
> RFC text in the backwards-compatibility sections and not update the yang-
> version number as long as no change is required in the compilers. If anyone
> can point to actual things

Re: [netmod] Poll on YANG Versioning NBC Approach

[Jürgen Schönwälder]

The two options mix things together. Option 1 says updating YANG 1 and
YANG 1.1 to allow YANG modules to be modified _based on
draft-ietf-netmod-yang-module-versioning_ but this document has much
more in it than just changing a MUST to SHOULD.

There are features in draft-ietf-netmod-yang-module-versioning that
you can use only with new tools that implement the features. I am not
sure why tools that support different variants of YANG 1 and YANG 1.1
are any easier in practice than a tool that says clearly what it
implements.

I continue to believe the questions are badly phrased. Instead of
discussing properties and trade-offs of solutions, we discuss the
version number. And we accept that bumping the version number is
considered too costly but at the same time the entire work is about
introducing version numbers to data models (where the same logic will
sooner of later apply). Yes, for me, this is real-world irony.

/js

PS: There is no need to update YANG 1.1 modules to YANG 1.2 as long
as you do not use YANG 1.2 rules and mechanism.

On Tue, Sep 12, 2023 at 12:43:56PM +, Jan Lindblad (jlindbla) wrote:
> Jürgen, all,
> 
> I see the irony in changing the YANG RFC(s) without updating the YANG 
> language version number, but digging a bit deeper, I think the question is 
> not as clear-cut as it might seem at first.
> 
> Altering the contents of the backwards-compatibility section of RFC 6020 (sec 
> 10) and RFC 7950 (sec 11) clearly implies changes in YANG module authors' 
> behavior.
> 
> Speaking as a YANG compiler implementor, however, I don't see any changes 
> that have to made to the compiler because of this RFC change. There are no 
> new keywords, none are removed. There is no change in the meaning of existing 
> keywords. There is no difference in the output the compiler needs to generate.
> 
> So while there are changes to the YANG *standard* (meaning RFCs) there is no 
> actual change to the YANG *language*. If we require user's to mark their 
> modules with version 1.2 (or 2.0), from the compiler's pov, that would just 
> be an alias for YANG 1.1. It means a fair amount of trouble to update all the 
> tools out there to accept "yang-version 1.2" but do nothing new. It also adds 
> a burden to YANG module implementors, since they would have to go through all 
> YANG 1.1 modules and mark them 1.2, for no change in meaning. For 
> organizations with some modules still on YANG 1.0, the bar is even higher.
> 
> I think the most pragmatic approach in this case would be to change the RFC 
> text in the backwards-compatibility sections and not update the yang-version 
> number as long as no change is required in the compilers. If anyone can point 
> to actual things the compiler needs to do differently, I'd be interested to 
> hear.
> 
> Best Regards,
> /jan
> 
> 
> 
> > On 12 Sep 2023, at 07:55, Jürgen Schönwälder 
> >  wrote:
> > 
> > I disagree with the poll. There are important teachnigal differences
> > behind the two options that this polls tries to hide.
> > 
> > Updating YANG 1 and YANG 1.1 means creating YANG 1' and YANG
> > 1.1'. There is no way that a new versioning approach will be
> > understood by existing YANG tooling. That's an illusion.
> > 
> > /js
> > 
> > On Mon, Sep 11, 2023 at 10:39:39PM +, Kent Watsen wrote:
> >> WG,
> >> 
> >> Please help the YANG-versioning effort move forward by participating in 
> >> the following poll:
> >> 
> >>  - https://notes.ietf.org/netmod-2023-sept-poll  (Datatracker login 
> >> required)
> >> 
> >> Kent and Lou
> >> 
> > 
> >> ___
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> > 
> > 
> > -- 
> > 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
> 

-- 
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] Poll on YANG Versioning NBC Approach

[Rob Wilton (rwilton)]

Further to Jan's comments, given that all organizations (vendors, SDOs, and 
industry consortia) producing YANG modules all occasionally update then in NBC 
ways to fix bugs and issues, then I presume that all pragmatic YANG tooling is 
obliged to handle cases where modules change in NBC ways.

Hence, I see changing the following paragraph in RFC 7950 section 11 from

   Otherwise, if the semantics of any previous definition are changed
   (i.e., if a non-editorial change is made to any definition other than
   those specifically allowed above), then this MUST be achieved by a
   new definition with a new identifier.

to

   Otherwise, if the semantics of any previous definition are changed
   (i.e., if a non-editorial change is made to any definition other than
   those specifically allowed above), then this SHOULD be achieved by a
   new definition with a new identifier.

really as bugfix to RFC 7950 (given that it how everyone is interpreting it) 
rather than a new version of YANG.

If, the landscape was different and everyone defining YANG 1 and YANG 1.1 
modules was only making BC changes, then I would advocate for a new version of 
YANG, but that is not where we are, as has Jan as explained below, I think that 
defining a new version of YANG for this will just cause pain/confusion rather 
than any wider benefit to the industry.

Regards,
Rob

// As a contributor



> -Original Message-
> From: netmod  On Behalf Of Jan Lindblad
> (jlindbla)
> Sent: 12 September 2023 13:44
> To: Jürgen Schönwälder 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Poll on YANG Versioning NBC Approach
> 
> Jürgen, all,
> 
> I see the irony in changing the YANG RFC(s) without updating the YANG
> language version number, but digging a bit deeper, I think the question is not
> as clear-cut as it might seem at first.
> 
> Altering the contents of the backwards-compatibility section of RFC 6020 (sec
> 10) and RFC 7950 (sec 11) clearly implies changes in YANG module authors'
> behavior.
> 
> Speaking as a YANG compiler implementor, however, I don't see any changes
> that have to made to the compiler because of this RFC change. There are no
> new keywords, none are removed. There is no change in the meaning of
> existing keywords. There is no difference in the output the compiler needs to
> generate.
> 
> So while there are changes to the YANG *standard* (meaning RFCs) there is
> no actual change to the YANG *language*. If we require user's to mark their
> modules with version 1.2 (or 2.0), from the compiler's pov, that would just
> be an alias for YANG 1.1. It means a fair amount of trouble to update all the
> tools out there to accept "yang-version 1.2" but do nothing new. It also adds
> a burden to YANG module implementors, since they would have to go
> through all YANG 1.1 modules and mark them 1.2, for no change in meaning.
> For organizations with some modules still on YANG 1.0, the bar is even
> higher.
> 
> I think the most pragmatic approach in this case would be to change the RFC
> text in the backwards-compatibility sections and not update the yang-version
> number as long as no change is required in the compilers. If anyone can
> point to actual things the compiler needs to do differently, I'd be interested
> to hear.
> 
> Best Regards,
> /jan
> 
> 
> 
> > On 12 Sep 2023, at 07:55, Jürgen Schönwälder
>  wrote:
> >
> > I disagree with the poll. There are important teachnigal differences
> > behind the two options that this polls tries to hide.
> >
> > Updating YANG 1 and YANG 1.1 means creating YANG 1' and YANG
> > 1.1'. There is no way that a new versioning approach will be
> > understood by existing YANG tooling. That's an illusion.
> >
> > /js
> >
> > On Mon, Sep 11, 2023 at 10:39:39PM +, Kent Watsen wrote:
> >> WG,
> >>
> >> Please help the YANG-versioning effort move forward by participating in
> the following poll:
> >>
> >>  - https://notes.ietf.org/netmod-2023-sept-poll  (Datatracker login
> required)
> >>
> >> Kent and Lou
> >>
> >
> >> ___
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >
> >
> > --
> > 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] Poll on YANG Versioning NBC Approach

[Jan Lindblad (jlindbla)]

Jürgen, all,

I see the irony in changing the YANG RFC(s) without updating the YANG language 
version number, but digging a bit deeper, I think the question is not as 
clear-cut as it might seem at first.

Altering the contents of the backwards-compatibility section of RFC 6020 (sec 
10) and RFC 7950 (sec 11) clearly implies changes in YANG module authors' 
behavior.

Speaking as a YANG compiler implementor, however, I don't see any changes that 
have to made to the compiler because of this RFC change. There are no new 
keywords, none are removed. There is no change in the meaning of existing 
keywords. There is no difference in the output the compiler needs to generate.

So while there are changes to the YANG *standard* (meaning RFCs) there is no 
actual change to the YANG *language*. If we require user's to mark their 
modules with version 1.2 (or 2.0), from the compiler's pov, that would just be 
an alias for YANG 1.1. It means a fair amount of trouble to update all the 
tools out there to accept "yang-version 1.2" but do nothing new. It also adds a 
burden to YANG module implementors, since they would have to go through all 
YANG 1.1 modules and mark them 1.2, for no change in meaning. For organizations 
with some modules still on YANG 1.0, the bar is even higher.

I think the most pragmatic approach in this case would be to change the RFC 
text in the backwards-compatibility sections and not update the yang-version 
number as long as no change is required in the compilers. If anyone can point 
to actual things the compiler needs to do differently, I'd be interested to 
hear.

Best Regards,
/jan



> On 12 Sep 2023, at 07:55, Jürgen Schönwälder 
>  wrote:
> 
> I disagree with the poll. There are important teachnigal differences
> behind the two options that this polls tries to hide.
> 
> Updating YANG 1 and YANG 1.1 means creating YANG 1' and YANG
> 1.1'. There is no way that a new versioning approach will be
> understood by existing YANG tooling. That's an illusion.
> 
> /js
> 
> On Mon, Sep 11, 2023 at 10:39:39PM +, Kent Watsen wrote:
>> WG,
>> 
>> Please help the YANG-versioning effort move forward by participating in the 
>> following poll:
>> 
>>  - https://notes.ietf.org/netmod-2023-sept-poll  (Datatracker login required)
>> 
>> Kent and Lou
>> 
> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> 
> 
> -- 
> 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] Poll on YANG Versioning NBC Approach

[Jürgen Schönwälder]

Versioning people told me that the version numbers follows from the
kind of changes made. If true, then discussing the version number
first is backwards.

/js

On Tue, Sep 12, 2023 at 11:59:45AM +, Jason Sterne (Nokia) wrote:
> Hi Jurgen,
> 
> We need this poll to set fundamental direction in the WG. Yes, there will 
> still be discussion & debate around *either* option once we select one. But 
> we need to agree on whether we're moving ahead by updating YANG 1.0/YANG 1.1 
> (without requiring any sort of new YANG version number) or if we as a WG are 
> going to insist on only allowing this work to continue and exist in YANG 
> modules marked with a new YANG version 1.2.
> 
> We need to put this part of the decision behind us and move onto the next set 
> of discussions & issues.
> 
> Jason
> 
> > -Original Message-
> > From: netmod  On Behalf Of Jürgen Schönwälder
> > Sent: Tuesday, September 12, 2023 1:55 AM
> > To: Kent Watsen 
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] Poll on YANG Versioning NBC Approach
> > 
> > 
> > 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.
> > 
> > 
> > 
> > I disagree with the poll. There are important teachnigal differences
> > behind the two options that this polls tries to hide.
> > 
> > Updating YANG 1 and YANG 1.1 means creating YANG 1' and YANG
> > 1.1'. There is no way that a new versioning approach will be
> > understood by existing YANG tooling. That's an illusion.
> > 
> > /js
> > 
> > On Mon, Sep 11, 2023 at 10:39:39PM +, Kent Watsen wrote:
> > > WG,
> > >
> > > Please help the YANG-versioning effort move forward by participating in 
> > > the
> > following poll:
> > >
> > >   - https://notes.ietf.org/netmod-2023-sept-poll  (Datatracker login 
> > > required)
> > >
> > > Kent and Lou
> > >
> > 
> > > ___
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > 
> > 
> > --
> > 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

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

Re: [netmod] Poll on YANG Versioning NBC Approach

[Jason Sterne (Nokia)]

Hi Jurgen,

We need this poll to set fundamental direction in the WG. Yes, there will still 
be discussion & debate around *either* option once we select one. But we need 
to agree on whether we're moving ahead by updating YANG 1.0/YANG 1.1 (without 
requiring any sort of new YANG version number) or if we as a WG are going to 
insist on only allowing this work to continue and exist in YANG modules marked 
with a new YANG version 1.2.

We need to put this part of the decision behind us and move onto the next set 
of discussions & issues.

Jason

> -Original Message-
> From: netmod  On Behalf Of Jürgen Schönwälder
> Sent: Tuesday, September 12, 2023 1:55 AM
> To: Kent Watsen 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Poll on YANG Versioning NBC Approach
> 
> 
> 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.
> 
> 
> 
> I disagree with the poll. There are important teachnigal differences
> behind the two options that this polls tries to hide.
> 
> Updating YANG 1 and YANG 1.1 means creating YANG 1' and YANG
> 1.1'. There is no way that a new versioning approach will be
> understood by existing YANG tooling. That's an illusion.
> 
> /js
> 
> On Mon, Sep 11, 2023 at 10:39:39PM +, Kent Watsen wrote:
> > WG,
> >
> > Please help the YANG-versioning effort move forward by participating in the
> following poll:
> >
> >   - https://notes.ietf.org/netmod-2023-sept-poll  (Datatracker login 
> > required)
> >
> > Kent and Lou
> >
> 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> 
> --
> 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] Poll on YANG Versioning NBC Approach

[Jason Sterne (Nokia)]

Hi all,

I'd encourage anyone to remind themselves of some of the details around this 
issue before answering the poll.

Summary of options by the YANG Versioning weekly call group:
https://mailarchive.ietf.org/arch/msg/netmod/MSjLKSy7PwjaDkJdnwKREY9KCbc/

IETF 117 NETMOD meeting recording (YANG Versioning starts at 14 minutes in, 
also see results of the "Show of Hands"): IETF117-NETMOD-20230724-2000 
(meetecho.com)

Rgds,
Jason

From: netmod  On Behalf Of Kent Watsen
Sent: Monday, September 11, 2023 6:40 PM
To: netmod@ietf.org
Subject: [netmod] Poll on YANG Versioning NBC Approach


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.


WG,

Please help the YANG-versioning effort move forward by participating in the 
following poll:

  - https://notes.ietf.org/netmod-2023-sept-poll  (Datatracker login required)

Kent and Lou

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

Re: [netmod] Poll on YANG Versioning NBC Approach

[Jürgen Schönwälder]

I disagree with the poll. There are important teachnigal differences
behind the two options that this polls tries to hide.

Updating YANG 1 and YANG 1.1 means creating YANG 1' and YANG
1.1'. There is no way that a new versioning approach will be
understood by existing YANG tooling. That's an illusion.

/js

On Mon, Sep 11, 2023 at 10:39:39PM +, Kent Watsen wrote:
> WG,
> 
> Please help the YANG-versioning effort move forward by participating in the 
> following poll:
> 
>   - https://notes.ietf.org/netmod-2023-sept-poll  (Datatracker login required)
> 
> Kent and Lou
> 

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


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