From ananth@cisco.com Fri Mar 2 16:42:46 2012 Return-Path: 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 8404E21E8082 for ; Fri, 2 Mar 2012 16:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.219 X-Spam-Level: X-Spam-Status: No, score=-9.219 tagged_above=-999 required=5 tests=[AWL=1.380, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 eXXKfoNuUW+a for ; Fri, 2 Mar 2012 16:42:45 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6B88621E8037 for ; Fri, 2 Mar 2012 16:42:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=2863; q=dns/txt; s=iport; t=1330735365; x=1331944965; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=SS5oSLTx35EWhDyBy49l8XWvnr2zQ2AY7K69aJM2I7g=; b=mFufE6nMJDuIIWJkDfc/HizhYtr+UVwzTK7njYz1dwNcW07LM7UlqKUP XpGbB/OWWdkxRpbckpzBnimsZ0eBkUHdI5hy915LWNtHpgwuXD9a3GvLo JR7ODRhw24XC/hNVkk5MhhGeyoxftM57ZAw2a5qMy7jh8GuFGNokHiQme 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnUAAOpoUU+rRDoH/2dsb2JhbABAA6JvkVuBB4F9AQEBBAEBAQ8BHQo0FwQCAQgOAwQBAQsGFwEGASYfCQgBAQQBEggah2MBC6B/AZcVBI0ogkRjBIhQoAQ X-IronPort-AV: E=Sophos;i="4.73,521,1325462400"; d="scan'208";a="31701706" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 03 Mar 2012 00:42:41 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q230ge54000685; Sat, 3 Mar 2012 00:42:40 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Mar 2012 16:42:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Mar 2012 16:42:39 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580EA21847@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580E546254@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [middisc] middisc specification update Thread-Index: AcyG5wLVJKtf0Y74SiSodjFq7qJ2lxObcJ+QAAJE5sAI3dxCQA== References: <4E9241F7.5090406@mti-systems.com><2AE215BDC76842F885AC7E9D34BD2CA4@davidPC> <0C53DCFB700D144284A584F54711EC580E546254@xmb-sjc-21c.amer.cisco.com> From: "Anantha Ramaiah (ananth)" To: "David Harrington" , "Wesley Eddy" , X-OriginalArrivalTime: 03 Mar 2012 00:42:41.0003 (UTC) FILETIME=[8A120BB0:01CCF8D6] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 00:42:46 -0000 Hi Wes/David, I just posted a draft (draft-ananth-middisc-tcpopt-00.txt) which is a result of all the discussions we have had among the stakeholders. What are the next steps? Is any presentation needed? I assume this is treated as an individual submission and not targeted to any WG and directly IESG would review it (Based on what you hinted last time, Wes) Sorry it took time, but better late than never I guess. Thanks to all for their discussions, review and feedback. Thanks, Anantha > -----Original Message----- > From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On > Behalf Of Anantha Ramaiah (ananth) > Sent: Tuesday, January 17, 2012 1:30 PM > To: David Harrington; Wesley Eddy; middisc@ietf.org > Subject: Re: [middisc] middisc specification update >=20 > I hope to get something out (based on the discussions so far) before > the > IETF deadlines. I'll start looking into this very soon. I assume we > are > talking about the -00- cutoff deadline here and the IETF page says it > is > March 5th. > -Anantha >=20 > > -----Original Message----- > > From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On > > Behalf Of David Harrington > > Sent: Tuesday, January 17, 2012 12:16 PM > > To: 'Wesley Eddy'; middisc@ietf.org > > Subject: Re: [middisc] middisc specification update > > > > three months later and a new deadline is approaching. > > Any chance of seeing progress on a draft? > > > > 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 Wesley Eddy > > > Sent: Sunday, October 09, 2011 5:53 PM > > > To: middisc@ietf.org > > > Subject: [middisc] middisc specification update > > > > > > Hi folks, this is a reminder that there are cut-off dates > > approaching > > > for draft submission prior to the next IETF meeting. If I > > understand > > > correctly, Andrew has the pen and should be working on either a new > > or > > > updated document based on prior discussions. If it's at all > > possible > > > to get that in before the relevant cut-off date, that would be very > > > encouraging. > > > > > > -- > > > Wes Eddy > > > MTI Systems > > > _______________________________________________ > > > 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 > _______________________________________________ > middisc mailing list > middisc@ietf.org > https://www.ietf.org/mailman/listinfo/middisc From lars@netapp.com Mon Mar 5 01:32:45 2012 Return-Path: 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 A818221F8725 for ; Mon, 5 Mar 2012 01:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.079 X-Spam-Level: X-Spam-Status: No, score=-10.079 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] 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 Ndsm8YCYQ-3q for ; Mon, 5 Mar 2012 01:32:44 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9C11721F8704 for ; Mon, 5 Mar 2012 01:32:41 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.73,533,1325491200"; d="p7s'?scan'208";a="630708727" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 05 Mar 2012 01:32:26 -0800 Received: from vmwexceht05-prd.hq.netapp.com (vmwexceht05-prd.hq.netapp.com [10.106.77.35]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q259WPZU006409; Mon, 5 Mar 2012 01:32:25 -0800 (PST) Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.92]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0247.003; Mon, 5 Mar 2012 01:32:24 -0800 From: "Eggert, Lars" To: "middisc@ietf.org" Thread-Topic: [middisc] middisc specification update Thread-Index: AcyG5wLVJKtf0Y74SiSodjFq7qJ2lxObcJ+QAAJE5sAI3dxCQACIKKiA Date: Mon, 5 Mar 2012 09:32:24 +0000 Message-ID: References: <4E9241F7.5090406@mti-systems.com><2AE215BDC76842F885AC7E9D34BD2CA4@davidPC> <0C53DCFB700D144284A584F54711EC580E546254@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EA21847@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580EA21847@xmb-sjc-21c.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_FC2D73C2-07FB-41E2-A01D-87D471BB48B0"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Martin Stiemerling 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 09:32:45 -0000 --Apple-Mail=_FC2D73C2-07FB-41E2-A01D-87D471BB48B0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi, On Mar 3, 2012, at 1:42, Anantha Ramaiah (ananth) wrote: > I just posted a draft (draft-ananth-middisc-tcpopt-00.txt) which is a > result of all the discussions we have had among the stakeholders. a few comments on the ID. (Also CC'ing Martin as the incoming AD.) Lars I think you need to add some text that says that although TCP is end-to-end and therefore network infrastructure was supposed to not mess with the TCP headers, current deployment practice has resulted in middleboxes that do in fact "violate" the original architecture in order to address a perceived need. This shouldn't say whether that's good or bad, but merely acknowledges reality and encourages use of a shared documented option number for such uses. INTRODUCTION, paragraph 1: > Intended status: Informational You need to make this PS. Or do you want to ask for IESG Approval of the option number? INTRODUCTION, paragraph 5: > This document describes a TCP option for use by middleboxes to > facilitate transparent detection of other middleboxes along the path > of the TCP connection during the connection initiation phase. The > option has no effect if an appropriate middlebox is not present on > the path. I'd move all the rest of the abstract to the introduction; not appropriate for the abstract. Section 6., paragraph 4: > The TCP-MDO option is incompatible with TCP options which aim to > protect the integrity of the TCP SYN. An example of such an option > is the TCP MD5 signature option[RFC2385]. Such TCP options are not > commonly seen by current WAN optimization systems, so the restriction > should not pose any worries. Also, more importantly, TCP-AO. Section 7., paragraph 3: > IANA is also requested to assign an 8 bit vendor code that can be > used to differentiate multiple vendors and to maintain an associated > registry. Insufficient information to define the registry. Please read RFC5226 on how to write an IANA considerations section. Section 7., paragraph 5: > Vendor TCP option number > -------------------------------------- > Bluecoat 253 > Cisco 33 I thought we also knew about Riverbed and Citrix? --Apple-Mail=_FC2D73C2-07FB-41E2-A01D-87D471BB48B0 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDMwNTA5MzIyNFowIwYJKoZIhvcNAQkEMRYEFEVs +olnPzluiRQhX2DGGHZ/+aKtMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAJws6Nxc 1OHEb9mNUM9DDx3MbMk4qnwfMpBp0LPQ4gaeGWt1kp3V5kMNH7oVRcIW9t7fKH9tfyOAqGFN9LUX PoAd5wCvAOn33XEuT3JuxMeabJh73u0OoA/GJ7cgkT5r4MDSrbiPUK5OR0atyo6EhucBcpceL34D H+4zg5JlhTl7ZGlPYzLUtlNVBRy1LjAKHVDewF7gLDaKTQMiJtceIKfm+uWhcoKZZOdSZpQ53ZCN 6UWX8VYsbOpB8wv6A+5Vl0Fp/6lO9WJeGQku/qvr9I0bkot5zmnSqrUQuFExhdezkXijgbuQbkJo /P+H4Se5lDYzJ8QihsO3zopm/JlQ4RYAAAAAAAA= --Apple-Mail=_FC2D73C2-07FB-41E2-A01D-87D471BB48B0-- From wesley.m.eddy@nasa.gov Mon Mar 5 10:43:24 2012 Return-Path: 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 78ADB21F8903 for ; Mon, 5 Mar 2012 10:43:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 aBAF6Psf-dEU for ; Mon, 5 Mar 2012 10:43:23 -0800 (PST) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5DB21F8900 for ; Mon, 5 Mar 2012 10:43:23 -0800 (PST) Received: from ndjsppt04.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 065B3328467; Mon, 5 Mar 2012 12:43:23 -0600 (CST) Received: from ndjshub05.ndc.nasa.gov (ndjshub05.ndc.nasa.gov [198.117.4.164]) by ndjsppt04.ndc.nasa.gov (8.14.4/8.14.4) with ESMTP id q25IgHEB016857; Mon, 5 Mar 2012 12:43:22 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub05.ndc.nasa.gov ([198.117.4.164]) with mapi; Mon, 5 Mar 2012 12:42:27 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "Anantha Ramaiah (ananth)" , David Harrington , Wesley Eddy , "middisc@ietf.org" Date: Mon, 5 Mar 2012 12:42:25 -0600 Thread-Topic: [middisc] middisc specification update Thread-Index: AcyG5wLVJKtf0Y74SiSodjFq7qJ2lxObcJ+QAAJE5sAI3dxCQACKW9EQ Message-ID: References: <4E9241F7.5090406@mti-systems.com><2AE215BDC76842F885AC7E9D34BD2CA4@davidPC> <0C53DCFB700D144284A584F54711EC580E546254@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EA21847@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580EA21847@xmb-sjc-21c.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498, 1.0.260, 0.0.0000 definitions=2012-03-05_05:2012-03-05, 2012-03-05, 1970-01-01 signatures=0 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 18:43:24 -0000 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 be done, I will ask for a shepherd to do a writeup on it, and I will do an AD review. If it's acceptable, I'll send it to IETF Last Call and through the rest of the IESG at that point. At that point, I also think it will be good to notify TSVAREA of it so that people have the opportunity to check it out during the IETF LC. -- Wes Eddy MTI Systems >-----Original Message----- >From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On >Behalf Of Anantha Ramaiah (ananth) >Sent: Friday, March 02, 2012 7:43 PM >To: David Harrington; Wesley Eddy; middisc@ietf.org >Subject: Re: [middisc] middisc specification update > >Hi Wes/David, > >I just posted a draft (draft-ananth-middisc-tcpopt-00.txt) which is a >result of all the discussions we have had among the stakeholders. What >are the next steps? Is any presentation needed? I assume this is >treated as an individual submission and not targeted to any WG and >directly IESG would review it (Based on what you hinted last time, Wes) > >Sorry it took time, but better late than never I guess. Thanks to all >for their discussions, review and feedback. >Thanks, >Anantha > >> -----Original Message----- >> From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On >> Behalf Of Anantha Ramaiah (ananth) >> Sent: Tuesday, January 17, 2012 1:30 PM >> To: David Harrington; Wesley Eddy; middisc@ietf.org >> Subject: Re: [middisc] middisc specification update >> >> I hope to get something out (based on the discussions so far) before >> the >> IETF deadlines. I'll start looking into this very soon. I assume we >> are >> talking about the -00- cutoff deadline here and the IETF page says it >> is >> March 5th. >> -Anantha >> >> > -----Original Message----- >> > From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On >> > Behalf Of David Harrington >> > Sent: Tuesday, January 17, 2012 12:16 PM >> > To: 'Wesley Eddy'; middisc@ietf.org >> > Subject: Re: [middisc] middisc specification update >> > >> > three months later and a new deadline is approaching. >> > Any chance of seeing progress on a draft? >> > >> > 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 Wesley Eddy >> > > Sent: Sunday, October 09, 2011 5:53 PM >> > > To: middisc@ietf.org >> > > Subject: [middisc] middisc specification update >> > > >> > > Hi folks, this is a reminder that there are cut-off dates >> > approaching >> > > for draft submission prior to the next IETF meeting. If I >> > understand >> > > correctly, Andrew has the pen and should be working on either a >new >> > or >> > > updated document based on prior discussions. If it's at all >> > possible >> > > to get that in before the relevant cut-off date, that would be >very >> > > encouraging. >> > > >> > > -- >> > > Wes Eddy >> > > MTI Systems >> > > _______________________________________________ >> > > 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 >> _______________________________________________ >> 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 From ananth@cisco.com Mon Mar 5 10:56:35 2012 Return-Path: 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 52C7621F887C for ; Mon, 5 Mar 2012 10:56:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.344 X-Spam-Level: X-Spam-Status: No, score=-9.344 tagged_above=-999 required=5 tests=[AWL=1.255, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 sPuMlrMk5gf8 for ; Mon, 5 Mar 2012 10:56:34 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8E98621F8871 for ; Mon, 5 Mar 2012 10:56:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=5133; q=dns/txt; s=iport; t=1330973794; x=1332183394; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=jRqt6zm5miblEkixmsiuhuid/egAM5OZbrS4VV1zXvc=; b=ElIJHfGmOHLnfFVpXmwRt1tXM7tHIv/MNA7AOCIwztDxlENEE6B+e6gC o7ZANDpQAabHCde8M0zBQZGorZ3+4/KK4/mUPz25EyX9AYdoXiWFB90G6 rHVet44t4703eBDAIvEugBZkJr/crgDTjVZaR+zPDBhsXpK0Ld6j80g/o A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkAAGULVU+rRDoG/2dsb2JhbABAA6MCkW2BB4F9AQEBAwEBAQEPAR0KNBAHBAIBCBEEAQELBhcBBgEmHwkIAQEEARIIGodgBAELoGkBlwMEjTaCRGMEiFCdAIME X-IronPort-AV: E=Sophos;i="4.73,535,1325462400"; d="scan'208";a="34485481" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 05 Mar 2012 18:56:33 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q25IuWXk022768; Mon, 5 Mar 2012 18:56:32 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Mar 2012 10:56:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Mar 2012 10:56:31 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580EA21B2D@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [middisc] middisc specification update Thread-Index: AcyG5wLVJKtf0Y74SiSodjFq7qJ2lxObcJ+QAAJE5sAI3dxCQACKW9EQAABRXxA= References: <4E9241F7.5090406@mti-systems.com><2AE215BDC76842F885AC7E9D34BD2CA4@davidPC><0C53DCFB700D144284A584F54711EC580E546254@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EA21847@xmb-sjc-21c.amer.cisco.com> From: "Anantha Ramaiah (ananth)" To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" , "David Harrington" , "Wesley Eddy" , X-OriginalArrivalTime: 05 Mar 2012 18:56:32.0872 (UTC) FILETIME=[AE89FE80:01CCFB01] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 18:56:35 -0000 Wes, > -----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 >=20 > Thanks for posting the draft. >=20 > The intention is to handle this as an AD-sponsored document, > not via an IETF working group. >=20 > No presentation is needed. >=20 > 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. > be done, I will ask for a shepherd to do a writeup on it, and > I will do an AD review. If it's acceptable, I'll send it > to IETF Last Call and through the rest of the IESG at that point. Great. >=20 > At that point, I also think it will be good to notify TSVAREA > of it so that people have the opportunity to check it out during > the IETF LC. Sure, that makes sense.=20 One process question though, what would be the "intended status" of this document?. If it was IETF WG doc, it would have been a standards track... since it is taking the AD sponsored route, I am assuming it needs to be informational.. not sure. Short question is : "is it ok to have a TCP option allocation request draft to be categorized as a non-standards track?" Thanks, -Anantha >=20 > -- > Wes Eddy > MTI Systems >=20 >=20 > >-----Original Message----- > >From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On > >Behalf Of Anantha Ramaiah (ananth) > >Sent: Friday, March 02, 2012 7:43 PM > >To: David Harrington; Wesley Eddy; middisc@ietf.org > >Subject: Re: [middisc] middisc specification update > > > >Hi Wes/David, > > > >I just posted a draft (draft-ananth-middisc-tcpopt-00.txt) which is a > >result of all the discussions we have had among the stakeholders. What > >are the next steps? Is any presentation needed? I assume this is > >treated as an individual submission and not targeted to any WG and > >directly IESG would review it (Based on what you hinted last time, > Wes) > > > >Sorry it took time, but better late than never I guess. Thanks to all > >for their discussions, review and feedback. > >Thanks, > >Anantha > > > >> -----Original Message----- > >> From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On > >> Behalf Of Anantha Ramaiah (ananth) > >> Sent: Tuesday, January 17, 2012 1:30 PM > >> To: David Harrington; Wesley Eddy; middisc@ietf.org > >> Subject: Re: [middisc] middisc specification update > >> > >> I hope to get something out (based on the discussions so far) before > >> the > >> IETF deadlines. I'll start looking into this very soon. I assume we > >> are > >> talking about the -00- cutoff deadline here and the IETF page says > it > >> is > >> March 5th. > >> -Anantha > >> > >> > -----Original Message----- > >> > From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] > On > >> > Behalf Of David Harrington > >> > Sent: Tuesday, January 17, 2012 12:16 PM > >> > To: 'Wesley Eddy'; middisc@ietf.org > >> > Subject: Re: [middisc] middisc specification update > >> > > >> > three months later and a new deadline is approaching. > >> > Any chance of seeing progress on a draft? > >> > > >> > 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 Wesley Eddy > >> > > Sent: Sunday, October 09, 2011 5:53 PM > >> > > To: middisc@ietf.org > >> > > Subject: [middisc] middisc specification update > >> > > > >> > > Hi folks, this is a reminder that there are cut-off dates > >> > approaching > >> > > for draft submission prior to the next IETF meeting. If I > >> > understand > >> > > correctly, Andrew has the pen and should be working on either a > >new > >> > or > >> > > updated document based on prior discussions. If it's at all > >> > possible > >> > > to get that in before the relevant cut-off date, that would be > >very > >> > > encouraging. > >> > > > >> > > -- > >> > > Wes Eddy > >> > > MTI Systems > >> > > _______________________________________________ > >> > > 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 > >> _______________________________________________ > >> 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 From wesley.m.eddy@nasa.gov Mon Mar 5 11:19:23 2012 Return-Path: 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 D0E3C21F891A for ; Mon, 5 Mar 2012 11:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 OMjO82riwy9a for ; Mon, 5 Mar 2012 11:19:23 -0800 (PST) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by ietfa.amsl.com (Postfix) with ESMTP id DAC3B21F8907 for ; Mon, 5 Mar 2012 11:19:22 -0800 (PST) Received: from ndjsppt04.ndc.nasa.gov (ndjsppt04.ndc.nasa.gov [198.117.1.103]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 68D47328492; Mon, 5 Mar 2012 13:19:22 -0600 (CST) Received: from ndjshub03.ndc.nasa.gov (ndjshub03-pub.ndc.nasa.gov [198.117.1.33]) by ndjsppt04.ndc.nasa.gov (8.14.4/8.14.4) with ESMTP id q25JJMq7028635; Mon, 5 Mar 2012 13:19:22 -0600 Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub03.ndc.nasa.gov ([10.202.202.162]) with mapi; Mon, 5 Mar 2012 13:19:22 -0600 From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" To: "Anantha Ramaiah (ananth)" , David Harrington , Wesley Eddy , "middisc@ietf.org" Date: Mon, 5 Mar 2012 13:19:21 -0600 Thread-Topic: [middisc] middisc specification update Thread-Index: AcyG5wLVJKtf0Y74SiSodjFq7qJ2lxObcJ+QAAJE5sAI3dxCQACKW9EQAABRXxAAAH7XAA== Message-ID: References: <4E9241F7.5090406@mti-systems.com><2AE215BDC76842F885AC7E9D34BD2CA4@davidPC><0C53DCFB700D144284A584F54711EC580E546254@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EA21847@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EA21B2D@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580EA21B2D@xmb-sjc-21c.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498, 1.0.260, 0.0.0000 definitions=2012-03-05_05:2012-03-05, 2012-03-05, 1970-01-01 signatures=0 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 19:19:23 -0000 Since we want vendors to move off of other codepoints and onto whatever one may be allocated for this, I think Informational may not be quite right. Experimental could capture this well. We want vendors to implement it and try it out. The "experiment" is really to see if people will use this or not, and whether it succeeds in relieving some of the chaos of unallocated options in use. I think this would also require making sure there's clear discussion in the document of why the existing experimental codepoints aren't felt to be sufficient for this (especially since one has already been successfully used by one vendor!). >-----Original Message----- >From: Anantha Ramaiah (ananth) [mailto:ananth@cisco.com] >Sent: Monday, March 05, 2012 1:57 PM >To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; David Harrington; >Wesley Eddy; middisc@ietf.org >Subject: RE: [middisc] middisc specification update > >Wes, > >> -----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. > >> be done, I will ask for a shepherd to do a writeup on it, and >> I will do an AD review. If it's acceptable, I'll send it >> to IETF Last Call and through the rest of the IESG at that point. > >Great. > >> >> At that point, I also think it will be good to notify TSVAREA >> of it so that people have the opportunity to check it out during >> the IETF LC. > >Sure, that makes sense. > >One process question though, what would be the "intended status" of this >document?. If it was IETF WG doc, it would have been a standards >track... since it is taking the AD sponsored route, I am assuming it >needs to be informational.. not sure. Short question is : "is it ok to >have a TCP option allocation request draft to be categorized as a >non-standards track?" > >Thanks, >-Anantha >> >> -- >> Wes Eddy >> MTI Systems >> >> >> >-----Original Message----- >> >From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On >> >Behalf Of Anantha Ramaiah (ananth) >> >Sent: Friday, March 02, 2012 7:43 PM >> >To: David Harrington; Wesley Eddy; middisc@ietf.org >> >Subject: Re: [middisc] middisc specification update >> > >> >Hi Wes/David, >> > >> >I just posted a draft (draft-ananth-middisc-tcpopt-00.txt) which is a >> >result of all the discussions we have had among the stakeholders. >What >> >are the next steps? Is any presentation needed? I assume this is >> >treated as an individual submission and not targeted to any WG and >> >directly IESG would review it (Based on what you hinted last time, >> Wes) >> > >> >Sorry it took time, but better late than never I guess. Thanks to all >> >for their discussions, review and feedback. >> >Thanks, >> >Anantha >> > >> >> -----Original Message----- >> >> From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On >> >> Behalf Of Anantha Ramaiah (ananth) >> >> Sent: Tuesday, January 17, 2012 1:30 PM >> >> To: David Harrington; Wesley Eddy; middisc@ietf.org >> >> Subject: Re: [middisc] middisc specification update >> >> >> >> I hope to get something out (based on the discussions so far) >before >> >> the >> >> IETF deadlines. I'll start looking into this very soon. I assume >we >> >> are >> >> talking about the -00- cutoff deadline here and the IETF page says >> it >> >> is >> >> March 5th. >> >> -Anantha >> >> >> >> > -----Original Message----- >> >> > From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] >> On >> >> > Behalf Of David Harrington >> >> > Sent: Tuesday, January 17, 2012 12:16 PM >> >> > To: 'Wesley Eddy'; middisc@ietf.org >> >> > Subject: Re: [middisc] middisc specification update >> >> > >> >> > three months later and a new deadline is approaching. >> >> > Any chance of seeing progress on a draft? >> >> > >> >> > 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 Wesley Eddy >> >> > > Sent: Sunday, October 09, 2011 5:53 PM >> >> > > To: middisc@ietf.org >> >> > > Subject: [middisc] middisc specification update >> >> > > >> >> > > Hi folks, this is a reminder that there are cut-off dates >> >> > approaching >> >> > > for draft submission prior to the next IETF meeting. If I >> >> > understand >> >> > > correctly, Andrew has the pen and should be working on either a >> >new >> >> > or >> >> > > updated document based on prior discussions. If it's at all >> >> > possible >> >> > > to get that in before the relevant cut-off date, that would be >> >very >> >> > > encouraging. >> >> > > >> >> > > -- >> >> > > Wes Eddy >> >> > > MTI Systems >> >> > > _______________________________________________ >> >> > > 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 >> >> _______________________________________________ >> >> 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 From ananth@cisco.com Mon Mar 5 11:44:30 2012 Return-Path: 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 9DF6F21F8967 for ; Mon, 5 Mar 2012 11:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.449 X-Spam-Level: X-Spam-Status: No, score=-9.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 cLliPQ6yWoQ3 for ; Mon, 5 Mar 2012 11:44:29 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 988F421F8966 for ; Mon, 5 Mar 2012 11:44:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=8441; q=dns/txt; s=iport; t=1330976669; x=1332186269; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=EVnW92VAFRGF9La2XPTjKNAiat1mvQSToR0KWcfOb3g=; b=InT6cz3fjf99vIghPctMNFIDrQ5h6ExkTwQ5RHBLh6c8RtvDrZhdvdYP N02IiLFBXPzbWPoscZeyfrs7LKL3kdRJYKJCjjNF8jS9ZmvcisrCxspSO 4W6LA/DpGShMqbaSORpUbevFHAUwx3R4vhWt3H1FHjOhgxDZPE7kZkUBp w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkAABYXVU+rRDoJ/2dsb2JhbABAA6MFkW2BB4F9AQEBAwEBAQEPAR0KNBAHBAIBCBEEAQELBhcBBgEmHwkIAgQBEggah2AEAQugXQGXCASNNoJEYwSIUJ0AgwQ X-IronPort-AV: E=Sophos;i="4.73,535,1325462400"; d="scan'208";a="34630719" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 05 Mar 2012 19:44:27 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q25JiR37012546; Mon, 5 Mar 2012 19:44:27 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Mar 2012 11:44:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Mar 2012 11:44:25 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580EA21B77@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [middisc] middisc specification update Thread-Index: AcyG5wLVJKtf0Y74SiSodjFq7qJ2lxObcJ+QAAJE5sAI3dxCQACKW9EQAABRXxAAAH7XAAABHpIQ References: <4E9241F7.5090406@mti-systems.com><2AE215BDC76842F885AC7E9D34BD2CA4@davidPC><0C53DCFB700D144284A584F54711EC580E546254@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EA21847@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EA21B2D@xmb-sjc-21c.amer.cisco.com> From: "Anantha Ramaiah (ananth)" To: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" , "David Harrington" , "Wesley Eddy" , X-OriginalArrivalTime: 05 Mar 2012 19:44:27.0067 (UTC) FILETIME=[5FB158B0:01CCFB08] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 19:44:30 -0000 Wes, > -----Original Message----- > From: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] > [mailto:wesley.m.eddy@nasa.gov] > Sent: Monday, March 05, 2012 11:19 AM > To: Anantha Ramaiah (ananth); David Harrington; Wesley Eddy; > middisc@ietf.org > Subject: RE: [middisc] middisc specification update >=20 > Since we want vendors to move off of other codepoints and onto > whatever one may be allocated for this, I think Informational > may not be quite right. Ok. >=20 > Experimental could capture this well. We want vendors to > implement it and try it out. The "experiment" is really to > see if people will use this or not, and whether it succeeds in > relieving some of the chaos of unallocated options in use. I Right, from vendors pov, experimental may sound fine. But from IETF standards pov, this sort of an effort is aimed at reducing unauthorized TCP option poaching and if such a draft exists it would both act as a recommendation and for vendors to not use unauthorized options. In such cases would experimental convey the "strong" message. May be some text needs to be added to the draft echoing what you alluded above... > think this would also require making sure there's clear > discussion in the document of why the existing experimental > codepoints aren't felt to be sufficient for this (especially > since one has already been successfully used by one vendor!). - in some cases existing code points would work, provided they are not used by other purposes and not allocated by IANA for other purposes. - in some cases where experimental TCP option code points are used (Bluecoat?) they would collide with other experimental TCP option code points. So, in any case having a single TCP option code point eliminates these surprises and also would be considered as a step forward for even going down the road of interoperability among various vendors (wishful thinking but always start with a better hope...) I am not sure these things are spelled out clearly in the draft, but the message is spread across and may be if there is a need for making it more clear, please let us know. Also if the status is experimental, I am assuming that we would still get a regular TCP option code point and not the TCP experimental option code point. I am assuming when you said experiment above it is more on the lines of multiple vendors dis-continuing and using the standard TCP option number that is allocated for this purpose. Thanks, -Anantha >=20 >=20 >=20 >=20 > >-----Original Message----- > >From: Anantha Ramaiah (ananth) [mailto:ananth@cisco.com] > >Sent: Monday, March 05, 2012 1:57 PM > >To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; David Harrington; > >Wesley Eddy; middisc@ietf.org > >Subject: RE: [middisc] middisc specification update > > > >Wes, > > > >> -----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. > > > >> be done, I will ask for a shepherd to do a writeup on it, and > >> I will do an AD review. If it's acceptable, I'll send it > >> to IETF Last Call and through the rest of the IESG at that point. > > > >Great. > > > >> > >> At that point, I also think it will be good to notify TSVAREA > >> of it so that people have the opportunity to check it out during > >> the IETF LC. > > > >Sure, that makes sense. > > > >One process question though, what would be the "intended status" of > this > >document?. If it was IETF WG doc, it would have been a standards > >track... since it is taking the AD sponsored route, I am assuming it > >needs to be informational.. not sure. Short question is : "is it ok to > >have a TCP option allocation request draft to be categorized as a > >non-standards track?" > > > >Thanks, > >-Anantha > >> > >> -- > >> Wes Eddy > >> MTI Systems > >> > >> > >> >-----Original Message----- > >> >From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On > >> >Behalf Of Anantha Ramaiah (ananth) > >> >Sent: Friday, March 02, 2012 7:43 PM > >> >To: David Harrington; Wesley Eddy; middisc@ietf.org > >> >Subject: Re: [middisc] middisc specification update > >> > > >> >Hi Wes/David, > >> > > >> >I just posted a draft (draft-ananth-middisc-tcpopt-00.txt) which is > a > >> >result of all the discussions we have had among the stakeholders. > >What > >> >are the next steps? Is any presentation needed? I assume this is > >> >treated as an individual submission and not targeted to any WG and > >> >directly IESG would review it (Based on what you hinted last time, > >> Wes) > >> > > >> >Sorry it took time, but better late than never I guess. Thanks to > all > >> >for their discussions, review and feedback. > >> >Thanks, > >> >Anantha > >> > > >> >> -----Original Message----- > >> >> From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] > On > >> >> Behalf Of Anantha Ramaiah (ananth) > >> >> Sent: Tuesday, January 17, 2012 1:30 PM > >> >> To: David Harrington; Wesley Eddy; middisc@ietf.org > >> >> Subject: Re: [middisc] middisc specification update > >> >> > >> >> I hope to get something out (based on the discussions so far) > >before > >> >> the > >> >> IETF deadlines. I'll start looking into this very soon. I assume > >we > >> >> are > >> >> talking about the -00- cutoff deadline here and the IETF page > says > >> it > >> >> is > >> >> March 5th. > >> >> -Anantha > >> >> > >> >> > -----Original Message----- > >> >> > From: middisc-bounces@ietf.org [mailto:middisc- > bounces@ietf.org] > >> On > >> >> > Behalf Of David Harrington > >> >> > Sent: Tuesday, January 17, 2012 12:16 PM > >> >> > To: 'Wesley Eddy'; middisc@ietf.org > >> >> > Subject: Re: [middisc] middisc specification update > >> >> > > >> >> > three months later and a new deadline is approaching. > >> >> > Any chance of seeing progress on a draft? > >> >> > > >> >> > 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 Wesley Eddy > >> >> > > Sent: Sunday, October 09, 2011 5:53 PM > >> >> > > To: middisc@ietf.org > >> >> > > Subject: [middisc] middisc specification update > >> >> > > > >> >> > > Hi folks, this is a reminder that there are cut-off dates > >> >> > approaching > >> >> > > for draft submission prior to the next IETF meeting. If I > >> >> > understand > >> >> > > correctly, Andrew has the pen and should be working on either > a > >> >new > >> >> > or > >> >> > > updated document based on prior discussions. If it's at all > >> >> > possible > >> >> > > to get that in before the relevant cut-off date, that would > be > >> >very > >> >> > > encouraging. > >> >> > > > >> >> > > -- > >> >> > > Wes Eddy > >> >> > > MTI Systems > >> >> > > _______________________________________________ > >> >> > > 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 > >> >> _______________________________________________ > >> >> 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 From ananth@cisco.com Tue Mar 6 07:17:03 2012 Return-Path: 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 7A91E21F8783 for ; Tue, 6 Mar 2012 07:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.237 X-Spam-Level: X-Spam-Status: No, score=-9.237 tagged_above=-999 required=5 tests=[AWL=0.762, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] 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 U+aSSRn32CqH for ; Tue, 6 Mar 2012 07:17:02 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 5052E21F8793 for ; Tue, 6 Mar 2012 07:17:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=3615; q=dns/txt; s=iport; t=1331047022; x=1332256622; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=zyEJ7/I26t3iP2IYvzsgmImJokrWZEF04asVI9hJFs8=; b=U8jm7O2Qm6g/PDiwaLGCU2u6as8HbLCTb5G+A9gsc8/sGEfNNEQlXSqj 3Mhx660dkcn1qHH5qQR8x76Y9pocGt33tt+gBHfqzhAL45eb24CzVpKPS FJSXHmdGAan7GSnVMlOvocfbAqjczFsksCPWBDOwjjj/N+i3bS4rzZZYY I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGgpVk+rRDoI/2dsb2JhbABDtGuBB4F9AQEBAwESAR0KPwwEAgEIEQEDAQEBCgYXAQYBRQMGCAEBBAESCBqHYAQBmiEBnxGPe2MEiFKdA4MEgTs X-IronPort-AV: E=Sophos;i="4.73,540,1325462400"; d="scan'208";a="34659700" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 06 Mar 2012 15:17:02 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q26FH2xY001778; Tue, 6 Mar 2012 15:17:02 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 07:17:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Mar 2012 07:17:00 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580EA21EDC@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [middisc] middisc specification update Thread-Index: AcyG5wLVJKtf0Y74SiSodjFq7qJ2lxObcJ+QAAJE5sAI3dxCQACIKKiAAC1JnuA= References: <4E9241F7.5090406@mti-systems.com><2AE215BDC76842F885AC7E9D34BD2CA4@davidPC><0C53DCFB700D144284A584F54711EC580E546254@xmb-sjc-21c.amer.cisco.com><0C53DCFB700D144284A584F54711EC580EA21847@xmb-sjc-21c.amer.cisco.com> From: "Anantha Ramaiah (ananth)" To: "Eggert, Lars" , X-OriginalArrivalTime: 06 Mar 2012 15:17:02.0081 (UTC) FILETIME=[2E8C8710:01CCFBAC] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 15:17:03 -0000 Hi Lars, =20 I missed this email and just got to this. Comments inline.. > -----Original Message----- > From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On > Behalf Of Eggert, Lars > Sent: Monday, March 05, 2012 1:32 AM > To: middisc@ietf.org > Cc: Martin Stiemerling > Subject: Re: [middisc] middisc specification update >=20 > Hi, >=20 > On Mar 3, 2012, at 1:42, Anantha Ramaiah (ananth) wrote: > > I just posted a draft (draft-ananth-middisc-tcpopt-00.txt) which is a > > result of all the discussions we have had among the stakeholders. >=20 > a few comments on the ID. (Also CC'ing Martin as the incoming AD.) >=20 > Lars >=20 >=20 > I think you need to add some text that says that although TCP is > end-to-end and therefore network infrastructure was supposed to not > mess with the TCP headers, current deployment practice has resulted > in > middleboxes that do in fact "violate" the original architecture in > order to address a perceived need. This shouldn't say whether that's > good or bad, but merely acknowledges reality and encourages use of a > shared documented option number for such uses. Right, to my reply to Wes's other email, I acknowledged that there is need to add text to cover the aspect of option poaching etc., >=20 >=20 > INTRODUCTION, paragraph 1: > > Intended status: Informational >=20 > You need to make this PS. Or do you want to ask for IESG Approval of > the option number? Wes's response to my comment was to make it Experimental. So we have 3 choices : info (current), experimental and PS. I am not sure, whichever is the fastest route in getting the TCP option allocated, I'll take that :-) Of course, this is just my opinion. Other stakeholders may have different opinion. >=20 >=20 > INTRODUCTION, paragraph 5: > > This document describes a TCP option for use by middleboxes to > > facilitate transparent detection of other middleboxes along the > path > > of the TCP connection during the connection initiation phase. The > > option has no effect if an appropriate middlebox is not present on > > the path. >=20 > I'd move all the rest of the abstract to the introduction; not > appropriate > for the abstract. Good point. I'll move the rest to the introduction section. >=20 >=20 > Section 6., paragraph 4: > > The TCP-MDO option is incompatible with TCP options which aim to > > protect the integrity of the TCP SYN. An example of such an > option > > is the TCP MD5 signature option[RFC2385]. Such TCP options are > not > > commonly seen by current WAN optimization systems, so the > restriction > > should not pose any worries. >=20 > Also, more importantly, TCP-AO. Right, I just gave an example. I can also list AO as reference. >=20 >=20 > Section 7., paragraph 3: > > IANA is also requested to assign an 8 bit vendor code that can be > > used to differentiate multiple vendors and to maintain an > associated > > registry. >=20 > Insufficient information to define the registry. Please read RFC5226 > on how to write an IANA considerations section. Ok. >=20 >=20 > Section 7., paragraph 5: > > Vendor TCP option number > > -------------------------------------- > > Bluecoat 253 > > Cisco 33 >=20 > I thought we also knew about Riverbed and Citrix? Right, I know Riverbed's option usage, not sure about Citrix. Does anyone have a contact point for Citrix? Thanks, -Anantha >=20 From ron.frederick@bluecoat.com Tue Mar 6 19:22:38 2012 Return-Path: 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 A8A8B21E8039 for ; Tue, 6 Mar 2012 19:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 fS9xfisFpN1l for ; Tue, 6 Mar 2012 19:22:38 -0800 (PST) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by ietfa.amsl.com (Postfix) with ESMTP id 175C921E8013 for ; Tue, 6 Mar 2012 19:22:38 -0800 (PST) Received: from PWSVL-EXCHTS-02.internal.cacheflow.com (sai-rp.bluecoat.com [10.2.2.126] (may be forged)) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id q273MZQI008396 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Mar 2012 19:22:35 -0800 (PST) Received: from PWSVL-EXCMBX-03.internal.cacheflow.com ([fe80::f1c6:61a6:35aa:6971]) by PWSVL-EXCHTS-02.internal.cacheflow.com ([fe80::4910:317f:407:6ecc%14]) with mapi id 14.01.0289.001; Tue, 6 Mar 2012 19:22:29 -0800 From: "Frederick, Ron" To: "Anantha Ramaiah (ananth)" Thread-Topic: [middisc] middisc specification update Thread-Index: AcyG5wLVJKtf0Y74SiSodjFq7qJ2lxObcJ+QAAJE5sAI3dxCQACKW9EQAABRXxAAVSWDgA== Date: Wed, 7 Mar 2012 03:22:29 +0000 Message-ID: <56A8F14C-C1E1-4793-BC82-F27E89A9F8D4@bluecoat.com> References: <4E9241F7.5090406@mti-systems.com><2AE215BDC76842F885AC7E9D34BD2CA4@davidPC><0C53DCFB700D144284A584F54711EC580E546254@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EA21847@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EA21B2D@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580EA21B2D@xmb-sjc-21c.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.2.106] Content-Type: text/plain; charset="us-ascii" Content-ID: <83872CCB0080B748B9B2212E30E581F9@bluecoat.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 03:22:38 -0000 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 >>=20 >> Thanks for posting the draft. >>=20 >> The intention is to handle this as an AD-sponsored document, >> not via an IETF working group. >>=20 >> No presentation is needed. >>=20 >> When all of the authors have agreed on it and consider it to >=20 > 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 c= an be used for more than just discovery. The text already describes being a= ble to use the option to provide information to other middleboxes on the pa= th. I think we just need to emphasize that a bit more and make it clear tha= t 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" implementa= tion of a middlebox could run directly on a client or a server, and it woul= d want to be able to interoperate with other physical middleboxes that expe= ct to see this option. We want to be able to support that use case by allow= ing the soft middlebox on one of the end hosts to add or respond to this op= tion. 3) I'm good with supporting the single byte vendor code with vendor-specifi= c payload data after it, but I think we should at least leave some provisio= n 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 a= bout 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 extende= d vendor code that could be based on something like an OUI. If that's too b= ig, we could also do something like say that setting the high-bit in the ve= ndor code expands it to 16 bits. So, the first 128 vendor codes are one byt= e, and then we get another ~32K of them which are two bytes. --=20 Ron Frederick ronf@bluecoat.com From ananth@cisco.com Tue Mar 6 23:55:32 2012 Return-Path: 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 0607D21E8094 for ; Tue, 6 Mar 2012 23:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.659 X-Spam-Level: X-Spam-Status: No, score=-9.659 tagged_above=-999 required=5 tests=[AWL=0.940, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 ltifBYYLYAG8 for ; Tue, 6 Mar 2012 23:55:31 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id AFD6B21E8091 for ; Tue, 6 Mar 2012 23:55:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=3358; q=dns/txt; s=iport; t=1331106928; x=1332316528; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=R2imJhRnvtPJaQM9JDW8sypjpkwzSRch4dOLlGyynCA=; b=h40QSWVor0VfjQr0bfuM5LEo2vCSVVXF4GAZMRgkvwWsDn7c4F2yRr/e 3nlPMkNpI4xpS1tzfmV0t8mniwKZL5HE0h+vBSYg15syC1rkTJ2hfL5c2 wxUpl5JCqj+mXHSYizvv5p0bZ6soS30jH/59x5UrmJbNrybVQMuc681am s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAEMTV0+rRDoJ/2dsb2JhbABDtQyBB4F9AQEBAwESAR0KPwULAgEIIgYYBgFWAgQTCBqHYASadgGfEZANYwSIUp0DgwQ X-IronPort-AV: E=Sophos;i="4.73,544,1325462400"; d="scan'208";a="32333034" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 07 Mar 2012 07:55:28 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q277tSXS008425; Wed, 7 Mar 2012 07:55:28 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 23:55:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Mar 2012 23:55:23 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580EA222B2@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <56A8F14C-C1E1-4793-BC82-F27E89A9F8D4@bluecoat.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [middisc] middisc specification update Thread-Index: AcyG5wLVJKtf0Y74SiSodjFq7qJ2lxObcJ+QAAJE5sAI3dxCQACKW9EQAABRXxAAVSWDgAAHzeFA References: <4E9241F7.5090406@mti-systems.com><2AE215BDC76842F885AC7E9D34BD2CA4@davidPC><0C53DCFB700D144284A584F54711EC580E546254@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EA21847@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EA21B2D@xmb-sjc-21c.amer.cisco.com> <56A8F14C-C1E1-4793-BC82-F27E89A9F8D4@bluecoat.com> From: "Anantha Ramaiah (ananth)" To: "Frederick, Ron" X-OriginalArrivalTime: 07 Mar 2012 07:55:28.0455 (UTC) FILETIME=[A987C570:01CCFC37] Cc: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 07:55:32 -0000 Hi Ron, > I'm generally good with the latest draft, but there are a few items > that I think we need to address: >=20 > 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. Yes, I had proposed this long time back but somehow did not hear an explicit support. Ok, how about naming the draft as "TCP middlebox option" and the current use case is about middlebox discovery. There are handful of vendors doing WAN optimization today and a 255 byte vendor code is a whole lot. Hence if we make this option generic looking, other use cases can be handled as well. I need to make one thing clear : it is the not the intention of the draft to encourage middlebox insertions and uses, just to make this option extensible, so that at the discretion of IETF if there exists a strong use case tomorrow, this option can come to rescue. >=20 > 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. Middlebox can run inside the host as well, I guess middlebox definition is something that sits in the middle of the connection, if you run something that snoops on selected connections and does something to the TCP traffic it is still a middlebox. Maybe can note this in the terminology section. >=20 > 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. Fair enough. We can note that some vendor codes are going to be reserved (FF to F0). These can be used to extend as needed tomorrow. Would that address your concern? >=20 > I think we can address #2 here by reserving vendor code 0xFF for an You mean #3 above ? > 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. Well, I am happy with reserving some extended vendor codes for future extension. I think envisioning a 32 bit vendor code at this point seems very dubious to me at best. I also think we can use your MSB trick above to separate vendor codes from other codes if there is a need to have this option used for some other cases like NAT reveal etc., Thanks, Anantha > -- > Ron Frederick > ronf@bluecoat.com From lars@netapp.com Wed Mar 7 00:03:44 2012 Return-Path: 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 E5B7321E80B5 for ; Wed, 7 Mar 2012 00:03:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.374 X-Spam-Level: X-Spam-Status: No, score=-10.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 V-ayb4caEfOg for ; Wed, 7 Mar 2012 00:03:44 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 715C021E80AF for ; Wed, 7 Mar 2012 00:03:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.73,545,1325491200"; d="p7s'?scan'208";a="631349046" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 07 Mar 2012 00:03:44 -0800 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q2783ier001420; Wed, 7 Mar 2012 00:03:44 -0800 (PST) Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.92]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0247.003; Wed, 7 Mar 2012 00:03:44 -0800 From: "Eggert, Lars" To: "Anantha Ramaiah (ananth)" Thread-Topic: [middisc] middisc specification update Thread-Index: AcyG5wLVJKtf0Y74SiSodjFq7qJ2lxObcJ+QAAJE5sAI3dxCQACKW9EQAABRXxAAVSWDgAAHzeFAAAIEGQA= Date: Wed, 7 Mar 2012 08:03:42 +0000 Message-ID: <71231A86-7A22-48C0-987F-5C01C25E7B33@netapp.com> References: <4E9241F7.5090406@mti-systems.com><2AE215BDC76842F885AC7E9D34BD2CA4@davidPC><0C53DCFB700D144284A584F54711EC580E546254@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EA21847@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EA21B2D@xmb-sjc-21c.amer.cisco.com> <56A8F14C-C1E1-4793-BC82-F27E89A9F8D4@bluecoat.com> <0C53DCFB700D144284A584F54711EC580EA222B2@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580EA222B2@xmb-sjc-21c.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_F262C512-7B30-4EB1-950C-41A1F9135499"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "Frederick, Ron" , "" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 08:03:45 -0000 --Apple-Mail=_F262C512-7B30-4EB1-950C-41A1F9135499 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 7, 2012, at 8:55, Anantha Ramaiah (ananth) wrote: > Fair enough. We can note that some vendor codes are going to be > reserved (FF to F0). These can be used to extend as needed tomorrow. > Would that address your concern? Idle thought: What makes us think that vendors will go through IANA to = get one of these codepoints, when they have been squatting on option = numbers already? Lars= --Apple-Mail=_F262C512-7B30-4EB1-950C-41A1F9135499 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDMwNzA4MDM0MVowIwYJKoZIhvcNAQkEMRYEFHvC lecfbrVSwrt3S22ISCJLFD3lMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBADY54W5v tjx15t3Sa16bR7gZZbCEk2PRFTDFi5ezqXioHDeTlYNtAIGLtVjDYwvKjC4AZmc2bQ/n2pbpj02K LnlHeTLT3PeNTb0x8/+nOzrDCvlEp746+DmeB8euHCdGRY7peX3WVQfuyBy3ubOVq7/hKdIZ0T9t LB0ozQ+fc+9BfYlZotSEVCfsMihxhlv52Ygb5x0MggtukxbSp6Ev0cJnwtfo+pvLMOoty5y4pB9j AqqpARc63+D5El6PqGCpXrsRsioaog9EMXei+2olrvTxzCZ6UBQSPHa8PkN/Y7JC9FdtaDDpOUO4 PvwlDJq7cdU0QGKi8l9ucbIPWDN8nokAAAAAAAA= --Apple-Mail=_F262C512-7B30-4EB1-950C-41A1F9135499-- From ananth@cisco.com Wed Mar 7 00:18:53 2012 Return-Path: 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 21EF721E80A4 for ; Wed, 7 Mar 2012 00:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.718 X-Spam-Level: X-Spam-Status: No, score=-9.718 tagged_above=-999 required=5 tests=[AWL=0.881, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 1aoNON2lgS+U for ; Wed, 7 Mar 2012 00:18:52 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEC121E8094 for ; Wed, 7 Mar 2012 00:18:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=1782; q=dns/txt; s=iport; t=1331108332; x=1332317932; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Vb5ehfKNll9Bbpf22idD/95597d3u9rqrJleYEPB8jc=; b=ctSUMmrRJLPL6NcY1Gs9qKhyrqRq1fOeYYRZoEDZroVLfZ28KAZSKtsa VkwLDQoejTWOdn2l64GRif31YpsJbK8N1kGfhABmt88vJZ2OQaYSw5zFd tblZHSAqr9/GgODRpm5OMR1B6sPlDpVlDWQuvQuSxa3ITy2URvwfamP6Q s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKMZV0+rRDoG/2dsb2JhbABDtQ2BB4F9AQEBBBIBHQo/DAQCAQgRBAEBAQoGFwEGAUUJCAIEEwgTB4dkmnsBnxeQDWMEiFKdA4ME X-IronPort-AV: E=Sophos;i="4.73,545,1325462400"; d="scan'208";a="34931326" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 07 Mar 2012 08:18:52 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q278Ipdd029167; Wed, 7 Mar 2012 08:18:51 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Mar 2012 00:18:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Mar 2012 00:18:50 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580EA222B6@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <71231A86-7A22-48C0-987F-5C01C25E7B33@netapp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [middisc] middisc specification update Thread-Index: AcyG5wLVJKtf0Y74SiSodjFq7qJ2lxObcJ+QAAJE5sAI3dxCQACKW9EQAABRXxAAVSWDgAAHzeFAAAIEGQAAEL2wEA== References: <4E9241F7.5090406@mti-systems.com><2AE215BDC76842F885AC7E9D34BD2CA4@davidPC><0C53DCFB700D144284A584F54711EC580E546254@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EA21847@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EA21B2D@xmb-sjc-21c.amer.cisco.com> <56A8F14C-C1E1-4793-BC82-F27E89A9F8D4@bluecoat.com> <0C53DCFB700D144284A584F54711EC580EA222B2@xmb-sjc-21c.amer.cisco.com> <71231A86-7A22-48C0-987F-5C01C25E7B33@netapp.com> From: "Anantha Ramaiah (ananth)" To: "Eggert, Lars" X-OriginalArrivalTime: 07 Mar 2012 08:18:52.0080 (UTC) FILETIME=[EE27F300:01CCFC3A] Cc: "Frederick, Ron" , 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 08:18:53 -0000 Lars, Actually a good question. My simple answer (as you probably can guess) is to have some provision made in a hope that any vendor would try to approach the IETF before trying to adopt other evil means. It is a just a best effort, I guess :-) Funny, since IETF is not a policing agency, but I would be tempted to think if enough visibility is made on use cases that are "illegal" then that would force vendors to change, but there seems to be no formal way of enforcing this other than using some methods like this. Just let us take the example of the current draft. Mani (Cisco) who was one of the early architect of the WAN opt solution approached the IANA for getting this TCP option allocated, but later on got busy and never followed it up. Then with Bluecoat's draft, and the formation of middisc we have multiple vendors participating on this effort and agreeing in principle to move to the new TCP option. This is definitely a good progress and I should thank the initiative taken by you and Wes and David's support for getting this alias formed. -Anantha > -----Original Message----- > From: Eggert, Lars [mailto:lars@netapp.com] > Sent: Wednesday, March 07, 2012 12:04 AM > To: Anantha Ramaiah (ananth) > Cc: Frederick, Ron; > Subject: Re: [middisc] middisc specification update >=20 > On Mar 7, 2012, at 8:55, Anantha Ramaiah (ananth) wrote: > > Fair enough. We can note that some vendor codes are going to be > > reserved (FF to F0). These can be used to extend as needed tomorrow. > > Would that address your concern? >=20 > Idle thought: What makes us think that vendors will go through IANA to > get one of these codepoints, when they have been squatting on option > numbers already? >=20 > Lars From mani@cisco.com Wed Mar 7 06:31:55 2012 Return-Path: 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 6FAFE21F869A for ; Wed, 7 Mar 2012 06:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Iv7Wiy7gDOLv for ; Wed, 7 Mar 2012 06:31:54 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8912721F8693 for ; Wed, 7 Mar 2012 06:31:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mani@cisco.com; l=2390; q=dns/txt; s=iport; t=1331130714; x=1332340314; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=VIj85I35JgoXw7bG3YQjkVgMaoGeKkCGDiChDlFQeoI=; b=U03jvPnOMc7F7rbOr/ijntkTTkZmby4UhdtY76eUGyB2Paz0uEYj++n4 8dFuHZeIiezgAAwMLGgi9xGC9j9u5tqAu5gZRJrnGLvZRKpEN9yy+hzdc opjhlEUFq35Fnq0S4G0q7j2FSjyqY9TmeY37PPC09yn4fyvNeFyRIWve3 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFJwV0+rRDoH/2dsb2JhbABDtReBB4IKAQEBBAEBAQ8BHQo0CwwEAgEIEQQBAQEKBhcBBgEmHwkIAgQTCBMHh2UBC5oKAZ8qBJAMYwSIUp0GgwQ X-IronPort-AV: E=Sophos;i="4.73,546,1325462400"; d="scan'208";a="34971862" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 07 Mar 2012 14:31:54 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q27EVskl028620; Wed, 7 Mar 2012 14:31:54 GMT Received: from xmb-sjc-223.amer.cisco.com ([128.107.191.124]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Mar 2012 06:31:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Mar 2012 06:31:54 -0800 Message-ID: <4EF101F7236DB443A8FABF8164BFBD0C0F46BE0C@xmb-sjc-223.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580EA222B6@xmb-sjc-21c.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [middisc] middisc specification update Thread-Index: AcyG5wLVJKtf0Y74SiSodjFq7qJ2lxObcJ+QAAJE5sAI3dxCQACKW9EQAABRXxAAVSWDgAAHzeFAAAIEGQAAEL2wEAAULzrw References: <4E9241F7.5090406@mti-systems.com><2AE215BDC76842F885AC7E9D34BD2CA4@davidPC><0C53DCFB700D144284A584F54711EC580E546254@xmb-sjc-21c.amer.cisco.com><0C53DCFB700D144284A584F54711EC580EA21847@xmb-sjc-21c.amer.cisco.com><0C53DCFB700D144284A584F54711EC580EA21B2D@xmb-sjc-21c.amer.cisco.com><56A8F14C-C1E1-4793-BC82-F27E89A9F8D4@bluecoat.com><0C53DCFB700D144284A584F54711EC580EA222B2@xmb-sjc-21c.amer.cisco.com><71231A86-7A22-48C0-987F-5C01C25E7B33@netapp.com> <0C53DCFB700D144284A584F54711EC580EA222B6@xmb-sjc-21c.amer.cisco.com> From: "Mani Ramasamy (mani)" To: "Anantha Ramaiah (ananth)" , "Eggert, Lars" X-OriginalArrivalTime: 07 Mar 2012 14:31:54.0321 (UTC) FILETIME=[0B02E410:01CCFC6F] Cc: "Frederick, Ron" , 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 14:31:55 -0000 I agree with Anantha. If the process is light weight with a reasonably quick turnaround time, I think it would encourage the vendors to get their code points registered. Mani. -----Original Message----- From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On Behalf Of Anantha Ramaiah (ananth) Sent: Wednesday, March 07, 2012 12:19 AM To: Eggert, Lars Cc: Frederick, Ron; middisc@ietf.org Subject: Re: [middisc] middisc specification update Lars, Actually a good question. My simple answer (as you probably can guess) is to have some provision made in a hope that any vendor would try to approach the IETF before trying to adopt other evil means. It is a just a best effort, I guess :-) Funny, since IETF is not a policing agency, but I would be tempted to think if enough visibility is made on use cases that are "illegal" then that would force vendors to change, but there seems to be no formal way of enforcing this other than using some methods like this. Just let us take the example of the current draft. Mani (Cisco) who was one of the early architect of the WAN opt solution approached the IANA for getting this TCP option allocated, but later on got busy and never followed it up. Then with Bluecoat's draft, and the formation of middisc we have multiple vendors participating on this effort and agreeing in principle to move to the new TCP option. This is definitely a good progress and I should thank the initiative taken by you and Wes and David's support for getting this alias formed. -Anantha > -----Original Message----- > From: Eggert, Lars [mailto:lars@netapp.com] > Sent: Wednesday, March 07, 2012 12:04 AM > To: Anantha Ramaiah (ananth) > Cc: Frederick, Ron; > Subject: Re: [middisc] middisc specification update >=20 > On Mar 7, 2012, at 8:55, Anantha Ramaiah (ananth) wrote: > > Fair enough. We can note that some vendor codes are going to be > > reserved (FF to F0). These can be used to extend as needed tomorrow. > > Would that address your concern? >=20 > Idle thought: What makes us think that vendors will go through IANA to > get one of these codepoints, when they have been squatting on option > numbers already? >=20 > Lars _______________________________________________ middisc mailing list middisc@ietf.org https://www.ietf.org/mailman/listinfo/middisc From ietfdbh@comcast.net Wed Mar 7 07:27:10 2012 Return-Path: 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 ; 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 ; 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 ; 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 To: "Frederick, Ron" , "Anantha Ramaiah (ananth)" Message-ID: 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" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" 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 From ron.frederick@bluecoat.com Thu Mar 8 10:54:52 2012 Return-Path: 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 970E721F85D3 for ; Thu, 8 Mar 2012 10:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 6oKaR3JtiHWY for ; Thu, 8 Mar 2012 10:54:51 -0800 (PST) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by ietfa.amsl.com (Postfix) with ESMTP id DB6EC21F85D1 for ; Thu, 8 Mar 2012 10:54:51 -0800 (PST) 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 q28IslsE019336 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Mar 2012 10:54:47 -0800 (PST) Received: from PWSVL-EXCMBX-03.internal.cacheflow.com ([fe80::f1c6:61a6:35aa:6971]) by PWSVL-EXCHTS-01.internal.cacheflow.com ([fe80::5c50:e2ba:8115:4223%20]) with mapi id 14.01.0289.001; Thu, 8 Mar 2012 10:54:46 -0800 From: "Frederick, Ron" To: "Anantha Ramaiah (ananth)" Thread-Topic: [middisc] middisc specification update Thread-Index: AcyG5wLVJKtf0Y74SiSodjFq7qJ2lxObcJ+QAAJE5sAI3dxCQACKW9EQAABRXxAAVSWDgAAHzeFAAEsLsQA= Date: Thu, 8 Mar 2012 18:54:45 +0000 Message-ID: References: <4E9241F7.5090406@mti-systems.com><2AE215BDC76842F885AC7E9D34BD2CA4@davidPC><0C53DCFB700D144284A584F54711EC580E546254@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EA21847@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EA21B2D@xmb-sjc-21c.amer.cisco.com> <56A8F14C-C1E1-4793-BC82-F27E89A9F8D4@bluecoat.com> <0C53DCFB700D144284A584F54711EC580EA222B2@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580EA222B2@xmb-sjc-21c.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.2.106] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 18:54:52 -0000 On Mar 6, 2012, at 11:55 PM, Anantha Ramaiah (ananth) wrote: >> I'm generally good with the latest draft, but there are a few items >> that I think we need to address: >>=20 >> 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. >=20 > Yes, I had proposed this long time back but somehow did not hear an > explicit support. Ok, how about naming the draft as "TCP middlebox > option" and the current use case is about middlebox discovery. There > are handful of vendors doing WAN optimization today and a 255 byte > vendor code is a whole lot. Hence if we make this option generic > looking, other use cases can be handled as well. I need to make one > thing clear : it is the not the intention of the draft to encourage > middlebox insertions and uses, just to make this option extensible, so > that at the discretion of IETF if there exists a strong use case > tomorrow, this option can come to rescue. I was thinking of something like "TCP middlebox negotiation option". It's m= ore general than discovery, but it's still getting at the core use cases he= re which I think are all related to the middleboxes both discovering each o= ther and negotiating a set of transformations they want to apply to the dat= a stream. >> 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. >=20 > Middlebox can run inside the host as well, I guess middlebox definition > is something that sits in the middle of the connection, if you run > something that snoops on selected connections and does something to the > TCP traffic it is still a middlebox. Maybe can note this in the > terminology section. That seems like a reasonable way of looking at it. If this can be clarified= in the text, that should cover my objection. >> 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. >=20 > Fair enough. We can note that some vendor codes are going to be > reserved (FF to F0). These can be used to extend as needed tomorrow. > Would that address your concern? Given the previous discussion we had on the list of not wanting to use more= than one byte for "standard" type codes, I'm not sure that reserving a sma= ll range of vendor codes is quite enough here. Originally, I had proposed r= eserving only 0x00 for standard types and 0xff for extended vendor codes, b= ut that wasn't accepted by the group. >> I think we can address #2 here by reserving vendor code 0xFF for an >=20 > You mean #3 above ? Yes, sorry - I did. I edited my list of points while composing the mail and= forgot to update this reference. :) >> 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. >=20 > Well, I am happy with reserving some extended vendor codes for future > extension. I think envisioning a 32 bit vendor code at this point seems > very dubious to me at best. I also think we can use your MSB trick above > to separate vendor codes from other codes if there is a need to have > this option used for some other cases like NAT reveal etc., The OUI would be 24 bits, but with the 0xFF I guess that would turn into 32= bits total. The other option here would be to use the IANA private enterpr= ise number, but I think that's allowed to be up to 32 bits in length (thoug= h IANA has only assigned around 40,000 of them so far). I'm good with reserving 0xFF for extended vendor codes without specifying t= he rest of the mechanism here, but that still leaves open the question abou= t how we want to make room for standard middlebox message types. As David H= arrington pointed out, we should be trying to encourage this, so we should = have a good story for how such cases can use this option. Previously I sugg= ested the following: > Allow standard type codes to be allocated starting with 0x00 in an increa= sing fashion and allow vendor codes to be allocated starting with 0xFE in a= decreasing fashion. At some point, if it looks like too many vendor codes = are being allocated, IANA can declare that no more are available and that a= dditional vendors must use the 0xFF form with an OUI, leaving the remainder= of the space for standard type codes. What do others think of this? --=20 Ron Frederick ronf@bluecoat.com From andrew.knutsen@bluecoat.com Thu Mar 8 11:29:30 2012 Return-Path: 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 6FC8521E801B for ; Thu, 8 Mar 2012 11:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 s0uVFUulPXtq for ; Thu, 8 Mar 2012 11:29:29 -0800 (PST) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by ietfa.amsl.com (Postfix) with ESMTP id B5B2221E8019 for ; Thu, 8 Mar 2012 11:29:29 -0800 (PST) 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 q28JTRkr002000 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Mar 2012 11:29:27 -0800 (PST) Received: from [10.9.43.134] (10.2.2.106) by exchange.bluecoat.com (10.2.2.122) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 8 Mar 2012 11:29:22 -0800 Message-ID: <4F590892.5030701@bluecoat.com> Date: Thu, 8 Mar 2012 11:29:22 -0800 From: Andrew Knutsen User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "middisc@ietf.org" References: <4E9241F7.5090406@mti-systems.com><2AE215BDC76842F885AC7E9D34BD2CA4@davidPC><0C53DCFB700D144284A584F54711EC580E546254@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EA21847@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EA21B2D@xmb-sjc-21c.amer.cisco.com> <56A8F14C-C1E1-4793-BC82-F27E89A9F8D4@bluecoat.com> <0C53DCFB700D144284A584F54711EC580EA222B2@xmb-sjc-21c.amer.cisco.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: "Frederick, Ron" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 19:29:30 -0000 I like the idea of assigning vendor codes from one end and standard codes from the other, with one code reserved for future expansion. I also like the idea of not specifying the expansion mechanism; that can wait until more requirements are known. Andrew On 3/8/2012 10:54 AM, Frederick, Ron wrote: > On Mar 6, 2012, at 11:55 PM, Anantha Ramaiah (ananth) wrote: >>> 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. >> Yes, I had proposed this long time back but somehow did not hear an >> explicit support. Ok, how about naming the draft as "TCP middlebox >> option" and the current use case is about middlebox discovery. There >> are handful of vendors doing WAN optimization today and a 255 byte >> vendor code is a whole lot. Hence if we make this option generic >> looking, other use cases can be handled as well. I need to make one >> thing clear : it is the not the intention of the draft to encourage >> middlebox insertions and uses, just to make this option extensible, so >> that at the discretion of IETF if there exists a strong use case >> tomorrow, this option can come to rescue. > I was thinking of something like "TCP middlebox negotiation option". It's more general than discovery, but it's still getting at the core use cases here which I think are all related to the middleboxes both discovering each other and negotiating a set of transformations they want to apply to the data stream. > >>> 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. >> Middlebox can run inside the host as well, I guess middlebox definition >> is something that sits in the middle of the connection, if you run >> something that snoops on selected connections and does something to the >> TCP traffic it is still a middlebox. Maybe can note this in the >> terminology section. > That seems like a reasonable way of looking at it. If this can be clarified in the text, that should cover my objection. > >>> 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. >> Fair enough. We can note that some vendor codes are going to be >> reserved (FF to F0). These can be used to extend as needed tomorrow. >> Would that address your concern? > Given the previous discussion we had on the list of not wanting to use more than one byte for "standard" type codes, I'm not sure that reserving a small range of vendor codes is quite enough here. Originally, I had proposed reserving only 0x00 for standard types and 0xff for extended vendor codes, but that wasn't accepted by the group. > >>> I think we can address #2 here by reserving vendor code 0xFF for an >> You mean #3 above ? > Yes, sorry - I did. I edited my list of points while composing the mail and forgot to update this reference. :) > >>> 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. >> Well, I am happy with reserving some extended vendor codes for future >> extension. I think envisioning a 32 bit vendor code at this point seems >> very dubious to me at best. I also think we can use your MSB trick above >> to separate vendor codes from other codes if there is a need to have >> this option used for some other cases like NAT reveal etc., > The OUI would be 24 bits, but with the 0xFF I guess that would turn into 32 bits total. The other option here would be to use the IANA private enterprise number, but I think that's allowed to be up to 32 bits in length (though IANA has only assigned around 40,000 of them so far). > > I'm good with reserving 0xFF for extended vendor codes without specifying the rest of the mechanism here, but that still leaves open the question about how we want to make room for standard middlebox message types. As David Harrington pointed out, we should be trying to encourage this, so we should have a good story for how such cases can use this option. Previously I suggested the following: > >> Allow standard type codes to be allocated starting with 0x00 in an increasing fashion and allow vendor codes to be allocated starting with 0xFE in a decreasing fashion. At some point, if it looks like too many vendor codes are being allocated, IANA can declare that no more are available and that additional vendors must use the 0xFF form with an OUI, leaving the remainder of the space for standard type codes. > What do others think of this? From ananth@cisco.com Thu Mar 8 12:26:52 2012 Return-Path: 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 EF86D21E8049 for ; Thu, 8 Mar 2012 12:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.77 X-Spam-Level: X-Spam-Status: No, score=-9.77 tagged_above=-999 required=5 tests=[AWL=0.829, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 RVY+nHEy-2mZ for ; Thu, 8 Mar 2012 12:26:52 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4F62121E8047 for ; Thu, 8 Mar 2012 12:26:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=891; q=dns/txt; s=iport; t=1331238412; x=1332448012; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=NFt9CzwCMyQckeuXX6x/weWrnvp7MLTHYKXMZsIjcfo=; b=NMkHWMfLIaUyPlNJogNeVX7wdS2gkyV4PepLbNA8Ec+eCfUcvELqamPt awfjlPJ1gGPBOJKoK7b4ejNxpCsUQcAQYVRDWyRkUr8xgpfQ6cCqP/FBf tUuUQ0QQ0fJMTYaADrA9UWqowvGuAzQe5Y6HtdMnikKe+qSuJflE2SnWf 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAOsVWU+rRDoI/2dsb2JhbABDtSmBB4ILAQEEEgEdCj8QAgEIIgYYBgFWAgQTCBqHZwGbQQGfCI9zYwSIUp0LgwQ X-IronPort-AV: E=Sophos;i="4.73,553,1325462400"; d="scan'208";a="32614050" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 08 Mar 2012 20:26:51 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q28KQod9027299; Thu, 8 Mar 2012 20:26:50 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 12:26:50 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Mar 2012 12:26:50 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC580EAB248A@xmb-sjc-21c.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [middisc] middisc specification update Thread-Index: AcyG5wLVJKtf0Y74SiSodjFq7qJ2lxObcJ+QAAJE5sAI3dxCQACKW9EQAABRXxAAVSWDgAAHzeFAAEsLsQAADcGhoA== References: <4E9241F7.5090406@mti-systems.com><2AE215BDC76842F885AC7E9D34BD2CA4@davidPC><0C53DCFB700D144284A584F54711EC580E546254@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EA21847@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EA21B2D@xmb-sjc-21c.amer.cisco.com> <56A8F14C-C1E1-4793-BC82-F27E89A9F8D4@bluecoat.com> <0C53DCFB700D144284A584F54711EC580EA222B2@xmb-sjc-21c.amer.cisco.com> From: "Anantha Ramaiah (ananth)" To: "Frederick, Ron" X-OriginalArrivalTime: 08 Mar 2012 20:26:50.0873 (UTC) FILETIME=[CB289690:01CCFD69] Cc: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 20:26:53 -0000 Hi Ron, >=20 > > Allow standard type codes to be allocated starting with 0x00 in an > increasing fashion and allow vendor codes to be allocated starting with > 0xFE in a decreasing fashion. At some point, if it looks like too many > vendor codes are being allocated, IANA can declare that no more are > available and that additional vendors must use the 0xFF form with an > OUI, leaving the remainder of the space for standard type codes. >=20 > What do others think of this? Question : when you say vendor code, are you saying one vendor can get multiple vendor codes? Or is strictly one per vendor. I assumed the latter. When you say "standard type", what are those? Are those the ones used by multiple vendors and really interoperable? Just wanted to make sure we both are on the same page w.r.t terminology. -Anantha > -- > Ron Frederick > ronf@bluecoat.com From ron.frederick@bluecoat.com Thu Mar 8 12:34:20 2012 Return-Path: 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 6D72821E8051 for ; Thu, 8 Mar 2012 12:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 JO1hwhR+ROp2 for ; Thu, 8 Mar 2012 12:34:19 -0800 (PST) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by ietfa.amsl.com (Postfix) with ESMTP id B225A21E8050 for ; Thu, 8 Mar 2012 12:34:19 -0800 (PST) Received: from PWSVL-EXCHTS-02.internal.cacheflow.com (sai-rp.bluecoat.com [10.2.2.126] (may be forged)) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id q28KYFBC025643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Mar 2012 12:34:16 -0800 (PST) Received: from PWSVL-EXCMBX-03.internal.cacheflow.com ([fe80::f1c6:61a6:35aa:6971]) by PWSVL-EXCHTS-02.internal.cacheflow.com ([fe80::4910:317f:407:6ecc%14]) with mapi id 14.01.0289.001; Thu, 8 Mar 2012 12:34:15 -0800 From: "Frederick, Ron" To: "Anantha Ramaiah (ananth)" Thread-Topic: [middisc] middisc specification update Thread-Index: AcyG5wLVJKtf0Y74SiSodjFq7qJ2lxObcJ+QAAJE5sAI3dxCQACKW9EQAABRXxAAVSWDgAAHzeFAAEsLsQAADcGhoP//rcCA Date: Thu, 8 Mar 2012 20:34:15 +0000 Message-ID: References: <4E9241F7.5090406@mti-systems.com><2AE215BDC76842F885AC7E9D34BD2CA4@davidPC><0C53DCFB700D144284A584F54711EC580E546254@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EA21847@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EA21B2D@xmb-sjc-21c.amer.cisco.com> <56A8F14C-C1E1-4793-BC82-F27E89A9F8D4@bluecoat.com> <0C53DCFB700D144284A584F54711EC580EA222B2@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EAB248A@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580EAB248A@xmb-sjc-21c.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.2.106] Content-Type: text/plain; charset="us-ascii" Content-ID: <17D99CF23A3FA04683055456F2B19578@bluecoat.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 20:34:20 -0000 On Mar 8, 2012, at 12:26 PM, Anantha Ramaiah (ananth) wrote: >>> Allow standard type codes to be allocated starting with 0x00 in an >> increasing fashion and allow vendor codes to be allocated starting with >> 0xFE in a decreasing fashion. At some point, if it looks like too many >> vendor codes are being allocated, IANA can declare that no more are >> available and that additional vendors must use the 0xFF form with an >> OUI, leaving the remainder of the space for standard type codes. >>=20 >> What do others think of this? >=20 > Question : when you say vendor code, are you saying one vendor can get > multiple vendor codes? Or is strictly one per vendor. I assumed the > latter. In cases where a vendor wants their own vendor code, my thinking was that t= hey only get one. If they need multiple middlebox option types, they would = have to distinguish them using some other bits in the vendor-specific paylo= ad. If they didn't make provisions in advance for that, they'd have to eith= er adjust their payload format later to add it, or have their additional op= tions use the 0xFF+OUI version of the header. > When you say "standard type", what are those? Are those the ones used by > multiple vendors and really interoperable? >=20 > Just wanted to make sure we both are on the same page w.r.t terminology. Yes - the notion would be that we could standardize certain payload types w= hich could be used to interoperate between vendors. These would have RFCs a= ssociated with them, and they would be assigned a type code by IANA which w= ould come out of the same space as the vendor codes. To keep them organized= , though, the standard type codes would be assigned counting up from 0x00 a= nd the vendor codes would be assigned counting down from 0xFE (with 0xFF re= served for longer vendor codes). --=20 Ron Frederick ronf@bluecoat.com From wes@mti-systems.com Tue Mar 13 09:25:04 2012 Return-Path: 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 96C4B21E803D for ; Tue, 13 Mar 2012 09:25:04 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pou3oSSJfOQy for ; Tue, 13 Mar 2012 09:24:37 -0700 (PDT) Received: from omr16.networksolutionsemail.com (omr16.networksolutionsemail.com [205.178.146.66]) by ietfa.amsl.com (Postfix) with ESMTP id 69C8621E8034 for ; Tue, 13 Mar 2012 09:24:34 -0700 (PDT) Received: from cm-omr12 (mail.networksolutionsemail.com [205.178.146.50]) by omr16.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q2DGOWHg022362 for ; Tue, 13 Mar 2012 12:24:32 -0400 Authentication-Results: cm-omr12 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [107.50.175.168] ([107.50.175.168:43530] helo=[192.168.43.65]) by cm-omr12 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 7B/BC-16767-EB47F5F4; Tue, 13 Mar 2012 12:24:32 -0400 Message-ID: <4F5F74BB.2020306@mti-systems.com> Date: Tue, 13 Mar 2012 12:24:27 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <4E9241F7.5090406@mti-systems.com><2AE215BDC76842F885AC7E9D34BD2CA4@davidPC><0C53DCFB700D144284A584F54711EC580E546254@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EA21847@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EA21B2D@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EA21B77@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC580EA21B77@xmb-sjc-21c.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 16:25:04 -0000 On 3/5/2012 2:44 PM, Anantha Ramaiah (ananth) wrote: > > Right, from vendors pov, experimental may sound fine. But from IETF > standards pov, this sort of an effort is aimed at reducing unauthorized > TCP option poaching and if such a draft exists it would both act as a > recommendation and for vendors to not use unauthorized options. In such > cases would experimental convey the "strong" message. May be some text > needs to be added to the draft echoing what you alluded above... I have a real problem with Standards Track, given that the middlebox association seemed to introduce a combination of distaste and eventual disinterest in TCPM. Also, based on the slow progress in getting this specification done, I have some doubt that it will quickly be integrated into products and deployed. I think that given the options we have, Experimental is a reasonable fit, and if it does wind up in wide use by multiple vendors, we can look at advancing it. > I am not sure these things are spelled out clearly in the draft, but the > message is spread across and may be if there is a need for making it > more clear, please let us know. I would like it to be very clear. > Also if the status is experimental, I am assuming that we would still > get a regular TCP option code point and not the TCP experimental option > code point. I am assuming when you said experiment above it is more on > the lines of multiple vendors dis-continuing and using the standard TCP > option number that is allocated for this purpose. With IESG approval, a regular option can be allocated, regardless of whether the document status is Experimental. -- Wes Eddy MTI Systems From andrew.knutsen@bluecoat.com Tue Mar 13 09:38:02 2012 Return-Path: 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 8BEF321E804E for ; Tue, 13 Mar 2012 09:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 gml5+OXjFol3 for ; Tue, 13 Mar 2012 09:38:01 -0700 (PDT) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by ietfa.amsl.com (Postfix) with ESMTP id EC85E21E804B for ; Tue, 13 Mar 2012 09:38:00 -0700 (PDT) Received: from PWSVL-EXCHTS-02.internal.cacheflow.com (sai-rp.bluecoat.com [10.2.2.126] (may be forged)) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id q2DGbuHQ013959 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Mar 2012 09:37:56 -0700 (PDT) Received: from PWSVL-EXCMBX-01.internal.cacheflow.com ([fe80::15bc:12e2:4676:340f]) by PWSVL-EXCHTS-02.internal.cacheflow.com ([fe80::4910:317f:407:6ecc%14]) with mapi id 14.01.0289.001; Tue, 13 Mar 2012 09:37:50 -0700 From: "Knutsen, Andrew" To: David Harrington , "Frederick, Ron" , "Anantha Ramaiah (ananth)" Thread-Topic: [middisc] middisc specification update Thread-Index: AQHMhucFU/ulB73iwUW1CC0ioy3eMpYSIfyAgAAUjQCARu7WgIAEUlmAgAAD8YCAAh+ygIAAynOAgAj7ACs= Date: Tue, 13 Mar 2012 16:37:50 +0000 Message-ID: <974FE049BD0F2E4188567FAD99DEF03306CBC9@PWSVL-EXCMBX-01.internal.cacheflow.com> References: <56A8F14C-C1E1-4793-BC82-F27E89A9F8D4@bluecoat.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.91.133.85] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 16:38:02 -0000 =0A= The ultimate goal is to move towards inter-vendor solutions, which is wh= y we're providing for "standard" types as well as vendor types. However, t= his will take some time, so we also have an intermediate goal which is to s= top using unassigned option kinds.=0A= =0A= Andrew=0A= ________________________________________=0A= From: middisc-bounces@ietf.org [middisc-bounces@ietf.org] on behalf of Davi= d Harrington [ietfdbh@comcast.net]=0A= Sent: Wednesday, March 07, 2012 7:27 AM=0A= To: Frederick, Ron; Anantha Ramaiah (ananth)=0A= Cc: middisc@ietf.org=0A= Subject: Re: [middisc] middisc specification update=0A= =0A= Hi,=0A= =0A= I will just observe that the IETF goal is to get cross-vendor=0A= interoperability (and to get vendors to use an assigned code point),=0A= because that helps the Internet run better.=0A= =0A= It is not very consistent with IETF goals to define a standard option=0A= through which vendors can add all sorts of proprietary solutions. We=0A= really would like to see industry standardization of middlebox discovery,= =0A= not provide a place for vendors to invent a bunch of new non-interoperable= =0A= solutions.=0A= =0A= --=0A= David Harrington=0A= Director, Transport Area=0A= Internet Engineering Task Force (IETF)=0A= Ietfdbh@comcast.net=0A= +1-603-828-1401=0A= =0A= =0A= =0A= =0A= =0A= On 3/6/12 10:22 PM, "Frederick, Ron" wrote:=0A= =0A= >On Mar 5, 2012, at 10:56 AM, Anantha Ramaiah (ananth) wrote:=0A= >>> -----Original Message-----=0A= >>> From: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]=0A= >>> [mailto:wesley.m.eddy@nasa.gov]=0A= >>> Sent: Monday, March 05, 2012 10:42 AM=0A= >>> To: Anantha Ramaiah (ananth); David Harrington; Wesley Eddy;=0A= >>> middisc@ietf.org=0A= >>> Subject: RE: [middisc] middisc specification update=0A= >>>=0A= >>> Thanks for posting the draft.=0A= >>>=0A= >>> The intention is to handle this as an AD-sponsored document,=0A= >>> not via an IETF working group.=0A= >>>=0A= >>> No presentation is needed.=0A= >>>=0A= >>> When all of the authors have agreed on it and consider it to=0A= >>=0A= >> From my point of view, I am done. Other stakeholders also have reviewed= =0A= >> this document and they seem ok with it (as far as I can tell). They can= =0A= >> comment in any case.=0A= >=0A= >I'm generally good with the latest draft, but there are a few items that= =0A= >I think we need to address:=0A= >=0A= >1) I think it would be good to rename the option to make it clear that it= =0A= >can be used for more than just discovery. The text already describes=0A= >being able to use the option to provide information to other middleboxes= =0A= >on the path. I think we just need to emphasize that a bit more and make=0A= >it clear that discovery is only one potential use for the option.=0A= >=0A= >2) The current text explicitly discourages end hosts from participating=0A= >in this exchange. I think that's a mistake. In some cases, a "soft"=0A= >implementation of a middlebox could run directly on a client or a server,= =0A= >and it would want to be able to interoperate with other physical=0A= >middleboxes that expect to see this option. We want to be able to support= =0A= >that use case by allowing the soft middlebox on one of the end hosts to=0A= >add or respond to this option.=0A= >=0A= >3) I'm good with supporting the single byte vendor code with=0A= >vendor-specific payload data after it, but I think we should at least=0A= >leave some provision in there for the other two cases we previously=0A= >discussed of standard type codes and an escape of some kind for a longer= =0A= >vendor code if we're wrong about the adoption of this and we run out of=0A= >space in the single byte.=0A= >=0A= >I think we can address #2 here by reserving vendor code 0xFF for an=0A= >extended vendor code that could be based on something like an OUI. If=0A= >that's too big, we could also do something like say that setting the=0A= >high-bit in the vendor code expands it to 16 bits. So, the first 128=0A= >vendor codes are one byte, and then we get another ~32K of them which are= =0A= >two bytes.=0A= >--=0A= >Ron Frederick=0A= >ronf@bluecoat.com=0A= >=0A= >_______________________________________________=0A= >middisc mailing list=0A= >middisc@ietf.org=0A= >https://www.ietf.org/mailman/listinfo/middisc=0A= =0A= =0A= _______________________________________________=0A= middisc mailing list=0A= middisc@ietf.org=0A= https://www.ietf.org/mailman/listinfo/middisc=0A= From ananth@cisco.com Tue Mar 13 10:16:18 2012 Return-Path: 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 EF55121E8045 for ; Tue, 13 Mar 2012 10:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Vdkkk8ZQfKi2 for ; Tue, 13 Mar 2012 10:16:18 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6556C21E8043 for ; Tue, 13 Mar 2012 10:16:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=3049; q=dns/txt; s=iport; t=1331658978; x=1332868578; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=AEZwAVIWvsqnKkZkWsXvfb3e+rglRMNpIulJWPIO8wY=; b=kAKj6PaE6w2ToSUGHED6IhK4TIVS38M1ZMG1INvMZTYqCKwsITEkje+g YrWg6ISlifdwIpBxYAKjJR7GfYFmTVxTqLs0c/OEc8u807sDQFPX6DB48 Xo1z+w9C1hsjlrdFrv2Jw88onbq6+gfiXrcWFxfkM/s0WUld7k0Q1merx U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPB/X0+rRDoG/2dsb2JhbABDtWSBB4IJAQEBBBIBHQo/DAQCAQgOAwQBAQEKBhcBBgFFCQgBAQQTCBqHZwGdMgGfE5ACYwSIVZ0egwWBPA X-IronPort-AV: E=Sophos;i="4.73,577,1325462400"; d="scan'208";a="35940184" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 13 Mar 2012 17:16:18 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2DHGHwM001845; Tue, 13 Mar 2012 17:16:17 GMT Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Mar 2012 10:16:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Mar 2012 10:16:16 -0700 Message-ID: <1F8E0A684D3FF54680294BCFE57A7DB504A5B564@xmb-sjc-23e.amer.cisco.com> In-Reply-To: <4F5F74BB.2020306@mti-systems.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [middisc] middisc specification update Thread-Index: Ac0BNccSFIAmoasxRQCi5mfk9Az5LgABbtCg References: <4E9241F7.5090406@mti-systems.com><2AE215BDC76842F885AC7E9D34BD2CA4@davidPC><0C53DCFB700D144284A584F54711EC580E546254@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EA21847@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EA21B2D@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EA21B77@xmb-sjc-21c.amer.cisco.com> <4F5F74BB.2020306@mti-systems.com> From: "Anantha Ramaiah (ananth)" To: "Wesley Eddy" X-OriginalArrivalTime: 13 Mar 2012 17:16:18.0126 (UTC) FILETIME=[00C696E0:01CD013D] Cc: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 17:16:19 -0000 Hi Wes, Ok, I am on page with the process now and I am fine with the status being experimental ( I guess it should be ok with others as well). So, the next steps are I guess is to revise the draft with the comments received so far, put the intended status to "experimental" and re-submit it. I guess the IETF submission re-opens after IETF meeting, so I'll have some time to do this. I'll be coming to IETF this time and we can chat sometime when you are free. Just to add (in response to your concern below): From the various email discussions there is a lot of interest among multiple vendors (Bluecoat, Riverbed and Cisco) to move towards the new TCP option when it gets allocated, but the obvious challenge is going to be backwards compatibility and eventual EOL of boxes doing the unassigned options. It will take time for sure but it should eventually happen I guess. -Anantha > -----Original Message----- > From: Wesley Eddy [mailto:wes@mti-systems.com] > Sent: Tuesday, March 13, 2012 9:24 AM > To: Anantha Ramaiah (ananth) > Cc: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; David Harrington; > middisc@ietf.org > Subject: Re: [middisc] middisc specification update >=20 > On 3/5/2012 2:44 PM, Anantha Ramaiah (ananth) wrote: > > > > Right, from vendors pov, experimental may sound fine. But from IETF > > standards pov, this sort of an effort is aimed at reducing > unauthorized > > TCP option poaching and if such a draft exists it would both act as a > > recommendation and for vendors to not use unauthorized options. In > such > > cases would experimental convey the "strong" message. May be some > text > > needs to be added to the draft echoing what you alluded above... >=20 >=20 > I have a real problem with Standards Track, given that the middlebox > association seemed to introduce a combination of distaste and > eventual disinterest in TCPM. Also, based on the slow progress in > getting this specification done, I have some doubt that it will > quickly be integrated into products and deployed. I think that given > the options we have, Experimental is a reasonable fit, and if it does > wind up in wide use by multiple vendors, we can look at advancing it. >=20 >=20 > > I am not sure these things are spelled out clearly in the draft, but > the > > message is spread across and may be if there is a need for making it > > more clear, please let us know. >=20 >=20 > I would like it to be very clear. >=20 >=20 > > Also if the status is experimental, I am assuming that we would still > > get a regular TCP option code point and not the TCP experimental > option > > code point. I am assuming when you said experiment above it is more > on > > the lines of multiple vendors dis-continuing and using the standard > TCP > > option number that is allocated for this purpose. >=20 >=20 > With IESG approval, a regular option can be allocated, regardless of > whether the document status is Experimental. >=20 > -- > Wes Eddy > MTI Systems