Re: [middisc] middisc specification update

   The ultimate goal is to move towards inter-vendor solutions, which is why we're providing for "standard" types as well as vendor types.  However, this will take some time, so we also have an intermediate goal which is to stop using unassigned option kinds.

Andrew
________________________________________
From: middisc-bounces@ietf.org [middisc-bounces@ietf.org] on behalf of David Harrington [ietfdbh@comcast.net]
Sent: Wednesday, March 07, 2012 7:27 AM
To: Frederick, Ron; Anantha Ramaiah (ananth)
Cc: middisc@ietf.org
Subject: Re: [middisc] middisc specification update

Hi,

I will just observe that the IETF goal is to get cross-vendor
interoperability (and to get vendors to use an assigned code point),
because that helps the Internet run better.

It is not very consistent with IETF goals to define a standard option
through which vendors can add all sorts of proprietary solutions. We
really would like to see industry standardization of middlebox discovery,
not provide a place for vendors to invent a bunch of new non-interoperable
solutions.

--
David Harrington
Director, Transport Area
Internet Engineering Task Force (IETF)
Ietfdbh@comcast.net
+1-603-828-1401

On 3/6/12 10:22 PM, "Frederick, Ron" <ron.frederick@bluecoat.com> wrote:

>On Mar 5, 2012, at 10:56 AM, Anantha Ramaiah (ananth) wrote:
>>> -----Original Message-----
>>> From: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
>>> [mailto:wesley.m.eddy@nasa.gov]
>>> Sent: Monday, March 05, 2012 10:42 AM
>>> To: Anantha Ramaiah (ananth); David Harrington; Wesley Eddy;
>>> middisc@ietf.org
>>> Subject: RE: [middisc] middisc specification update
>>>
>>> Thanks for posting the draft.
>>>
>>> The intention is to handle this as an AD-sponsored document,
>>> not via an IETF working group.
>>>
>>> No presentation is needed.
>>>
>>> When all of the authors have agreed on it and consider it to
>>
>> From my point of view, I am done. Other stakeholders also have reviewed
>> this document and they seem ok with it (as far as I can tell).  They can
>> comment in any case.
>
>I'm generally good with the latest draft, but there are a few items that
>I think we need to address:
>
>1) I think it would be good to rename the option to make it clear that it
>can be used for more than just discovery. The text already describes
>being able to use the option to provide information to other middleboxes
>on the path. I think we just need to emphasize that a bit more and make
>it clear that discovery is only one potential use for the option.
>
>2) The current text explicitly discourages end hosts from participating
>in this exchange. I think that's a mistake. In some cases, a "soft"
>implementation of a middlebox could run directly on a client or a server,
>and it would want to be able to interoperate with other physical
>middleboxes that expect to see this option. We want to be able to support
>that use case by allowing the soft middlebox on one of the end hosts to
>add or respond to this option.
>
>3) I'm good with supporting the single byte vendor code with
>vendor-specific payload data after it, but I think we should at least
>leave some provision in there for the other two cases we previously
>discussed of standard type codes and an escape of some kind for a longer
>vendor code if we're wrong about the adoption of this and we run out of
>space in the single byte.
>
>I think we can address #2 here by reserving vendor code 0xFF for an
>extended vendor code that could be based on something like an OUI. If
>that's too big, we could also do something like say that setting the
>high-bit in the vendor code expands it to 16 bits. So, the first 128
>vendor codes are one byte, and then we get another ~32K of them which are
>two bytes.
>--
>Ron Frederick
>ronf@bluecoat.com
>
>_______________________________________________
>middisc mailing list
>middisc@ietf.org
>https://www.ietf.org/mailman/listinfo/middisc

_______________________________________________
middisc mailing list
middisc@ietf.org
https://www.ietf.org/mailman/listinfo/middisc