Re: [middisc] TCP middlebox option requirements

Hi,

I also have no skin in this game. and I'm looking at this list after
months of ignoring it, so I'm way behind in the discussions.

I am concerned that unless severely limited in what it can be used
for, this will lead to other vendor-specific options.
Whether that is good or bad I'll leave to other people to decide, such
as my co-area director Wes, the IETF community and the IESG that will
need to approve any document produced as a result of this discussion.

I will observe that many IETF protocols developed for a limited use
"escape into the wild". This happens ofetn when people decide to
develop a weak or non- security solution and claim it will be only be
used within an enterprise, but it then gains use in the Internet. I
don't know if there is anything you can do to prevent this from
becoming a generic option for vendor-specific features if you design
in a vendor code. The best way to avoid that is to reach agreement on
a standard that does not include a vendor code (which means accepting
that your current products continue to not be compliant to the new
standard).

If you do have vendor-specific options, it will be important to make
sure that each vendor is uniquely identified, so we don't have two
vendors fighting over a vendor code. I recommend registering vendor
codes with IANA to make sure this doesn't happen. 

IANA already maintains an Enterprise Number registry that is used for
many IETF standards. It is a widely used ***standard*** in IETF
standards for identifying vendors using a code number.
http://www.iana.org/assignments/enterprise-numbers. 

Maybe you can convince the IESG that having another set of codes to
identify vendors is important, and that a given vendor will likely
have a different code in your vendor code list than that used by other
standards. It doesn't sound very convincing to me. 

If expansion CAN take place in the future, and now you need 0xff plus
an OUI, you will also have added complexity to TCP, requiring suppoort
for one-byte vendor codes plus OUI support. and you will have added a
new list of vendor codes (whether maintained by IANA or not), and
you'll need to convince IESG all this extra complexity is justified.

I recommend you consider simply using an existing IETF standard
registry already supported by IANA, such as Enterprise Numbers, for
your vendor codes. OR don't support vendor codes at all, and agree on
a single standard.

David Harrington
Director, IETF Transport Area
ietfdbh@comcast.net (preferred for ietf)
dbharrington@huaweisymantec.com
+1 603 828 1401 (cell)

> -----Original Message-----
> From: middisc-bounces@ietf.org 
> [mailto:middisc-bounces@ietf.org] On Behalf Of Eddy, Wesley 
> M. (GRC-MS00)[ASRC AEROSPACE CORP]
> Sent: Thursday, May 27, 2010 12:53 PM
> To: Ron Frederick; Mark Day
> Cc: middisc@ietf.org
> Subject: Re: [middisc] TCP middlebox option requirements
> 
> >-----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
> 