Mike Heard
(speaking for both Joe and myself)
On Thu, Sep 11, 2025 at 9:57 AM <[email protected]> wrote:
Authors,
While reviewing this document during AUTH48, please resolve (as
necessary)
the following questions, which are also in the source file.
1) <!-- [rfced] Mike, we note that your name appears as follows in the
Authors' Addresses section:
C. M. (Mike) Heard (editor)
Is this how you prefer that it be displayed going forward?
Yes please.
In your earlier RFCs, it has appeared as follows:
C. M. Heard
In addition, we note that RFC 3637 displayed "C. M. Heard" in the
document
header, while RFCs 3638 and 4181 used "C. Heard". Please let us
know you
preference, and we will use that in this document and any future RFCs.
-->
Let's use C. Heard in the document header. That will match RFCs 3638,
4181, and 4841.
2) <!-- [rfced] Please insert any keywords (beyond those that
appear in
the title) for use on https://www.rfc-editor.org/search. -->
We believe that the title has all the keywords that are needed.
3) <!--[rfced] Text that is preceded with ">>" is not indented.
Would you
like each instance to be indented, or may we update this text as
follows?
Original:
In this document, the characters ">>" preceding an indented line(s)
indicates a statement using the key words listed above.
Perhaps:
In this document, the characters ">>" preceding text
indicate a statement using the key words listed above.
-->
Since these always occur at the start of a paragraph, we prefer:
In this document, the characters ">>" at the beginning of a
paragraph indicate a statement using the key words listed above.
4) <!-- [rfced] Informative reference RFC 793 has been obsoleted
by RFC
9293. We recommend replacing RFC 793 with RFC 9293. However, if
RFC 793
must be referenced, we suggest mentioning RFC 9293 (e.g., "most widely
known from TCP [RFC793], which has been obsoleted by [RFC9293]"). See
Section 4.8.6 of RFC 7322 ("RFC Style Guide").
Original:
o Socket pair - a pair of sockets defining a UDP exchange, defined
by a remote socket and a local socket, each composed of an IP
address and UDP port number (most widely known from TCP
[RFC793])
-->
We agree. The new text should be:
o Socket pair – a pair of sockets defining a UDP exchange, defined
by a remote socket and a local socket, each composed of an IP
address and UDP port number (most widely known from TCP [RFC793],
which has been obsoleted by [RFC9293])
5) <!--[rfced] We are having some difficulty understanding the
intention
of "to ignore" in the sentence below. Should all UDP options that a
receiver does not recognize be ignored? Please review and let us
know how
this sentence may be clarified.
Original:
o UNSAFE options - UDP options that are not designed to be
safe for
a receiver that does not understand them to ignore.
-->
We propose:
o UNSAFE options – UDP options that are not designed to be safely
ignored by a receiver that does not understand them.
6) <!--[rfced] To avoid use of "required" and "require" in the same
sentence to improve readability, may we update "require" with "need"?
Original:
Internet historians have suggested a number of possible
reasons why the design of UDP includes this field, e.g., to support
multiple UDP packets within the same IP datagram or to indicate the
length of the UDP user data as distinct from zero padding required
for systems that require writes that are not byte-aligned.
Perhaps:
Internet historians have suggested a number of possible
reasons why the design of UDP includes this field, e.g., to support
multiple UDP packets within the same IP datagram or to indicate the
length of the UDP user data as distinct from zero padding required
for systems that need writes that are not byte-aligned.
-->
We would prefer:
Internet historians have suggested a number of possible reasons why
the design of UDP includes this field, e.g., to support multiple UDP
packets within the same IP datagram or to indicate the length of the
UDP user data as distinct from zero padding required for systems that
cannot write an arbitrary number of bytes of data.
7) <!--[rfced] We are having difficulty parsing the second
sentence below.
In particular, the meaning of "in the absence of these extensions" is
unclear. Please review and let us know how this text may be
updated for
clarity.
Original:
UDP options have been designed based on the following core
principles. Each is an observation about (preexisting) UDP [RFC768]
in the absence of these extensions that this document does not
intend to change or a lesson learned from other protocol designs.
Perhaps:
UDP options have been designed based on the following core
principles. Each is an (preexisting) observation about UDP [RFC768]
that this document does not intend to change or is a lesson learned
from other protocol designs.
-->
We would prefer:
UDP options have been designed based on the following core principles.
Each is an observation about preexisting behavior of UDP [RFC768] in
the absence of these extensions that this document does not intend to
change or a lesson learned from other protocol designs.
8) <!--[rfced] In the Meaning column of Table 1, should "UCMP",
"UENC",
and "UEXP" be updated to include "UNSAFE" to reflect their
expansions in
Sections 12.1, 12.2, and 12.3, respectively?
Original:
RESERVED for Compression (UCMP)
...
RESERVED for Encryption (UENC)
...
RFC 3692-style experiments (UEXP)
Perhaps:
RESERVED for UNSAFE Compression (UCMP)
...
RESERVED for UNSAFE Encryption (UENC)
...
RFC 3692-style UNSAFE experiments (UEXP)
Note that "RFC 3692-style" has been updated to "RFC3692-style" (no
space)
to match use in other RFCs. We also updated some capitalization
in the
meaning column. If there are no objections, we will ask IANA to
update
their registry accordingly.
-->
We agree with this suggestion.
9) <!-- [rfced] The "UDP Option Kind Numbers" registry does not
include
the asterisks that appear in Table 1 (see
https://www.iana.org/assignments/udp/udp.xhtml#udp-options). We
believe this is an expected
difference between what appears in the RFC and the IANA registry,
as the
asterisks are defined in the RFC and the IANA registry has a
comparable
note about values 0-7. Please confirm that this is correct.
-->
Yes, this is correct.
10) <!--[rfced] Should "MUST be" also apply to "user data received
sent to
the user"?
Original:
If the
user data is not empty, all UDP options MUST be silently
ignored and
the user data received sent to the user.
Perhaps:
If the
user data is not empty, all UDP options MUST be silently
ignored and
the user data received MUST be sent to the user.
-->
We agree with this change.
11) <!--[rfced] As "RES" means "Response", should "RES response" be
updated to "RES option"?
Original:
For example, an application needs to explicitly enable the
generation
of a RES response by DPLPMTUD when using UDP Options [Fa25].
Perhaps:
For example, an application needs to explicitly enable the
generation
of a RES option by DPLPMTUD when using UDP Options [Fa25].
-->
We agree with this change.
12) <!--[rfced] Should "UKind" be updated to simply be "Kind"? "UKind"
does not appear to be defined in this document.
Original:
>> Receivers supporting UDP options MUST silently drop the UDP user
data of the reassembled datagram if any fragment or the entire
datagram includes an UNSAFE option whose UKind is not supported or
if an UNSAFE option appears outside the context of a fragment or
reassembled fragments.
-->
We agree with this change. "UKind" is a leftover from a previous
approach ☹️
13) <!--[rfced] To avoid repetition of "except" and "excepting" in the
same sentence to improve readability, may be update "excepting" to
"besides"?
Original:
>> At the sender, new options MUST NOT modify UDP packet content
anywhere except within their option field, excepting only those
contained within the UNSAFE option...
Perhaps:
>> At the sender, new options MUST NOT modify UDP packet content
anywhere except within their option field, besides only those
contained within the UNSAFE option...
-->
We would prefer:
>> At the sender, new options MUST NOT modify UDP packet content
anywhere outside their option field, excepting only those contained
within the UNSAFE option; areas that need to remain unmodified include
the IP header, IP options, the UDP user data, and the surplus area
(i.e., other options).
14) <!--[rfced] As "RECOMMENDS" is not a 2119/8174 keyword, may we
rephrase this sentence to use "RECOMMENDED"?
Original:
This document RECOMMENDS that options be
useful per-fragment and also RECOMMENDS that options used per-
fragment be reported to the user as a finite aggregate (e.g., a
sum,
a flag, etc.) rather than individually.
Perhaps B:
It is RECOMMENDED that options be
useful per-fragment; it is also RECOMMENDED that options used per-
fragment be reported to the user as a finite aggregate (e.g., a
sum,
a flag, etc.) rather than individually.
-->
We are OK with the proposed change.
15) <!--[rfced] For clarity, may we update "certain" with "some"?
Original:
Note that only certain of the initially defined options violate
these rules:
Perhaps:
Note that only some of the initially defined options violate
these rules:
-->
Given the context of the paragraph that follows, we would prefer:
With one exception, UNSAFE options are used when UDP user data needs
to be modified:
16) <!--[rfced] To avoid awkward hyphenation, may we rephrase
"non-'must-support' options" as follows?
Original:
>> Non-"must-support" options MAY be ignored by receivers, if
present, e.g., based on API settings.
Perhaps:
>> Options that are not must-support options MAY be ignored by
receivers, if present, e.g., based on API settings.
-->
We would prefer:
>> Options that are not “must-support” options MAY, if present, be
ignored by receivers, based, e.g., on API settings.
17) <!--[rfced] FYI - To improve readability, we have rephrased this
sentence and added quotes. Please review and let us know of any
objections.
Original:
UDP options are no exception and here are
specified as MUST NOT be altered in transit.
Current:
UDP options are no exception and are
specified here as "MUST NOT be altered in transit".
-->
We agree with this change.
18) <!--[rfced] Would you like to add a citation for the claimed
report
below? If so, please provide us with the reference information.
Additionally, may we change the first instance of "reported" to
avoid "has
been reported ... to be reported"? Perhaps "has been noted"?
Original:
It has been reported that Alcatel-Lucent's "Brick" Intrusion
Detection System has a default configuration that interprets
inconsistencies between UDP Length and IP Length as an attack to be
reported. Note that other firewall systems, e.g., CheckPoint,
use a
default "relaxed UDP length verification" to avoid falsely
interpreting this inconsistency as an attack.
-->
We are OK with the proposed change. Unfortunately, we do not have a
citation.
19) <!--[rfced] May we update "non-aware" to "unaware"?
Original:
Some of the mechanisms in this document can generate more zero-
length UDP packets for a UDP option aware endpoint than for a
legacy
(non-aware) endpoint (e.g., based some error conditions) and some
can generate fewer (e.g., fragment reassembly).
-->
We prefer the phrase "(non-aware)" just be removed, as "legacy"
already implies "not UDP option aware." There is also a typo to be
fixed (s/based/based on/):
Some of the mechanisms in this document can generate more zero-length
UDP packets for a UDP Option aware endpoint than for a legacy endpoint
(e.g., based on some error conditions) and some can generate fewer
(e.g., fragment reassembly).
20) <!--[rfced] We note that "TCP Sharing" does not occur in RFC
9040, but
it does use "TCB sharing". In the sentence below, should "TCP Sharing"
be updated to "TCB sharing"?
Original:
Some TCP connection parameters, stored in the TCP Control
Block, can
be usefully shared either among concurrent connections or between
connections in sequence, known as TCP Sharing [RFC9040].
Perhaps:
Some TCP connection parameters, stored in the TCP Control Block
(TCB),
can be usefully shared either among concurrent connections or
between
connections in sequence, known as TCB sharing [RFC9040].
-->
We agree with this change. "TCP Sharing" was a typo.
21) <!--[rfced] We note that no other drafts, only RFCs, are mentioned
in Section 22. Therefore, may we update the section title as follows?
Original:
22. Interactions with other RFCs (and drafts)
Perhaps:
22. Interactions with Other RFCs
-->
We agree with this change.
22) <!--[rfced] FYI - To clarify the quoted text, we have added the
following citation.
Original:
TE defines the length
of an IPv6 payload inside UDP as pointing to less than the end of
the UDP payload, enabling trailing options for that IPv6 packet:
"..the IPv6 packet length (i.e., the Payload Length value in
the IPv6 header plus the IPv6 header size) is less than or
equal to the UDP payload length (i.e., the Length value in
the UDP header minus the UDP header size)"
Current (using blockquote):
In [RFC6081], TE defines the length
of an IPv6 payload inside UDP as pointing to less than the end of
the UDP payload, enabling trailing options for that IPv6 packet:
| ...the IPv6 packet length (i.e., the Payload Length value in the
| IPv6 header plus the IPv6 header size) is less than or equal to
| the UDP payload length (i.e., the Length value in the UDP header
| minus the UDP header size)
-->
We are fine with the addition of this reference; however, upon
reflection, we would prefer to eliminate the acronym TE. How about:
CURRENT:
Teredo extensions (TEs) define use of a similar difference between
these lengths for trailers [RFC4380] [RFC6081]. In [RFC6081], TE
defines the length of an IPv6 payload inside UDP as pointing to less
than the end of the UDP payload, enabling trailing options for that
IPv6 packet:
NEW:
Teredo extensions define use of a similar difference between these
lengths for trailers [RFC4380] [RFC6081]. In [RFC6081], Teredo
extensions define the length of an IPv6 payload inside UDP as pointing
to less than the end of the UDP payload, enabling trailing options for
that IPv6 packet:
23) <!-- [rfced] This text has been (mostly) updated to match the note
that appears in the unified registry. We say "mostly" because we
will ask
IANA to update their registry to use "RFC 9896" instead of "the
corresponding reference". Please review and let us know if any
updates
are needed.
Original:
IANA is also
hereby requested to update the unified TCP/UDP ExID registry with
the direction that "16-bit ExIDs can be used with either TCP or
UDP;
32-bit ExIDs can be used with TCP or their first 16 bits can be
used
with UDP", and with further detail provided below.
Current:
IANA has added a note to the unified TCP/UDP
ExID registry specifying the following:
| Note 16-bit ExIDs can be used with either TCP or UDP; 32-bit
ExIDs
| can be used with TCP or their first 16 bits can be used with
UDP.
| Use with each transport (TCP, UDP) is indicated in the protocol
| column, as defined in RFC 9868.
-->
The note to the registry looks good to us.
24) <!-- [rfced] For clarity, may we update this sentence as follows?
Original:
Values in the TCP/UDP ExID registry are to be assigned by IANA
using
first-come, first-served (FCFS) rules applied to both the ExID
value
and the acronym [RFC8126].
Perhaps:
Values in the TCP/UDP ExID registry are to be assigned by IANA using
the First Come First Served (FCFS) policy [RFC8126], which
applies to
both the ExID value and the acronym.
-->
We agree with this change.
25) <!--[rfced] FYI - We've added a URL to this reference. Please
review
and let us know of any objections.
Original:
[Zu20] Zullo, R., T. Jones, and G. Fairhurst, "Overcoming the
Sorrows of the Young UDP Options," 2020 Network Traffic
Measurement and Analysis Conference (TMA), IEEE, 2020.
Current:
[Zu20] Zullo, R., Jones, T., and G. Fairhurst, "Overcoming the
Sorrows of the Young UDP Options", 4th Network Traffic
Measurement and Analysis Conference (TMA), 2020,
<https://dl.ifip.org/db/conf/tma/tma2020/tma2020-camera-
paper70.pdf
<https://dl.ifip.org/db/conf/tma/tma2020/tma2020-camera-paper70.pdf>>.
-->
I have no objections, but Joe has concerns about the stability of this
URL.
The responsible AD for this RFC-to-be, Gorry Fairhurst, is a co-author
of that document; perhaps he can speak to that point.
26) <!--[rfced] Terminology
a) Throughout the text, the following terminology appears to be used
inconsistently. May we update to use the term on the right to make it
consistent throughout the document?
extended length > Extended Length
option length > Option Length
UDP length > UDP Length
UDP option > UPD Option
We are OK with these changes.
b) Throughout the text, the following terminology appears to be used
inconsistently. Please review these occurrences and let us know
if/how they
may be made consistent.
UDP Timestamp vs. UDP timestamp
-->
We believe that the usage is correct as is; the contexts are
different. Section 11.4 says:
UDP fragmentation relies on a fragment expiration timer, which can be
preset or could use a value computed using the UDP Timestamp option.
whereas Section 11.8 says:
UDP timestamps are modeled after TCP timestamps and have similar
expectations. In particular, they are expected to follow these guidelines:
27) <!--[rfced] Abbreviations
a) FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
Cyclic Redundancy Check (CRC)
Datagram Congestion Control Protocol (DCCP)
Effective MTU for Receiving (EMTU_R)
Internet Small Computer System Interface (iSCSI)
Path MTU (PMTU)
Stream Control Transmission Protocol (SCTP)
TCP Authentication Option Encryption (TCP-AO-ENC)
The following change is requested for the first use of EMTU_R:
Section 11.4, CURRENT:
The Fragmentation (FRAG, Kind=3) option supports UDP fragmentation and
reassembly, which can be used to transfer UDP messages larger than
allowed by the IP receive MTU (Effective MTU for Receiving (EMTU_R)
[RFC1122]).
NEW:
The Fragmentation (FRAG, Kind=3) option supports UDP fragmentation and
reassembly, which can be used to transfer UDP messages larger than
allowed by the IP Effective MTU for Receiving (EMTU_R) [RFC1122].
The following change is requested for the first (and only) use TCP-AO-ENC:
Section 12.2, OLD:
UENC is expected to provide all of the services of the AUTH option
(Section 11.9) and in addition to encrypt the UDP user data and some
(e.g., later, in sequence) UDP options, in a similar manner as TCP
Authentication Option Encryption (TCP-AO-ENC) [To18].
NEW:
UENC is expected to provide all of the services of the AUTH option
(Section 11.9) and in addition to encrypt the UDP user data and some
(e.g., later, in sequence) UDP options, in a similar manner as TCP
Authentication Option Extension for Payload Encryption (TCP-AO-ENC)
[To18].
b) How should "MMS_S" be expanded?
Original:
Suppose that MMS_S is the PMTU less the size of
the IP header and the UDP header, i.e., the maximum UDP message
size
that can be successfully sent in a single UDP datagram if there are
no IP options or extension headers and no UDP per-fragment options.
This was intended to be a local definition of the symbol MMS_S for use
in the equation that follows the above paragraph, and it's used
nowhere else. Just expanding it in the obvious way as Maximum Message
Size for Sending (that's what it's mnemonic for) would result in some
really weird text. What about the following edits to make it clear
that we are defining a symbol, not using an acronym?
Section 11.6, CURRENT:
These parameters plus the Path MTU (PMTU) allow a sender to compute
the size of the largest pre-fragmentation UDP packet that a receiver
will guarantee to accept. Suppose that MMS_S is the PMTU less the size
of the IP header and the UDP header, i.e., the maximum UDP message
size that can be successfully sent in a single UDP datagram if there
are no IP options or extension headers and no UDP per-fragment options.
Then, the size of the largest pre-fragmentation UDP packet that the
receiver will guarantee to accept is the smaller of the MRDS size and
(MMS_S - 12) * (MRDS segs) - 2 - (Total Per-Frag IP/UDP Options) + 8
NEW:
These parameters plus the Path MTU (PMTU) allow a sender to compute
the size of the largest pre-fragmentation UDP packet that a receiver
will guarantee to accept. Define MMS_S as the PMTU less the size of
the IP header and the UDP header, i.e., the maximum UDP message size
that can be successfully sent in a single UDP datagram if there are no
IP options or extension headers and no UDP per-fragment options. Then
the size of the largest pre-fragmentation UDP packet that the receiver
will guarantee to accept is the smaller of the MRDS size and
(MMS_S - 12) * (MRDS segs) - 2 - (Total Per-Frag IP/UDP Options) + 8
c) We note that "TIME" is expanded as "Timestamps" and "Timestamp"
(plural and singular). How should it be updated for consistency?
Original:
11.8. Timestamps (TIME)
...
The Timestamp (TIME, Kind=8) option exchanges two four-byte
unsigned
timestamp fields.
Similarly, should "TS" be expanded as "Timestamp" or "Timestamps"
(singular or plural)?
Original:
It serves a similar purpose to TCP's TS option
[RFC7323], enabling UDP to estimate the round-trip time (RTT)
between hosts.
-->
It should be singular ("Timestamp").
28) <!--[rfced] To avoid redundant acronym expansions, should the
following instances be updated for simplicity?
a) APC checksums: If expanded, "APC checksum" would read as
"Additional
Payload Checksum checksum".
Original:
>> UDP packets with incorrect APC checksums SHOULD be passed to the
application with an indication of APC failure.
...
>> UDP packets with unrecognized APC lengths MUST receive the same
treatment as UDP packets with incorrect APC checksums.
Perhaps:
>> UDP packets with incorrect APCs SHOULD be passed to the
application with an indication of APC failure.
...
>> UDP packets with unrecognized APC lengths MUST receive the same
treatment as UDP packets with incorrect APCs.
The option is called APC, but within the APC is a kind, a length, and
a checksum field. We would therefore prefer:
>> UDP packets with incorrect APC Option checksums fields SHOULD be
passed to the
application with an indication of APC Option checksum failure.
...
>> UDP packets with unrecognized APC lengths MUST receive the same
treatment as UDP packets with incorrect APC Option checksum fields.
b) MRDS size: If expanded, "MRDS size" would read "Maximum Reassembled
Datagram Size size".
Original:
MRDS size is the UDP equivalent of IP's EMTU_R but the
two are not related [RFC1122].
Perhaps:
MRDS is the UDP equivalent of IP's EMTU_R but the
two are not related [RFC1122].
We would prefer:
The MRDS size field is the UDP equivalent of IP’s EMTU_R, but the two
are not related [RFC1122].
c) TSval value: If expanded, "TSval value" would read as "TS Value
value".
Original:
Received TSval and TSecr values are provided to the
application, which can pass the TSval value to be used as TSecr on
UDP messages sent in response (i.e., to echo the received TSval).
Perhaps:
Received TSval and TSecr values are provided to the
application, which can pass the TSval to be used as TSecr on
UDP messages sent in response (i.e., to echo the received TSval).
-->
We would prefer:
Received TSval and TSecr field contents are provided to the
application, which can pass the received TSval to be used as TSecr in
UDP messages sent in response (i.e., to echo the received TSval).
29) <!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature
typically result in more precise language, which is helpful for
readers.
Note that our script did not flag any words in particular, but
this should
still be reviewed as a best practice.
-->
Thank you.
Alanna Paloma and Sandy Ginoza
RFC Production Center
On Sep 11, 2025, at 9:49 AM, [email protected] wrote:
*****IMPORTANT*****
Updated 2025/09/11
RFC Author(s):
--------------
Instructions for Completing AUTH48
Your document has now entered AUTH48. Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular
attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that
elements of
content are correctly tagged. For example, ensure that
<sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
* [email protected] (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
* [email protected], which is a new archival mailing
list
to preserve AUTH48 conversations; it is not an active discussion
list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* Note: If only absolutely necessary, you may temporarily
opt out
of the archiving of messages (e.g., to discuss a sensitive
matter).
If needed, please add a note at the top of the message
that you
have dropped the address. When the discussion is concluded,
[email protected] will be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes
that seem
beyond editorial in nature, e.g., addition of new text, deletion
of text,
and technical changes. Information about stream managers can be
found in
the FAQ. Editorial changes do not require approval from a stream
manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email
stating
that you approve this RFC for publication. Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc9868.xml
https://www.rfc-editor.org/authors/rfc9868.html
https://www.rfc-editor.org/authors/rfc9868.pdf
https://www.rfc-editor.org/authors/rfc9868.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9868-diff.html
https://www.rfc-editor.org/authors/rfc9868-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9868-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9868
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC 9868 (draft-ietf-tsvwg-udp-options-45)
Title : Transport Options for UDP
Author(s) : J. Touch, C. M. Heard, Ed.
WG Chair(s) : Martin Duke, Zaheduzzaman Sarker
Area Director(s) : Gorry Fairhurst, Mike Bishop
