Re: [netconf] I-D Action: draft-ietf-netconf-udp-notif-07.txt

Dear Tom,

Thanks for the feedback.
See comments inline

> On 30 Aug 2022, at 12:17, tom petch <ietfc@btconnect.com> wrote:
> 
> From: netconf <netconf-bounces@ietf.org <mailto:netconf-bounces@ietf.org>> on behalf of internet-drafts@ietf.org <mailto:internet-drafts@ietf.org> <internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>
> Sent: 11 July 2022 13:06
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Network Configuration WG of the IETF.
> 
>        Title           : UDP-based Transport for Configured Subscriptions
>        Authors         : Guangying Zheng
>                          Tianran Zhou
>                          Thomas Graf
>                          Pierre Francois
>                          Alex Huang Feng
>                          Paolo Lucente
>  Filename        : draft-ietf-netconf-udp-notif-07.txt
>  Pages           : 24
>  Date            : 2022-07-11
> 
> <tp>
> There are a number of tweaks that could benefit this I-D
> 
> Requirements Language is out of date
Will be updated in the upcoming draft.

> s.4 Options MUST be ordered ..
> And if they are not?
Ordered options allow to optimise the collector, notably for reassembly of the UDP-notif segmented messages. Together with the proposed option 1 for segmentation allows the collector not needing to parse the other options to know if a message is segmented.

> 
> prefix un
> I think this a poor choice.  This I-D is one of a family which suggests the prefix should have a common pattern for the family.  Since the base spec uses 'sn' (unfortunately but now a given), then I would use 
> sn...
> with something to indicate udp
We don’t have a preference on the prefix. 
We suggest to remain consistent with HTTPS-notif YANG module and use ietf-subscribed-notif-receivers. We are open to suggestions.

> 
> Simplified BSD License
> out of date, should be Revised
Will be changed in the upcoming draft.

> ip-address
> this is the format with a zone; is that intended?
If the group prefers ip-address-no-zone, we are fine with it.

> IANA Considerations
> You are asking for three actions, easier for IANA and everyone else as three sections, 9.1 9.2 9.3
Changed for the next draft.

> As RFC8126 says, the structure of the IANA Registry is registries under groups.  You should use this terminology.   A new group name should be chosen such that users can find it.  TLS get this right; most IETF WG get this wrong making it a nightmare to try and find a registry.
> 
> This also applies to a lesser extent to registry names.  Thus a registry about netconf notifications in a group that is clearly netconf might well start with notifications followed by a qualifier thereof.
If the NETCONF WG decides to do that, we will follow.

> And this logic could also benefit the module name.

> You import tls-client; must be a Normative Reference; ditto 6991, core-yang-cbor while dtls13  I cannot see as Informative.
Sorry about that. It is corrected.

> RFC8040 Tree Diagrams needs adding.
Do you mean showing all the levels in section 7?

> Tom Petch 
> _______________________________________________
> netconf mailing list
> netconf@ietf.org <mailto:netconf@ietf.org>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>