[tsvwg] BCP 14 uppercase words vs. ">>" markers in draft-ietf-tsvwg-udp-options-22

[Erik Auerswald <[e-mail]>]

Hi,

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.


Regards,
Erik

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/'