[core] Re: Coreconf Notifications

[Andy Bierman <[e-mail]>]

On Wed, Jul 24, 2024 at 11:25 AM Alex Huang Feng <
[e-mail]> wrote:

> Dear Carsten,
>
> My apologies, checking again, you are right, tags are needed for RFC9254.
>
> What I want to raise (and discuss) in this thread is NOT how the datetime
> specified in the leaf “eventTime” is encoded in CBOR.
> I agree with Carsten that draft-bormann-cbor-yang-standin-00 can be used
> in draft-ahuang-netconf-notif-yang for better encoding the datetime.
>
> As I said on the mic during the WG meeting, there is a gap on how YANG
> notifications are currently encoded in the different YANG encodings (XML,
> JSON, CBOR).
> Having a common structure for such notifications is beneficial to YANG
> tooling (such as the integration of YANG into the Kafka Schema registry
> https://github.com/network-analytics/draft-daisy-kafka-yang-integration/blob/main/schema-registry-yangkit-integration-03.pdf
> )
>
> What I am referring to as a structure is the metadata that needs to be
> present in the notification header.
> The current understanding at NETCONF WG is that the notification header
> MUST have a eventTime leaf, as specified in RFC5277.
> RFC5277 was dedicated to XML, but YANG notifications have been generalised
> with YANG-Push [RFC8641].
>
>
I have implemented notifications in XML, JSON, and CBOR with no problems
adapting the XSD in RFC 5277.
The XSD describes an XML element but it is easy to construct this pattern
in JSON or CBOR.

RFC 5277 is widely deployed and in constant use.
RFC 6241, 8639, 8641 and others have normative references to this RFC.
I am strongly opposed to declaring RFC 5277 obsolete.


Andy

The current understanding is that in XML, a notification is encoded as
> follows:
>
> <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
>     <eventTime>2007-07-08T00:04:00Z</eventTime>       <— eventTime present
>     <event xmlns="http://example.com/event/1.0">
>         <eventClass>fault</eventClass>
>         <reportingEntity>
>             <card>ATM1</card>
>         </reportingEntity>
>         <severity>minor</severity>
>     </event>
> </notification>
>
> JSON as:
>
> {
>     "ietf-notification:notification": {
>         "eventTime": "2023-02-10T08:00:11.22Z”,     <—eventTime present
>         "yang-defining-notif:event": {
>             "eventClass": "fault",
>             "reportingEntity": {
>                 "card": "ATM1"
>             },
>             "severity": "minor"
>         }
>     }
> }
>
> And CBOR (diag-notation) I would expect:
> {
>     "ietf-notification:notification": {
>         "eventTime": "2023-02-10T08:00:11.22Z”,    <— eventTime present
>         "yang-defining-notif:event": {
>             "eventClass": "fault",
>             "reportingEntity": {
>                 "card": "ATM1"
>             },
>             "severity": "minor"
>         }
>     }
> }
>
> That is what we are trying to solve with
> https://datatracker.ietf.org/doc/html/draft-ahuang-netconf-notif-yang-05;
> having a common schema for all the YANG notifications and having a YANG
> module defining such structure.
>
> That is why I was suggesting to the authors of draft-ietf-core-comi-18 to
> use this draft as reference rather than RFC5277 (as Thomas Graf was saying,
> RFC5277 is expected to be obsoleted)
>
> On a second note, I’d be happy to hear any feedback from the CORE WG
> whether updating RFC9254 is the way to go to solve this issue with CBOR
> notifications in
> https://datatracker.ietf.org/doc/html/draft-ahuang-netconf-notif-yang-05.
>
> Cheers,
> Alex
>
> On 20 Jul 2024, at 08:42, Carsten Bormann <[e-mail]> wrote:
>
> Hi Alex
>
> On 2024-07-20, at 00:37, Alex Huang Feng <[e-mail]>
> wrote:
>
>
> Thanks for the pointers, will check out this draft. My text does not state
> that the timestamp needs to be encoded as text-encoded date-time.
>
>
> I would expect that you would want to encode these using standard YANG
> means, and (without YANG-CBOR with stand-in tags) that would be the RFC
> 3339 date-times used in RFC 6991.
> (Which resolution do you need in practice for eventtime, by the way?)
>
>
> Are you suggesting that the draft should state the usage of tags for
> date-times? For implementations that does not support tags, isn’t it
> contra-productive?
>
>
> You cannot do YANG-CBOR without CBOR tags, so I don’t think there is an
> actual problem.
>
> By the way, you may want to look at the CoRE telemetry spec [1].
> This is six years old (we just didn’t have the RFCs in place for YANG-CBOR
> and YANG SID at the time, so the draft was a bit premature), but it solves
> many of the problems being discussed right now.
> (Henk will be at the Hackathon, so please talk to him about that.)
>
> Grüße, Carsten
>
> [1]:
> https://datatracker.ietf.org/doc/html/draft-birkholz-yang-core-telemetry-01
>
>
>