Re: [netmod] Poll on YANG Versioning NBC Approach

[Acee Lindem <[e-mail]>]

> On Sep 14, 2023, at 12:40, Andy Bierman <[e-mail]> wrote:
> 
> 
> 
> On Thu, Sep 14, 2023 at 9:05 AM Acee Lindem <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>> > On Sep 13, 2023, at 10:36, Ladislav Lhotka <ladislav.lhotka=[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> 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 <[e-mail]> 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 +0000, 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
>> >>>>>>> [e-mail] <mailto:[e-mail]>
>> >>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>> >>>>>> 
>> >>>>>> --
>> >>>>>> Jürgen Schönwälder              Constructor University Bremen gGmbH
>> >>>>>> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>> >>>>>> Fax:   [phone] <https://constructor.university/>
>> >>>>>> 
>> >>>>>> _______________________________________________
>> >>>>>> netmod mailing list
>> >>>>>> [e-mail] <mailto:[e-mail]>
>> >>>>>> https://www.ietf.org/mailman/listinfo/netmod
>> >>>>> _______________________________________________
>> >>>>> netmod mailing list
>> >>>>> [e-mail] <mailto:[e-mail]>
>> >>>>> https://www.ietf.org/mailman/listinfo/netmod
>> >>> 
>> >> _______________________________________________
>> >> netmod mailing list
>> >> [e-mail] <mailto:[e-mail]>
>> >> https://www.ietf.org/mailman/listinfo/netmod
>> > 
>> > -- 
>> > Ladislav Lhotka, CZ.NIC
>> > PGP Key ID: 0xB8F92B08A9F76C67
>> > 
>> > _______________________________________________
>> > netmod mailing list
>> > [e-mail] <mailto:[e-mail]>
>> > https://www.ietf.org/mailman/listinfo/netmod
>> 
>> _______________________________________________
>> netmod mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/netmod