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

["Rob Wilton (rwilton)" <[e-mail]>]

I’m trying to implement YANG Push with a JSON encoding of the notifications, I agree that they are underspecified.

RFC 8040 does have a solution (6.4), and states to use ietf-restconf as the module for a notification, e.g., there is this example from page 72:


   Two child nodes within the "notification" container are expected,

   representing the event time and the event payload.  The "eventTime"

   node is defined within the same XML namespace as the <notification>

   element.  It is defined to be within the "ietf-restconf" module

   namespace for JSON-encoding purposes.



   The name and namespace of the payload element are determined by the

   YANG module containing the notification-stmt representing the

   notification message.



   ...

   An example SSE event notification encoded using JSON:

      data: {
      data:   "ietf-restconf:notification" : {
      data:     "eventTime" : "2013-12-21T00:01:00Z",
      data:     "example-mod:event" : {
      data:       "event-class" : "fault",
      data:       "reporting-entity" : { "card" : "Ethernet0" },
      data:       "severity" : "major"
      data:     }
      data:   }
      data: }

Of course, that only helps if you are using JSON with RESTCONF (which I’m not).

RFC 7951 also states:


Abstract



   This document defines encoding rules for representing configuration

   data, state data, parameters of Remote Procedure Call (RPC)

   operations or actions, and notifications defined using YANG as

   JavaScript Object Notation (JSON) text.


But I’m not sure that it has any normative text to say how notifications are encoded in JSON.

It does have this anydata example containing a notification, but in this case the pseudo module for the notification is “ietf-notification”:


   "data": {

     "ietf-notification:notification": {

       "eventTime": "2014-07-29T13:43:01Z",

       "example-event:event": {

         "event-class": "fault",

         "reporting-entity": {

           "card": "Ethernet0"

         },

         "severity": "major"

       }

     }

   }

Regards,
Rob



From: [e-mail] <[e-mail]>
Date: Sunday, 19 May 2024 at 10:10
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: [netconf] Re: Adoption call for notif-yang-04
Dear Andy,

Thanks for the feedback. I am unable to follow your assessment without taking guesses. I think a proper problem statement is needed first. Could you please detail and especially reference your assessment by refering to existing documents. That would help me to follow the conversation.

Best wishes
Thomas

From: Andy Bierman <[e-mail]>
Sent: Friday, May 10, 2024 7:44 PM
To: Graf Thomas, INI-NET-VNC-HCS <[e-mail]>
Cc: [e-mail]; [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.



On Fri, May 10, 2024 at 7:40 AM <[e-mail]<mailto:[e-mail]>> wrote:
Dear Per, Kent, Med and Andy

My apology for late feedback on the mailing list. I did some research and clarifications before coming with a proposal and would like to have you feedback and comments.

I think I need a virtual interim meeting to catch up on all the issues.
NETCONF has only one notification message, defined in an XSD.
It is quite rigid and XML-specific:

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

There are standard mappings from YANG to JSON and CBOR. (Not XML to JSON and CBOR).
YANG is incapable of representing this XSD correctly (no SubstitutionGroup).
The YANG-specific mappings in RFC 7951 and RFC 9254 only apply to the event element.

Issue 1) Translating the RFC 5277 notification XSD to JSON and CBOR

Issue 2) Using a notification message that does not conform to the RFC 5277 XSD

Issue 3) Specific changes to the notification message

Issue 4) Specific changes to Subscriptions/YANG Push

I need to go through your email before commenting more.


Andy


The XSD defined in https://datatracker.ietf.org/doc/html/rfc5277#section-4 describes the creation of the subscription creation and the event notification. The event notification includes the eventTime. There has been an errata being opened https://www.rfc-editor.org/errata/eid6770 and rejected by Rob Wilton after Andy Bierman's feedback. See https://mailarchive.ietf.org/arch/msg/netconf/8et-gI8Gvh2mG7jZIq7VyhTRU1Q/. However I believe that the concerned addressed is valid but should have been filed under RFC 8639 errata instead.

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

   o  The <notification> message of [RFC5277], Section 4 is used.

