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

[Mahesh Jethanandani <[e-mail]>]

Hi Thomas,

Thanks for your responses. Please see inline.

> On Mar 22, 2022, at 2:13 PM, <[e-mail]> <[e-mail]> wrote:
> 
> Hi Mahesh,
>  
> Section 3 of the document (https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distributed-notif#section-3 <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 <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 <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 <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distributed-notif#section-3>)

[mj] My first observation is that UDP transport header format for that you describe in Section 3.2 of draft-ietf-netconf-udp-notif is more than just a 32-bit field that describes the Observation Domain ID. Most of the other fields are there to support the transport, i.e. UDP in this case. You seem to be suggesting that for TCP/HTTP  (and maybe for QUIC also), only the 32-bit field is needed between the transport layer and the notification messages. Is that the case? And does the following figure capture your point?



>  
> 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.

[mj] What is your recommendation? If you believe the Observation Domain ID should be part of the message header, then your message header is different for different transports. If your recommendation is that it should be part of the notification, then you need to modify the message header in the UDP-Notif draft to move it out of the Message Header and show it as part of Notif Message.

>  
> 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?

[mj] That is correct, and preferably an example for each type of transport supported.

Thanks.

>  
> 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)