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

Hi,

On Sun, May 19, 2024 at 8:59 AM Rob Wilton (rwilton) <rwilton@cisco.com>
wrote:

> I’m trying to implement YANG Push with a JSON encoding of the notifications, I agree that they are underspecified.
>
>
https://datatracker.ietf.org/doc/html/rfc8040#section-6.4

The JSON encoding of the RFC 5277 'notification' element is clearly defined
for RESTCONF.

There is actually no need for a 'notification' structure at all.
One problem this draft claims to solve (validation) is not actually
possible in YANG.
The other one (CBOR encoding) could easily be solved by asking IANA for 2
SID assignments.

Andy

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: *Thomas.Graf@swisscom.com <Thomas.Graf@swisscom.com>
> *Date: *Sunday, 19 May 2024 at 10:10
> *To: *andy@yumaworks.com <andy@yumaworks.com>
> *Cc: *netconf@ietf.org <netconf@ietf.org>, pierre.francois@insa-lyon.fr <
> pierre.francois@insa-lyon.fr>
> *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 <andy@yumaworks.com>
> *Sent:* Friday, May 10, 2024 7:44 PM
> *To:* Graf Thomas, INI-NET-VNC-HCS <Thomas.Graf@swisscom.com>
> *Cc:* per.ietf@ionio.se; kent+ietf@watsen.net;
> mohamed.boucadair@orange.com; netconf@ietf.org;
> alex.huang-feng@insa-lyon.fr; benoit.claise@huawei.com;
> pierre.francois@insa-lyon.fr
> *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 <Thomas.Graf@swisscom.com> 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 <netconf-bounces@ietf.org> On Behalf Of Per Andersson
> Sent: Tuesday, April 23, 2024 3:33 PM
> To: Kent Watsen <kent+ietf@watsen.net>
> Cc: netconf@ietf.org
> 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 <kent+ietf@watsen.net> 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
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>