Minutes interim-2024-netconf-02: Thu 13:00
minutes-interim-2024-netconf-02-202409191300-01

NETCONF WG Interim Meeting 2024-09-19

Agenda: to discuss how to support the requirements behind notif-yang and
other documents wishing to extend the RFC5277 header.

Kent Watsen (as co-chair): Data being added is to make the notification
data more useful, for closed loop automation etc
How to do this is BC way with existing clients etc.

Alex Huang Feng (presenting slides on YANG-Push notification header
definition, related document is draft-ahuang-netconf-notif-yang)
Make hdr extensible and some YANG-Push related work
Goal is for collector to be able validate a notif msg before storing it
in a TSDB. To validate msg, collector needs YANG modules.
Messages can be XML,JSON, CBOR etc.
Issues from RFC8641:
YANG module not in notification
No normative text defining the HDR

Because of RFC5277, header can be validated if in XML. Issue for JSON
and CBOR encodings.
Related documents to this work RFC8641 (YANG-Push), RFC8639 (sibscribed
notification) etc FIXME add others from slide 5? Or ignore.

RFC7951 (YANG-JSON) doesn’t explicitly cover notifications.
Same for RFC9254 (YANG-CBOR).
And header should be extensible (slide 10)

Kent Watsen: looking at slide 10, is the scope limited to subscribed
notification or does it include RFC5277 also?
Alex Huang: due to YANG-Push architecture which based off
subscribed-notifications which builds on top of RFC5277. So we need to
update 5277. Solution which will be presented first addresses this in
backwards compatible way and secondly it can be used to extend RFC5277
header.

Ahmed Elhassany: YANG notifications are descrribed in RFC7950. Are you
trying to fix only notifications in YANG-Push or all notifications in
YANG?
Alex Huang: All notifications in YANG
Kent Watsen: this question is related to scope question I asked earlier.
I was hoping it’d be limited to configured subscriptions but Alex has
mentoned it is related to dynamic subscriptions also.
Alex Huang: the notification message itself doesn’t change between
configured and dynamic
Kent Watsen: the reason I was asking this question is because of impact
on legacy clients
Thomas Graf: wrt legacy clients we have have slides on this topic

Alex Huang (continuing presentation on the proposal in
draft-ahuang-netconf-notif-yang on slide 11):
Use normative text on how messages need to be encoded
Definition of the notification structure in YANG.
RESTCONF out of scope
No header extension

Robert Wilton: on the backwards compatibility, is there anythng else?
Thomas Graf: on the document just presented, there is no change. So the
impact on clients is none for this document, but applies to the
extension.
Robert Wilton: yes we need the ability to extend, so use of structure is
nice.
Benoit Claise: it would be great to have YANG tooling validation.
Ahmed Elhassany: have you used any of the existing tools like libyang or
pyang?
Alex Huang: not yet
Ahmed Elhassany: a structure is encoded as anydata, so my udnerstanding
is that it’ll be subtree, not like the way it’s shown on slide 13.
Andy Bierman: I have brought up this point many times, the proposed
structure is only for 1 leaf node eventTime. I believe Rob has already
proposed a solution: a new structure for the extension header. I’d
rather see 1 document for a new extension header as opposed to multiple
documents. RFC5277 is done.
Ahmed Elhassany: is this docuemnt enough for validation
Andy Bierman: no, there is only 1 leaf in there
Alex Huang: YANG-Push is defined via YANG so with this structure for
5277 header, yes we can, can’t we?
Andy Bierman: it will validate just for the new notification structure.
Unless you make another structure with all the leaf nodes.
Alex Huang: you’re saying there’s no solution with YANG?
Alex Bierman: if you’re trying to validate a notification message, then
no you can’t. New notification header doesn’t have to follow RFC5277.
Why have all these documents instead of 1?
Alex Huang: Because YANG-Push is built on top of RFC5277.
Kent Watsen: it is planned that the multiple documents will be brought
in together into 1 document.
Andy Bierman: I agree with previous suggestion: show me the yanglint
example which shows that this works. On slide 4 , YANG can’t do the part
in yellow.
Robert Wilton: can we bypass RC5277 with a new structure? Would that be
a cleaner path for extension and validation etc. What might not be
addressed is RFC5277 notifications over JSON.
Alex Huang: if we remove the YANG model and just add the normative text,
is that good enough for YANG-Push?
Andy Bierman: I think you should define a new header. Combine these docs
in 1.
Alex Huang: I agree with you for the new extension hdr,but for YANG-Push
how do we solve this gap?
Andy Bierman: I understand what you’re saying, things are working fine.

