Re: [middisc] TCP middlebox option requirements

Lars Eggert <lars.eggert@nokia.com> Tue, 01 June 2010 09:22 UTC

Return-Path: <lars.eggert@nokia.com>
X-Original-To: middisc@core3.amsl.com
Delivered-To: middisc@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A863D3A6959 for <middisc@core3.amsl.com>; Tue, 1 Jun 2010 02:22:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.705
X-Spam-Level:
X-Spam-Status: No, score=-4.705 tagged_above=-999 required=5 tests=[AWL=-0.706, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76G0IuhtBt1V for <middisc@core3.amsl.com>; Tue, 1 Jun 2010 02:22:15 -0700 (PDT)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 6319F3A6950 for <middisc@ietf.org>; Tue, 1 Jun 2010 02:22:15 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o519LcWn002750; Tue, 1 Jun 2010 12:21:56 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Jun 2010 12:21:48 +0300
Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Jun 2010 12:21:48 +0300
Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o519LmL4018188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Jun 2010 12:21:48 +0300
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.96.1 at fit.nokia.com
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset="us-ascii"
From: Lars Eggert <lars.eggert@nokia.com>
In-Reply-To: <4BFEF23D.5060005@bluecoat.com>
Date: Tue, 01 Jun 2010 12:21:41 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <4D77FCA9-A50D-4BE2-BEF6-0C688888402C@nokia.com>
References: <0C53DCFB700D144284A584F54711EC5809BD740A@xmb-sjc-21c.amer.cisco.com> <4BF6CF8A.5030707@bluecoat.com> <AF3CDDFAE1BB6C41B8F9EF3F4ADA9D11ADAB3597@MAILBOXES2.nbttech.com> <4BFC6B29.1080706@bluecoat.com> <2A7D4A79-0E08-480F-A67B-35338D226E14@bluecoat.com> <AF3CDDFAE1BB6C41B8F9EF3F4ADA9D11ADB9D3D6@MAILBOXES2.nbttech.com> <93730462-B3C5-4ACA-8C0A-C69F52BF0822@bluecoat.com> <B583FBF374231F4A89607B4D08578A4303EB17F3@bcs-mail03.internal.cacheflow.com> <ECD8F3EA-A5DB-4B47-B33F-E8952A6D2B4E@bluecoat.com> <4BFEF23D.5060005@bluecoat.com>
To: Andrew Knutsen <andrew.knutsen@bluecoat.com>
X-Mailer: Apple Mail (2.1078)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.fit.nokia.com); Tue, 01 Jun 2010 12:21:42 +0300 (EEST)
X-OriginalArrivalTime: 01 Jun 2010 09:21:48.0558 (UTC) FILETIME=[DCAC02E0:01CB016B]
X-Nokia-AV: Clean
Cc: "middisc@ietf.org" <middisc@ietf.org>, Ron Frederick <ronf@bluecoat.com>
Subject: Re: [middisc] TCP middlebox option requirements
X-BeenThere: middisc@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussions on TCP option for middlebox discovery." <middisc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 01 Jun 2010 09:22:16 -0000

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