[tcpm] draft-ietf-tcpm-experimental-options

["Mahdavi, Jamshid" <[e-mail]>]

I have reviewed this proposed draft.  I don't believe that commercial vendors who have TCP option needs would view this as changing the current landscape at all.  If your intent is to provide a new alternative that "cooperating protocol designers" could use, in my opinion this is not meeting the need.

(If your intent is just to make it safer and easier to use the experimental TCP options for actual experiments, you can ignore the rest of this email.)

The draft claims that experimental TCP options are
          "intended to be used both in controlled environments and in are allowed in public deployments (when not enabled as default) [RFC3962]"
(Side note:  typo "in", and the citation is wrong, it should be 3692.)

However, that goes against other documentation - for example these statements in 3692:

"Mutually consenting devices could use these numbers for whatever purposes they desire, but under the understanding that they are reserved for generic testing purposes" (i.e. not for production use)

"They are not intended to be used in general deployments or be enabled by default in products or other general releases."  (my reading of that has always been, "not intended for use in the public Internet")

And, on the IANA assigned numbers:

"RFC3692-style Experiment 1 (also improperly used for shipping products)" - clearly implying these are not intended for use in commercial products.

Finally, the draft itself implies the experimental option usage is still intended to be temporary in the discussion "Migration to Assigned Options".
(Another side note:  I'd have concerns about implementing the proposed migration mechanism in practice due to the creation of extra connections which would just be dropped.)

In the absence of a better solution, a vendor may find using an experimental option to be preferable to squatting somewhere else in the option space, but this draft in its current form does not really appear to change any of the underlying rules which suggest experimental options are not intended for this type of use.

One other suggestion for the draft:  it might merit a word or two in the security considerations how this draft might affect the firewall processing of TCP options 253 and 254.  Having the IANA registry suggested elsewhere in the thread would actually help firewalls to have better visibility into the contents of these options to be more selective about what to allow.

--Jamshid