Hi Tom and Gorry, Thank you for your approvals. They have been noted on the AUTH48 status page: https://www.rfc-editor.org/auth48/rfc9869
FYI - We made one minor editorial change to reflect the terminology from RFC-to-be 9868 (capitalized “option”). Old: When the remote endpoint advertises a UDP Maximum Datagram Size (MDS) option (see Section 11.5 of [RFC9868]), this value MAY be used as a hint to initialize this search to increase the PLPMTU. Current: When the remote endpoint advertises a UDP Maximum Datagram Size (MDS) Option (see Section 11.5 of [RFC9868]), this value MAY be used as a hint to initialize this search to increase the PLPMTU. The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9869.xml https://www.rfc-editor.org/authors/rfc9869.txt https://www.rfc-editor.org/authors/rfc9869.html https://www.rfc-editor.org/authors/rfc9869.pdf The relevant diff files have been posted here: https://www.rfc-editor.org/authors/rfc9869-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9869-auth48diff.html (AUTH48 changes) https://www.rfc-editor.org/authors/rfc9869-auth48rfcdiff.html (AUTH48 changes side by side) We have now received all necessary approvals and consider AUTH48 complete. As this document is part of Cluster C405, you may track the progress of all documents in this cluster through AUTH48 at: https://www.rfc-editor.org/auth48/C405 We will move this document forward in the publication process once the other necessary documents in the cluster complete AUTH48 as well. Please let us know if you have any questions. Thank you, Alanna Paloma RFC Production Center > On Sep 23, 2025, at 8:31 AM, Gorry Fairhurst <[email protected]> wrote: > > On 22/09/2025 17:25, Alanna Paloma wrote: >> Hi Authors, >> >> This is a friendly reminder that we await your reviews and approvals of the >> updated files prior to moving this document in the publication process. >> >> The files have been posted here (please refresh): >> https://www.rfc-editor.org/authors/rfc9869.xml >> https://www.rfc-editor.org/authors/rfc9869.txt >> https://www.rfc-editor.org/authors/rfc9869.html >> https://www.rfc-editor.org/authors/rfc9869.pdf >> >> The relevant diff files have been posted here: >> https://www.rfc-editor.org/authors/rfc9869-diff.html (comprehensive diff) >> https://www.rfc-editor.org/authors/rfc9869-auth48diff.html (AUTH48 changes) >> https://www.rfc-editor.org/authors/rfc9869-auth48rfcdiff.html (AUTH48 >> changes side by side) >> >> For the AUTH48 status of this document, please see: >> https://www.rfc-editor.org/auth48/rfc9869 >> >> Thank you, >> Alanna Paloma >> RFC Production Center > > Thanks for this work. > > In see you have moved to US English, rather than UK English. If this is my > choice, I'd prefer UK English, but I can live with "ize" if this is really > necessary! > > Apart from that, I am content with these changes made. > > Best wishes, > > Gorry > >> >>> On Sep 15, 2025, at 11:32 AM, Alanna Paloma <[email protected]> >>> wrote: >>> >>> Hi Gorry, >>> >>> Thank you for your reply. We’ve formatted those notes to appear in the >>> <aside> element. >>> >>> The files have been posted here (please refresh): >>> https://www.rfc-editor.org/authors/rfc9869.xml >>> https://www.rfc-editor.org/authors/rfc9869.txt >>> https://www.rfc-editor.org/authors/rfc9869.html >>> https://www.rfc-editor.org/authors/rfc9869.pdf >>> >>> The relevant diff files have been posted here: >>> https://www.rfc-editor.org/authors/rfc9869-diff.html (comprehensive diff) >>> https://www.rfc-editor.org/authors/rfc9869-auth48diff.html (AUTH48 changes) >>> https://www.rfc-editor.org/authors/rfc9869-auth48rfcdiff.html (AUTH48 >>> changes side by side) >>> >>> For the AUTH48 status of this document, please see: >>> https://www.rfc-editor.org/auth48/rfc9869 >>> >>> Please note that we are still awaiting a response from RFC-to-be 9868 to >>> address the terminology question. >>> >>> Best regards, >>> Alanna Paloma >>> RFC Production Center >>> >>>> On Sep 13, 2025, at 12:38 AM, Gorry Fairhurst <[email protected]> wrote: >>>> >>>> On 12/09/2025 21:10, Alanna Paloma wrote: >>>>> Hi Gorry and Tom, >>>>> >>>>> Thank you for your replies. We have updated as requested. >>>>> >>>>> Please note that we have some follow-up questions/comments. >>>> Ah - I see I didn't understand, thanks for the clarification. >>>>>>> 7) <!-- [rfced] Please review whether any of the notes in this document >>>>>>> should be in the <aside> element. It is defined as "a container for >>>>>>> content that is semantically less important or tangential to the >>>>>>> content that surrounds it" >>>>>>> (https://authors.ietf.org/en/rfcxml-vocabulary#aside). >>>>>>> - >>>>>> All extra notes/comments can all be discarded at this stage. >>>>> ) To clarify, would you like these notes within the document to be >>>>> discarded, moved into the <aside> element, or left as is? >>>>> >>>>> Section 3: >>>>> Note: UDP allows an Upper Layer protocol to send datagrams with or >>>>> without payload data (with or without UDP Options). These are >>>>> delivered across the network to the remote Upper Layer. When >>>>> DPLPMTUD is implemented within the UDP transport service, probe >>>>> packets that include a REQ or RES UDP Option can be sent with no UDP >>>>> payload. In this case, these probe packets were not generated by a >>>>> sending application; therefore, the corresponding received datagrams >>>>> are not delivered to the remote application. >>>>> >>>>> Section 3.3: >>>>> Note: A receiver that only responds when there is a datagram queued >>>>> for transmission by the Upper Layer could potentially receive >>>>> multiple datagrams with a REQ Option before it can respond. When >>>>> sent, the RES Option will only acknowledge the latest received token >>>>> value. A sender would then conclude that any earlier REQ Options >>>>> were not successfully received. However, DPLPMTUD does not usually >>>>> result in sending more than one probe packet per timeout interval, >>>>> and a delay in responding will already have been treated as a failed >>>>> probe attempt. Therefore, this does not significantly impact >>>>> performance, although a more prompt response would have resulted in >>>>> DPLPMTUD recording reception of all probe packets. >>>> I was refering to XML comments, and made the wrong call. >>>> >>>> These notes NEED to appear in the published RFC as notes, yes please >>>> format them as aside elements. >>>> >>>> Gorry >>>> >>>>>>> 8) <!-- [rfced] We note that this document uses "UDP Options", while >>>>>>> RFC-to-be 9868 <draft-ietf-tsvwg-udp-options> uses "UDP options" >>>>>>> (lowercase). Please review and let us know if these should be made >>>>>>> consistent. Perhaps lowercase for "UDP options" in general, but >>>>>>> "Option" when referring to a specific option (e.g., Response (RES) >>>>>>> Option). >>>>>>> >>>>>>> See <https://www.rfc-editor.org/authors/rfc9868.html>. >>>>>>> --> >>>>>>> >>>>>> This document should be updated to become consistent with the RFC that >>>>>> will define UDP options, please ammend this document to match the final >>>>>> format used in the options specification. >>>>> ) FYI, we will hold off on making these updates until we’ve received a >>>>> response from RFC-to-be 9868 regarding this terminology. >>>> OK >>>>> --- >>>>> The files have been posted here (please refresh): >>>>> https://www.rfc-editor.org/authors/rfc9869.xml >>>>> https://www.rfc-editor.org/authors/rfc9869.txt >>>>> https://www.rfc-editor.org/authors/rfc9869.html >>>>> https://www.rfc-editor.org/authors/rfc9869.pdf >>>>> >>>>> The relevant diff files have been posted here: >>>>> https://www.rfc-editor.org/authors/rfc9869-diff.html (comprehensive diff) >>>>> https://www.rfc-editor.org/authors/rfc9869-auth48diff.html (AUTH48 >>>>> changes) >>>>> https://www.rfc-editor.org/authors/rfc9869-auth48rfcdiff.html (AUTH48 >>>>> changes side by side) >>>>> >>>>> >>>>> Please review the document carefully and contact us with any further >>>>> updates you may have. Note that we do not make changes once a document >>>>> is published as an RFC. >>>>> >>>>> We will await approvals from each party listed on the AUTH48 status page >>>>> below prior to moving this document forward in the publication process. >>>>> >>>>> For the AUTH48 status of this document, please see: >>>>> https://www.rfc-editor.org/auth48/rfc9869 >>>>> >>>>> Thank you, >>>>> Alanna Paloma >>>>> RFC Production Center >>>>> >>>>>> On Sep 12, 2025, at 9:05 AM, Tom Jones <[email protected]> wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Please ammend the draft RFC. I plan to check the rendered document in >>>>>>> detail after you complete this update. >>>>>>> >>>>>> I think Gorry and I concur on these edits, Gorry thanks for the quick >>>>>> reply. >>>>>> >>>>>> - Tom -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
