Subject: [tsvwg] draft-ietf-tsvwg-udp-options-16 : technical comments

From: "C. M. Heard" <[email-masked]>
Date: Thu, 24 Mar 2022 15:20:04 -0700

Greetings TSVWG,

My thanks to Joe Touch for producing this draft -- it's a lot cleaner than
its predecessors. I already sent some purely editorial comments to Joe
off-list.  This message contains assorted technical comments that I would
like the WG to consider. Some of these comments may actually be editorial,
but I decided it would be best to air anything that would change the
meaning of the text as written.

#Sections 6 and 7: The requirement to make OCS 4-byte aligned seems to me
to be overkill, since neither the UDP checksum nor the IPv4 header checksum
are 4-byte aligned (in fact, their alignment is 4n+2, relative to the start
of the IP header,). For that reason, two-byte alignment should be
sufficient. Suggested text:

First paragraph of Section 6: s/4-byte/2-byte/

And in Section 7:

OLD

   The Option Checksum (OCS) option is conventional Internet checksum
   [RFC791] that detects errors in the surplus area. The OCS option
   contains a *32-bi*t checksum that is aligned to the first *4-byte*
   boundary, preceded by zeroes for padding (if needed), as shown in
   Figure 4.

NEW

   The Option Checksum (OCS) option is a conventional Internet checksum
   [RFC791] that detects errors in the surplus area. The OCS field
   contains a *16-bit* checksum that is aligned to the first *2-byte*
   boundary, preceded if necessary by a zero-valued padding byte, as
   shown in Figure 4.

#Section 8: the unsafe option value 192 is not included in the table. If
the intent was to make that value reserved, an entry indicating that fact
should be present. Alternatively, UENC could be assigned the value 192 and
then 193-253 could be available for assignment. I recommend the latter
course unless there is a compelling reason to reserve the value 192.

