Re: [middisc] TCP middlebox option requirements

[Mark Day <[e-mail]>]

[Ron] A single byte for vendor ID clearly will not scale. There can easily be more than 256 vendors our there who may eventually want to use this option. I don't see any obvious way to do better space-wise than what we proposed with the OUI if we want this to be truly extensible to support all possible vendors.

I may be confused about what we expect will be the future developments in this space, but it's not obvious to me that we need to support more than 256 vendors.  I suppose the key question here is what we mean by "eventually." I thought this option-number reconciliation-and-rationalization was envisioned as a first step toward taking one (or a small number) of the "vendor" codes and using them as a basis for a standardized discovery protocol.  I'm not meaning that this particular group should do it, and certainly not that we should try to do it right now - but I did think that was a shared goal for some point in the future.

We currently have a handful of different proprietary discovery protocols that we are expecting to reconcile at the level of allowing them to multiplex a single consistent option code.  Do we really think that we'll have hundreds of additional discovery protocols between now and when there is agreement on some kind of open-standard discovery protocol(s)?  I just don't see that as a realistic concern, but perhaps I'm misunderstanding.

--Mark