Re: [netconf] Adoption poll for draft-tgraf-netconf-yang-notifications-versioning

[[e-mail]]

Dear Andy, Jürgen, Nacho and Frank,

Thanks a lot for the feedback and comments. I understand your concerns that they are targeting section 2, extending the YANG push subscription capability to not only subscribing to an xpath but also be capable to select with revision or revision-label.

In section 1 we introduce the problem statement, here an excerpt:

---
This semantic reference is available when the subscription is being establish as described in Section 3.6 of [RFC8641] and being streamed from the publisher to receiver with the subscription state change notifications described in Section 2.7 of [RFC8639] where for each subscription a locally unique subscription ID described in Section 4.3.2 of [RFC8641] is being issued and streamed as metadata with the notification message in the YANG push message header.

The semantics can change between different YANG module revisions. The YANG module version statement is specified in Section 7.1.2 of [RFC6020] and states that the newer revision needs to be backward compatible to the previous revision. Section 3.1 of [I-D.ietf-netmod-yang-module-versioning] specifies that newer semantic versions introduced in [I-D.ietf-netmod-yang-semver] MAY not be backward compatible to the previous version when indicated with non-backwards-compatible keyword.
---

When the software of a network node is being upgraded, possibly the YANG module revisions might change. Thanks to the extension describes in section 3 of the document, the YANG push receiver is now able to learn through the subscription state change notification message that the revision or/and revision-label has changed and through netconf <get-schema> the new YANG module must be obtained outband to retrieve the new semantics for the push-update notification message.

So far so good. With this we prevented that the end to end data processing chain breaks because semantics can be maintained across network node software upgrades, YANG module changes, in configured subscription as well. However if the YANG module change involved a non-backward compatible change, messages are being dropped within the data processing chain. A network operator might ask, why should we publish YANG push messages from a network node when they cant be processed further down the data processing chain? Why shouldn't we give the network engineer the ability to express in the YANG push subscription that only YANG push messages complying to a certain revision or revision-label (semantic revision) should be published. This is what section 2 of the document tries to address.

I understood in the mail thread that it was assumed that the YANG data store would need to support more than one revision per YANG module. This is not the case. The point is that when the configured subscription is established and while the messages are being published, the revision or revision-label might change. Today we do not have the ability to subscribe to a specific revision nor to a specific compatible revision-label. This is what we try to enable in this document.

These are the network operators concerns and needs. From an implementer point of view, do you believe this makes sense and is implementable?

Looking forward for your feedback and comments.

Best wishes
Thomas

From: netconf <[e-mail]> On Behalf Of Andy Bierman
Sent: Wednesday, May 17, 2023 7:27 PM
To: Jürgen Schönwälder <[e-mail]>; IGNACIO DOMINGUEZ MARTINEZ-CASANUEVA <[e-mail]>; Mahesh Jethanandani <[e-mail]>; netconf <[e-mail]>; netconf-chairs <[e-mail]>
Subject: Re: [netconf] Adoption poll for draft-tgraf-netconf-yang-notifications-versioning



On Wed, May 17, 2023 at 1:42 AM Jürgen Schönwälder <[e-mail]<mailto:[e-mail]>> wrote:
All of this has been pointed out before and does not come as a
surprise. So we should have a general answer how to handle the
"damage" created by an NBC update of YANG that according to some does
not even require a YANG version number change.

It is more than just a conformance issue.
It is hard to overstate the importance of RFC 7950 as the 1 well-written
document needed to learn YANG.  It may be OK to distribute the
YANG data model in lots of ad-hoc specifications, but not the
data modeling language definition.

People (way outside the IETF) will be expected to learn and use the "new" YANG correctly,
and that will be much more difficult without even a name, let alone a version number.
What is the new YANG called? "NBC YANG"?


Andy


..
/js
...