https://datatracker.ietf.org/doc/html/rfc8639#section-2.9 states that "ietf-subscribed-notifications" YANG Module is being used and JSON encoding is optionally.

From that I deduct that https://datatracker.ietf.org/doc/html/rfc8639#section-2.1 in RFC 8639 is technically not implementable for reasons explained in https://www.rfc-editor.org/errata/eid6770. Therefore what has been described in https://www.rfc-editor.org/errata/eid6770 should have led to an updated RFC 8639.

From the comments of Med and Andy in the draft-ahuang-netconf-notif-yang-04 adoption call

https://mailarchive.ietf.org/arch/msg/netconf/Abw9mRHZos_yK9-x1HWHCVyv_xM/
https://mailarchive.ietf.org/arch/msg/netconf/Q4S-qPV323F-1KsCSVNf5W1ungc/

I understand the following concerns:

1. The path how to resolve that https://datatracker.ietf.org/doc/html/rfc8639#section-2.1 in RFC 8639 is technically not implementable for JSON and CBOR encoded messages
2. That the YANG module described in draft-ahuang-netconf-notif-yang-04 could be augmented (example https://datatracker.ietf.org/doc/html/draft-tgraf-netconf-notif-sequencing) and therefore no longer matches the XSD described in https://datatracker.ietf.org/doc/html/rfc5277#section-4

Regarding the first point from Med. To my understanding the content of draft-ahuang-netconf-notif-yang-04 has not been questioned. What has been question was that it updates RFC 5277. This should be changed in my opinion to updates RFC 8639 instead and introduction rephrased to describe that it augments RFC 8639 with the capability to model the XSD defined in https://datatracker.ietf.org/doc/html/rfc5277#section-4 in YANG for enabling JSON and CBOR encoding. Alternatively this could be expanded to a RFC8639bis which I do not recommended since this would defeat the purpose that this document should move forward quickly unless there is a very valid reason not to do so. Does that makes sense? How do we proceed after the adoption call?

Regarding the second point from Andy. Some background first. I believe that NETCONF notifications described in https://datatracker.ietf.org/doc/html/rfc5277#section-2.2.1 do not match the consistency statement described in https://datatracker.ietf.org/doc/html/draft-boucadair-nmop-rfc3535-20years-later-02#section-4.7. https://datatracker.ietf.org/doc/html/draft-tgraf-netconf-notif-sequencing is addressing this and consequently propagates this to RFC 8639 and RFC 8641 since they build on top of RFC 5277. The observation time described in https://datatracker.ietf.org/doc/html/draft-tgraf-netconf-yang-push-observation-time is being added in the ietf-subscribed-notifications defined in RFC 8639 since the timestamping is relevant to the subscription type, on-change vs- periodical.

I agree with Andy's concern. I suggest therefore that https://datatracker.ietf.org/doc/html/draft-tgraf-netconf-notif-sequencing needs to be updated to reflect the changes also in the XSD and NETCONF notifications version should be raised from version 1.0 to 2.0. Through capabilities described in RFC 9196 and YANG library in RFC 8525 a client can discover which netconf notification version is supported. This discovery will be described in step 0 in https://datatracker.ietf.org/doc/html/draft-netana-nmop-yang-message-broker-integration#section-3 as described by Andy at https://mailarchive.ietf.org/arch/msg/nmop/Dd_mMO8U4y3RSkNYZB6-phvxtwc/.  Does that makes sense?

Looking forward for feedback and comments to both points.

Best wish
Thomas

-----Original Message-----
From: netconf <[e-mail]<mailto:[e-mail]>> On Behalf Of Per Andersson
Sent: Tuesday, April 23, 2024 3:33 PM
To: Kent Watsen <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [netconf] Adoption call for notif-yang-04


Be aware: This is an external email.



On Mon, Apr 22, 2024 at 7:39 PM Kent Watsen <[e-mail]<mailto:[e-mail]>> wrote:
>
> BTW, I almost wonder why this isn’t an rfc5277-bis.

That is RFC 8639 Subscribed Notifications.

However the notification modelling isn't updated in that document.


--
Per

_______________________________________________
netconf mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/netconf