Alex Huang: yes for XML but not for CBOR and JSON.
Andy Bierman: then write a new draft which is unrelated to RFC5277, this
is specific to CBOR and JSON.
Per Anderson: on the slide with the yellow, is it because the data is
anydata that it can’t be validated?
Andy Bierman: according to RFC5277, after eventTime we have an abstract
element (any namespace). That’s how XSD works. YANG doesn’t have the
ability to have an unnamed element in there.
Ahmed Elhassany: can we split this into 2 problems since we’re going
into circles. There is a gap for CBOR and JSON (undefined) and there is
a proposal for this. And we want ability to extend to have extra fields.

Alex Huang: In UDP-notif draft, and CBOR/JSON encodings there is no
definition on how this notification should look like.
Ahmed Elhassany: I agree that some implementations seem to be making
assumptions for CBOR/JSON. In libyang they assume evenTime is there
Andy Bierman: RFC8040/RESTCONF doesn’t support JSON. YANG_Push isn’t a
protocol, it’s a mechanism.
Ahmed Elhassany: how can I validate a notification mesage in JSON (the
one on slide 4 for example)
Andy Bierman: as we’ve said before, YANG has no ability to validate the
part in yellow. It’s not one in 1 YANG validation step.
Ahmed Elhassany: to me that confirms there is a gap, because how to do
validation isn’t defined in any IETF RFC/document.
Alex Huang: I agree
Andy Bierman: the part which seems interesting to me is the draft from
Thomas Graf and us moving on to a new header. That’s new work.
Benoit Claise: whether one step or not, we need to validate. We can’t
pollute TSDB contents.
Andy Bierman: having this new tiny structure which will be augmented in
different ways, I don’t think that helps interop.
Benoit Claise: the validation part seemed to have been obvious to you,
but not to others
Andy Bierman: I don’t care if YANG-Push uses existing RFC5277 header, it
could use new header. Been waiting for a SID file for 4 years.
Kent Watsen: to me the main requirement is the ability to create SID
files for notifications.
Andy Bierman: WG chairs, please make this an official mandate for
NETCONF. I’ve discussed this with Carsten why isn’t supporting YANG-Push
with CBOR “official work”?
Kent Watsen: that is the unstated requirement we’re trying to address in
this interim. And how to extend the headers with new fields such as
observation time. I fully support that work. The discussion should be
how to do opt-in for the new header (legacy clients should only receive
existing HDR).
Thomas Graf: Alex tried to explain the problem in slides 8/9, can we
discuss whether it’s a valid issue?
Dan Voyer: slide 4 describes the problem. Andy said that we can’t
validate the yellow. Isn’t that the problem statement we should be
tackling?
Kent Watsen: I am not so sure this is the problem. That header is on top
of other headers (e…g TCP and iP), are we going to validate those
headers too, no. In my mind this HDR with eventTime is like the
transport. It’s unfortunate the way RFC5277 defined the header as meta
data. I’d suggest an ubder notification which can support all
transports. So I don’t think the problem is that we can’t validate the
RFC5277 hdr. Each “transport” should validate its header.
Dan Voyer: no alignment on the problem statement
Alex Huang: does the WG think that the validation is an issue we should
tackle or hsould we just go to the next (extensible) notification
header?
Thomas Graf: what worries me, and Ahmed said it nicely, is that
implementors “found a way” around this problem. We could end up with
different implementations, which would make non-interoperable solutions.
I think the validation is worth solving.
Robert Wilton: I think we want extra fields in there. Define a new
header (sys name etc), and then no need to go back and fix 5277
validation. Config on devices to enable use of new notifications hdr.
Thomas Graf: why not use existing HDR.
Robert Wilton: I don’t think we can add fields as peers to eventTime.
Thomas Graf: my proposal is (looking at slide 17) to add the data we
need in the push-update, not at the top level.
Robert Wilton: you’d need to do that to push-update, push-update-change
etc
Benoit Claise: on slide 5, do we start from scratch?
Robert Wilton: we’d update RFC8639, and not update RFC5277
Andy Bierman: you’d just need a new leaf in establish-subscriptions (or
configured) to get the new header to do opt-in. No need to touch
RFC5277. I am agreeing with what was just said.
Holger Keller: supporting the idea of new HDR. I had some concerns but
maybe Andy addressed those. In CBOR the sysname can’t be encoded.
Alex Huang: I don’t want headers defined in transport documents (e.g.
http and UDP-notif), want this in application layer.
Kent Watsen: on the idea of uber-notification: YANG module for a
notification which could contain all the new headers and could be
augmented. Clients would need to opt-in. It would be easy to validate
(in whatever number of steps needed).
Ahmed Elhassany: we should define a new header. We should have a
definition for all messages, based off YANG schema, which can be sent
(whatever the encoding).
Thomas Graf: if we don’t fix validation of RFC5277 hdr we need a new hdr

