> On Sep 13, 2023, at 10:36, Ladislav Lhotka > <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 Thanks, Acee > > Lada > >> Jernej >>> >>> Best Regards, >>> /jan >>> >>> >>> >>> >>> >>>> On 13 Sep 2023, at 10:57, Jernej Tuljak <jernej.tul...@mg-soft.si> 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 >>>>>> <jschoenwaelder@constructor.university> 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 >>>>>>> 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 > > -- > Ladislav Lhotka, CZ.NIC > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > 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
