Re: [tcpm] request for feedback - proposed update to draft-touch-tcpm-experimental-options

[[e-mail]]

This sounds good. You could consider citing one of the existing longer
value as a concrete example.

Gorry

> PS - one additional point:
>
> 	regardless of the length that might be registered with IANA,
> 	using a longer experiment ID might still be useful, since
> 	it helps guard against both squatters and those who don't
> 	support this mechanism
>
> I'll be sure to include that in the update if we converge on this
> approach.
>
> Joe
>
> On 2/15/2013 11:56 AM, Joe Touch wrote:
>> Hi, all,
>>
>> The IESG has reviewed draft-touch-tcpm-experimental-options and is
>> holding the document up on two key concerns:
>>
>>      I. the lack of a registry for magic numbers
>>
>>      II. potential for prefix collision within the set of magic numbers
>>      supported in a single implementation
>>
>> Addressing their concerns would involve a substantive change to the
>> draft, so I would appreciate some feedback on the following possible
>> solution before updating the document.
>>
>> Please post your comments on this proposed change.
>>
>> Here's what we need to know:
>>
>> 1. do you agree with change (A)?
>>
>> 2. do you agree with change (B)?
>>
>> 3. do you agree with change (C)?
>>
>>      if so, which variant (i), (ii), (iii)?
>>
>> My preference is:
>>      A yes
>>      B yes
>>      C yes
>>          first choice (i)
>>          second choice (iii)
>>          (I think (ii) is inelegant)
>>
>> Thanks,
>>
>> Joe
>>
>> -----------------------------------------------------------------------
>>
>> PROPOSED CHANGES:
>>
>>      A) change the name from MAGIC NUMBER to "experiment ID"
>>
>>      Rationale: because the new value will be delegated by IANA,
>>      it no longer qualifies as a self-assigned "magic number"
>>
>>      B) request that IANA register experiment IDs
>>      The procedure would be:
>>          FCFC assignment from among unassigned values
>>          zero hurdle for assignment (no ID required)
>>          OK to indicate multiple assignees
>>              list in the order of request
>>
>>      Rationale: Needed to satisfy IANA concern (I) above.
>>
>>      C) Specify a more limited number of sizes to avoid overlap
>>
>>      Here's a list of the current known uses of the magic
>>      number as already proposed in this doc:
>>
>>      draft-ietf-tcpm-fastopen-02
>>              0xF989
>>
>>      draft-fox-tcpm-shared-memory-rdma-01
>>              0xE2D4C3D9
>>
>>      draft-sarolahti-irtf-catcp-00
>>              0x20120229
>>
>>      draft-trammell-tcpm-timestamp-interval-00
>>              0x75ec
>>
>>      i) Given this, my first inclination - given we'd be using
>>      an IANA registry - would be to just stick to 16-bits,
>>      and assign the values for current uses to be consistent.
>>
>>      ii) a second variant would be 16- and 32-bit values
>>
>>          a) assign as follows to be compatible with current use:
>>              16-bit    0x0000 - 0x7FFF
>>                  0xF000 - 0xFFFF
>>
>>              32-bit    0x8000 0000 - 0xEFFF 0000
>>
>>              This allows all current known uses unchanged.
>>
>>          b) assign according a simpler split, and assign a large
>>          range to one of the members above:
>>
>>              16-bit    0x0000 - 0x7FFF
>>
>>              32-bit    0x8000 0000 - 0xFFFF FFFF
>>
>>              All current uses would be unchanged except:
>>
>>              fastopen    0xF989 0000 - 0xF989 FFFF
>>
>>              catcp        0x2012
>>
>>              (note - this would be updated in their spec,
>>              but need not affect their implementations)
>>
>> -----------------------------------------------------------------------
>>
>>
>>
>>
>>
>>
>>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>