Alex Huang: should we define a common way for all encodings
Robert Wilton: if we use YANG we have a common way but we probbaly need
encoding-specific text
Ahmed Elhassany: it should be just YANG. Encoding will be in the spec
for the encoding format. I would stay away from structures because not
widely used.
Robert Wilton: need some text for binding at top level. If you look at
RFC8040, there is some text stating how to encode a notification in
RESTCONF.
Alex Huang: I agree with Rob that some text is needed.
Thomas Graf: Kent, would the uber-notification replace the notification
of RFC5277.
Kent Watsen: the uber-notification would be what’s used e.g. SSE in
RFC8040. It’d have all the extra headers. I don’t see a problem with the
data at the top-level.
Dan Voyer: still no consensus, should we have a poll?
Kent Watsen: Per, can you start a poll?
Dan Voyer: maybe with 15 people, not enough. We wait for Dublin?
Thomas Graf: go to slides 8 and 9, are we agreeing with this?
Alex Huang: I would phrase the question as “whether the notification is
under-defined” (even if we ignore CBOR’s SIDs)?
Per Andersson: it seems apparent to everyone that we need a new
definition
Kent Watsen: please consider at uber-notification: a YANG module which
defines an ubder-notification statement. The contents would be set
number of hdr fields, event time, sys name etc, and also anydata which
would be able to convey the notificiation payload.
Robert Wilton: is it using RFC5277?
Kent Watsen: yes, you just discard the eventTime n RFC5277 header.
Benoit Claise: so you’d have eventTime twice.
Kent Watsen: yes we discard the first one.
Benoit Claise: why do that instead of something new?
Robert Wilton: so you’re adding a shim layer?
Kent Watsen: that’s the idea
Ahmed Elhassany: I like the ubder-notification but I don’t think we need
backwards compatibility with RFC5277
Per Andersson (as participant): it’d be better to have new hdr. How does
a server handle old and new clients, it has to be per-subscription (not
global).
Alex Huang: I agree we should replace RFC5277 as opposed to adding to.
We can use opt-in as suggested.
Thomas Graf: have a new poll to see whether we build on top of RFC5277
hdr or we replace it?
Benoit Claise: very good question. If I have a network, I’ll want to use
the same hdr everywhere.
Alex Huang: RFC5277 is tightly coupled with XML, replacing that hdr will
help for other encodings.
Per Andersson (as co-chair): agreement is new header. How do we do
opt-in?
Kent Watsen: at subscription time (new data in establish-subscriptions
or in the configured subscriptions). We don’t touch the other stuff.
Alex Huang: it would be extensions to YANG-Push and subscribed
notifications.
Per Andersson (as participant): I agree we should have it per
subscription.
Robert Wilton: have it global too for cases where everyone wants that.
Robert Wilton: for configured subscriptions: per receiver or per
subscription?
Holger Keller: I would prefer a global knob e.g. per device. And having
somethign per subscription which can override that.
Ahmed Elhassany: for dynamic subscriptions, there is negotiation. For
consifured subscriptions, just assume that the config is correct.
Thomas Graf: new poll for whether there is a gap in RFC8639 and RFC8641.

Benoit Claise: is your question whether we start from scratch?
Thomas Graf: attendees were clear that we replace RFC5277 header
Benoit Claise and Rob Wilton: not sure how to answer this one
Kent Watsen: don’t think changes should be made to RFC8639. We may need
a new RFC with mappings.
Ahmed Elhassany: not sure, because current problems are encoding related

Thomas Graf: to clarify, sections 1.4 and 2.6 of RFC8639 refer to
RFC5277 header. I think we can update this hdr optional and make this
hdr optonal.
Holger Keller: The problem isn’t encoding related anymore
Alex Huang: I am not sure since we need to define what is done for these
encodings. I agree it should be YANG based solution. But we have to
handle CBOR and JSON.
Thomas Graf: RFC7951 would be updated then?
Alex Huang: similar to RFC8639 changes, where can opt in for the new
notification hdr
Robert Wilton: note that the updates tag in RFCs doesn’t have a
well-defined definition :-)
Kent Watsen: do we need a follow-up interim before Dublin, any thoughts?

Benoit Claise: we had clarifications but we need to do some homework
Robert Wilton: I think we should write the text and then figure out the
dependencies
Robert Wilton: because of time restrictions, if the new proposal/text
isn’t ready relatively soon, discussing in Dublin makes sense
Kent Watsen: this concludes the interim, thank you everyone.