[core] Re: Coreconf Notifications

[[e-mail]]

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.

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.

Best wishes
Thomas

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]<mailto:[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