Re: [middisc] TCP middlebox option requirements

    One issue I just remembered with the OUI, and I can't remember who 
brought it up, is that it opens the option to "safe" (but unsanctioned) 
use for arbitrary purposes by anyone with an OUI. With vendor codes, we 
can specify criteria for assignment, so the vendor would be breaking 
their agreement if they used it for other purposes.

    It seems like this might be an IESG policy issue.  Lars, are you 
still here?

Andrew

Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:
>> -----Original Message-----
>> From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On
>> Behalf Of Ron Frederick
>> Sent: Thursday, May 27, 2010 12:44 PM
>> To: Mark Day
>> Cc: middisc@ietf.org
>> Subject: Re: [middisc] TCP middlebox option requirements
>>
>> ...
>>
>> If this is really the case, it would be a mistake to limit the total
>> number of type codes across all vendors to 256. We'd basically be
>> repeating the mistake that led to this effort in the first place, where
>> TCP options as a whole have a space of 256 options and we're currently
>> using multiple of those to solve this problem.
>>     
>
>
> I don't have skin in the game, but on reading this thread, my
> thought was that it's probably possible to use a single byte,
> but define one codepoint (like 0xFF) to mean "use a full OUI
> which follows".  This way you can start with using a single
> byte given the relatively small number of vendors today, and
> have a way to accommodate larger numbers in the future, if
> the need arises.
>
> This only works if the means of extending to a full OUI is
> part of the base specification and everyone has to support
> it, otherwise there are backwards-compatibility issues when
> someone tries to use it in the future.
>
> --
> Wes Eddy
> MTI Systems
>
>
> _______________________________________________
> middisc mailing list
> middisc@ietf.org
> https://www.ietf.org/mailman/listinfo/middisc
>