Re: [tcpm] TCP option kind number for TCP Fast Open

[Joe Touch <[e-mail]>]

On 10/1/2014 3:59 PM, Scharf, Michael (Michael) wrote:
> Hi Joe,
> 
> Isn't 29 allocated to RFC 5925? Do you mean 25?

Yup.

> My thinking is that right now we have enough option numbers to avoid
> the ones for which unauthorized use has been reported.

It might be useful to consider that use. TCPCT was only in a draft, and
the final code ended up using 253.

And 25 was returned for reuse.

> While we clearly
> do not accept unauthorized use of option numbers, the IETF should
> probably not create known interop issues as long as this can be avoided,
> imho. We may indeed have to discuss this question at some point in
> future, e.g., when more than 50% of the codepoints are allocated. But I
> am not sure whether this will ever happen in the foreseeable future.

I disagree, if only because it makes it even more attractive to
squatters to claim we'll do this.

Joe

> 
> Michael
> 
> 
> ________________________________________
> Von: Joe Touch [[e-mail]]
> Gesendet: Donnerstag, 2. Oktober 2014 00:19
> An: Scharf, Michael (Michael); [e-mail]
> Cc: [e-mail]
> Betreff: Re: [tcpm] TCP option kind number for TCP Fast Open
> 
> Hi, Michael,
> 
> 29 is unassigned and available.
> 
> Also, IMO, we should not shy away from using numbers that others are
> squatting on. E.g., 31-31 was only used by TCPCT in Internet Drafts;
> when it was released, it was implemented using 253 and AFAICT only in
> Linux versions that have since been cleaned up.
> 
> Joe
> 
> On 10/1/2014 8:26 AM, Scharf, Michael (Michael) wrote:
>> Hi all,
>>
>> According to TCPM consensus, the plan is to allocate TCP option kind number 34 for TCP fast open. This number is "reserved" according to http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml.
>>
>> If there are suggestions that another value would be more appropriate, please speak up ASAP.
>>
>> Best regards
>>
>> Michael
>>
>>
>>
>> -----Original Message-----
>> From: IETF-Announce [mailto:[e-mail]] On Behalf Of The IESG
>> Sent: Tuesday, September 30, 2014 11:36 PM
>> To: IETF-Announce
>> Cc: tcpm chair; tcpm mailing list; RFC Editor
>> Subject: Document Action: 'TCP Fast Open' to Experimental RFC (draft-ietf-tcpm-fastopen-10.txt)
>>
>> The IESG has approved the following document:
>> - 'TCP Fast Open'
>>   (draft-ietf-tcpm-fastopen-10.txt) as Experimental RFC
>>
>> This document is the product of the TCP Maintenance and Minor Extensions
>> Working Group.
>>
>> The IESG contact persons are Martin Stiemerling and Spencer Dawkins.
>>
>> A URL of this Internet Draft is:
>> http://datatracker.ietf.org/doc/draft-ietf-tcpm-fastopen/
>>
>>
>>
>>
>>
>> Technical Summary
>>
>>    This document describes an experimental TCP mechanism TCP Fast Open
>>    (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets
>>    and consumed by the receiving end during the initial connection
>>    handshake, thus saving up to one full round trip time (RTT)
>>    compared to the standard TCP, which requires a three-way handshake
>>    (3WHS) to complete before data can be exchanged. However TFO
>>    deviates from the standard TCP semantics since the data in the SYN
>>    could be replayed to an application in some rare
>>    circumstances. Applications should not use TFO unless they can
>>    tolerate this issue detailed in the Applicability section.
>>
>> Working Group Summary
>>
>>   This document was extensively discussed and reviewed by the TCPM
>>   working group and there is strong support to publish the
>>   document. While being an experimental document, the TCPM working
>>   group decided to ask IESG for approving an IANA allocation of a new
>>   TCP option codepoint.
>>
>> Document Quality
>>
>>   The protocol extension described in this document is implemented and
>>   deployed in the Linux TCP/IP stack, and it is supported by the Chrome
>>   Web browser and all Google servers. Experimental results have been
>>   discussed in the TCPM working group. An early SECDIR review
>>   concluded that the document had no substantive issues.
>>
>> Personnel
>>
>>   The Document Shepherd is Michael Scharf
>>   <[e-mail]>. The Responsible Area Director
>>   is Martin Stiemerling <[e-mail]>.
>>
>>
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm
>>