[netconf] Re: WGLC for udp-notif

[Benoit Claise <[e-mail]>]

Thanks you Alex and the authors.

That makes sense.
Will draft-ietf-netconf-udp-notif-19.txt posted, I'll now review the 
UDP-distributed-notif (somewhere next week)
However, I am afraid I will be missing the WGLC deadline of today.

Regards, Benoit



On 2/21/2025 10:31 AM, Alex Huang Feng wrote:
> Dear Med and Benoit,
>
> After discussing the private encoding option issue offline with the 
> authors, we agreed to remove this option.
>
> Diff of last commit: 
> https://author-tools.ietf.org/diff?url_1=https://raw.githubusercontent.com/netconf-wg/udp-notif/12f8e7085b7f54bc2ffd84c94274e52ec4b53b4f/draft-ietf-netconf-udp-notif-19.txt&url_2=https://raw.githubusercontent.com/netconf-wg/udp-notif/refs/heads/main/draft-ietf-netconf-udp-notif-19.txt 
> <https://author-tools.ietf.org/diff?url_1=https://raw.githubusercontent.com/netconf-wg/udp-notif/12f8e7085b7f54bc2ffd84c94274e52ec4b53b4f/draft-ietf-netconf-udp-notif-19.txt&url_2=https://raw.githubusercontent.com/netconf-wg/udp-notif/refs/heads/main/draft-ietf-netconf-udp-notif-19.txt>
>
> Cheers,
> Alex
>
>> On 17 Feb 2025, at 10:29, Alex Huang Feng 
>> <[e-mail]> wrote:
>>
>> Hi Med, and Benoit,
>>
>> @Benoit and @Med:
>> I have been discussing with the authors regarding the private 
>> encoding option.
>> The motivation of adding this option was to enable users to encode 
>> information in the UDP-Notif header for private use.
>> A use case is the encoding flavors as explained in -19 iteration, but 
>> an user may put internal references (URIs of a server, or any other 
>> info) that are needed for their collectors to correctly decode the 
>> message.
>> See this as simply "having an option for use by private 
>> encodings/uses of the protocol".
>> It's not more than that, an option that is reserved for private uses.
>>
>> @Med:
>> Thanks for the comments.
>> See inline for the rest of the points.
>>
>>> On 14 Feb 2025, at 14:17,[e-mail]:
>>>
>>> Hi Alex,
>>> Thanks for the follow-up.
>>> Please see inline.
>>> Cheers,
>>> Med
>>> *De :*Alex Huang Feng <[e-mail]>
>>> *Envoyé :*mardi 11 février 2025 11:57
>>> *À :*BOUCADAIR Mohamed INNOV/NET <[e-mail]>
>>> *Cc :*Per Andersson 
>>> <[e-mail]>;[e-mail];[e-mail]
>>> *Objet :*Re: [netconf] WGLC for udp-notif
>>> Dear Med, NETCONF WG,
>>> Thanks a lot for the (very) detailed review and proposals. They have 
>>> been very useful.
>>> I have been working on integrating these (and other suggestions from 
>>> the WGLC) into 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 
>>> <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>
>>> */[Med] The changes are in the good direction. I appreciate that you 
>>> added a new appendix to illustrate the use of the private encoding 
>>> option, but I’m still not comfortable with having this in a PS./*
>>> *//*
>>> Hoping this iteration addresses your concerns.
>>> See also inline.
>>>
>>>
>>>     On 31 Jan 2025, at 09:44,[e-mail]:
>>>     Hi all,
>>>
>>>     I support this effort. Many thanks to the authors for taking
>>>     care of this.
>>>
>>>     # Detailed Review
>>>
>>>     I think that there are still some places where the spec needs to
>>>     be updated. There is also room to simplify a bit and focus on
>>>     the core functions (e.g., remove the private encoding; that part
>>>     is underspecified anyway and don't see how this can be included
>>>     in a standard).
>>>
>>>     My detailed review, comments, and suggestions can be found at:
>>>     *
>>>     pdf:https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-netconf-udp-notif-18-rev%20Med.pdf
>>>     *
>>>     doc:https://github.com/boucadair/IETF-Drafts-Reviews/raw/refs/heads/master/2025/draft-ietf-netconf-udp-notif-18-rev%20Med.doc
>>>
>>>     # Options, Segmentation, and CC
>>>
>>>     The segmentation and congestion control are key features that
>>>     need some more work, IMO. The authors may look into the similar
>>>     work in that area (e.g., RFC9177 for both segments/CC, and the
>>>     FRAG option in the UDP option spec
>>>     (draft-ietf-tsvwg-udp-options-38#11.4)). I'm not saying that
>>>     those can be reused as such, but simply suggesting that you look
>>>     into those and grab whatever useful here. For example,
>>>      * 9177 has guards to protect the network form overloads due to
>>>     flying a large number of blocks/segments.
>>>      * UDP-option require the FRAG to be the first option (to
>>>     accommodate hw acceleration, etc.), while udp-notif requires the
>>>     options to be ordered (without any rationale/apparent benefit)
>>>
>>> This has been changed to only requiring the segmentation placed in 
>>> the first position.
>>> */[Med] This looks better. Thanks./*
>>> I have been discussing with the authors about the ordered options. 
>>> The main reason behind this was to prepare future allocations of 
>>> UDP-Notif options, so that implementations could already expect the 
>>> positioning of these options.
>>>
>>>
>>>     Also, the segmentation is discussed independent of the DTLS,
>>>     which I think requires some checks from the authors, especially
>>>     that DTLS requires records to fit within a single datagram (that
>>>     is, it does not handle fragmentation for application data).
>>>
>>> I added a sub-section in DTLS section:
>>> [RFC9147] states that DTLS message may be fragmented into multiple
>>> DTLS records.  A DTLS message carrying a UDP-Notif message SHOULD fit
>>> within a single datagram to avoid DTLS fragmentation.
>>> Implementations SHOULD account for DTLS overhead when determining the
>>> maximum UDP-Notif notification message size.
>>> */[Med] ACK/*
>>>
>>>
>>>
>>>     The document says that the seg num does not wrap around (while
>>>     mandating the initial value to be 0). It is unlikely to exceed
>>>     32 765 segments. Rather, I suggest to add a guard in the
>>>     security section to discard segments when they exceed a certain
>>>     number because this can be used as an abuse to require
>>>     computation resources to reassemble a large number of segments.
>>>     Knobs to control those should be supported.
>>>
>>> We added:
>>> A receiver collecting segmented UDP-Notif messages SHOULD have a
>>>  configurable parameter to discard segments when they exceed a certain
>>>  amount of segments.  The generation of too many segments by a
>>>  publisher can be used as an abuse to require computation resources
>>>  for reassembling large messages at the receiver.
>>> *//*
>>> */[Med] Thanks. I guess a parameter is missing to control that in 
>>> the YANG module./*
>> The YANG module is for configuring the publisher, not the receiver.
>>>
>>>
>>>     # Consistency with 8639
>>>
>>>     There is a need to be consistent with the transport reco in
>>>     RFC8639.For example, this part is not followed:
>>>
>>>     "A specification for a transport MUST identify any encodings
>>>     that are supported. If a configured subscription's transport
>>>     allows different encodings, the specification MUST identify the
>>>     default encoding."
>>>
>>>     I trust you will check that section again.
>>>
>>> This statement has been raised multiple times on the ML: 
>>> https://mailarchive.ietf.org/arch/msg/netconf/7tqFOjLnaKNKT2BHwFHco2gwbCY/
>>> So far, the consensus from the WG is to ignore this statement and 
>>> enable the discovery through other mechanisms: 
>>> https://www.rfc-editor.org/errata/eid6211
>>> *//*
>>> */[Med] We need to explicitly mention that we deviate from that MUST 
>>> and explain the rationale./*
>> How about the following? (added in Sec 3.3):
>>    Subscribed Notifications [RFC8639] states that a transport MUST
>>    identify a default encoding.  However, as per [Errata-6211],
>>    Subscribed Notifications does not require to define a default
>>    encoding.
>>>
>>>
>>>     # YANG
>>>
>>>     It is unfortunate that the version that is being last called
>>>     wasn't checked to be clean vs. yang validation.It not late to
>>>     fix those, though :-)
>>>
>>> Fixed :)
>>>
>>>
>>>     The YANG module includes a provision for managing keepalives,
>>>     but the use of these is not covered in the main spec.
>>>
>>> Keepalives are part of the tlsc:tls-client-grouping.
>>> *//*
>>> */[Med] That’s not a reason to import it here! You can disable that 
>>> part if there is no actual use in this context./*
>> Good point. We have removed the keep-alives-related leaves.
>>> *//*
>>>
>>>
>>>     Suggest to add parameter to control the timer/resources to store
>>>     fragments, rate-limit sending of segments, etc.
>>>
>>>
>>>     Aaah, please update the security section to cover YANG cons (see
>>>     the template
>>>     inhttps://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-22#name-security-considerations-sect)
>>>
>>> Added.
>>> */[Med] Thanks. 8407bis does not need to be listed as normative. The 
>>> same applies for/*RFC6242, RFC8446. Please double check.
>> Thanks for the pointers !
>> Fixed.
>>
>> Cheers,
>> Alex
>>
>>> Cheers,
>>> Alex
>>>
>>>
>>>
>>>     Also, included some proposals to better structure the various
>>>     registries.
>>>
>>>     Hope this is useful.
>>>
>>>     Cheers,
>>>     Med
>>>
>>>
>>>         -----Message d'origine-----
>>>         De : Per Andersson <[e-mail]>
>>>         Envoyé : jeudi 30 janvier 2025 16:07
>>>         À :[e-mail]
>>>         Objet : [netconf] WGLC for udp-notif
>>>
>>>
>>>         Hi!
>>>
>>>         This email begins a two-week WGLC on:
>>>
>>>         UDP-based Transport for Configured Subscriptions
>>>
>>>         Please take time to review this draft and post comments by
>>>         February 13.  Favorable comments are especially welcomed.
>>>
>>>     ____________________________________________________________________________________________________________
>>>     Ce message et ses pieces jointes peuvent contenir des
>>>     informations confidentielles ou privilegiees et ne doivent donc
>>>     pas etre diffuses, exploites ou copies sans autorisation. Si
>>>     vous avez recu ce message par erreur, veuillez le signaler
>>>     a l'expediteur et le detruire ainsi que les pieces jointes. Les
>>>     messages electroniques etant susceptibles d'alteration,
>>>     Orange decline toute responsabilite si ce message a ete altere,
>>>     deforme ou falsifie. Merci.
>>>
>>>     This message and its attachments may contain confidential or
>>>     privileged information that may be protected by law;
>>>     they should not be distributed, used or copied without
>>>     authorisation.
>>>     If you have received this email in error, please notify the
>>>     sender and delete this message and its attachments.
>>>     As emails may be altered, Orange is not liable for messages that
>>>     have been modified, changed or falsified.
>>>     Thank you.
>>>
>>>     _______________________________________________
>>>     netconf mailing list [e-mail]
>>>     To unsubscribe send an email [e-mail]
>>>
>>> ____________________________________________________________________________________________________________
>>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>
>>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>>> they should not be distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>>> Thank you.
>