[netconf] Re: WGLC for udp-notif

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

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

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] <mailto:[e-mail]> wrote:
>> 
>> Hi Alex,
>>  
>> Thanks for the follow-up.
>>  
>> Please see inline.
>>  
>> Cheers,
>> Med
>>  
>> De : Alex Huang Feng <[e-mail] <mailto:[e-mail]>> 
>> Envoyé : mardi 11 février 2025 11:57
>> À : BOUCADAIR Mohamed INNOV/NET <[e-mail] <mailto:[e-mail]>>
>> Cc : Per Andersson <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[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
>>  
>> [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] <mailto:[e-mail]> wrote:
>>  
>> 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 in https://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] <mailto:[e-mail]>>
>> Envoyé : jeudi 30 janvier 2025 16:07
>> À : [e-mail] <mailto:[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] <mailto:[e-mail]>
>> To unsubscribe send an email to [e-mail] <mailto:[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.