Re: [middisc] TCP middlebox option requirements

[Andrew Knutsen <[e-mail]>]

    What about the OUI option, which would bypass the vendor code 
assignment (although whoever used it could be assumed to be aware of the 
spec for the option kind)?

Andrew

Lars Eggert wrote:
> Hi,
>
> 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).
>
> Lars