Re: [middisc] TCP middlebox option requirements

[Ron Frederick <[e-mail]>]

On Jun 1, 2010, at 2:21 AM, Lars Eggert wrote:
> On 2010-5-28, at 1:29, Andrew Knutsen wrote:
>>    What I was thinking is simply that there would be a stipulation (in the option spec) that when an entity applied for a vendor code that they'd use it for the specified purpose.  Ie, not for some other purpose, or just to sit on. Then, if the option was seen "in the wild" being used inappropriately, the vendor would have an interest in not doing that since they'd be publicly breaking their agreement.  No police (unless you count the vendor itself), just peer pressure, so to speak. 
> 
> that seems like a reasonable approach. From the IETF perspective, we'd want to assign an option number for middlebox discovery techniques, with enough flexibility in the description that the option could be shared by and work with the techniques different vendors employ. But we wouldn't want to allow arbitrary flexibility, so that the option could be used for any vendor-specific purpose.
> 
> Obviously, the IETF cannot police whether implementations/vendors will comply. (We can't even police if folks are using option numbers without proper assignment...) The best we can hope for is, as Andrew says, some sort of community fingerpointing if a vendor disregards and goes beyond the stated use case of the option (middlebox discovery).

I agree that we'd want some kind of accountability here, and I think the OUI would give us that just as much accountability as some new IANA registry of vendor codes for this option would. For me, it just comes down to the question of how much space we think we can afford.

In our original proposal, standard versions of this option would cost 2 bytes for the type code and vendor-specific versions would cost 5 bytes. While we could squeeze things down to a single byte type code and single byte vendor ID to make both versions fit in 2 bytes, this severely limits the amount of room we have to grow either of those spaces if the option gets a lot of use. It all comes down to how many different applications we think will eventually find value in this.
-- 
Ron Frederick
[e-mail]