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

[Joe Touch <[e-mail]>]

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)

-----------------------------------------------------------------------