Re: [netconf] Comments on draft-ietf-netconf-distributed-notif

[[e-mail]]

Hi Mahesh,

Section 3 of the document (https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distributed-notif#section-3) describes the motivation. Being able to recognize lost and corrupt YANG notification messages when multiple publisher process sharing the same transport session properties.

Section 8 (https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distributed-notif#section-8) describes the differences between draft-ietf-netconf-udp-notif and draft-ietf-netconf-https-notif.


  *   If this was transported over another transport, e.g. TCP/HTTP or QUIC, would they require a similar header?

If multiple publisher process sharing the same transport session properties, yes.


  *   If so, what would it look like.

Section 2 (https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distributed-notif#section-2) describes Observation Domain ID as a 32-bit identifier.

Observation Domain ID can also be part of the YANG notification messages header as describes in draft-ietf-netconf-distributed-notif Section 3 (https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distributed-notif#section-3)


  *   With this transport message header, do you still believe you are transport independent?

Yes. Because the Observation Domain ID can be either be implemented in the transport header or in the YANG notification messages header.


  *   How does the publisher know where to send the notification messages? If this configuration a part of yang push, maybe an example of how yang push needs to be configured would be nice.

Yes it is part of the YANG push configuration. If I understand you correctly, you would like to see an example YANG push subscription including with the transport session properties as well. Correct?

Best wishes
Thomas

From: netconf <[e-mail]> On Behalf Of Mahesh Jethanandani
Sent: Tuesday, March 22, 2022 11:00 AM
To: Netconf <[e-mail]>
Subject: [netconf] Comments on draft-ietf-netconf-distributed-notif

Hi Authors,

I promised in the NETCONF WG 113 meeting that I would provide comments on the draft. These comments were provided in the meeting, and I will expand on them here.

My first comments was on the transport. The authors have asserted that this draft is transport independent. The motivation section of the draft, Section 3, talks about Observation Domain ID in the transport message header of the YANG notification, and very specifically cite how the UDP transport draft supports this header. Two comments. If this was transported over another transport, e.g. TCP/HTTP or QUIC, would they require a similar header? If so, what would it look like. If not, why not? With this transport message header, do you still believe you are transport independent?

My second comment was around examples. The examples in the Appendix focus on establishing subscription, modify subscription, and subscription started. However, it was not clear how would a notification be setup between publisher and receiver. How does the publisher know where to send the notification messages? If this configuration a part of yang push, maybe an example of how yang push needs to be configured would be nice. Similarly, if UDP transport is used for transport, what needs to be configured to use UDP transport, including any DTLS configuration.

Thanks.

Mahesh Jethanandani (as contributor)