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

[Andy Bierman <[e-mail]>]

On Sun, May 19, 2024 at 9:08 AM Andy Bierman <[e-mail]> wrote:

>
>
> On Sun, May 19, 2024 at 2:10 AM <[e-mail]> 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?
>
>
>
I am referring to the larger problem of YANG Push/Message Broker, but it is
not exactly clear
what this notif draft is supposed to solve wrt/ any existing standard
protocols.


>>
>> Best wishes
>>
>> Thomas
>>
>
> Andy
>


Andy


>
>
>>
>>
>> *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]> 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]> On Behalf Of Per Andersson
>> Sent: Tuesday, April 23, 2024 3:33 PM
>> To: Kent Watsen <[e-mail]>
>> Cc: [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]> 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]
>> https://www.ietf.org/mailman/listinfo/netconf
>>
>>