On 5/15/2013 11:08 AM, Ted Lemon wrote:
On May 15, 2013, at 1:23 PM, Joe Touch <touch(_at_)isi(_dot_)edu> wrote:
You don't agree that the motivation for the difference between using 16-bit vs.
32-bit ExIDs is sufficient, even though that is already discussed in the
document.
I don't think this is a topic that the IETF as a whole is likely to
find very interesting. However, if anyone is curious, they are welcome
to read the DISCUSS here and see if they agree with your
characterization of my question:
http://datatracker.ietf.org/doc/draft-ietf-tcpm-experimental-options/ballot/
For those who may be interested, the last sentence of the first
paragraph is the motivation for this being a DISCUSS position (as
opposed to a comment).
Which is "I think that using a 4-byte ExID runs a real risk of
overflowing the available space in the TCP header in real-world
circumstances."
Except that the document already describes the ExID as either 16-bit or
32-bit:
>> All ExIDs MUST be either 16-bits or 32-bits long.
Motivation for the additional two bytes is already explained in the
document in several places, notably:
The second two bytes serve as a "magic number".
...
Using the additional magic number bytes helps the option contents
have the same byte alignment in the TCP header as they would have if
(or when) a conventional (non-experiment) TCP option codepoint is
assigned. Use of the same alignment reduces the potential for
implementation errors, especially in using the same word-alignment
padding, if the same software is later modified to use a
conventional codepoint. Use of the longer, 32-bit ExID further
decreases the probability of such a false positive compared to those
using shorter, 16-bit ExIDs.
...
Use of the longer, 32-bit ExID consumes more
space, but provides more protection against false positives.
Which is why I feel this motivation isn't sufficient for a DISCUSS.
I'd be glad to hear others' view of this as well.
Joe