[netconf] Re: Adoption call for notif-yang-04

[[e-mail]]

Dear Kent,

See my answers inline.

Best wishes
Thomas


From: Kent Watsen <[e-mail]>
Sent: Thursday, June 13, 2024 5:21 PM
To: Graf Thomas, INI-NET-VNC-HCS <[e-mail]>
Cc: Andy Bierman <[e-mail]>; Per Andersson <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [netconf] Adoption call for notif-yang-04


Be aware: This is an external email.


Hi Thomas,


On May 19, 2024, at 5:46 AM, [e-mail]<mailto:[e-mail]> wrote:

Dear Kent,


  *   Code I’ve written in the past manually-validates the envelope and then, separately, validates the payload via the YANG “notification” definition.

I would phrase "manually-validates" differently. I think you have excluded from validation because it can't be validated. That’s what we have seen during IETF 117 hackathon when using yanglint.

KW> The word “manual” was out of place.   What I meant was that the code validates in two-steps: first the envelop is validated using generic schema, then the payload is validated using the specific schema.



TG> I think we are on the same page but lets try to be precise that we have a solid base. I would like to learn wherever you have the same understanding. You are refering to the XSD defined in https://datatracker.ietf.org/doc/html/rfc5277#section-4 for the event notification envelop and the notifications schemas in the ietf-subscribed-notifications YANG module described in https://datatracker.ietf.org/doc/html/rfc8639#section-4 resp. ietf-yang-push YANG module described in https://datatracker.ietf.org/doc/html/rfc8641#section-5. Correct?





https://datatracker.ietf.org/doc/html/rfc8639#section-4

  /*

   * NOTIFICATIONS

   */



  notification replay-completed {

    sn:subscription-state-notification;

    if-feature "replay";

    description

      "This notification is sent to indicate that all of the replay

       notifications have been sent.";

    leaf id {

      type subscription-id;

      mandatory true;

      description

        "This references the affected subscription.";

    }

  }



https://datatracker.ietf.org/doc/html/rfc8641#section-5

     /*

      * NOTIFICATIONS

      */



     notification push-update {

       description

         "This notification contains a push update that in turn contains

          data subscribed to via a subscription.  In the case of a

          periodic subscription, this notification is sent for periodic

          updates.  It can also be used for synchronization updates of

          an on-change subscription.  This notification shall only be

          sent to receivers of a subscription.  It does not constitute

          a general-purpose notification that would be subscribable as

          part of the NETCONF event stream by any receiver.";

       leaf id {

         type sn:subscription-id;

         description

           "This references the subscription that drove the

            notification to be sent.";

       }

       anydata datastore-contents {

         description

           "This contains the updated data.  It constitutes a snapshot

            at the time of update of the set of data that has been

            subscribed to.  The snapshot corresponds to the same

            snapshot that would be returned in a corresponding 'get'

            operation with the same selection filter parameters

            applied.";

       }

       leaf incomplete-update {

         type empty;

         description

           "This is a flag that indicates that not all datastore

            nodes subscribed to are included with this update.  In

            other words, the publisher has failed to fulfill its full

            subscription obligations and, despite its best efforts, is

            providing an incomplete set of objects.";

       }

     }


TG> If correct, then I think the word payload is misplaced. I would word that the YANG-push notification schema is defined in XSD for the notification statement and in YANG for the rest of the YANG-push notification schema. This would be in line with

https://datatracker.ietf.org/doc/html/rfc8639#section-1.4


   o  The <notification> message of [RFC5277], Section 4<https://datatracker.ietf.org/doc/html/rfc5277#section-4> is used.

TG> And lets agree that schema is equally necessary for encoding, decoding and validating of messages.

TG> Is my assessment correct? Do you also come to the same conclusion?

TG> I find reading that YANG-Push is based on notifications in https://datatracker.ietf.org/doc/html/rfc8639#section-1.4 and notifications can be encoded in JSON according to https://www.rfc-editor.org/rfc/rfc7951#section-1 for an implementer rather misleading. Would you agree?

KW> I don’t understand.  Can you say some more?  Also, what remediation do you have in mind?


