Consistent use of ">>" as a marker

[gorryfair]

Erik noted draft-ietf-tsvwg-udp-options-22 uses ">>" as a marker to indicate paragraphs with BCP 14 nomenclature. This seems to be not yet completely consistent.

A) There seem to be four instances where the marked paragraph does not contain BCP 14 key words:

A.1) In section 8 on page 12:

UNSAFE options are used only with the FRAG option, in a manner that prevents them from being silently ignored while still passing up potentially modified UDP payload. This ensures their safe use in environments that might include legacy receivers (See Section 10), because the UDP payload occurs inside the FRAG option area and is silently discarded by legacy receivers.

A.2) In section 9.4 on page 18:

During fragmentation, the UDP header checksum of each fragment remains constant and does not depend on the fragment data (which appears in the surplus area), because all fragments have a zero- length user data field.

A.3) In section 11 on page 27:

UNSAFE options can both depend on and vary user data content because they are contained only inside UDP fragments and thus are processed only by UDP option capable receivers.

A.4) In section 11 on page 28:

o >> Only FRAG and UNSAFE options are permitted to modify the UDP body.

B) There seem to be twelve instances where a paragraph containing BCP 14 key words is not marked with ">>":

B.1) In section 8 on page 13:

Receivers cannot generally treat unexpected option lengths as invalid, as this would unnecessarily limit future revision of options (e.g., defining a new APC that is defined by having a different length). The exception is only for lengths that imply a physical impossibility, e.g., smaller than two for conventional options and four for extended length options. Impossible lengths SHOULD be treated as an indication of a malformed surplus area and all options SHOULD silently be discarded. Lengths other than those expected should result in safe options being ignored and skipped over, as with any other unknown safe option.

B.2) In section 9.4 on page 20:

  Process these UDP options before the rest of the fragmentation
  steps below. Note that the OCS value of the original packet
  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).

B.3) In section 9.4 on page 21:

The OCS value for the reassembled datagram SHOULD be zero, because either the original UDP CS=0 or OCS!=0 in each of the fragments.

B.4) In section 9.4 on page 21:

Reassembly failures at the receiver result in silent discard of any per-fragment options and fragment contents. To emulate the behavior of a legacy host, any initial fragments received but not successfully reassembled SHOULD each generate a zero-length UDP application message.

B.5) In section 9.4 on page 21:

Finally, because fragmentation processing can be expensive, the FRAG option SHOULD be avoided unless the original datagram requires fragmentation or it is needed for "safe" use of UNSAFE options. Users MAY also select the FRAG option to support limited header processing.

B.6) In section 9.5 on page 21:

The Maximum Datagram Size (MDS, Kind=4) option is a 16-bit hint of the largest unfragmented UDP packet that an endpoint believes can be received. As with the TCP Maximum Segment Size (MSS) option [RFC9293], the size indicated is the IP layer MTU decreased by the fixed IP and UDP headers only [RFC9293]. The space needed for IP and UDP options need to be adjusted by the sender when using the value indicated. The value transmitted is based on EMTU_R, the largest IP datagram that can be received (i.e., reassembled at the receiver) [RFC1122]. However, as with TCP, this value is only a hint at what the receiver believes; it does not indicate a known path MTU and thus MUST NOT be used to limit transmissions.

B.7) In section 9.5 on page 21:

The UDP MDS option MAY be used as a hint for path MTU discovery [RFC1191][RFC8201], but this may be difficult because of known issues with ICMP blocking [RFC2923] as well as UDP lacking automatic retransmission. It is more likely to be useful when coupled with IP source fragmentation or UDP fragmentation to limit the largest reassembled UDP message as indicated by MRDS (see Section 9.6), e.g., when EMTU_R is larger than the required minimums (576 for IPv4 [RFC791] and 1500 for IPv6 [RFC8200]). It can also be used with DPLPMTUD [RFC8899] to provide a hint to maximum DPLPMTU, though it MUST NOT prohibit transmission of larger UDP packets (or fragments) used as DPLPMTU probes.

B.8) In section 13 on page 30:

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.

B.9) In section 13 on page 30:

o SAFE options associated with fragments are accumulated when associated with the reassembled packet; values MAY be coalesced, e.g., to indicate only that an AUTH failure of a fragment occurred or not rather than indicating the AUTH status of each fragment.

B.10) In section 14 on page 31:

UDP options are transport options. Generally, transport headers, options, and data are not intended to be modified in-transit. UDP options are no exception and here are specified as "MUST NOT" be altered in transit. However, the UDP option mechanism provides no specific protection against in-transit modification of the UDP header, UDP payload, or surplus area, except as provided by the OCS or the options selected (e.g., AUTH, or UENC).

