Hi, I agree with Andy, Jurgen, and Randy that this is not a valid errata, and hence I will reject it.
Kaja, if you are not aware, there is active work progressing in NETMOD looking at versioning and conformance. A reasonable chunk of time will be spent discussing some aspects of this in next weeks NETMOD meeting at IETF 113. A closely related issue to what you described came up in the discussions: What does a backwards compatible change mean in the context of operational data that is being read from the server, as opposed to configuration data that is being written to the server. Specifically, expanding a leaf range on a config true item, will equate to an expanded range on the same (logically config false) item represented in the NMDA operational datastore view. After quite a lot of discussion, the conclusion was that trying to either be stricter about operational data or trying to describe the changes in a module version number wouldn't be useful. I think that you get to the logical conclusion that you can't add or change anything at all! E.g., if an updated version of a module adds a new leaf A, set by client C1, then a separate client C2, that doesn't understand the new version of the module won't understand leaf A when it reads the config (or operational data) back from the server. When I have thought about this issue, I have always considered that the operator needs to coordinate between all their clients, so that if they make use of new functionality in one client (e.g., an expanded item range for a config item) then they need to ensure that all their other clients interacting with the server can handle (or ignore) the changes in the schema. Note the weekly versioning calls (2-3 pm UK time on Tuesday, the webex link will be in the Netmod mail archives) are open to all participants. Regards, Rob > -----Original Message----- > From: Jürgen Schönwälder <[email protected]> > Sent: 16 March 2022 06:13 > To: RFC Errata System <[email protected]> > Cc: [email protected]; [email protected]; Rob Wilton (rwilton) > <[email protected]>; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected] > Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6885) > > YANG update rules expect clients to be lenient about values they > received but did not expect. It is possible to debate that design > choice but this surely is not an errata, hence this errata should > be rejected. > > /js > > On Tue, Mar 15, 2022 at 10:21:12PM -0700, RFC Errata System wrote: > > The following errata report has been submitted for RFC7950, > > "The YANG 1.1 Data Modeling Language". > > > > -------------------------------------- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid6885 > > > > -------------------------------------- > > Type: Technical > > Reported by: R Kaja Mohideen <[email protected]> > > > > Section: 11 > > > > Original Text > > ------------- > > A definition in a published module may be revised in any of the > > following ways: > > > > o An "enumeration" type may have new enums added, provided the old > > enums's values do not change. Note that inserting a new enum > > before an existing enum or reordering existing enums will result > > in new values for the existing enums, unless they have explicit > > values assigned to them. > > > > o A "bits" type may have new bits added, provided the old bit > > positions do not change. Note that inserting a new bit before an > > existing bit or reordering existing bits will result in new > > positions for the existing bits, unless they have explicit > > positions assigned to them. > > > > Corrected Text > > -------------- > > See Notes. > > > > Notes > > ----- > > When server is exposing updated yang model as mentioned in Section 11, > particularly with enums, bits having new items - client systems that are not > updated to use the new yang module will not be able to recognize and use > the new values. > > > > This is problematic when there are multiple clients and those systems are > getting updated to catch up with yang changes over time. Updated "Client A" > recognizing new enum and using it (update datastore with new value using > edit-config), will make, old/not-yet-updated "Client B" to encounter the new > value (received as response of get-config) that it cannot work with. > > > > So, the "backward compatible" ways of updating a yang module should > consider "multiple clients" scenario and make recommendations in such a > way that clients are not forced to update all at once. > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC7950 (draft-ietf-netmod-rfc6020bis-14) > > -------------------------------------- > > Title : The YANG 1.1 Data Modeling Language > > Publication Date : August 2016 > > Author(s) : M. Bjorklund, Ed. > > Category : PROPOSED STANDARD > > Source : Network Modeling > > Area : Operations and Management > > Stream : IETF > > Verifying Party : IESG > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Jürgen Schönwälder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
