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