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

[Joe Touch <[e-mail]>]

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)
>
> -----------------------------------------------------------------------
>
>
>
>
>
>
>