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

[Andy Bierman <[e-mail]>]

On Fri, May 19, 2023 at 7:42 AM Andy Bierman <[e-mail]> wrote:

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

I do not see any clear YANG definition or examples for these augments:

module: ietf-yang-push-revision

  augment /sn:establish-subscription/sn:input/sn:target:
    +--rw revision?         rev:revision-date-or-label
    +-- revision-label?   ysver:version
  augment /sn:modify-subscription/sn:input/sn:target:
    +--rw revision?         rev:revision-date-or-label
    +-- revision-label?   ysver:version
  augment /sn:subscription-started/sn:target:
    +--ro revision          rev:revision-date-or-label
    +-- revision-label?   ysver:version
  augment /sn:subscription-modified/sn:target:
    +--ro revision          rev:revision-date-or-label
    +-- revision-label?   ysver:version
  augment /sn:subscriptions/sn:subscription/sn:target:
    +--ro revision          rev:revision-date-or-label
    +--rw revision-label?   ysver:version



Since a subscription filter is not limited to 1 module, It is unclear how
this draft would be implemented.

The augment is not a module-name + revision, just a revision.
The purpose is unclear. These leafs are added to the
establish-subscription input.

    leaf revision {
      type rev:revision-date-or-label;
      description
        "This references the YANG module revision to be sent in the
subscription.";
    }
    leaf revision-label {
      type ysver:version;
      description
        "This references the YANG module semversion to be sent in the
subscription.";
    }



The subscription never specifies a module, so what module name do these
parameters affect?

Sec 2 describes some parameter values that do not exist (latest,
latest-compatible-semversion)
The YANG module defines a yang-push-revision-supported feature, but there
are no if-feature
statements that reference it.

Andy



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