#Section 9,2, page 14, second paragraph of section:
Probably a typo, but the second sentence seems to contradict the third one
(and parts of the text in the preceding section. Suggested change:

OLD
UDP packets SHOULD use NOPs at the end of the options area as a substitute
for EOL followed by zero-fill.

NEW
UDP packets SHOULD NOT use NOPs at the end of the options area as a
substitute for EOL followed by zero-fill.

#Section 9.4, FRAG: I raise several issues here.

(a) Since the following is a SHOULD rather than a MUST:

   >> When FRAG is present, it SHOULD come as early as possible in the
   UDP options list.

I conclude that it is possible to send per-fragment options both prior to
the FRAG option and afterward (the latter up to the size indicated by Frag.
Start). Thus receivers need to be prepared to deal with that situation.
Surely no good comes of having more than one way to transmit and receive
per-fragment options. I recommend that we consider one of the the following
alternatives:

1. Eliminate the Frag. Start field and put all per-fragment options before
the FRAG option. All data remaining in the packet after the FRAG option
would be consumed by that option and used in the reassembly process. The
terminal fragment would still contain Frag. End (or possibly Opt. Offset --
more on that below) to indicate where the per-datagram options begin in the
reassembled datagram.

2. Leave the FRAG option as is, but REQUIRE that it appear immediately
after OCS, except possibly for NOPs used for alignment. If the option
appears anywhere else, the entire option field would be considered
malformed and silently discarded.

>From my point of view, alternative #1 is compelling because it has simpler
logic (there is one less check needed to ensure that the per-datagram
options are well-formed) and potentially consumes less space in the packet.
Note that alternative #1 would require minor adjustments to step 3 of the
fragment creation process.

(b) In the terminal FRAG option format: I propose changing "Frag. End" to
"Opt. Offset", which would be the location of the per-datagram options
measured  in bytes from the beginning of the original unfragmented
datagram. This would remove the requirement that all per-datagram options
fit into the trailing fragment and would decouple the fragmentation and
reassembly process from the generation and processing of the per-datagram
options. I had understood that this was what was originally intended, based
on discussions on the mailing list; see, e.g.,
https://mailarchive.ietf.org/arch/msg/tsvwg/rLhGaa4jG0u6TslpPQpTwzzGmnM/.
If this change is adopted, minor adjustments will be needed to step 3 of
the fragment creation process.

(c) I believe that the following statement is incorrect:

   >> During fragmentation, the UDP header checksum of each fragment
   needs to be recomputed based on each datagram's pseudoheader.

In point of fact, the UDP header of each fragment of a single user datagram
has the same port values and a UDP length of zero (since UDP user data is
not allowed with this option). Thus, none of the data used to compute the
UDP checksum, including the UDP pseudo header, changes from one fragment to
the next, and the UDP checksum can be pre-computed. I suggest removing this
text.

(d) the treatment of per-datagram OCS should be made more explicit. I
propose this change at the end of step 1 of the fragmentation process:

OLD

      Process these UDP options before the rest of the fragmentation
      steps below.

NEW

      Prepare these UDP options before the rest of the fragmentation
      steps below. The OCS value SHOULD be zero if each fragment will
      have a non-zero OCS value (as will be the case if the UDP
      checksum is non-zero).

#Section 9.5, MDS, second sentence of second paragraph:

OLD
It is more likely to be useful when coupled with IP source fragmentation

NEW
It is more likely to be useful when coupled with IP source fragmentation or
UDP fragmentation

#Section 9.8, TIME option:

OLD

   Rollover can be handled as a special case or more completely using
   sequence number extension [RFC9187], however zero values need to be
   avoided.

NEW

   Rollover can be handled as a special case or more completely using
   sequence number extension [RFC9187], however zero values need to be
   avoided, e.g., by using one's-complement arithmetic.

I would in fact prefer to be more prescriptive about this, in order to
ensure that a receiver will always respond to a request with the highest TSval
received, allowing for rollover while avoiding zero values; one's-complement
arithmetic skips over zero values and accomplishes this. But if all we can
agree upon is to provide a non-normative suggestion, I'll settle for that.

#Section 9.9, AUTH: Figure 16 needs to be corrected to include the KeyID
and RNextKeyID fields shown in RFC 5925 Section 2.2, as discussed in
https://mailarchive.ietf.org/arch/msg/tsvwg/N3nX_SE6gtCintx4tjUOVI-7BWo/
(it's called Figure 17 there because we were discussing an earlier draft). Note
that the technical content of Section 10.1 (UENCR) also depends on this
change, but there are no text changes because the figure is incorporated by
reference and not repeated. I'm pretty sure that this was an oversight lost
in the 100s of emails that Joe mentioned 😊

#Section 10.1, UENC: consider adding the following sentence at the end of
the only paragraph in the section:

   Unlike AUTH, if UENC fails, the packet and its options are silently
discarded.

.

#Section 12:

(a) Terminology, on p. 26: does "mandatory" mean the same thing as
"must-support", as defined in Section 8? If so, please change "mandatory"
to "must-support"; if not, please define the term.

(b) Pseudo-code on p. 27:

OLD:

           if the UDP checksum fails then
               silently drop the entire UDP packet (per RFC1122
<https://datatracker.ietf.org/doc/html/rfc1122>)
           if the UDP checksum passes then
               if OCS is nonzero and fails then
                   deliver the UDP user data but ignore other options
                   (this is required to emulate legacy behavior)

NEW:

           if the UDP checksum fails then
               silently drop the entire UDP packet (per RFC1122
<https://datatracker.ietf.org/doc/html/rfc1122>)
           if the UDP checksum passes then
               if OCS != 0 and fails or is zero when UDP CS != 0 then
                   deliver the UDP user data but ignore other options
                   (this is required to emulate legacy behavior)

This corrects an inconsistency with Section 7.

#Section 13: I raise multiple issues here.

(a) Handling of options received in fragments is incompletely specified.
The existing text says:

   o  Extend the receive function to indicate the options and their
      parameters as received with the corresponding received datagram.

This is clear enough when dealing with per-datagram options, but IMO it
leaves too much to the imagination for per-fragment options. Specifically,
are per-fragment options reported to the application layer as each fragment
is received or only when a datagram is successfully reassembled? The answer
to that question seems to depend on the option involved. TIME, for
instance, isn't especially useful as a per-fragment option unless it is
reported to the receiver as each fragment arrives. On the other hand, if
AUTH (when configured to protect the UDP options) is used as a per-fragment
option, then the most useful behavior is probably to provide a logical "OR"
of the failure indications of the fragments with the reassembled datagram.

(b) Handling of options by the send function has some omissions. The
existing text says:

   o  Extend the send function to indicate the options to be added to
      the corresponding sent datagram. This includes indicating which
      options apply to individual fragments vs. which apply to the UDP
      packet prior to fragmentation, if fragmentation is enabled.

When fragmentation is enabled, the application should be able to specify,
at a minimum, an upper bound on how large each fragment can be.

Additionally, when fragmentation is disabled, the application should be
able to specify that the outgoing datagram must be padded up to a specified
size, using EOL followed by zeroes, as specified in Section 9.1.

Thanks again for the work on this important spec.

Mike Heard

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 24 Mar 2022 19:53:09 -0700

Hi, Mike (et al.),

Notes below as needed. 

See >>>> marking where I think continued discussion appears needed. 

(Everyone - please delete anything you already agree with)

Joe

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On Mar 24, 2022, at 3:20 PM, C. M. Heard <[email-masked]> wrote:
> 
> Greetings TSVWG,
> 
> My thanks to Joe Touch for producing this draft -- it's a lot cleaner than its predecessors. I already sent some purely editorial comments to Joe off-list.  This message contains assorted technical comments that I would like the WG to consider. Some of these comments may actually be editorial, but I decided it would be best to air anything that would change the meaning of the text as written.
> 
> 
> #Sections 6 and 7: The requirement to make OCS 4-byte aligned seems to me to be overkill, since neither the UDP checksum nor the IPv4 header checksum are 4-byte aligned (in fact, their alignment is 4n+2, relative to the start of the IP header,). For that reason, two-byte alignment should be sufficient.

Agreed and fixed as noted.

> ...
> #Section 8: the unsafe option value 192 is not included in the table. If the intent was to make that value reserved, an entry indicating that fact should be present. Alternatively, UENC could be assigned the value 192 and then 193-253 could be available for assignment. I recommend the latter course unless there is a compelling reason to reserve the value 192.

This was already noted and fixed; 192 is now UENC.

> Probably a typo, but the second sentence seems to contradict the third one (and parts of the text in the preceding section. Suggested change:
> 
> OLD
> UDP packets SHOULD use NOPs at the end of the options area as a substitute for EOL followed by zero-fill.
> 
> NEW
> UDP packets SHOULD NOT use NOPs at the end of the options area as a substitute for EOL followed by zero-fill.

Yes, fixed.

———
FRAG issue:

> I conclude that it is possible to send per-fragment options both prior to the FRAG option and afterward (the latter up to the size indicated by Frag. Start). Thus receivers need to be prepared to deal with that situation. Surely no good comes of having more than one way to transmit and receive per-fragment options.

The problem is that we want FRAG early - to allow offloading to handle that TLV as quickly as possible.

However, we don’t want to *require* it to be first, largely because there are arguments pro and con. Other options might arguably be first (per fragment AUTH or UENC).

Regardless of where FRAG occurs, packets always look like this before fragmentation:

	[userdata] OCS Opt1 Opt2 Opt3 Opt4 

I’ll add curly braces to those per-datagram options so I can refer to them later:

	[userdata] {OCS Opt1 Opt2 Opt3 Opt4}

And then this after fragmentation:

	[no data] OCS OptA FRAG OptB OptC [first frag]
…
	[no data] OCS OptA FRAG OptB OptC [lastfrag {OCS Opt1 Opt2 Opt3}]

Yes, FRAG can come right after the leftmost OCS or after OptC. FRAG header placement is intended to be able to float in the header so an implementation can put it where it thinks it will be most convenient to the receiver (e.g., 8-byte aligned, for example), without wasting the space in front of it with NOPs all the time.

The only thing we do know is that no options appear after then end of the fragment itself.

> I recommend that we consider one of the the following alternatives:
> 
> 1. Eliminate the Frag. Start field and put all per-fragment options before the FRAG option. All data remaining in the packet after the FRAG option would be consumed by that option and used in the reassembly process. The terminal fragment would still contain Frag. End (or possibly Opt. Offset -- more on that below) to indicate where the per-datagram options begin in the reassembled datagram.

This appears to be bad for offloading, because all the options have to be TLV parsed before knowing it’s a reassembled fragment. 

> 2. Leave the FRAG option as is, but REQUIRE that it appear immediately after OCS, except possibly for NOPs used for alignment. If the option appears anywhere else, the entire option field would be considered malformed and silently discarded.

See above; this just wastes space.

I also don’t like saying anything “must be first” unless that’s really inherently true; it’s not here. Making it “first” only invites problems when someone does the same with some other option later (which one is first if they both claim so?).

> From my point of view, alternative #1 is compelling because it has simpler logic (there is one less check needed to ensure that the per-datagram options are well-formed) and potentially consumes less space in the packet. Note that alternative #1 would require minor adjustments to step 3 of the fragment creation process.

>>> so I’d ask everyone to weigh in as to whether we need to change this; I personally think it’s better as it is.

> (b) In the terminal FRAG option format: I propose changing "Frag. End" to "Opt. Offset", which would be the location of the per-datagram options measured  in bytes from the beginning of the original unfragmented datagram. This would remove the requirement that all per-datagram options fit into the trailing fragment and would decouple the fragmentation and reassembly process from the generation and processing of the per-datagram options. I had understood that this was what was originally intended, based on discussions on the mailing list; see, e.g., https://mailarchive.ietf.org/arch/msg/tsvwg/rLhGaa4jG0u6TslpPQpTwzzGmnM/ <https://mailarchive.ietf.org/arch/msg/tsvwg/rLhGaa4jG0u6TslpPQpTwzzGmnM/>.

Yup - that change fell on the floor. Thanks for the catch. I think I fixed it.

> If this change is adopted, minor adjustments will be needed to step 3 of the fragment creation process.
> 
> In point of fact, the UDP header of each fragment of a single user datagram has the same port values and a UDP length of zero (since UDP user data is not allowed with this option). Thus, none of the data used to compute the UDP checksum, including the UDP pseudo header, changes from one fragment to the next, and the UDP checksum can be pre-computed. I suggest removing this text.

Agreed.

> (d) the treatment of per-datagram OCS should be made more explicit. I propose this change at the end of step 1 of the fragmentation process:
> 
> OLD

Done.

> It is more likely to be useful when coupled with IP source fragmentation or UDP fragmentation 

Done.

One’s complement isn’t enough. 0+0+0… will still generate 0. The result has to be negated if zero (that won’t happen if any values are nonzero in ones complement, but can if they’re all zero or if the clock starts at zero). I just added “explicitly” to the old text; how this is done is up to the implementer and more specifically excluded by the following text that was already there:
>> TIME values MUST NOT use zeros as valid time values, because they are used as indicators of requests and responses.

> I would in fact prefer to be more prescriptive about this, in order to ensure that a receiver will always respond to a request with the highest TSval received, allowing for rollover while avoiding zero values; one's-complement arithmetic skips over zero values and accomplishes this. But if all we can agree upon is to provide a non-normative suggestion, I'll settle for that.

I don’t think we need to say how time is represented except as unsigned (I added that to the first sentence of 9.8).

> #Section 9.9, AUTH: Figure 16 needs to be corrected to include the KeyID and RNextKeyID fields shown in RFC 5925 Section 2.2, as discussed in https://mailarchive.ietf.org/arch/msg/tsvwg/N3nX_SE6gtCintx4tjUOVI-7BWo/ <https://mailarchive.ietf.org/arch/msg/tsvwg/N3nX_SE6gtCintx4tjUOVI-7BWo/> (it's called Figure 17 there because we were discussing an earlier draft). Note that the technical content of Section 10.1 (UENCR) also depends on this change, but there are no text changes because the figure is incorporated by reference and not repeated. I'm pretty sure that this was an oversight lost in the 100s of emails that Joe mentioned 😊

I just referred to both as using the fields of the TCP-AO option.

> #Section 10.1, UENC: consider adding the following sentence at the end of the only paragraph in the section:
> 
>    Unlike AUTH, if UENC fails, the packet and its options are silently discarded.

The options are silently discarded; zero-length packets still need to show up.

I added text in Sec 10 that explains that applications that rely on any UNSAFE options SHOULD NOT depend on zero-length packets as signals.

> #Section 12:
> 
> (a) Terminology, on p. 26: does "mandatory" mean the same thing as "must-support", as defined in Section 8? If so, please change "mandatory" to "must-support"; if not, please define the term. 

Done.

>                silently drop the entire UDP packet (per RFC1122 <https://datatracker.ietf.org/doc/html/rfc1122>)
>                silently drop the entire UDP packet (per RFC1122 <https://datatracker.ietf.org/doc/html/rfc1122>)

Done.

> (a) Handling of options received in fragments is incompletely specified. The existing text says:
> 
> This is clear enough when dealing with per-datagram options, but IMO it leaves too much to the imagination for per-fragment options. Specifically, are per-fragment options reported to the application layer as each fragment is received or only when a datagram is successfully reassembled? The answer to that question seems to depend on the option involved. TIME, for instance, isn't especially useful as a per-fragment option unless it is reported to the receiver as each fragment arrives. On the other hand, if AUTH (when configured to protect the UDP options) is used as a per-fragment option, then the most useful behavior is probably to provide a logical "OR" of the failure indications of the fragments with the reassembled datagram.

If AUTH fails on a fragment, reassembly fails. I don’t know that we would deliver anything to users when that happens except the zero-length packet associated with the failed AUTH.

I added a note about this, but it may need work (see -17 “WG QUESTION").

> (b) Handling of options by the send function has some omissions. The existing text says:
> 
> When fragmentation is enabled, the application should be able to specify, at a minimum, an upper bound on how large each fragment can be.

Also noted with WG QUESTION in the text now. I don’t know if we need or want either a frag min or frag max size; the max seems like it should be determined by the path MTU or interface config.

> Additionally, when fragmentation is disabled, the application should be able to specify that the outgoing datagram must be padded up to a specified size, using EOL followed by zeroes, as specified in Section 9.1.

Added.

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 26 Mar 2022 10:54:01 -0700

Regarding this:

> per-fragment options.
> However, we don’t want to *require* it to be first, largely because there
> are arguments pro and con. Other options might arguably be first (per
> fragment AUTH or UENC).
>

[ ... ]
> This appears to be bad for offloading, because all the options have to be
> TLV parsed before knowing it’s a reassembled fragment.
>
> I also don’t like saying anything “must be first” unless that’s really
> inherently true; it’s not here. Making it “first” only invites problems
> when someone does the same with some other option later (which one is first
> if they both claim so?).
>

After going through two gedanken experiments, I'm persuaded by Joe's
arguments.

First: for UENC to function at all as a per-fragment option, encryption of
the option area has to be enabled, with the exception of the UENC option
itself. In order for implementations that do not understand UENC to be able
to recognize that an UNSAFE option is present before attempting to parse
encrypted TLVs, the UENC option has to come first, before FRAG. So
alternative #2 is out.

Second: I went through an exercise to see what it would take, in the case
where there are no per-fragment options other than NOP, to ensure (a)
that the fragment data is aligned on a 4- or 8-byte boundary and (b) that
the Identification field is aligned on a 4-byte boundary. Assuming that I
got the intended  value of Frag. Start correct, this is what the initial
16-bytes of the option area would look like for a non-terminal fragment,
using the current format:

                   +--------+--------+--------+--------+
                   |       OCS       |  NOP   |  NOP   |
                   +--------+--------+--------+--------+

                   | Kind=3 | Len=10 | Frag. Start=24  |
                   +--------+--------+--------+--------+
                   |           Identification          |
                   +--------+--------+--------+--------+
                   |  Frag. Offset   |  NOP   |  NOP   |
                   +--------+--------+--------+--------+

and this is what it would look like for a terminal fragment:

                   +--------+--------+--------+--------+
                   |       OCS       |  NOP   |  NOP   |
                   +--------+--------+--------+--------+

                   | Kind=3 | Len=12 | Frag. Start=24  |
                   +--------+--------+--------+--------+
                   |           Identification          |
                   +--------+--------+--------+--------+
                   |  Frag. Offset   | Dgram Opt Start |
                   +--------+--------+--------+--------+

It's possible, using alternative #1 (with no Frag. Start field), to save
four bytes on non-terminal fragments if the fragment data is to be aligned
on a 4-byte boundary, but not if it is to be aligned on an 8-byte boundary
-- in the latter case, four NOPs would be required for a non-terminal
fragment and six would be required for a non-terminal fragment.

So I'm satisfied to leave this as is.

Mike Heard

---

From: "[email-masked]" <[email-masked]>
Date: Sat, 26 Mar 2022 11:17:34 -0700

AOK - thanks for the detailed discussion on this!

Joe

—

> On Mar 26, 2022, at 10:54 AM, C. M. Heard <[email-masked]> wrote:
>

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 27 Mar 2022 04:36:16 -0700

In this message I address matters that remain unresolved in
draft-ietf-tsvwg-udp-options-18.

On Thu, Mar 24, 2022 at 7:53 PM Joe  wrote:

> On Mar 24, 2022, at 3:20 PM, C. M. Heard wrote:
>
> [ ... ]

> If AUTH fails on a fragment, reassembly fails. I don’t know that we would
> deliver anything to users when that happens except the zero-length packet
> associated with the failed AUTH.
>

To be consistent with what happens when AUTH fails when applied to whole
datagrams, it seems to me that AUTH failures need to be accumulated and
passed to the upper layer; each UENC failure needs to result in a
zero-length datagram and, ultimately, reassembly failure. I actually think
we are converged to this point of view during the thread "Issues with the
specification of AUTH and UENC in draft-ietf-tsvwg-udp-options-18" (see
https://mailarchive.ietf.org/arch/msg/tsvwg/tiEGEO-0bj2V8m8BfNOjF5E2Kuk/).

> Also noted with WG QUESTION in the text now. I don’t know if we need or
> want either a frag min or frag max size; the max seems like it should be
> determined by the path MTU or interface config.
>

In -18, the text "WG QUESTION: DO WE ALSO WANT A MIN FRAG SIZE? OR MAX?"
ended up after the paragraph on creating receive ports. The requested text
was intended to apply to the paragraph concerning the send function. I
presume that was a mistake. In any case ...

My motivation for requesting that text was to ensure that an application
that performs its own DPLPMTUD will be able to make use of the path MTU
that it discovers by telling the UDP layer how large a UDP fragment can be.
This could include the case where DLPMTUD as documented in
draft-ietf-tsvwg-udp-options-dplpmtud and
RFC 8899 is implemented as a "shim" layer between the application layer and
UDP.

This is not intended to preclude DLPMTUD from being integrated into the UDP
layer -- based on the answer Tom Jones gave to my question during last
Friday's TSVWG session at IETF 113, I think that's the direction many
people expect -- but I don't think we want to mandate that.

I hope that this explanation makes the requested change uncontroversial (or
at least less controversial).

> size, using EOL followed by zeroes, as specified in Section 9.1.

In -18, the requested text ended up in the paragraph on creating receive
ports:

   o  Extend the method to create receive ports to include per-packet
      and per-fragment receive options that are required as indicated
      by the application. Datagrams not containing these required
      options MUST be silently dropped and MAY be logged. This includes
      a minimum datagram length, such that the options list ends in EOL
      and additional space is zero-filled as needed.

The last sentence should be moved to the paragraph concerning the send
function.

Mike Heard

---

From: "[email-masked]" <[email-masked]>
Date: Sun, 27 Mar 2022 08:12:53 -0700

Hi, Mike,

To wrap up on this...

> On Mar 27, 2022, at 4:36 AM, C. M. Heard <[email-masked]> wrote:
> 
> In this message I address matters that remain unresolved in draft-ietf-tsvwg-udp-options-18.
> 
> www.strayalpha.com <http://www.strayalpha.com/>
> 
> To be consistent with what happens when AUTH fails when applied to whole datagrams, it seems to me that AUTH failures need to be accumulated and passed to the upper layer; each UENC failure needs to result in a zero-length datagram and, ultimately, reassembly failure. I actually think we are converged to this point of view during the thread "Issues with the specification of AUTH and UENC in draft-ietf-tsvwg-udp-options-18" (see https://mailarchive.ietf.org/arch/msg/tsvwg/tiEGEO-0bj2V8m8BfNOjF5E2Kuk/ <https://mailarchive.ietf.org/arch/msg/tsvwg/tiEGEO-0bj2V8m8BfNOjF5E2Kuk/>).

Agreed.

> In -18, the text "WG QUESTION: DO WE ALSO WANT A MIN FRAG SIZE? OR MAX?" ended up after the paragraph on creating receive ports. The requested text was intended to apply to the paragraph concerning the send function. I presume that was a mistake.

Location was not intended as necessarily meaningful...

> In any case ...
> 
> My motivation for requesting that text was to ensure that an application that performs its own DPLPMTUD will be able to make use of the path MTU that it discovers by telling the UDP layer how large a UDP fragment can be. This could include the case where DLPMTUD as documented in draft-ietf-tsvwg-udp-options-dplpmtud and RFC 8899 is implemented as a "shim" layer between the application layer and UDP.

I’d like to hear Gorry’s input on this too, but seems OK.

> This is not intended to preclude DLPMTUD from being integrated into the UDP layer -- based on the answer Tom Jones gave to my question during last Friday's TSVWG session at IETF 113, I think that's the direction many people expect -- but I don't think we want to mandate that.
> 
> I hope that this explanation makes the requested change uncontroversial (or at least less controversial).
> 
> In -18, the requested text ended up in the paragraph on creating receive ports:
> 
> The last sentence should be moved to the paragraph concerning the send function.

Agreed.