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

[Pierre Francois <[e-mail]>]

Tom,

We'll propose something on the behaviour when order is not respected.
ok for the reference to RFC8340.

Cheers,

Pierre.

Le mer. 14 sept. 2022 à 12:42, tom petch <[e-mail]> a écrit :

> Two comments inline under <tp2>
>
> From: Alex Huang Feng <[e-mail]>
> Sent: 12 September 2022 09:49
>
> Dear Tom,
>
> Thanks for the feedback.
> See comments inline
>
> On 30 Aug 2022, at 12:17, tom petch <[e-mail]<mailto:
> [e-mail]>> wrote:
>
> From: netconf <[e-mail]<mailto:[e-mail]>>
> on behalf of [e-mail]<mailto:[e-mail]> <
> [e-mail]<mailto:[e-mail]>>
> 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
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/netconf
>
>
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>