Subject: [netmod] [Technical Errata Reported] RFC7950 (6885)

From: RFC Errata System <[email-masked]>
Date: Tue, 15 Mar 2022 22:21:12 -0700 (PDT)

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-masked]>

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

---

From: Jürgen Schönwälder <[email-masked]>
Date: Wed, 16 Mar 2022 07:13:27 +0100

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:
> _______________________________________________
> netmod mailing list
> [email-masked]
> 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/>

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 16 Mar 2022 13:43:53 -0700

Hi -

> choice but this surely is not an errata, hence this errata should

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.

Randy

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 17 Mar 2022 09:58:36 +0000

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-masked]>
> Sent: 16 March 2022 06:13
> To: RFC Errata System <[email-masked]>
> Cc: [email-masked]; [email-masked]; Rob Wilton (rwilton)
> <[email-masked]>; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6885)
> 
> > 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:
> > -------------

---

From: Andy Bierman <[email-masked]>
Date: Wed, 16 Mar 2022 14:59:14 -0700

> consistent with the approach taken in the SNMP SMI, for whatever
+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

> 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.
> >>
> consider "multiple clients" scenario and make recommendations in such a way
> that clients are not forced to update all at once.
> >>
> >> Instructions:
> >> -------------

---

From: "Mohideen, Kaja (Nokia - IN/Chennai)" <[email-masked]>
Date: Thu, 17 Mar 2022 07:11:36 +0000

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-masked]>
Sent: Thursday, March 17, 2022 3:29 AM
To: Randy Presuhn <[email-masked]>
Cc: RFC Errata System <[email-masked]>; Martin Bjorklund <[email-masked]>; Warren Kumari <[email-masked]>; Robert Wilton <[email-masked]>; Kent Watsen <[email-masked]>; Joel Jaeggli <[email-masked]>; Berger Lou <[email-masked]>; Mohideen, Kaja (Nokia - IN/Chennai) <[email-masked]>; NetMod WG <[email-masked]>
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6885)

On Wed, Mar 16, 2022 at 1:44 PM Randy Presuhn <[email-masked]<mailto:[email-masked]>> wrote:
Hi -

+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.

Randy

Andy

>> Reported by: R Kaja Mohideen <[email-masked]<mailto:[email-masked]>>
>>
>> Section: 11
>>
>> Original Text
>> -------------
>> [email-masked]<mailto:[email-masked]>

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: Jürgen Schönwälder <[email-masked]>
Date: Tue, 22 Mar 2022 21:04:04 +0100

> 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 encou…

I do not agree that an expanded value space necessarily implies that
clients have to fail.

> 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 opt…

The update rules defined in Section 11 try to guarantee that server
updates do not break existing clients. This requires that clients play
nicely with data that they do not understand and it requires that
updates are done in a way to maintain backwards compatibility with
existing clients. I wonder what makes you believe this would be
different.

I am trimming the CC list since we already concluded that this is not
an errata.

/js

---

From: "Mohideen, Kaja (Nokia - IN/Chennai)" <[email-masked]>
Date: Wed, 23 Mar 2022 05:22:16 +0000

-----Original Message-----
From: Jürgen Schönwälder <[email-masked]> 
Sent: Wednesday, March 23, 2022 1:34 AM
To: Mohideen, Kaja (Nokia - IN/Chennai) <[email-masked]>
Cc: NetMod WG <[email-masked]>
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6885)

> 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 encou…

I do not agree that an expanded value space necessarily implies that clients have to fail.

[R Kaja Mohideen] What else the client can do? How can the client map the new value to one of the old values it recognize? Whatever the scenario the client is trying to get done, at least the specific step cannot be considered 'successful'.

> 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 opt…

The update rules defined in Section 11 try to guarantee that server updates do not break existing clients. This requires that clients play nicely with data that they do not understand and it requires that updates are done in a way to maintain backwards compatibility with existing clients. I wonder what makes you believe this would be different.

[R Kaja Mohideen] Sure. It's helping the existing client assuming there is only one set of clients and those are all updated at same time OR there is no new client using the updated module co-existing with old clients.

I am trimming the CC list since we already concluded that this is not an errata.

/js

---

From: Jürgen Schönwälder <[email-masked]>
Date: Wed, 23 Mar 2022 07:48:08 +0100

> [R Kaja Mohideen] What else the client can do? How can the client map the new value to one of the old values it recognize? Whatever the scenario the client is trying to get done, at least the speci…

It depends on the semantics of the type/leaf, there is no generic
answer or mapping rule that does the right thing.

Yes, multiple clients configuring the same parts of a data model on a
server using different versions of the data model is not trivial (but
such a scenario is by design not trivial).

/js

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 23 Mar 2022 07:57:23 +0100

On 22. Mar 2022, at 21:04, Jürgen Schönwälder <[email-masked]> wrote:
> 
> updates are done in a way to maintain backwards compatibility

(Forward compatibility?
Backward compatibility = old data, new system.
Forward compatibility = new data, old system.
Just saying…)

Grüße, Carsten

---

From: Jürgen Schönwälder <[email-masked]>
Date: Wed, 23 Mar 2022 08:43:18 +0100

> Forward compatibility = new data, old system.

The design goal was to ensure that server upgrades do not break
existing clients. We commonly call YANG data model changes ensuring
that old clients continue to work 'backwards compatible'.

This discussion seems to be about a scenario where a server has been
upgraded and there are old and new clients talking to the same server,
i.e., the problem is a version mix on the client side. Such a scenario
is tricky and requires a lot of careful design since clients must be
written with the idea in mind that they may have a limited view on the
state of the world.

/js