1/ I understand that clients may/may-not be yang aware, not using hello/yang-lib and may have hard-coded requests, response processing to get its job done using the server. Such a client when encountering ‘unknown’ nodes can either fail or ignore those nodes. It’s the client choice. But, with expanded range of ‘enum and bits’, there is no choice but to fail as the ‘value’ is now unknown. OK.
2/ If I understand right, RFC 7950 – Section 11 is talking about ways to update yang module so the existing data in the server doesn’t gets invalidated. That’s why the new data definition to be optional or conditional using if-feature. Not about clients at all. Thank you for making this clear. Shouldn’t the RFC text capture this so readers are informed? Regards, R Kaja Mohideen From: Andy Bierman <[email protected]> Sent: Thursday, March 17, 2022 3:29 AM To: Randy Presuhn <[email protected]> Cc: RFC Errata System <[email protected]>; Martin Bjorklund <[email protected]>; Warren Kumari <[email protected]>; Robert Wilton <[email protected]>; Kent Watsen <[email protected]>; Joel Jaeggli <[email protected]>; Berger Lou <[email protected]>; Mohideen, Kaja (Nokia - IN/Chennai) <[email protected]>; NetMod WG <[email protected]> Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6885) On Wed, Mar 16, 2022 at 1:44 PM Randy Presuhn <[email protected]<mailto:[email protected]>> wrote: Hi - On 2022-03-15 11:13 PM, Jürgen Schönwälder wrote: > 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. I agree that the proposed erratum should be rejected. The text of RFC 7950 says what the working group clearly intended, and is consistent with the approach taken in the SNMP SMI, for whatever that might be worth. +1 The RFCs are server-centric. It is not 100% clear what a NETCONF client MUST, SHOULD, or MAY do for various scenarios. I just scanned the text, and cannot find any that says a client MUST accept augmentations. Consider a client that ignores the server <hello> and YANG library (they are out there!). It is hard-wired to retrieve some subtree. If the server implements any module augmenting that subtree, the client drops the session because "unknown nodes" were found in the retrieved data. Clearly not the intent of the WG, not not clear RFC 7950 is being violated. (Insert plug for YANG Conformance based on packages and NOT modules) Randy Andy > /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]<mailto:[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]<mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
