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

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
>