Re: [middisc] middisc specification update

David Harrington <ietfdbh@comcast.net> Wed, 07 March 2012 15:27 UTC

Return-Path: <ietfdbh@comcast.net>
X-Original-To: middisc@ietfa.amsl.com
Delivered-To: middisc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0374021F86BD for <middisc@ietfa.amsl.com>; Wed, 7 Mar 2012 07:27:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.252
X-Spam-Level:
X-Spam-Status: No, score=-102.252 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZffrx0CKV4s for <middisc@ietfa.amsl.com>; Wed, 7 Mar 2012 07:27:09 -0800 (PST)
Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id 26CF121F86B0 for <middisc@ietf.org>; Wed, 7 Mar 2012 07:27:09 -0800 (PST)
Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta10.westchester.pa.mail.comcast.net with comcast id idP71i0091ap0As5AfT9RE; Wed, 07 Mar 2012 15:27:09 +0000
Received: from [192.168.1.33] ([71.233.85.150]) by omta22.westchester.pa.mail.comcast.net with comcast id ifT71i00h3Ecudz3ifT8zE; Wed, 07 Mar 2012 15:27:09 +0000
User-Agent: Microsoft-MacOutlook/14.14.0.111121
Date: Wed, 07 Mar 2012 10:27:05 -0500
From: David Harrington <ietfdbh@comcast.net>
To: "Frederick, Ron" <ron.frederick@bluecoat.com>, "Anantha Ramaiah (ananth)" <ananth@cisco.com>
Message-ID: <CB7CE72B.1E2B6%ietfdbh@comcast.net>
Thread-Topic: [middisc] middisc specification update
In-Reply-To: <56A8F14C-C1E1-4793-BC82-F27E89A9F8D4@bluecoat.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: "middisc@ietf.org" <middisc@ietf.org>
Subject: Re: [middisc] middisc specification update
X-BeenThere: middisc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussions on TCP option for middlebox discovery." <middisc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/middisc>, <mailto:middisc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/middisc>
List-Post: <mailto:middisc@ietf.org>
List-Help: <mailto:middisc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/middisc>, <mailto:middisc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Mar 2012 15:27:10 -0000

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