[middisc] TCP middlebox option requirements

"Knutsen, Andrew" <andrew.knutsen@bluecoat.com> Wed, 08 June 2011 21:44 UTC

Return-Path: <andrew.knutsen@bluecoat.com>
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 BBB0E11E80A0 for <middisc@ietfa.amsl.com>; Wed, 8 Jun 2011 14:44:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+z2MQZnJ41V for <middisc@ietfa.amsl.com>; Wed, 8 Jun 2011 14:44:22 -0700 (PDT)
Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by ietfa.amsl.com (Postfix) with ESMTP id 584A711E809B for <middisc@ietf.org>; Wed, 8 Jun 2011 14:44:19 -0700 (PDT)
Received: from PWSVL-EXCHTS-01.internal.cacheflow.com ([10.2.2.122]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id p58LiIDK009753 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <middisc@ietf.org>; Wed, 8 Jun 2011 14:44:18 -0700 (PDT)
Received: from PWSVL-EXCMBX-01.internal.cacheflow.com ([fe80::15bc:12e2:4676:340f]) by PWSVL-EXCHTS-01.internal.cacheflow.com ([fe80::5c50:e2ba:8115:4223%20]) with mapi id 14.01.0255.000; Wed, 8 Jun 2011 14:44:13 -0700
From: "Knutsen, Andrew" <andrew.knutsen@bluecoat.com>
To: "middisc@ietf.org" <middisc@ietf.org>
Thread-Topic: TCP middlebox option requirements
Thread-Index: AcwmI0zFfltUolLcSMitiuc7V9sSUA==
Date: Wed, 08 Jun 2011 21:44:12 +0000
Message-ID: <974FE049BD0F2E4188567FAD99DEF03301B4BD@PWSVL-EXCMBX-01.internal.cacheflow.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [216.52.23.68]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [middisc] TCP middlebox option requirements
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, 08 Jun 2011 21:44:22 -0000

   While we're waiting for any more details that may help us reach consensus on the format of the option, I've been thinking about the text we'll use to restrict its uses.  This text would be guidance to the IANA (or other assigning authority) to determine when to assign a vendor or standard code.  It could also be used for policing after assignment, but thats a bit more problematic (although that's all that would be possible in the OUI/PEN case).

   There are a few details to be considered, but I'm curious about one thing which is perhaps fundamental:

   Do we anticipate any use of this option where the intended consumer of the option is the actual host at the destination IP address?  (Excepting responses).

   To me, this is a pretty clear discriminator for a "middlebox option".  My impression is that we want a minimum of requirements in the text, so that we can all use this for the things we need it for; however we also want to make sure its not a "catch-all", like the old SNAP option.

Andrew