[core] Re: Coreconf Notifications

[[e-mail]]

Dear Andy,


  *   I have implemented notifications in XML, JSON, and CBOR with no problems adapting the XSD in RFC 5277.

The worry is on "adapting". I prefer to have normative machine readable semantics describing that to ensure interoperability.


  *   I am strongly opposed to declaring RFC 5277 obsolete.

I pointed out during the core working group session that the netconf working group has in its charter 19 the objection described to obsolete RFC 5277 with the introduction of RFC 8639/8641.

https://datatracker.ietf.org/doc/charter-ietf-netconf/19/

Provide a set of documents enabling advanced notification/subscription capabilities, which gracefully co-exist with deployments of NETCONF Event Notification (RFC 5277<https://datatracker.ietf.org/doc/rfc5277/>) The new capabilities include transport independence and multiple dynamic and configured subscriptions in a single transport session. RFC 5277<https://datatracker.ietf.org/doc/rfc5277/> will be obsoleted in parallel with the publication of the new document set. The following specifications will be published:
- A protocol-independent notification framework, explaining the concepts of subscriptions, filters, subscription state notifications, replay, etc. and defining the associated YANG data model, RPCs, etc.
- Definition of notifications sent over NETCONF and HTTP. Examples for the encoding of YANG notifications in XML and JSON will be given and considerations for parallel support and implementation compatibility with RFC 5277<https://datatracker.ietf.org/doc/rfc5277/> will be included.
- Definition of notifications sent over RESTCONF and HTTP2 and of how YANG notifications are encoded in XML and JSON, including specifics of call-home and heartbeat for subscriptions.
- The subscription and push mechanism for YANG datastores allowing subscriber applications to request updates from a YANG datastore.
- Definition of transport agnostic notification headers and of a mechanism for bundling multiple YANG notifications into a single message.

We are proposing with https://datatracker.ietf.org/doc/html/draft-ahuang-netconf-notif-yang to define the transport agnostic notification header as mentioned in the last line of section 5 of charter 19.

I believe this is also in line what is proposed in netmod with https://datatracker.ietf.org/meeting/120/materials/slides-120-netmod-9-rfc7950bis-and-friends-01.pdf. Separating the YANG definition with the encoding.

I agree that it is to early to obsolete RFC 5277, however I worry with new documents with new implementations referencing RFC 5277 that we can't make the transition.

Best wishes
Thomas

From: Andy Bierman <[e-mail]>
Sent: Wednesday, July 24, 2024 11:53 AM
To: Alex Huang Feng <[e-mail]>
Cc: Carsten Bormann <[e-mail]>; [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: [core] Coreconf Notifications


Be aware: This is an external email.




On Wed, Jul 24, 2024 at 11:25 AM Alex Huang Feng <[e-mail]<mailto:[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]<mailto:[e-mail]>> wrote:

Hi Alex

On 2024-07-20, at 00:37, Alex Huang Feng <[e-mail]<mailto:[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