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

[Andy Bierman <[e-mail]>]

On Fri, May 19, 2023 at 4:05 AM <[e-mail]> wrote:

> 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?
>
>
>


Good news: you are not trying to undo the 'implement 1 revision'
requirement in RFC 7950.
Not so good news: There are already 2 events (netconf-capability-change and
yang-library-change)
to notify the client of the extremely rare module update event.

In the rare event a module is updated, the subscriber gets a 3rd
notification for this change,
and the data from the module starts to be filtered by the server so the
subscriber is prevented
from receiving the "unwanted" data.  This can be quite complicated to
implement,
forcing special processing for each subscription.

I am not in favor of changing YANG Push in this way.



> Looking forward for your feedback and comments.
>
>
>
> Best wishes
>
> Thomas
>


Andy


>
>
> *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]> 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
>
> ...
>
>
>