Eric Rescorla <[email protected]> writes:
> My sense is that this is over-design and it would be better just for
> A to send a list and B to pick out of the list. I'm not very compelled by
> the "static option" reason. That's certainly not something I am excited
> about, and I tend to think it would be easier to have a special design
> for SO, if needed at all (since you already need special logic for
> the symmetry-breaking anyway).
We are already saying that implementations SHOULD behave the way you
want them to. So really your question is about whether to upgrade that
to a MUST, and if it is a MUST, whether we should specify the behavior
of host A when host B deviates from the protocol with multiple
suboptions or whether we should leave that behavior unspecified.
I'm not super opposed. There are some plausible ways in which TCPINC
could gain faster deployment with a SHOULD than a MUST. However, at
this point we just don't have enough implementation experience or data
to debate the point productively. So I'd suggest we postpone
consideration of the question until we've had some time to kick the
tires on some candidate TCPINC implementations.
> I forgot to mention something. The text about the ENO option in the non-SYN
> packet doesn't seem entirely clear about what must appear in that option.
> I'm assuming it's the negotiated _spec_ but unless I've missed it, I don't
> see where it actually says that. What happens if that doesn't match the
> highest priority option.
In a non-SYN option, the content doesn't matter, only the presence of
the ENO option. The normative diagram and language were supposed to be
this:
byte 0 1 0 1 2 N-1
+-----+-----+ +-----+-----+-----...----+
|Kind=|Len= | |Kind=|Len= | ignored |
| ENO | 2 | or | ENO | N | by TCP-ENO |
+-----+-----+ +-----+-----+-----...----+
Figure 2: non-SYN TCP-ENO option in segment without SYN flag
...
Figure 2 illustrates the non-SYN form of the ENO option.
Encryption specs MAY include extra bytes in a non-SYN ENO
option, but TCP-ENO itself MUST ignore them.
David
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
