Hello Nate, Thanks for your reply and the revised I-D.
See below for EV> about a remaining issue. I am trusting you and the co-authors to quickly address this issue and will therefore request the IETF Last Call on this document. Up to you, but when I suggested to replace some "SHALL" by "MUST" (for clarity as they are synonymous) I gave an example but was actually suggesting to s/SHALL/MUST/g (i.e., all occurrences). Really a matter of taste, feel free to ignore. Regards -éric From: Karstens, Nate <[email protected]> Date: Saturday, 13 June 2026 at 13:48 To: Eric Vyncke (evyncke) <[email protected]>; [email protected] <[email protected]> Cc: CARLOS JESUS BERNARDOS CANO <[email protected]>; Stuart Cheshire <[email protected]>; Mike McBride <[email protected]> Subject: RE: AD review of draft-ietf-intarea-multicast-application-port-06 Thanks, Éric! We updated the draft with v07 based on your comments. Individual replies are below, marked [NK]. Cheers, Nate From: Eric Vyncke (evyncke) <[email protected]> Sent: Monday, June 8, 2026 01:52 To: [email protected] Cc: CARLOS JESUS BERNARDOS CANO <[email protected]>; Karstens, Nate <[email protected]>; Stuart Cheshire <[email protected]>; Mike McBride <[email protected]> Subject: AD review of draft-ietf-intarea-multicast-application-port-06 # Éric Vyncke, INT AD, AD review for draft-ietf-intarea-multicast-application-port-06 CC @evyncke Thank you for the work put into this document. Please find below my AD review. As the responsible AD, I expect all the points below to be addressed, # Éric Vyncke, INT AD, AD review for draft-ietf-intarea-multicast-application-port-06 CC @evyncke Thank you for the work put into this document. Please find below my AD review. As the responsible AD, I expect all the points below to be addressed, either by a revised I-D, or an email reply. Of course, authors and WG can reject my points, but this needs to be justified. Once all the points are addressed, I will proceed with the publication process, i.e., IETF Last Call. Special thanks to Carlos Bernardos for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric Note: this AD reviews follows the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main<https://urldefense.com/v3/__https:/github.com/mnot/ietf-comments/tree/main__;!!EJc4YC3iFmQ!QrwHPIrM1CZt1bRiYPsF9U_pNmXpu-Yiz475BjeDrBRcNAOYicqhGXYI7t7GdIi_H05MUZTdZBShJ9HT$>, i.e., they can be processed by a tool to create github issues. ## Critical issues ### Updating shepherd's write-up As the Q9 was addressed in revision -06, the write-up should be updated. Q11 should also be updated to state that PS is required for interoperation between source and members. [NK] Will rely on Carlos to update. ### Abstract s/The document *proposes assigning* a UDP port/The document *assigns* a UDP port/, be assertive as it will be published as PS. [NK] Done ### Section 1 Please add informative references to ASM and SSM. [NK] Done Perhaps ? s/source address and destination multicast address /source *unicast* address and destination multicast address / ? [NK] Makes sense, done It is unclear (at least to me) what is `with a unicast port` in the last paragraph, is it a unicast post assigned to the application ? or ? Let's be clear. [NK] Done. If you are interested, Lorenzo’s original comment at IETF 122 can be seen at https://youtu.be/NkbWXK1I-74?si=pl0NbFnwHV-LFzbZ&t=2070 ### Section 6 Why not a MUST in `rules referencing the Multicast Application Port SHOULD also consider the destination multicast address` ? [NK] The RFC 2119 language for MUST is that it is an absolute requirement, which is not the case here. SHOULD seems more appropriate because “there may exist valid reasons in particular circumstances to ignore a particular item”. For example, a network administrator may want to block all traffic using the Multicast Application Port for some reason. Prohibiting them from doing so seemed outside the mandate of this document. EV> per https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ all "SHOULD" must have some guidance to implementers, i.e., EV> explaining when the SHOULD can be bypassed or what are the consequences of bypassing it. ### Section 7 What is meant by `ask if the Multicast Application Port may be used` ? I.e., to whom should the IANA ask the question ? [NK] Clarified that the applicant should be asked ## Non-critical / cosmetic issues Note: these points must also be addressed. ### Note about IPv4/IPv6 Suggest adding a simple note in the introduction stating that this technique applies both for IPv6 and IPv4. [NK] Done ### Section 2 s/the Multicast Application Port SHALL NOT be used/the Multicast Application Port *MUST** NOT be used/ while SHALL/MUST are equivalent per BCP14, I find "MUST" more obvious. It is a matter of taste, feel free to leave as it is. [NK] MUST seems fine, thanks! ________________________________ CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