B.11) In section 23 on page 37:

Although option nicknames are not used in-band, new UNSAFE safe option names SHOULD commence with the capital letter "U" and avoid either uppercase or lowercase "U" as commencing safe options.

B.12) In appendix A on page 43:

The following option is included for debugging purposes, and MUST NOT be enabled otherwise.

P.S. I have used "rfcstrip" from Henrik Levkowetz and "awk" to check this:

 rfcstrip draft-ietf-tsvwg-udp-options-22.txt | awk -v RS='' -v ORS=$'\n--\n' '/>>/ && !/MUST|SHOULD|REQUIRED|SHALL|RECOMMENDED|MAY|OPTIONAL/'

 rfcstrip draft-ietf-tsvwg-udp-options-22.txt | awk -v RS='' -v ORS=$'\n--\n' '!/>>/ && /MUST|SHOULD|REQUIRED|SHALL|RECOMMENDED|MAY|OPTIONAL/'

[jtouch]

Thanks - these are all incorporated (I think) in -23; I will need to continue to check, but the RFC Editor also checks upon final publication as well.

[auerswal]

Thanks. I still see two missing >> markers:

1. In section 9.4, page 21:

   1. Create a UDP packet with data and UDP options. This is the
      original UDP datagram, which we will call "D". The UDP options
      follow the UDP user data and occur in the surplus area, just as
      in an unfragmented UDP datagram with UDP options. These options
      MUST be fully prepared before the rest of the fragmentation steps
      that follow here.

2. In section 9.5, page 23:

   MDS is more likely to be useful when coupled with IP source
   fragmentation or UDP fragmentation to limit the largest reassembled
   UDP message as indicated by MRDS (see Section 9.6), e.g., when
   EMTU_R is larger than the required minimums (576 for IPv4 [RFC791]
   and 1500 for IPv6 [RFC8200]). It can also be used with DPLPMTUD
   [RFC8899] to provide a hint to maximum DPLPMTU, though it MUST NOT
   prohibit transmission of larger UDP packets (or fragments) used as
   DPLPMTU probes.

The command lines above produce a third instance in section 20 on page 37, but that is a quote from RFC 3095 and should not be marked with >> in this draft.

[jtouch]

Thanks - will check and update all three as needed in next rev.

[gorryfair]

Thought to be resolved when new text is in the next rev.

[jtouch]

I believe these have been addressed in -24.

[Mike-Heard]

Some residual edits are needed:

OLD:

>> MSD can be used with DPLPMTUD [RFC8899] to provide a hint to maximum DPLPMTU, though it MUST NOT prohibit transmission of larger UDP packets (or fragments) used as DPLPMTU probes.

NEW:

>> MDS can be used with DPLPMTUD [RFC8899] to provide a hint to maximum PMTU, though it MUST NOT prohibit transmission of larger UDP packets used as DPLPMTUD probes.

[jtouch]

fixed in -25

[auerswal]

There is still the typo of using "MSD" instead of "MDS" in the second to last paragraph of section 11.5. (I do think that it is OK to distinguish between "PMTU" and "DPLPMTU", since "PMTU" usually refers to IP, but MDS refers to UDP.)

[jtouch]

Fixed in -26. Thank you.

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

On Nov 13, 2023, at 5:53 AM, Erik Auerswald @.***> wrote:

There is still the typo of using "MSD" instead of "MDS" in the second to last paragraph of section 11.5. (I do think that it is OK to distinguish between "PMTU" and "DPLPMTU", since "PMTU" usually refers to IP, but MDS refers to UDP.)

— Reply to this email directly, view it on GitHub https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/9#issuecomment-1808206327, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJVISGPKZ3FYJGFIWWIYCTYEIQ5FAVCNFSM6AAAAAAZ2ZMHIWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBYGIYDMMZSG4. You are receiving this because you commented.

[jtouch]

Make that -27 — Dr. Joe Touch, temporal epistemologist www.strayalpha.com

On Nov 13, 2023, at 7:43 AM, @.*** wrote:

Fixed in -26. Thank you.

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

On Nov 13, 2023, at 5:53 AM, Erik Auerswald @.***> wrote:

There is still the typo of using "MSD" instead of "MDS" in the second to last paragraph of section 11.5. (I do think that it is OK to distinguish between "PMTU" and "DPLPMTU", since "PMTU" usually refers to IP, but MDS refers to UDP.)

— Reply to this email directly, view it on GitHub https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/9#issuecomment-1808206327, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJVISGPKZ3FYJGFIWWIYCTYEIQ5FAVCNFSM6AAAAAAZ2ZMHIWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBYGIYDMMZSG4. You are receiving this because you commented.

[gorryfair]

">>" marker now seems to be consistent throughout the document