[tsvwg] Comments on draft-ietf-tsvwg-udp-options-02

["C. M. Heard" <[e-mail]>]

Greetings,

Some issues came to my attention during a recent off-list discussion with
someone from the DNS community.

Section 5.4, Alternate Checksum (ACS): since the option area is not
included in the ACS, the following text seems out of place:

   When ACS is computed, its checksum (CRC) area is zeroed. No other
   options are zeroed before computing ACS.


All that is needed is to stuff the remainder of the standard polynomial
long division in the ACS checksum area.

There are also some issues that need to nailed down for clarity. the usual
way that the specified polynomial is used is to invert the first 16 bits of
data and transmit the complement of the resulting polynomial division. If
that is not done here, it would probably be good to say so. Also, it is
necessary to specify whether the data polynomial is constructed as if the
bytes are transmitted most significant bit first or least significant bit
first. Finally, the polynomial is x^16 + x^12 + x^5 + 1 (which would be
0x11021, but that fact is not needed, and I recommend omitting it).

Section 5.5, LITE option: the following instruction

   3. Swap all four bytes of the LITE option with the first 4 bytes of
      the LITE data area (Figure 11).


works only if the LITE data area is at least four bytes long. However, the
option will work just fine with 0, 1, 2, or 3 bytes of LITE data if one
simply moves the option to the start of the LITE data area and moves the
displaced LITE bytes just past the end of the relocated LITE option. This
operation is then reversed on the receive side. In effect, one is swapping
the locations of the LITE option and the initial segment of the LITE data
area of length min(4, LITE offset).

Note that being able to use the LITE option with a length of zero is
important for option negotiation.

Section 5,8, FRAG option: it appears to me that the length of the the
terminal FRAG option is 10 bytes, not 12. This isn't stated, but the
inference I make is that the the checksum is the standard UDP checksum,
computed as if the datagram were sent unfragmented, but not including the
pseudo-header (to avoid issues created by NAT). If this isn't what was
intended, then the intent needs to be clearly spelled out. I note that if
the alternate checksum as defined in Section 5.4 does not admit the use of
the value zero to indicate that it is not present.

Section 5.8.1, Coupling FRAG with LITE: if the comments above about the
checksum field in the terminal FRAG option are correct, some text should be
added here that the final checksum in the reconstituted UDP header is not
taken directly from the terminal fragment, but is adjusted to include the
UDP pseudo-header.

Section 8, UDP options vs. UDP-Lite: Is the following paragraph left over
from a previous incarnation of the draft?

   UDP options support a similar service to UDP-Lite by terminating the
   UDP options with an EOL option. The additional data not covered by
   the UDP checksum follows that EOL option, and is passed to the user
   separately. The difference is that UDP-Lite provides the un-
   checksummed user data to the application by default, whereas UDP
   options can provide the same capability only for endpoints that are
   negotiated in advance (i.e., by default, UDP options would silently
   discard this non-checksummed data). Additionally, in UDP-Lite the
   checksummed and non-checksummed payload components are adjacent,
   whereas in UDP options they are separated by the option area -
   which, minimally, must consist of at least one EOL option.


It seems to me that this should be rewritten, because the service in
question is now provided by the LITE option.

I'm hoping that there is still enough interest in this draft to push it to
completion.

Thanks and regards,

Mike Heard