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