TG> Sure. RFC 7951 and RFC 9254 describing encoding rules how YANG. Both RFC's describing in the abstract and introduction that notifications are in scope but missing encoding rules for YANG. The only related information I was able to find is an example in the encoding rule section on anydata https://www.rfc-editor.org/rfc/rfc7951#section-5.5. In RFC 8639 and RFC 8641 it is assumed that the notification messages are JSON and CBOR encodable. However the encoding rules for notifications in RFC 7951 and RFC 9254 and the YANG module for https://datatracker.ietf.org/doc/html/rfc5277#section-4 is missing. Does that clarify?



TG> Where I am puzzled is that this problem has already being reported in an errata for RC5277: https://www.rfc-editor.org/errata/eid6770 and discussed on the netconf mailing list here: https://mailarchive.ietf.org/arch/msg/netconf/VF8QwvhG8nLii6dXTYZYThrNhgc/. It received the same push back reasoning as Med did on https://mailarchive.ietf.org/arch/msg/netconf/Abw9mRHZos_yK9-x1HWHCVyv_xM/.



TG> I believe the root cause that notifications can't be encoded in JSON and CBOR due to missing YANG module does not lie in RFC 5277, it lies in Section 1.4 of RFC 8639. I highlighted in green the paragraphs describing where RFC 8639 is defining new elements and in yellow where it is based on RFC 5277. Agree?



https://datatracker.ietf.org/doc/html/rfc8639#section-1.4



   o  This document defines a transport-independent capability;

      [RFC5277<https://datatracker.ietf.org/doc/html/rfc5277>] is specific to NETCONF.



   o  For the new operations, the data model defined in this document is

      used instead of the data model defined in Section 3.4 of<https://datatracker.ietf.org/doc/html/rfc5277#section-3.4>

      [RFC5277]<https://datatracker.ietf.org/doc/html/rfc5277#section-3.4>.



   o  The RPC operations in this document replace the operation

      <create-subscription> as defined in [RFC5277], Section 4<https://datatracker.ietf.org/doc/html/rfc5277#section-4>.



   o  The <notification> message of [RFC5277], Section 4<https://datatracker.ietf.org/doc/html/rfc5277#section-4> is used.



   o  The included contents of the "NETCONF" event stream are identical

      between this document and [RFC5277<https://datatracker.ietf.org/doc/html/rfc5277>]



   o  A publisher MAY implement both the Notification Management Schema

      and RPCs defined in [RFC5277<https://datatracker.ietf.org/doc/html/rfc5277>] and this document concurrently.



   o  Unlike [RFC5277<https://datatracker.ietf.org/doc/html/rfc5277>] this document enables a single transport session

      to intermix notification messages and RPCs for different

      subscriptions.



   o  A subscription "stop-time" can be specified as part of a

      notification replay.  This supports a capability analogous to the

      <stopTime> parameter of [RFC5277<https://datatracker.ietf.org/doc/html/rfc5277>]  However, in this

      specification, a "stop-time" parameter can also be applied without

      replay.



From: Kent Watsen <[e-mail]<mailto:[e-mail]>>
Sent: Saturday, May 11, 2024 12:38 AM
To: Andy Bierman <[e-mail]<mailto:[e-mail]>>
Cc: Graf Thomas, INI-NET-VNC-HCS <[e-mail]<mailto:[e-mail]>>; Per Andersson <[e-mail]<mailto:[e-mail]>>; BOUCADAIR Mohamed IMT/OLN <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Alex Huang Feng <[e-mail]<mailto:[e-mail]>>; Benoit Claise <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [netconf] Adoption call for notif-yang-04


Be aware: This is an external email.






On May 10, 2024, at 1:43 PM, Andy Bierman <[e-mail]<mailto:[e-mail]>> wrote:

It is quite rigid and XML-specific:

   <notification>
       <eventTime>...</eventTime>
       < **event element**  />
   </notification>

<snip/>
YANG is incapable of representing this XSD correctly (no SubstitutionGroup).

True, not even an “anydata” helps.  If the goal is to be able to validate the entire “notification” message, I don’t see how that’s possible.

Code I’ve written in the past manually-validates the envelope and then, separately, validates the payload via the YANG “notification” definition.

K.