[netconf] Re: WGLC for udp-notif

[Alex Huang Feng <[e-mail]>]

Dear Qiufang,

Thanks for the review and feedback.

Changes have been proposed in the -19 iteration https://github.com/netconf-wg/udp-notif/blob/main/draft-ietf-netconf-udp-notif-19.txt

The rfcdiff: https://author-tools.ietf.org/diff?doc_1=draft-ietf-netconf-udp-notif-18&url_2=https://raw.githubusercontent.com/netconf-wg/udp-notif/refs/heads/main/draft-ietf-netconf-udp-notif-19.txt

See inline.

> On 11 Feb 2025, at 08:24, maqiufang (A) <maqiufang1=[e-mail]> wrote:
> 
> Hi, all,
> 
> I support the progress of this draft. I've reviewed -18 and below are some comments/nits that I believe should be addressed before the publication:
> 
> ---
> Sec.1 Introduction
> The document title is "UDP-based Transport for Configured Subscriptions", but I found the draft didn’t make it clear in the introduction section that the UDP-notif specified in the document is used for configured subscription. It also references NETCONF transport and RESTCONF transport RFCs, but maybe should be clear that these are transport specifications for dynamic subscription.
We added in the intro:
This document specifies a transport option for Configured
   Subscriptions as defined in Section 2.5 of [RFC8639] that leverages
   UDP.
> 
> ---
> Sec.2 
> This section might need better refinement. The first paragraph says "This section describes how the proposed mechanism can be controlled using subscription channels based on NETCONF or RESTCONF", but I think the rest part is kind of hand-waving. If there is nothing different from what has specified in 8639, perhaps remove this whole section for simplicity?
Based also on the comment from James, we have removed this section and moved the normative text to the "Design Overview” section.
Hope this way the doc is clearer.
> 
> ---
> Sec.3.1 The structure of the Notification Message is defined in Section 2.6 of [RFC8639] and a YANG model has been proposed in [I-D.ahuang-netconf-notif-yang].
> Maybe also reference RFC 5277 here. Please reference netconf-notif-envelope draft instead of the replaced one.
We have removed both references to I-D.ahuang-netconf-notif-yang and I-D.ietf-netconf-notification-messages to really focus on the UDP transport.
Question to the WG, is it interesting to reference netconf-notif-envelope draft? 

3.1. Design Overview
   *  The Notification Message is the encoded content that is
      transported by the publication stream.  The common encoding
      methods are listed in Section 3.2.  The structure of the
      notification message is defined in Section 2.6 of Subscribed
      Notifications [RFC8639].

> 
> ---
> Sec.3.2 Note that the main purpose of the Message ID is to reconstruct messages which are segmented using the segmentation option described in section Section 4.1.  (duplicate section)
Fixed
> 
> ---
> Sec.3.2 It seems that Message Publisher ID should be a term mentioned in the terminology section.
Yes, good point. Added.
> 
> ---
> Section 5  In the following, we discuss recommendations on congestion control, message size guidelines, reliability considerations and security considerations.
> Maybe give the reference to the section number in this sentence to be clearer.
We added: 
We discuss recommendations on congestion control in
   Section 5.1, message size guidelines in Section 5.2 and reliability
   considerations in Section 5.3.
> 
> ---
> Sec.5.1  s/Publisher/publisher/
Fixed.
> 
> ---
> Sec.7.2 
> The grouping "udp-notif-receiver-grouping" defines the necessary parameters to configure the transport defined in this document using the generic "udp-client-grouping" grouping from the "ietf-udp-client" module [I-D.ahuang-netconf-udp-client-server] and the "tls-client-grouping" defined in the "ietf-tls-client" module [I-D.ietf-netconf-tls-client-server].
> Note netconf-tls-client-server is already published as RFC 9645.
Fixed.
> 
> ---
> Sec.8.2  IANA is also requested to assign a two new URI from the IETF XML Registry [RFC3688].
> Remove “a”
Fixed.
> 
> ---
> Sec.8.3 This document also requests a new YANG module names in the YANG Module Names registry [RFC8342] with the following suggestions.
> s/names/name/
Fixed.
> 
> ---
> Sec.10 
> Please also provide the security consideration for the ietf-udp-notif-transport YANG module.
Added in -19.

Regards,
Alex
> 
> Best Regards,
> Qiufang
> 
> -----Original Message-----
> From: Per Andersson [mailto:[e-mail]] 
> Sent: Thursday, January 30, 2025 11:07 PM
> To: [e-mail]
> Subject: [netconf] WGLC for udp-notif
> 
> Hi!
> 
> This email begins a two-week WGLC on:
> 
> UDP-based Transport for Configured Subscriptions
> https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-18
> 
> Please take time to review this draft and post comments by February 13.  Favorable comments are especially welcomed.
> 
> None of the authors or contributors have declared IPR:
> 
> https://mailarchive.ietf.org/arch/msg/netconf/VQUz-x7mEWVmdxwG_ZZAbN-mlUk/
> 
> 
> --
> Per, co-chair
> 
> _______________________________________________
> netconf mailing list -- [e-mail] To unsubscribe send an email to [e-mail]
> _______________________________________________
> netconf mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]