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 <go...@erg.abdn.ac.uk> 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 <t...@erg.abdn.ac.uk> 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 -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
