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

Two comments inline under <tp2>

From: Alex Huang Feng <alex.huang-feng@insa-lyon.fr>
Sent: 12 September 2022 09:49

Dear Tom,

Thanks for the feedback.
See comments inline

On 30 Aug 2022, at 12:17, tom petch <ietfc@btconnect.com<mailto: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.

<tp2>
Yes, but my question is what happens if the MUST is not obeyed.  Treat the message as invalid, process those that are in order,   .?  I think that you should spell it out.

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?

<tp2>
No I  got the reference wrong.  I meant you should add  an Informative  reference to RFC8340 Tree Diagrams in section 7.

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