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

On Sun, May 19, 2024 at 2:10 AM <Thomas.Graf@swisscom.com> wrote:

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

There are no WG drafts that fully address the problem or the solution.
 I am curious about the end result of interoperable running code produced
by reading the RFCs.
This work does not exactly fit the usual design patterns.

There is a big difference between an OpenSource project and a standard.
The bar is much higher for a standard, since a specification is required
that is expected to allow
multiple independent interoperable implementations. Of Something.  Does
this work have such a solution path or not?
If so, what exactly are the deliverables needed to achieve this?

>
> Best wishes
>
> Thomas
>

Andy

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