Re: [core] Vendor-specific options

[Carsten Bormann <[e-mail]>]

On Jan 19, 2012, at 11:46, Alper Yegin wrote:

> Let's call it vendor-specific option, not user-defined option though.

(Option names are a bike shed color decision, so I'm sorry for responding to this, but:

You don't have to sell anything to define such an option :-)

But given all the "vendoring" that is going on, I don't have a strong opinion.)

                    .oOo.

Now back to the question:

> I think this makes sense.

Are there other people who want to do something in this space?

                    .oOo.

Let me quickly explain why I think the obvious approaches don't work:


1) Just squatting on option numbers.

This creates a lot of problems in other protocols.
Products that use squatted-on option numbers get deployed and make the number unavailable for any further use (even if the product then fades out).
Squatting is somewhat more acceptable for text-named options (lower probability of collision), but works very badly for a small number space.
Even more so as there are "good" and "worse" numbers (amount of fence posting required): the small numbers will be quickly squatted away for vendor vanity options, and we get to assign 93 for the next standards-based option.
There is a reason why coap-core defines the option number space as:

   The IANA policy for future additions to this registry is "IETF
   Review" as described in [RFC5226].


2) Defining a small "experimental" range.

This essentially means all the squatting is focused on a small range.
This works so badly in practice that tcpm has a draft trying to define a way to survive their current setup.

	draft-touch-tcpm-experimental-options-00.txt

TCP options and CoAP options pose related requirements, but are not the same.

I think Joe and I developed our proposals in parallel, from the same kind of thinking.
Joe is prepared to spend 32 bits for option identification, I'm *trying* to be a bit more frugal, but that works only very well for vendors (here they are again) that have been in play for long enough to have a 14-bit or smaller enterprise ID.
(16384 is "California State Polytechnic University, Pomona"…)

Creating a new registry for CoAP option vendor-IDs would be possible, but I'm not convinced yet we want to set this up.
Among other considerations, most companies in this space already need an enterprise number, so it is much more stealthy to use this instead of applying for a number out of a focused registry...

Grüße, Carsten