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

On Sun, May 19, 2024 at 9:59 AM Andy Bierman <andy@yumaworks.com> wrote:

> 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.
>
>
My original suggestion for NETCONF support was to simply assign 5 SIDs in
the registry:

    SID    element
    -------------------------------------
       1    <hello>
       2    <rpc>
       3     <rpc-reply>
       4     <notification>
       5     <eventTime>

I don't see much difference between a 1MB <rpc-reply> and a 1MB
<notification> wrt/ network impact.
RFC 9254 covers all the child nodes. These are the only SIDs missing from
full binary NETCONF.

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