[core] Re: Coreconf Notifications

[Andy Bierman <[e-mail]>]

On Thu, Jul 18, 2024 at 10:35 AM <[e-mail]> wrote:

> Dear Andy,
>
>
>
>    - The notification message defined in RFC 5277 is a conceptual
>    container that has an eventTime leaf and this event part
>    - that is modeled in YANG as child nodes.
>
>
>
> I haven't found a normative statement in any document supporting that.
> Could you please point me.
>
>
>

Those words are not in the RFC.
However an XSD for the XML representation of the Onw-Way Message is quite
clear.



> On top what Alex already wrote, what puzzles me and dares for an
> explanation is that RFC 5277 is intended for Netconf
> https://datatracker.ietf.org/doc/html/rfc5277#section-1, has been
> specified prior to YANG, and has been intended in the previous netconf
> working group charter
> https://datatracker.ietf.org/doc/charter-ietf-netconf/19/ in section 5 to
> be declared obsolete once netconf working group specified its successor
> which is RFC 8639/8641 and a new notification structure.
>
>
>


The RFC 5277 message definition for XML needs to be adapted or changed for
different protocols.

NETCONF has only XML support.
RFCs that claim to define more than that for NETCONF do not exist yet.
RESTCONF has XML and JSON support.
NETCONF and RESTCONF both use or adapt the RFC 5277 message, based on the
XSD.
Notifications over HTTP that are not RESTCONF need their own solution.
Other protocols need their own solution.

 A fake module or a manual SID file could provide the 2 missing SIDs for
the notification and eventTime nodes.
The fake module name "ietf-restconf" only applies to RESTCONF JSON.
The RFC 5277 XSD has no module-name only a namespace URI.

IMO the WG is making this problem way too complicated.
A simple RFC with simple hacks is needed, so everybody uses the same
strings and SIDs.


Best wishes
>
> Thomas
>


Andy


>
>
> *From:* Andy Bierman <[e-mail]>
> *Sent:* Thursday, July 18, 2024 9:06 AM
> *To:* Alex Huang Feng <[e-mail]>
> *Cc:* [e-mail]; [e-mail]; Pierre Francois <
> [e-mail]>; Vivekananda Boudia <
> [e-mail]>; Graf Thomas, INI-NET-VNC-HCS <
> [e-mail]>; Benoit Claise <[e-mail]>
> *Subject:* Re: Coreconf Notifications
>
>
>
> *Be aware:* This is an external email.
>
>
>
>
>
>
>
> On Thu, Jul 18, 2024 at 8:56 AM Alex Huang Feng <
> [e-mail]> wrote:
>
> Dear authors and CORE WG,
>
>
>
> I have some questions regarding how YANG notifications are encoded in CBOR.
>
>
>
> I am co-authoring draft-ahuang-netconf-notif-yang-05 where we are defining
> how NETCONF notifications are encoded in XML, JSON and CBOR.
>
> This definition is not explicit in JSON (RFC7951).
>
>
>
> Reading the YANG-CBOR (RFC9254) specification, the notifications are
> encoded as a “container-like” instance. This is rather a different approach
> from XML (RFC7950) and JSON (RFC7951) which to my understanding a leaf
> “eventTime” needs to be present in the notification as defined in RFC5277.
>
> I am wondering why YANG-CBOR defined YANG notifications differently. I
> don’t follow this WG closely but would love to hear the reasons which led
> to the wording in RFC9254. (Or if more consistency with XML and JSON is
> expected)
>
>
>
> For CORECONF, reading
> https://datatracker.ietf.org/doc/html/draft-ietf-core-comi-17#name-notify-examples,
> the notifications are also defined without the leaf defined in RFC5277 but
> still references this RFC.
>
>
>
>
>
>
>
> YANG has the notification-stmt which only models the event part of the
> notification message.
>
> The notification message defined in RFC 5277 is a conceptual container
> that has an eventTime leaf and this event part
>
> that is modeled in YANG as child nodes.
>
>
>
> YANG-CBOR defines the mapping to the YANG notification-stmt, not any
> conceptual protocol messages
>
> that are not defined in YANG.
>
>
>
> Andy
>
>
>
>
>
>
>
>
>
> We plan to use CBOR encoding with YANG-Push (RFC8641) to reduce the size
> of the YANG-defined messages between the NETCONF server and client.
>
> In
> https://datatracker.ietf.org/doc/html/draft-ahuang-netconf-notif-yang-05#name-cbor-structure we
> define how we expect the CBOR message to be encoded.
>
> Having a similar approach to encode YANG notifications between JSON and
> CBOR ease the development of some open-source projects, such as the
> integration of YANG in the Kafka message broker.
>
> Here some references of such integration:
>
> -
> https://datatracker.ietf.org/doc/html/draft-ietf-nmop-yang-message-broker-integration-03
>
> -
> https://github.com/network-analytics/draft-daisy-kafka-yang-integration/blob/main/schema-registry-yangkit-integration-02.pdf
>
>
>
> Note also that we request a .sid file for YANG-SIDs for compressed CBOR
> messages in
> https://datatracker.ietf.org/doc/html/draft-ahuang-netconf-notif-yang-05#appendix-A
> .
>
>
>
> We will be onsite in Vancouver, so happy to have a live discussion
> regarding these encoding mismatches.
>
>
>
> I think the integration of YANG and CBOR into Kafka might also be of
> interest to the WG.
>
> Feel free to ping me back to have a discussion during the IETF week. We
> will also be present at the Hackathon Saturday and Sunday.
>
>
>
> Regards,
>
> Alex
>
>
>
>
>
>
>
>
>
>
>
>
>
>