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

> 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]

Reply via email to