From wes@mti-systems.com Tue Jan 8 17:12:31 2013 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 F1A5F11E809C for ; Tue, 8 Jan 2013 17:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZw3llw+5-sW for ; Tue, 8 Jan 2013 17:12:30 -0800 (PST) Received: from atl4mhob12.myregisteredsite.com (atl4mhob12.myregisteredsite.com [209.17.115.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7E72911E80D2 for ; Tue, 8 Jan 2013 17:12:26 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob12.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r091COpL005180 for ; Tue, 8 Jan 2013 20:12:24 -0500 Received: (qmail 11435 invoked by uid 0); 9 Jan 2013 01:12:24 -0000 Received: from unknown (HELO ?172.20.4.157?) (wes@mti-systems.com@12.43.240.66) by 0 with ESMTPA; 9 Jan 2013 01:12:24 -0000 Message-ID: <50ECC3EF.1020405@mti-systems.com> Date: Tue, 08 Jan 2013 20:12:15 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: middisc@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [middisc] closure of the middisc list 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, 09 Jan 2013 01:12:31 -0000 I believe that this mailing list is pretty much dead as well as the associated effort to get a codepoint reserved for vendors to share a legitimate TCP option number across the various middlebox discovery mechanisms. Since this list was setup by the IETF TSV ADs in order to facilitate discussion and help to resolve the issue, seeing no discussion or progress, Martin and I are ready to close the list. I plan to request the IESG Secretary to close this list sometime next week. If there are still people interested in progressing some flavor of the specification we all were working on, please contact Martin or myself for possible AD-sponsoring. -- Wes Eddy MTI Systems From ananth@nttmcl.com Tue Jan 8 17:24:18 2013 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 B96B421F8480 for ; Tue, 8 Jan 2013 17:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BIBHWHTzncx for ; Tue, 8 Jan 2013 17:24:17 -0800 (PST) Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id 50D1421F847F for ; Tue, 8 Jan 2013 17:24:07 -0800 (PST) Received: by mail-pb0-f41.google.com with SMTP id xa7so596990pbc.28 for ; Tue, 08 Jan 2013 17:24:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Jc6JO0/NIO/EGQ0iH/F/78XbBfB9/8synUguP5cnKus=; b=CJOHmWyiCqPCZ36NTOAh9Qc2nzzwBZhQLU6OZk1Q9KDzI4PApbh1T21Dr8Ow7VFnR2 oyt99UYQRWVdOEl9yVWROZgmQKjcb32EbtD8ZVfsxU0c94C2PKROAB21T7zFXpTZGFxu 8QpA8JAuTszcaklApCHdUpNT05B3e6mwoQbH1g+uxw4M6b9np1DIVhrLgBxQB/3tm/tm aohzeYE9WWJP8MvvM0pt34k554yej4xxyjiMTr75zTDDuOmyOUM87/OLgHfsWHjZpXhH +ti2r7CrHvUWz0o8oQM9egsy0CB9zawXtSgOibkOTYdwu7Gb6GjtM5CNiFbnMqKluzOV wpcw== MIME-Version: 1.0 Received: by 10.68.237.135 with SMTP id vc7mr204175678pbc.2.1357694647097; Tue, 08 Jan 2013 17:24:07 -0800 (PST) Received: by 10.68.46.163 with HTTP; Tue, 8 Jan 2013 17:24:06 -0800 (PST) In-Reply-To: <50ECC3EF.1020405@mti-systems.com> References: <50ECC3EF.1020405@mti-systems.com> Date: Tue, 8 Jan 2013 17:24:06 -0800 Message-ID: From: Anantha Ramaiah To: Wesley Eddy Content-Type: multipart/alternative; boundary=047d7b33900327597304d2d0eb85 X-Gm-Message-State: ALoCoQlGtDZCkfMQqR4rcUkoeFTAFxQbVOobtM+YIsbh16ZM0ubnO1cft1lp1rnRccjn6OGNEHL/ Cc: middisc@ietf.org Subject: Re: [middisc] closure of the middisc list 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, 09 Jan 2013 01:24:18 -0000 --047d7b33900327597304d2d0eb85 Content-Type: text/plain; charset=ISO-8859-1 Hi, Wes, After I left Cisco, I am no longer able to work on this any further (sorry I should have finished it before thart...). However I believe Mani from Cisco (already in the list) may be interested get the review comments incorporated and push this forward. IMO, this draft is ready for publication and getting a TCP option number reserved for middlebox discovery. thanks, -Anantha On Tue, Jan 8, 2013 at 5:12 PM, Wesley Eddy wrote: > I believe that this mailing list is pretty much dead as well as the > associated effort to get a codepoint reserved for vendors to share a > legitimate TCP option number across the various middlebox discovery > mechanisms. > > Since this list was setup by the IETF TSV ADs in order to facilitate > discussion and help to resolve the issue, seeing no discussion or > progress, Martin and I are ready to close the list. > > I plan to request the IESG Secretary to close this list sometime > next week. If there are still people interested in progressing some > flavor of the specification we all were working on, please contact > Martin or myself for possible AD-sponsoring. > > -- > Wes Eddy > MTI Systems > _______________________________________________ > middisc mailing list > middisc@ietf.org > https://www.ietf.org/mailman/listinfo/middisc > --047d7b33900327597304d2d0eb85 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Wes,
=A0 =A0 =A0After I left Cisco, I am no longer able to work on = this any further (sorry I should have finished it before thart...). =A0Howe= ver I believe Mani from Cisco (already in the list) =A0may be interested ge= t the review comments incorporated and push this forward. IMO, this draft i= s ready for publication and getting a TCP option number reserved for middle= box discovery.=A0
thanks,
-Anantha

On Tue, J= an 8, 2013 at 5:12 PM, Wesley Eddy <wes@mti-systems.com> w= rote:
I believe that this mailing list is pretty m= uch dead as well as the
associated effort to get a codepoint reserved for vendors to share a
legitimate TCP option number across the various middlebox discovery
mechanisms.

Since this list was setup by the IETF TSV ADs in order to facilitate
discussion and help to resolve the issue, seeing no discussion or
progress, Martin and I are ready to close the list.

I plan to request the IESG Secretary to close this list sometime
next week. =A0If there are still people interested in progressing some
flavor of the specification we all were working on, please contact
Martin or myself for possible AD-sponsoring.

--
Wes Eddy
MTI Systems
_______________________________________________
middisc mailing list
middisc@ietf.org
https://www.ietf.org/mailman/listinfo/middisc

--047d7b33900327597304d2d0eb85-- From mani@cisco.com Tue Jan 8 18:16:22 2013 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 7FD461F0CB3 for ; Tue, 8 Jan 2013 18:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGAWWr6zEOo7 for ; Tue, 8 Jan 2013 18:16:21 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0D96D1F0C3E for ; Tue, 8 Jan 2013 18:16:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8362; q=dns/txt; s=iport; t=1357697781; x=1358907381; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6YPDKbT2+K5MzJd9MADZr3slZAbx1veRJ2Gywt1W41c=; b=khzH2Hk5ABHby0lUOVHWjZfBbaouzdLtOk9U3qvXoHjHKgtV04OZ0a69 w9jK1L3dj+XdP+aLrQE9o99qNg+Ns1u98oSsUdE8QBx8leLh6PZrHChIf OzHVh1A8yb+zu7Vwyla1V+x8tqfxos8e6zIN4Jf0NgNXyYd43sY78TgDr s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAGrS7FCtJV2Z/2dsb2JhbABFgki7FxZzgh4BAQEEAQEBKkELEAIBCA4DBAEBCx0HJwsUCQgCBAENBQiIDwyrfYsMBJA0YQOSWZN8gmcNgiY X-IronPort-AV: E=Sophos;i="4.84,435,1355097600"; d="scan'208,217";a="160327550" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 09 Jan 2013 02:16:20 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r092GK2x020841 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Jan 2013 02:16:20 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.75]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Tue, 8 Jan 2013 20:16:20 -0600 From: "Mani Ramasamy (mani)" To: Anantha Ramaiah , Wesley Eddy Thread-Topic: [middisc] closure of the middisc list Thread-Index: AQHN7gZoJ3eDBtsU7E6OW7KrYI/u+phAmJAA//+o1tA= Date: Wed, 9 Jan 2013 02:16:19 +0000 Message-ID: References: <50ECC3EF.1020405@mti-systems.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.160.123] Content-Type: multipart/alternative; boundary="_000_CD6E74FCC0FE024BB73C6B483F6706FE0FC0FCD3xmbrcdx07ciscoc_" MIME-Version: 1.0 Cc: "middisc@ietf.org" Subject: Re: [middisc] closure of the middisc list 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, 09 Jan 2013 02:16:22 -0000 --_000_CD6E74FCC0FE024BB73C6B483F6706FE0FC0FCD3xmbrcdx07ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Wes, As Anantha says, I would like to continue on this effort. I will target the completion of the revised draft by end of next week. Thanks, Mani. From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On Behalf = Of Anantha Ramaiah Sent: Tuesday, January 08, 2013 5:24 PM To: Wesley Eddy Cc: middisc@ietf.org Subject: Re: [middisc] closure of the middisc list Hi, Wes, After I left Cisco, I am no longer able to work on this any further (s= orry I should have finished it before thart...). However I believe Mani fr= om Cisco (already in the list) may be interested get the review comments i= ncorporated and push this forward. IMO, this draft is ready for publication= and getting a TCP option number reserved for middlebox discovery. thanks, -Anantha On Tue, Jan 8, 2013 at 5:12 PM, Wesley Eddy > wrote: I believe that this mailing list is pretty much dead as well as the associated effort to get a codepoint reserved for vendors to share a legitimate TCP option number across the various middlebox discovery mechanisms. Since this list was setup by the IETF TSV ADs in order to facilitate discussion and help to resolve the issue, seeing no discussion or progress, Martin and I are ready to close the list. I plan to request the IESG Secretary to close this list sometime next week. If there are still people interested in progressing some flavor of the specification we all were working on, please contact Martin or myself for possible AD-sponsoring. -- Wes Eddy MTI Systems _______________________________________________ middisc mailing list middisc@ietf.org https://www.ietf.org/mailman/listinfo/middisc --_000_CD6E74FCC0FE024BB73C6B483F6706FE0FC0FCD3xmbrcdx07ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Wes,=

    &= nbsp;           As Ananth= a says,  I would like to continue on this effort.

 <= /p>

I will target the complet= ion of the revised draft by end of next week.

 <= /p>

 <= /p>

Thanks,=

Mani.

 <= /p>

From: middisc-= bounces@ietf.org [mailto:middisc-bounces@ietf.org] On Behalf Of Anantha Ramaiah
Sent: Tuesday, January 08, 2013 5:24 PM
To: Wesley Eddy
Cc: middisc@ietf.org
Subject: Re: [middisc] closure of the middisc list=

 

Hi, Wes,

     After I left Cisco, I am no long= er able to work on this any further (sorry I should have finished it before= thart...).  However I believe Mani from Cisco (already in the list) &= nbsp;may be interested get the review comments incorporated and push this forward. IMO, this draft is ready for publication and gettin= g a TCP option number reserved for middlebox discovery. 

thanks,

-Anantha

On Tue, Jan 8, 2013 at 5:12 PM, Wesley Eddy <wes@mti-systems.com> wrote:

I believe that this mailing list is pretty much dead= as well as the
associated effort to get a codepoint reserved for vendors to share a
legitimate TCP option number across the various middlebox discovery
mechanisms.

Since this list was setup by the IETF TSV ADs in order to facilitate
discussion and help to resolve the issue, seeing no discussion or
progress, Martin and I are ready to close the list.

I plan to request the IESG Secretary to close this list sometime
next week.  If there are still people interested in progressing some flavor of the specification we all were working on, please contact
Martin or myself for possible AD-sponsoring.

--
Wes Eddy
MTI Systems
_______________________________________________
middisc mailing list
middisc@ietf.org=
https://www.ietf.org/mailman/listinfo/middisc

 

--_000_CD6E74FCC0FE024BB73C6B483F6706FE0FC0FCD3xmbrcdx07ciscoc_-- From lars@netapp.com Wed Jan 9 06:47:46 2013 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 8A07D21F87FD for ; Wed, 9 Jan 2013 06:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.545 X-Spam-Level: X-Spam-Status: No, score=-10.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQd84RDVKCDr for ; Wed, 9 Jan 2013 06:47:45 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 90D9E21F8497 for ; Wed, 9 Jan 2013 06:47:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,438,1355126400"; d="scan'208";a="3487883" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 09 Jan 2013 06:47:43 -0800 Received: from vmwexceht05-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.77.35]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r09ElgG0018946; Wed, 9 Jan 2013 06:47:42 -0800 (PST) Received: from SACEXCMBX06-PRD.hq.netapp.com ([169.254.8.16]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0328.009; Wed, 9 Jan 2013 06:47:42 -0800 From: "Eggert, Lars" To: "Mani Ramasamy (mani)" Thread-Topic: [middisc] closure of the middisc list Thread-Index: AQHN7gZol/XxpdOfEEeUs2bflsBXhJhAuhcAgAAOl4CAANHugA== Date: Wed, 9 Jan 2013 14:47:41 +0000 Message-ID: References: <50ECC3EF.1020405@mti-systems.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: <25E1216C6D44EE4AB28A42D55A4022DC@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Wesley Eddy , "middisc@ietf.org" Subject: Re: [middisc] closure of the middisc list 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, 09 Jan 2013 14:47:46 -0000 Hi, On Jan 9, 2013, at 3:16, Mani Ramasamy (mani) wrote: > As Anantha says, I would like to continue on this effort. > I will target the completion of the revised draft by end of next week. I was AD when this effort was started, and it's been a while. I fully agree= with Wes that we need to finish this, or declare failure and disband the l= ist. If there is anything I can do to help progress this, I'd be happy to. Lars= From Mark.Day@riverbed.com Wed Jan 9 07:00:14 2013 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 C744D21F8630 for ; Wed, 9 Jan 2013 07:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id po-mqHWcLMtG for ; Wed, 9 Jan 2013 07:00:13 -0800 (PST) Received: from smtp1.riverbed.com (incomingmail.riverbed.com [208.70.196.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6466421F862E for ; Wed, 9 Jan 2013 07:00:13 -0800 (PST) Received: from unknown (HELO 365EXCH-HUB-P3.nbttech.com) ([10.16.4.1]) by smtp1.riverbed.com with ESMTP; 09 Jan 2013 07:00:12 -0800 Received: from 365EXCH-MBX-P5.nbttech.com ([fe80::7b:394b:243e:83b6]) by 365EXCH-HUB-P3.nbttech.com ([::1]) with mapi id 14.02.0298.004; Wed, 9 Jan 2013 07:00:12 -0800 From: Mark Day To: "Eggert, Lars" , "Mani Ramasamy (mani)" Thread-Topic: [middisc] closure of the middisc list Thread-Index: AQHN7gZobmk5wVaynUGa+/vskCRzcZhAuhcAgAAOl4CAANHugP//et6w Date: Wed, 9 Jan 2013 15:00:11 +0000 Message-ID: References: <50ECC3EF.1020405@mti-systems.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.205.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Wesley Eddy , "middisc@ietf.org" Subject: Re: [middisc] closure of the middisc list 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, 09 Jan 2013 15:00:14 -0000 In principle this is still an important area to get right. Unfortunately t= here are currently dueling patent lawsuits between my company and a competi= tor, where one of the patents in the dispute is potentially relevant to thi= s technical issue. =20 Until that dispute ends (currently scheduled for trial this September) I am= unlikely to be able to contribute in any forum unrelated to the suits. --Mark=20 -----Original Message----- From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On Behalf = Of Eggert, Lars Sent: Wednesday, January 09, 2013 9:48 AM To: Mani Ramasamy (mani) Cc: Wesley Eddy; middisc@ietf.org Subject: Re: [middisc] closure of the middisc list Hi, On Jan 9, 2013, at 3:16, Mani Ramasamy (mani) wrote: > As Anantha says, I would like to continue on this effort. > I will target the completion of the revised draft by end of next week. I was AD when this effort was started, and it's been a while. I fully agree= with Wes that we need to finish this, or declare failure and disband the l= ist. If there is anything I can do to help progress this, I'd be happy to. Lars _______________________________________________ middisc mailing list middisc@ietf.org https://www.ietf.org/mailman/listinfo/middisc From Martin.Stiemerling@neclab.eu Wed Jan 9 07:11:01 2013 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 EE4AF21F86F8 for ; Wed, 9 Jan 2013 07:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.432 X-Spam-Level: X-Spam-Status: No, score=-103.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ryt3XKGvdzl for ; Wed, 9 Jan 2013 07:11:01 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3640621F8698 for ; Wed, 9 Jan 2013 07:11:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id A0316102CA9; Wed, 9 Jan 2013 16:11:00 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oeOoER4GIxtY; Wed, 9 Jan 2013 16:11:00 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 8576F102C9E; Wed, 9 Jan 2013 16:10:35 +0100 (CET) Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 9 Jan 2013 16:09:59 +0100 Message-ID: <50ED886B.1020500@neclab.eu> Date: Wed, 9 Jan 2013 16:10:35 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Mark Day References: <50ECC3EF.1020405@mti-systems.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.1.190] Cc: Wesley Eddy , "middisc@ietf.org" Subject: Re: [middisc] closure of the middisc list 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, 09 Jan 2013 15:11:02 -0000 So this would mean that an IPR disclosure about the draft is due, isn't it? On 01/09/2013 04:00 PM, Mark Day wrote: > In principle this is still an important area to get right. > Unfortunately there are currently dueling patent lawsuits between my > company and a competitor, where one of the patents in the dispute is > potentially relevant to this technical issue. > > Until that dispute ends (currently scheduled for trial this > September) I am unlikely to be able to contribute in any forum > unrelated to the suits. > > --Mark > > -----Original Message----- From: middisc-bounces@ietf.org > [mailto:middisc-bounces@ietf.org] On Behalf Of Eggert, Lars Sent: > Wednesday, January 09, 2013 9:48 AM To: Mani Ramasamy (mani) Cc: > Wesley Eddy; middisc@ietf.org Subject: Re: [middisc] closure of the > middisc list > > Hi, > > On Jan 9, 2013, at 3:16, Mani Ramasamy (mani) > wrote: >> As Anantha says, I would like to continue on this effort. I will >> target the completion of the revised draft by end of next week. > > I was AD when this effort was started, and it's been a while. I fully > agree with Wes that we need to finish this, or declare failure and > disband the list. > > If there is anything I can do to help progress this, I'd be happy > to. > > Lars _______________________________________________ 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 > -- martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 From Mark.Day@riverbed.com Wed Jan 9 07:12:59 2013 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 B320821F8598 for ; Wed, 9 Jan 2013 07:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMPe5Tuz-tx3 for ; Wed, 9 Jan 2013 07:12:59 -0800 (PST) Received: from smtp1.riverbed.com (smtp1.riverbed.com [208.70.196.45]) by ietfa.amsl.com (Postfix) with ESMTP id F388921F8569 for ; Wed, 9 Jan 2013 07:12:58 -0800 (PST) Received: from unknown (HELO 365EXCH-HUB-P2.nbttech.com) ([10.16.4.1]) by smtp1.riverbed.com with ESMTP; 09 Jan 2013 07:12:52 -0800 Received: from 365EXCH-MBX-P5.nbttech.com ([fe80::7b:394b:243e:83b6]) by 365EXCH-HUB-P2.nbttech.com ([fe80::4998:6c24:821c:b3e1%16]) with mapi id 14.02.0298.004; Wed, 9 Jan 2013 07:12:52 -0800 From: Mark Day To: Martin Stiemerling Thread-Topic: [middisc] closure of the middisc list Thread-Index: AQHN7gZobmk5wVaynUGa+/vskCRzcZhAuhcAgAAOl4CAANHugP//et6wgACLiID//3o8kA== Date: Wed, 9 Jan 2013 15:12:50 +0000 Message-ID: References: <50ECC3EF.1020405@mti-systems.com> <50ED886B.1020500@neclab.eu> In-Reply-To: <50ED886B.1020500@neclab.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.205.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Wesley Eddy , "middisc@ietf.org" Subject: Re: [middisc] closure of the middisc list 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, 09 Jan 2013 15:12:59 -0000 No, I didn't participate in the development of the current draft because of= this problem. Just wanted to be clear that my non-participation is not ca= used by lack of interest. -----Original Message----- From: Martin Stiemerling [mailto:martin.stiemerling@neclab.eu]=20 Sent: Wednesday, January 09, 2013 10:11 AM To: Mark Day Cc: Eggert, Lars; Mani Ramasamy (mani); Wesley Eddy; middisc@ietf.org Subject: Re: [middisc] closure of the middisc list So this would mean that an IPR disclosure about the draft is due, isn't it? On 01/09/2013 04:00 PM, Mark Day wrote: > In principle this is still an important area to get right. > Unfortunately there are currently dueling patent lawsuits between my=20 > company and a competitor, where one of the patents in the dispute is=20 > potentially relevant to this technical issue. > > Until that dispute ends (currently scheduled for trial this > September) I am unlikely to be able to contribute in any forum=20 > unrelated to the suits. > > --Mark > > -----Original Message----- From: middisc-bounces@ietf.org=20 > [mailto:middisc-bounces@ietf.org] On Behalf Of Eggert, Lars Sent: > Wednesday, January 09, 2013 9:48 AM To: Mani Ramasamy (mani) Cc: > Wesley Eddy; middisc@ietf.org Subject: Re: [middisc] closure of the=20 > middisc list > > Hi, > > On Jan 9, 2013, at 3:16, Mani Ramasamy (mani) > wrote: >> As Anantha says, I would like to continue on this effort. I will=20 >> target the completion of the revised draft by end of next week. > > I was AD when this effort was started, and it's been a while. I fully=20 > agree with Wes that we need to finish this, or declare failure and=20 > disband the list. > > If there is anything I can do to help progress this, I'd be happy to. > > Lars _______________________________________________ middisc mailing=20 > list middisc@ietf.org https://www.ietf.org/mailman/listinfo/middisc > _______________________________________________ middisc mailing list=20 > middisc@ietf.org https://www.ietf.org/mailman/listinfo/middisc > -- martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Regi= stered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in Engl= and 283 From jamshid.mahdavi@bluecoat.com Wed Jan 9 07:18:47 2013 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 EEF7621F854E for ; Wed, 9 Jan 2013 07:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzlY7Dsociwg for ; Wed, 9 Jan 2013 07:18:47 -0800 (PST) Received: from plsvl-mailgw-01.bluecoat.com (plsvl-mailgw-01.bluecoat.com [199.91.133.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDE921F84CA for ; Wed, 9 Jan 2013 07:18:47 -0800 (PST) Received: from pwsvl-exchts-03.internal.cacheflow.com (esxprd02.bluecoat.com [10.2.2.160]) by plsvl-mailgw-01.bluecoat.com (Postfix) with ESMTP id 15DDF81A0D1; Wed, 9 Jan 2013 07:24:14 -0900 (AKST) Received: from PWSVL-EXCMBX-04.internal.cacheflow.com ([fe80::c596:c77:dd67:b72d]) by pwsvl-exchts-03.internal.cacheflow.com ([fe80::a508:17dc:1550:e9f6%12]) with mapi id 14.01.0355.002; Wed, 9 Jan 2013 07:18:46 -0800 From: "Mahdavi, Jamshid" To: "Eggert, Lars" , "Mani Ramasamy (mani)" Thread-Topic: [middisc] closure of the middisc list Thread-Index: AQHN7gZoGzxDeTsZFk2tJjGzJZE5bJhAuhcAgAAOl4CAANHugP//gkbi Date: Wed, 9 Jan 2013 15:18:45 +0000 Message-ID: References: <50ECC3EF.1020405@mti-systems.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: Wesley Eddy , "middisc@ietf.org" Subject: Re: [middisc] closure of the middisc list 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, 09 Jan 2013 15:18:48 -0000 I have been moved on to other projects at Blue Coat, but if all we are look= ing at is review and approval of the latest draft, I should be able to do t= hat (or have someone else here do it) as soon as Mani publishes it.=0A= =0A= It would be very nice to see this done!=0A= =0A= --J=0A= =0A= ________________________________________=0A= From: middisc-bounces@ietf.org [middisc-bounces@ietf.org] on behalf of Egge= rt, Lars [lars@netapp.com]=0A= Sent: Wednesday, January 09, 2013 6:47 AM=0A= To: Mani Ramasamy (mani)=0A= Cc: Wesley Eddy; middisc@ietf.org=0A= Subject: Re: [middisc] closure of the middisc list=0A= =0A= Hi,=0A= =0A= On Jan 9, 2013, at 3:16, Mani Ramasamy (mani) wrote:=0A= > As Anantha says, I would like to continue on this effort.= =0A= > I will target the completion of the revised draft by end of next week.=0A= =0A= I was AD when this effort was started, and it's been a while. I fully agree= with Wes that we need to finish this, or declare failure and disband the l= ist.=0A= =0A= If there is anything I can do to help progress this, I'd be happy to.=0A= =0A= Lars=0A= _______________________________________________=0A= middisc mailing list=0A= middisc@ietf.org=0A= https://www.ietf.org/mailman/listinfo/middisc=0A= From mani@cisco.com Mon Jan 21 09:00:13 2013 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 3FC5921F8780 for ; Mon, 21 Jan 2013 09:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qd2vJA25xwJt for ; Mon, 21 Jan 2013 09:00:11 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 11A1721F84BA for ; Mon, 21 Jan 2013 09:00:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7965; q=dns/txt; s=iport; t=1358787611; x=1359997211; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xG9f5724lb1wXg0y4djeNhcgoTc0n4A75oY6RR7ZjA8=; b=dSbcf617e34R1wdgf9IUbD8R5WL2bIWtXhJ2pb0t+qY1HSlgMsAYTtxs TujNvpuiS8L1u7jCxm7G5K4c0ZqUYlk4UpU7wQSM5szf93/hryAWSLVBe 3+USRKz2nWPWG47BgKSKa2hdeOkHfYGiXl41votGx0uRRiAQBKzHsAHaB E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIGAE5z/VCtJV2c/2dsb2JhbABEg3WoD4kMAYZRgkgWc4IfAQEEeRACAQg/BzIUEQIEDgUJiBAHBbsVkFhhA5YMgRyPLYJ1 X-IronPort-AV: E=Sophos;i="4.84,507,1355097600"; d="scan'208,217";a="165725092" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 21 Jan 2013 17:00:10 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r0LH0ATT026050 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Jan 2013 17:00:10 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.75]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Mon, 21 Jan 2013 11:00:10 -0600 From: "Mani Ramasamy (mani)" To: "Eggert, Lars" Thread-Topic: [middisc] closure of the middisc list Thread-Index: AQHN7gZoJ3eDBtsU7E6OW7KrYI/u+phAmJAA//+o1tCAATevgIASnGjd Date: Mon, 21 Jan 2013 17:00:09 +0000 Message-ID: References: <50ECC3EF.1020405@mti-systems.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_D22144CF6E2B40F09DF18EF551B93D17ciscocom_" MIME-Version: 1.0 Cc: Wesley Eddy , "middisc@ietf.org" Subject: Re: [middisc] closure of the middisc list 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, 21 Jan 2013 17:00:13 -0000 --_000_D22144CF6E2B40F09DF18EF551B93D17ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, Just posted the updated version of the draft. Please review. Thanks. Mani. A new version of I-D, draft-ananth-middisc-tcpopt-01.txt has been successfully submitted by Arivu Ramasamy and posted to the IETF repository. Filename: draft-ananth-middisc-tcpopt Revision: 01 Title: TCP option for transparent Middlebox negotiation Creation date: 2013-01-21 WG ID: Individual Submission Number of pages: 16 URL: http://www.ietf.org/internet-drafts/draft-ananth-middisc-t= cpopt-01.txt Status: http://datatracker.ietf.org/doc/draft-ananth-middisc-tcpop= t Htmlized: http://tools.ietf.org/html/draft-ananth-middisc-tcpopt-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ananth-middisc-tc= popt-01 Abstract: 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. The IETF Secretariat Sent from my iPad On Jan 9, 2013, at 6:47 AM, "Eggert, Lars" > wrote: Hi, On Jan 9, 2013, at 3:16, Mani Ramasamy (mani) > wrote: As Anantha says, I would like to continue on this effort. I will target the completion of the revised draft by end of next week. I was AD when this effort was started, and it's been a while. I fully agree= with Wes that we need to finish this, or declare failure and disband the l= ist. If there is anything I can do to help progress this, I'd be happy to. Lars --_000_D22144CF6E2B40F09DF18EF551B93D17ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All, 
    Just posted the updated version of the dr= aft. Please review.

Thanks.
Mani.


A new version of I-D, draft-ananth-middisc-tcpopt-01.tx= t
has been successfully submitted by Arivu Ramasamy and posted to the
IETF repository.

Filename:     draft-ananth-middisc-tcpopt
Revision:     01
Title:         TCP option for transparent Middlebox neg= otiation
Creation date:     2013-01-21
WG ID:         Individual Submission
Number of pages: 16
URL:            &nbs= p;http://www.ietf.org/internet-drafts= /draft-ananth-middisc-tcpopt-01.txt
Status:          http://datatracker.ietf.org/doc/draft-ananth-middisc-tcpopt
Htmlized:        http://tools.ietf.org/html/draft-ananth-middisc-tcpopt-01
Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-anan= th-middisc-tcpopt-01

Abstract:
  This document describes a TCP option for use by middleboxes to<= br>   facilitate transparent detection of other middleboxes along the= path
  of the TCP connection during the connection initiation phase. &= nbsp;The
  option has no effect if an appropriate middlebox is not present= on
  the path.




The IETF Secretariat

Sent from my iPad
On Jan 9, 2013, at 6:47 AM= , "Eggert, Lars" <lars@neta= pp.com> wrote:

= Hi,
=
= On Jan 9, 2013, at 3:16, Mani Ramasamy (mani) <mani@cisco.com> wrote:
       &= nbsp;     As Anantha says,  I would like to c= ontinue on this effort.
I will target the completion of the revised= draft by end of next week.
=
= I was AD when this effort was started, and it's been a while. I fully agree= with Wes that we need to finish this, or declare failure and disband the l= ist.
=
= If there is anything I can do to help progress this, I'd be happy to.
=
= Lars
--_000_D22144CF6E2B40F09DF18EF551B93D17ciscocom_-- From ananth@nttmcl.com Mon Jan 21 09:05:30 2013 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 EB9AA21F84EA for ; Mon, 21 Jan 2013 09:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1o6DRNSBiik for ; Mon, 21 Jan 2013 09:05:30 -0800 (PST) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id EBEE721F8799 for ; Mon, 21 Jan 2013 09:05:26 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id u7so1531196wey.26 for ; Mon, 21 Jan 2013 09:05:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=jx8KMYOnoTINxmUdtdmUEpiY8KLQeQCryZJCXpsHdXs=; b=L8+yNDzQBt4kUlysVIHoZil3hN52/revSOyuBz/GVAD3yM6rBd7cOlnZuYvz5ZfzO7 Xu3hTLqWzoeCEnonP+X47pDZ60x6MBSD8S3HiwCyT6igYgznRB3+G5TOnGS4j5MzzDrh 7OiICG/t/qE+irp+Rmpqtn1Gk4tQWwtVM0P0AiyhGGPyPcLbfp91kcwg2bSs+pjS+cdP xF8HaHu9shD6hDI/6oSGqOHJKIZr90bbTB0zbilLIMg3hxYkhM3OHWPULvJGo7cxXLUy 0ap8W2ARCJjNwE2bI4Afr+Er+Fx7RrMPthcB0Cgm3LAlA/bHfQIBSSlftZiHo/hcI/Kc gGcA== MIME-Version: 1.0 X-Received: by 10.194.76.237 with SMTP id n13mr27667688wjw.57.1358787926038; Mon, 21 Jan 2013 09:05:26 -0800 (PST) Received: by 10.180.162.165 with HTTP; Mon, 21 Jan 2013 09:05:25 -0800 (PST) In-Reply-To: References: <50ECC3EF.1020405@mti-systems.com> Date: Mon, 21 Jan 2013 09:05:25 -0800 Message-ID: From: Anantha Ramaiah To: "Mani Ramasamy (mani)" Content-Type: multipart/alternative; boundary=047d7bfcef74a8196c04d3cf77c3 X-Gm-Message-State: ALoCoQkvomdxE4IHRi9vdCLSZFRWENAkMoFZdMmruQCQUUBb30X6hKvvxtfuM50YSloREoJXra5o Cc: Wesley Eddy , "middisc@ietf.org" Subject: Re: [middisc] closure of the middisc list 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, 21 Jan 2013 17:05:31 -0000 --047d7bfcef74a8196c04d3cf77c3 Content-Type: text/plain; charset=ISO-8859-1 I did work with Mani and reviewed this already. IMO this addresses all the review comments received so far and it is all set to go to the next stages. Thanks for taking the lead, Mani. thanks, -Anantha On Mon, Jan 21, 2013 at 9:00 AM, Mani Ramasamy (mani) wrote: > > All, > Just posted the updated version of the draft. Please review. > > Thanks. > Mani. > > > A new version of I-D, draft-ananth-middisc-tcpopt-01.txt > has been successfully submitted by Arivu Ramasamy and posted to the > IETF repository. > > Filename: draft-ananth-middisc-tcpopt > Revision: 01 > Title: TCP option for transparent Middlebox negotiation > Creation date: 2013-01-21 > WG ID: Individual Submission > Number of pages: 16 > URL: > http://www.ietf.org/internet-drafts/draft-ananth-middisc-tcpopt-01.txt > Status: > http://datatracker.ietf.org/doc/draft-ananth-middisc-tcpopt > Htmlized: http://tools.ietf.org/html/draft-ananth-middisc-tcpopt-01 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-ananth-middisc-tcpopt-01 > > Abstract: > 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. > > > > > The IETF Secretariat > > Sent from my iPad > > > On Jan 9, 2013, at 6:47 AM, "Eggert, Lars" wrote: > > Hi, > > > On Jan 9, 2013, at 3:16, Mani Ramasamy (mani) wrote: > > As Anantha says, I would like to continue on this effort. > > I will target the completion of the revised draft by end of next week. > > > I was AD when this effort was started, and it's been a while. I fully > agree with Wes that we need to finish this, or declare failure and disband > the list. > > > If there is anything I can do to help progress this, I'd be happy to. > > > Lars > > --047d7bfcef74a8196c04d3cf77c3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable =A0I did work with Mani and reviewed this already. =A0IMO this addresses al= l the review comments received so far and it is all set to go to the next s= tages. =A0Thanks for taking the lead, Mani.

thanks,
-Anantha

On Mon, Jan 21, 2013 at 9:0= 0 AM, Mani Ramasamy (mani) <mani@cisco.com> wrote:

All,=A0
=A0 =A0 Just post= ed the updated version of the draft. Please review.

Thanks.
Mani.


A new version of = I-D, draft-ananth-middisc-tcpopt-01.txt
has been successfully submitted by Arivu Ramasamy and posted to the
IETF repository.

Filename: =A0 =A0 draft-ananth-middisc-tcpopt
Revision: =A0 =A0 01
Title: =A0 =A0 =A0 =A0 TCP option for transparent Middlebox negotiation
Creation date: =A0 =A0 2013-01-21
WG ID: =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 16
URL: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0http://w= ww.ietf.org/internet-drafts/draft-ananth-middisc-tcpopt-01.txt
Status: =A0=A0=A0=A0=A0=A0=A0=A0=A0http://datatracker.ietf.o= rg/doc/draft-ananth-middisc-tcpopt
Htmlized: =A0=A0=A0=A0=A0=A0=A0http://tools.ietf.org/html/draf= t-ananth-middisc-tcpopt-01
Diff: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0http://www.ietf= .org/rfcdiff?url2=3Ddraft-ananth-middisc-tcpopt-01

Abstract:
=A0=A0This document describes a TCP option for use by middleboxes to
=A0=A0facilitate transparent detection of other middleboxes along the path<= br> =A0=A0of the TCP connection during the connection initiation phase. =A0The<= br> =A0=A0option has no effect if an appropriate middlebox is not present on =A0=A0the path.




The IETF Secretariat

Sent from my iPad

--047d7bfcef74a8196c04d3cf77c3-- From andrew.knutsen@bluecoat.com Tue Jan 22 14:39:33 2013 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 0782821F87A5 for ; Tue, 22 Jan 2013 14:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+gFPMsIHmxD for ; Tue, 22 Jan 2013 14:39:31 -0800 (PST) Received: from synonym.bluecoat.com (synonym.bluecoat.com [199.91.133.5]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0C521F875C for ; Tue, 22 Jan 2013 14:39:30 -0800 (PST) Received: from [10.9.43.135] (unknown [10.9.43.135]) by synonym.bluecoat.com (Postfix) with ESMTP id CECAD7FE1E2 for ; Tue, 22 Jan 2013 14:39:29 -0800 (PST) Message-ID: <50FF1520.4080901@bluecoat.com> Date: Tue, 22 Jan 2013 14:39:28 -0800 From: Andrew Knutsen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: middisc@ietf.org References: <50ECC3EF.1020405@mti-systems.com> , In-Reply-To: Content-Type: multipart/alternative; boundary="------------070203080903030902070607" Subject: Re: [middisc] closure of the middisc list 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, 22 Jan 2013 22:39:33 -0000 This is a multi-part message in MIME format. --------------070203080903030902070607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Looks good to me, except I would suggest adding a note at the end of section 5 saying that if for some reason more space is needed, a "extension" vendor code can be allocated (leaving exactly how it would work TBD). Also, I think its worth allowing vendor codes to be allocated for inter-vendor formats. This would allow such to be developed in fewer years than this draft has taken. Thanks Mani! Andrew On 1/21/2013 9:00 AM, Mani Ramasamy (mani) wrote: > > All, > Just posted the updated version of the draft. Please review. > > Thanks. > Mani. > > > A new version of I-D, draft-ananth-middisc-tcpopt-01.txt > has been successfully submitted by Arivu Ramasamy and posted to the > IETF repository. > > Filename: draft-ananth-middisc-tcpopt > Revision: 01 > Title: TCP option for transparent Middlebox negotiation > Creation date: 2013-01-21 > WG ID: Individual Submission > Number of pages: 16 > URL: > http://www.ietf.org/internet-drafts/draft-ananth-middisc-tcpopt-01.txt > Status: http://datatracker.ietf.org/doc/draft-ananth-middisc-tcpopt > Htmlized: http://tools.ietf.org/html/draft-ananth-middisc-tcpopt-01 > Diff: http://www.ietf.org/rfcdiff?url2=draft-ananth-middisc-tcpopt-01 > > Abstract: > 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. > > > > > The IETF Secretariat > > Sent from my iPad > > On Jan 9, 2013, at 6:47 AM, "Eggert, Lars" > wrote: > >> Hi, >> >> On Jan 9, 2013, at 3:16, Mani Ramasamy (mani) > > wrote: >>> As Anantha says, I would like to continue on this effort. >>> I will target the completion of the revised draft by end of next week. >> >> I was AD when this effort was started, and it's been a while. I fully >> agree with Wes that we need to finish this, or declare failure and >> disband the list. >> >> If there is anything I can do to help progress this, I'd be happy to. >> >> Lars > > > _______________________________________________ > middisc mailing list > middisc@ietf.org > https://www.ietf.org/mailman/listinfo/middisc --------------070203080903030902070607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

   Looks good to me, except I would suggest adding a note at the end of section 5 saying that if for some reason more space is needed, a "extension" vendor code can be allocated (leaving exactly how it would work TBD).

  Also, I think its worth allowing vendor codes to be allocated for inter-vendor formats. This would allow such to be developed in fewer years than this draft has taken.

   Thanks Mani!

Andrew

On 1/21/2013 9:00 AM, Mani Ramasamy (mani) wrote:

All, 
    Just posted the updated version of the draft. Please review.

Thanks.
Mani.


A new version of I-D, draft-ananth-middisc-tcpopt-01.txt
has been successfully submitted by Arivu Ramasamy and posted to the
IETF repository.

Filename:     draft-ananth-middisc-tcpopt
Revision:     01
Title:         TCP option for transparent Middlebox negotiation
Creation date:     2013-01-21
WG ID:         Individual Submission
Number of pages: 16
URL:             http://www.ietf.org/internet-drafts/draft-ananth-middisc-tcpopt-01.txt
Status:          http://datatracker.ietf.org/doc/draft-ananth-middisc-tcpopt
Htmlized:        http://tools.ietf.org/html/draft-ananth-middisc-tcpopt-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-ananth-middisc-tcpopt-01

Abstract:
  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.




The IETF Secretariat

Sent from my iPad

On Jan 9, 2013, at 6:47 AM, "Eggert, Lars" <lars@netapp.com> wrote:

Hi,

On Jan 9, 2013, at 3:16, Mani Ramasamy (mani) <mani@cisco.com> wrote:
             As Anantha says,  I would like to continue on this effort.
I will target the completion of the revised draft by end of next week.

I was AD when this effort was started, and it's been a while. I fully agree with Wes that we need to finish this, or declare failure and disband the list.

If there is anything I can do to help progress this, I'd be happy to.

Lars


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

--------------070203080903030902070607-- From mani@cisco.com Tue Jan 22 22:08:10 2013 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 D0A5B21F84D7 for ; Tue, 22 Jan 2013 22:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3Jp72fj4LQr for ; Tue, 22 Jan 2013 22:08:08 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7536421F84C9 for ; Tue, 22 Jan 2013 22:08:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15289; q=dns/txt; s=iport; t=1358921288; x=1360130888; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=q2iC5Mg5tgGT6DsSVuObdpj8RpIpBu6l9l3rh3GQbIY=; b=Ei27xLt4wtAoJDncdAVjbi42l0bGS4zcjNECK2OVZ68dFh9SdDx7jmU1 BXJoZnny2g6kxsaoRaMvPXch6uh8yZ8ompuGsL0QOjyCeWluSzGuQ/qso fZa4FxruMhfIh277r5ZcS1eJyyxw1AB8g2Ke4b2ntCCbOZYBaE9hvB/TI w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQFANp8/1CtJV2a/2dsb2JhbABEgkiBLYUvolaJDIZSglIWc4IeAQEBBAEBASpBGwIBCBEEAQELHQcnCxQJCAIEARIIAYgQBwW9AJBVYQOXKI8tgnWCJA X-IronPort-AV: E=Sophos;i="4.84,520,1355097600"; d="scan'208,217";a="166363167" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 23 Jan 2013 06:08:07 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0N687TK014473 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jan 2013 06:08:07 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.75]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Wed, 23 Jan 2013 00:08:06 -0600 From: "Mani Ramasamy (mani)" To: Andrew Knutsen , "middisc@ietf.org" Thread-Topic: [middisc] closure of the middisc list Thread-Index: AQHN7gZoJ3eDBtsU7E6OW7KrYI/u+phAmJAA//+o1tCAATevgIASnGjdgAJVtwCAABbOMA== Date: Wed, 23 Jan 2013 06:08:06 +0000 Message-ID: References: <50ECC3EF.1020405@mti-systems.com> , <50FF1520.4080901@bluecoat.com> In-Reply-To: <50FF1520.4080901@bluecoat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.127.56] Content-Type: multipart/alternative; boundary="_000_CD6E74FCC0FE024BB73C6B483F6706FE0FC3EED7xmbrcdx07ciscoc_" MIME-Version: 1.0 Subject: Re: [middisc] closure of the middisc list 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, 23 Jan 2013 06:08:10 -0000 --_000_CD6E74FCC0FE024BB73C6B483F6706FE0FC3EED7xmbrcdx07ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks, Andrew. Please see inline. Hi Wes, Can you pl. update on what the next steps are to move this = draft forward? Thanks. From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On Behalf = Of Andrew Knutsen Sent: Tuesday, January 22, 2013 2:39 PM To: middisc@ietf.org Subject: Re: [middisc] closure of the middisc list Looks good to me, except I would suggest adding a note at the end of sec= tion 5 saying that if for some reason more space is needed, a "extension" v= endor code can be allocated (leaving exactly how it would work TBD). MANI - Sure, will add. Also, I think its worth allowing vendor codes to be allocated for inter-v= endor formats. This would allow such to be developed in fewer years than th= is draft has taken. MANI - Just to make sure I understand - are you suggesting to allow codes t= o be defined so a subset of vendors can interoperate? For example, id 5 to = allow vendor A and B to interoperate, id 6 for vendor B and vendor to inter= operate? Or one standard code for all interoperating vendors? Mani. Thanks Mani! Andrew On 1/21/2013 9:00 AM, Mani Ramasamy (mani) wrote: All, Just posted the updated version of the draft. Please review. Thanks. Mani. A new version of I-D, draft-ananth-middisc-tcpopt-01.txt has been successfully submitted by Arivu Ramasamy and posted to the IETF repository. Filename: draft-ananth-middisc-tcpopt Revision: 01 Title: TCP option for transparent Middlebox negotiation Creation date: 2013-01-21 WG ID: Individual Submission Number of pages: 16 URL: http://www.ietf.org/internet-drafts/draft-ananth-middisc-t= cpopt-01.txt Status: http://datatracker.ietf.org/doc/draft-ananth-middisc-tcpop= t Htmlized: http://tools.ietf.org/html/draft-ananth-middisc-tcpopt-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ananth-middisc-tc= popt-01 Abstract: 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. The IETF Secretariat Sent from my iPad On Jan 9, 2013, at 6:47 AM, "Eggert, Lars" > wrote: Hi, On Jan 9, 2013, at 3:16, Mani Ramasamy (mani) > wrote: As Anantha says, I would like to continue on this effort. I will target the completion of the revised draft by end of next week. I was AD when this effort was started, and it's been a while. I fully agree= with Wes that we need to finish this, or declare failure and disband the l= ist. If there is anything I can do to help progress this, I'd be happy to. Lars _______________________________________________ middisc mailing list middisc@ietf.org https://www.ietf.org/mailman/listinfo/middisc --_000_CD6E74FCC0FE024BB73C6B483F6706FE0FC3EED7xmbrcdx07ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks, Andrew. Please se= e inline.

 <= /p>

Hi Wes,=

    &= nbsp;           Can you p= l. update on what the next steps are to move this draft forward?=

 <= /p>

Thanks.=

 <= /p>

 <= /p>

From: middisc-bounces@ietf.org [mailto:middisc-bounces@= ietf.org] On Behalf Of Andrew Knutsen
Sent: Tuesday, January 22, 2013 2:39 PM
To: middisc@ietf.org
Subject: Re: [middisc] closure of the middisc list=

 


   Looks good to me, except I would suggest adding a note at the = end of section 5 saying that if for some reason more space is needed, a &qu= ot;extension" vendor code can be allocated (leaving exactly how it wou= ld work TBD).

MANI – Sure, will a= dd.

 <= /p>


  Also, I think its worth allowing vendor codes to be allocated for in= ter-vendor formats. This would allow such to be developed in fewer years th= an this draft has taken.

MANI – Just to make= sure I understand – are you suggesting to allow codes to be defined = so a subset of vendors can interoperate? For example, id 5 to allow vendor A and B to interoperate, id 6 for vendor B and vendor to interopera= te? Or one standard code for all interoperating vendors?<= /p>

 <= /p>

Mani.

 <= /p>


   Thanks Mani!

Andrew

On 1/21/2013 9:00 AM, Mani Ramasamy (mani) wrote:



All, 

    Just posted the updated version of the= draft. Please review.



Thanks.

Mani.





A new version of I-D, draft-ananth-middisc-tcpopt-01= .txt
has been successfully submitted by Arivu Ramasamy and posted to the
IETF repository.

Filename:     draft-ananth-middisc-tcpopt
Revision:     01
Title:         TCP option for transparent Middlebox neg= otiation
Creation date:     2013-01-21
WG ID:         Individual Submission
Number of pages: 16
URL:            &nbs= p;http://www.ietf.org/internet-drafts/draft-ananth-middisc-tcpopt-0= 1.txt
Status:          http://datatrack= er.ietf.org/doc/draft-ananth-middisc-tcpopt
Htmlized:        http://tools.ietf.org/html/d= raft-ananth-middisc-tcpopt-01
Diff:            = http://www.ietf.org/rfcdiff?url2=3Ddraft-ananth-middisc-tcpopt-01

Abstract:
  This document describes a TCP option for use by middleboxes to<= br>   facilitate transparent detection of other middleboxes along the= path
  of the TCP connection during the connection initiation phase. &= nbsp;The
  option has no effect if an appropriate middlebox is not present= on
  the path.




The IETF Secretariat

Sent from my iPad

On Jan 9, 2013, at 6:47 AM, "Eggert, Lars" <lars@netapp.com> wrote:


Hi,

 

On Jan 9, 2013, at 3:16, Mani Ramasamy (mani) <mani@cisco.com> wrote:

        &nbs= p;    As Anantha says,  I would like to continue o= n this effort.

I will target the completion of the revised draft by= end of next week.

 

I was AD when this effort was started, and it's been= a while. I fully agree with Wes that we need to finish this, or declare fa= ilure and disband the list.

 

If there is anything I can do to help progress this,= I'd be happy to.

 

Lars




_______________________________________________
middisc mailing list
middisc@ietf.org

https://www.=
ietf.org/mailman/listinfo/middisc

 

--_000_CD6E74FCC0FE024BB73C6B483F6706FE0FC3EED7xmbrcdx07ciscoc_-- From andrew.knutsen@bluecoat.com Tue Jan 22 22:28:30 2013 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 78FF821F8799 for ; Tue, 22 Jan 2013 22:28:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=-1.999, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4QQzar2brfj for ; Tue, 22 Jan 2013 22:28:29 -0800 (PST) Received: from plsvl-mailgw-02.bluecoat.com (plsvl-mailgw-02.bluecoat.com [199.91.133.12]) by ietfa.amsl.com (Postfix) with ESMTP id DF31F21F86E8 for ; Tue, 22 Jan 2013 22:28:29 -0800 (PST) Received: from pwsvl-exchts-03.internal.cacheflow.com (esxprd02.bluecoat.com [10.2.2.160]) by plsvl-mailgw-02.bluecoat.com (Postfix) with ESMTP id EE106200F1; Tue, 22 Jan 2013 22:28:28 -0800 (PST) Received: from PWSVL-EXCMBX-04.internal.cacheflow.com ([fe80::c596:c77:dd67:b72d]) by pwsvl-exchts-03.internal.cacheflow.com ([fe80::a508:17dc:1550:e9f6%12]) with mapi id 14.01.0355.002; Tue, 22 Jan 2013 22:28:28 -0800 From: "Knutsen, Andrew" To: "Mani Ramasamy (mani)" , "middisc@ietf.org" Thread-Topic: [middisc] closure of the middisc list Thread-Index: AQHN7gZoJkNJRcyZVkqKlI8ATneWQ5hAuhcAgAAOl4CAANHugIATAP2AgAFrBgCAAQN1AP//fJkm Date: Wed, 23 Jan 2013 06:28:28 +0000 Message-ID: <974FE049BD0F2E4188567FAD99DEF0331E7F6846@pwsvl-excmbx-04.internal.cacheflow.com> References: <50ECC3EF.1020405@mti-systems.com> , <50FF1520.4080901@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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [middisc] closure of the middisc list 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, 23 Jan 2013 06:28:30 -0000 I now see this in the draft; did I miss it before? 1) Standard code: Standard code can be used in a such way that multiple vendors recognize the same and are interoperable for negotiation purposes 2) Extended vendor id: Should the unassigned space run out in the future, either the reserved space can be opened up for assignment, or a speical id can be added to extend the vendor id space to more than one byte (say by including OUI after the 1 byte vendor id) Looks good to me, except the special misspelling. I'm not sure we need = the OUI reference though --they're bigger then enterprise numbers. For ins= tance, if some reserved codes were each used to make 256 more (with one mor= e byte), I think we'd be fine for a long time. I'd just as soon we leave t= he question open (and leave out the parenthesized phrase). Andrew ________________________________ From: Mani Ramasamy (mani) [mani@cisco.com] Sent: Tuesday, January 22, 2013 10:08 PM To: Knutsen, Andrew; middisc@ietf.org Subject: RE: [middisc] closure of the middisc list Thanks, Andrew. Please see inline. Hi Wes, Can you pl. update on what the next steps are to move this = draft forward? Thanks. From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On Behalf = Of Andrew Knutsen Sent: Tuesday, January 22, 2013 2:39 PM To: middisc@ietf.org Subject: Re: [middisc] closure of the middisc list Looks good to me, except I would suggest adding a note at the end of sec= tion 5 saying that if for some reason more space is needed, a "extension" v= endor code can be allocated (leaving exactly how it would work TBD). MANI =96 Sure, will add. Also, I think its worth allowing vendor codes to be allocated for inter-v= endor formats. This would allow such to be developed in fewer years than th= is draft has taken. MANI =96 Just to make sure I understand =96 are you suggesting to allow cod= es to be defined so a subset of vendors can interoperate? For example, id 5= to allow vendor A and B to interoperate, id 6 for vendor B and vendor to i= nteroperate? Or one standard code for all interoperating vendors? Mani. Thanks Mani! Andrew On 1/21/2013 9:00 AM, Mani Ramasamy (mani) wrote: All, Just posted the updated version of the draft. Please review. Thanks. Mani. A new version of I-D, draft-ananth-middisc-tcpopt-01.txt has been successfully submitted by Arivu Ramasamy and posted to the IETF repository. Filename: draft-ananth-middisc-tcpopt Revision: 01 Title: TCP option for transparent Middlebox negotiation Creation date: 2013-01-21 WG ID: Individual Submission Number of pages: 16 URL: http://www.ietf.org/internet-drafts/draft-ananth-middisc-t= cpopt-01.txt Status: http://datatracker.ietf.org/doc/draft-ananth-middisc-tcpop= t Htmlized: http://tools.ietf.org/html/draft-ananth-middisc-tcpopt-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ananth-middisc-tc= popt-01 Abstract: 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. The IETF Secretariat Sent from my iPad On Jan 9, 2013, at 6:47 AM, "Eggert, Lars" > wrote: Hi, On Jan 9, 2013, at 3:16, Mani Ramasamy (mani) > wrote: As Anantha says, I would like to continue on this effort. I will target the completion of the revised draft by end of next week. I was AD when this effort was started, and it's been a while. I fully agree= with Wes that we need to finish this, or declare failure and disband the l= ist. If there is anything I can do to help progress this, I'd be happy to. Lars _______________________________________________ middisc mailing list middisc@ietf.org https://www.ietf.org/mailman/listinfo/middisc From andrew.knutsen@bluecoat.com Tue Jan 22 22:33:03 2013 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 23BC821F87AC for ; Tue, 22 Jan 2013 22:33:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaC9OVR-VNu5 for ; Tue, 22 Jan 2013 22:33:02 -0800 (PST) Received: from plsvl-mailgw-01.bluecoat.com (plsvl-mailgw-01.bluecoat.com [199.91.133.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8408621F8799 for ; Tue, 22 Jan 2013 22:33:02 -0800 (PST) Received: from pwsvl-exchts-03.internal.cacheflow.com (esxprd02.bluecoat.com [10.2.2.160]) by plsvl-mailgw-01.bluecoat.com (Postfix) with ESMTP id AB54181A0A3; Tue, 22 Jan 2013 22:39:11 -0900 (AKST) Received: from PWSVL-EXCMBX-04.internal.cacheflow.com ([fe80::c596:c77:dd67:b72d]) by pwsvl-exchts-03.internal.cacheflow.com ([fe80::a508:17dc:1550:e9f6%12]) with mapi id 14.01.0355.002; Tue, 22 Jan 2013 22:32:59 -0800 From: "Knutsen, Andrew" To: "Mani Ramasamy (mani)" , "middisc@ietf.org" Thread-Topic: [middisc] closure of the middisc list Thread-Index: AQHN7gZoJkNJRcyZVkqKlI8ATneWQ5hAuhcAgAAOl4CAANHugIATAP2AgAFrBgCAAQN1AP//fJkmgAAECqw= Date: Wed, 23 Jan 2013 06:32:59 +0000 Message-ID: <974FE049BD0F2E4188567FAD99DEF0331E7F6889@pwsvl-excmbx-04.internal.cacheflow.com> References: <50ECC3EF.1020405@mti-systems.com> , <50FF1520.4080901@bluecoat.com>, , <974FE049BD0F2E4188567FAD99DEF0331E7F6846@pwsvl-excmbx-04.internal.cacheflow.com> In-Reply-To: <974FE049BD0F2E4188567FAD99DEF0331E7F6846@pwsvl-excmbx-04.internal.cacheflow.com> 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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [middisc] closure of the middisc list 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, 23 Jan 2013 06:33:03 -0000 =0A= Oops, I was mixing up OUI's and Ethernet addresses. 3 bytes is still pr= etty big.=0A= =0A= Andrew=0A= ________________________________________=0A= From: middisc-bounces@ietf.org [middisc-bounces@ietf.org] on behalf of Knut= sen, Andrew=0A= Sent: Tuesday, January 22, 2013 10:28 PM=0A= To: Mani Ramasamy (mani); middisc@ietf.org=0A= Subject: Re: [middisc] closure of the middisc list=0A= =0A= I now see this in the draft; did I miss it before?=0A= =0A= =0A= 1) Standard code: Standard code can be used in a such way that=0A= multiple vendors recognize the same and are interoperable for=0A= negotiation purposes=0A= =0A= 2) Extended vendor id: Should the unassigned space run out in the=0A= future, either the reserved space can be opened up for assignment,=0A= or a speical id can be added to extend the vendor id space to more=0A= than one byte (say by including OUI after the 1 byte vendor id)=0A= =0A= Looks good to me, except the special misspelling. I'm not sure we need = the OUI reference though --they're bigger then enterprise numbers. For ins= tance, if some reserved codes were each used to make 256 more (with one mor= e byte), I think we'd be fine for a long time. I'd just as soon we leave t= he question open (and leave out the parenthesized phrase).=0A= =0A= Andrew=0A= =0A= ________________________________=0A= From: Mani Ramasamy (mani) [mani@cisco.com]=0A= Sent: Tuesday, January 22, 2013 10:08 PM=0A= To: Knutsen, Andrew; middisc@ietf.org=0A= Subject: RE: [middisc] closure of the middisc list=0A= =0A= Thanks, Andrew. Please see inline.=0A= =0A= Hi Wes,=0A= Can you pl. update on what the next steps are to move this = draft forward?=0A= =0A= Thanks.=0A= =0A= =0A= From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On Behalf = Of Andrew Knutsen=0A= Sent: Tuesday, January 22, 2013 2:39 PM=0A= To: middisc@ietf.org=0A= Subject: Re: [middisc] closure of the middisc list=0A= =0A= =0A= Looks good to me, except I would suggest adding a note at the end of sec= tion 5 saying that if for some reason more space is needed, a "extension" v= endor code can be allocated (leaving exactly how it would work TBD).=0A= =0A= MANI =96 Sure, will add.=0A= =0A= =0A= Also, I think its worth allowing vendor codes to be allocated for inter-v= endor formats. This would allow such to be developed in fewer years than th= is draft has taken.=0A= =0A= MANI =96 Just to make sure I understand =96 are you suggesting to allow cod= es to be defined so a subset of vendors can interoperate? For example, id 5= to allow vendor A and B to interoperate, id 6 for vendor B and vendor to i= nteroperate? Or one standard code for all interoperating vendors?=0A= =0A= Mani.=0A= =0A= =0A= Thanks Mani!=0A= =0A= Andrew=0A= =0A= On 1/21/2013 9:00 AM, Mani Ramasamy (mani) wrote:=0A= =0A= =0A= All,=0A= Just posted the updated version of the draft. Please review.=0A= =0A= =0A= Thanks.=0A= Mani.=0A= =0A= =0A= =0A= =0A= A new version of I-D, draft-ananth-middisc-tcpopt-01.txt=0A= has been successfully submitted by Arivu Ramasamy and posted to the=0A= IETF repository.=0A= =0A= Filename: draft-ananth-middisc-tcpopt=0A= Revision: 01=0A= Title: TCP option for transparent Middlebox negotiation=0A= Creation date: 2013-01-21=0A= WG ID: Individual Submission=0A= Number of pages: 16=0A= URL: http://www.ietf.org/internet-drafts/draft-ananth-middisc-t= cpopt-01.txt=0A= Status: http://datatracker.ietf.org/doc/draft-ananth-middisc-tcpop= t=0A= Htmlized: http://tools.ietf.org/html/draft-ananth-middisc-tcpopt-01= =0A= Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ananth-middisc-tc= popt-01=0A= =0A= Abstract:=0A= This document describes a TCP option for use by middleboxes to=0A= facilitate transparent detection of other middleboxes along the path=0A= of the TCP connection during the connection initiation phase. The=0A= option has no effect if an appropriate middlebox is not present on=0A= the path.=0A= =0A= =0A= =0A= =0A= The IETF Secretariat=0A= =0A= Sent from my iPad=0A= =0A= On Jan 9, 2013, at 6:47 AM, "Eggert, Lars" > wrote:=0A= =0A= =0A= Hi,=0A= =0A= On Jan 9, 2013, at 3:16, Mani Ramasamy (mani) > wrote:=0A= As Anantha says, I would like to continue on this effort.=0A= I will target the completion of the revised draft by end of next week.=0A= =0A= I was AD when this effort was started, and it's been a while. I fully agree= with Wes that we need to finish this, or declare failure and disband the l= ist.=0A= =0A= If there is anything I can do to help progress this, I'd be happy to.=0A= =0A= Lars=0A= =0A= =0A= =0A= =0A= _______________________________________________=0A= =0A= middisc mailing list=0A= =0A= middisc@ietf.org=0A= =0A= https://www.ietf.org/mailman/listinfo/middisc=0A= =0A= _______________________________________________=0A= middisc mailing list=0A= middisc@ietf.org=0A= https://www.ietf.org/mailman/listinfo/middisc=0A= From jamshid.mahdavi@bluecoat.com Wed Jan 23 07:11:57 2013 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 014EE21F86A8 for ; Wed, 23 Jan 2013 07:11:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLhu2-gNjnZX for ; Wed, 23 Jan 2013 07:11:56 -0800 (PST) Received: from plsvl-mailgw-01.bluecoat.com (plsvl-mailgw-01.bluecoat.com [199.91.133.11]) by ietfa.amsl.com (Postfix) with ESMTP id E387521F8698 for ; Wed, 23 Jan 2013 07:11:49 -0800 (PST) Received: from PWSVL-EXCHTS-02.internal.cacheflow.com (unknown [10.2.2.126]) by plsvl-mailgw-01.bluecoat.com (Postfix) with ESMTP id 43D9E81A090; Wed, 23 Jan 2013 07:18:02 -0900 (AKST) Received: from PWSVL-EXCMBX-04.internal.cacheflow.com ([fe80::c596:c77:dd67:b72d]) by PWSVL-EXCHTS-02.internal.cacheflow.com ([fe80::4910:317f:407:6ecc%14]) with mapi id 14.01.0289.001; Wed, 23 Jan 2013 07:11:48 -0800 From: "Mahdavi, Jamshid" To: "Knutsen, Andrew" , "Mani Ramasamy (mani)" , "middisc@ietf.org" Thread-Topic: [middisc] closure of the middisc list Thread-Index: AQHN7gZoGzxDeTsZFk2tJjGzJZE5bJhAuhcAgAAOl4CAANHugIATAP2AgAHxIgCAAH1ZAIAABbEAgAABQ4CAAAWX5Q== Date: Wed, 23 Jan 2013 15:11:48 +0000 Message-ID: References: <50ECC3EF.1020405@mti-systems.com> , <50FF1520.4080901@bluecoat.com>, , <974FE049BD0F2E4188567FAD99DEF0331E7F6846@pwsvl-excmbx-04.internal.cacheflow.com>, <974FE049BD0F2E4188567FAD99DEF0331E7F6889@pwsvl-excmbx-04.internal.cacheflow.com> In-Reply-To: <974FE049BD0F2E4188567FAD99DEF0331E7F6889@pwsvl-excmbx-04.internal.cacheflow.com> 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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [middisc] closure of the middisc list 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, 23 Jan 2013 15:11:57 -0000 A few small nits:=0A= =0A= * In section 3, the use of MUST for requirements appears incorrect to me. = I believe the capitalized terms are only supposed to be used for the actual= specification of the standard that implementations need to follow; I'd vie= w the underlying requirements are informational.=0A= =0A= If you agree with that, here is suggested rewording to avoid the standard t= erms. (Changes in []).=0A= =0A= 1) The TCP-MNO [needs to] be variable length to accommodate multiple ven= dor=0A= option formats.=0A= =0A= 2) The TCP-MNO [needs to] have a vendor ID which can identify the specif= ic=0A= vendor as implied by 1)=0A= =0A= 3) The TCP option space limitation puts a burden on how flexible the=0A= option can be. Please refer section 6 below.=0A= =0A= 4) TCP option numbers already in use by proprietary systems [should=0A= not] be reused for TCP-MNO since it would create confusion. (These= =0A= option numbers would get eventually retired when all vendors=0A= migrate to the newly allocated TCP-MNO option)=0A= =0A= In the last item, I'd like to slightly modify the content as we'd definitel= y envision cases where end hosts want to discover middle boxes:=0A= =0A= 5) The TCP-MNO [is intended for use by] for middleboxes only. [End host= s which are not participating in middlebox negotiation] are=0A= expected to silently ignore this option.=0A= =0A= * In section 5, there appear to be some formatting issue with the spaces in= the diagram. The bars separating the bytes should appear at [1,8] and [2,= 6].=0A= =0A= * On Andrew's point below, I think it is fine to leave in the reference to= OUI. It is just an example and it is the original idea that we had. At s= ome point, someone needs to solve the problem with option space and when th= ey do that might be feasible again.=0A= =0A= Otherwise, it looks great to me!=0A= =0A= --J=0A= ________________________________________=0A= From: middisc-bounces@ietf.org [middisc-bounces@ietf.org] on behalf of Knut= sen, Andrew=0A= Sent: Tuesday, January 22, 2013 10:32 PM=0A= To: Mani Ramasamy (mani); middisc@ietf.org=0A= Subject: Re: [middisc] closure of the middisc list=0A= =0A= Oops, I was mixing up OUI's and Ethernet addresses. 3 bytes is still pr= etty big.=0A= =0A= Andrew=0A= ________________________________________=0A= From: middisc-bounces@ietf.org [middisc-bounces@ietf.org] on behalf of Knut= sen, Andrew=0A= Sent: Tuesday, January 22, 2013 10:28 PM=0A= To: Mani Ramasamy (mani); middisc@ietf.org=0A= Subject: Re: [middisc] closure of the middisc list=0A= =0A= I now see this in the draft; did I miss it before?=0A= =0A= =0A= 1) Standard code: Standard code can be used in a such way that=0A= multiple vendors recognize the same and are interoperable for=0A= negotiation purposes=0A= =0A= 2) Extended vendor id: Should the unassigned space run out in the=0A= future, either the reserved space can be opened up for assignment,=0A= or a speical id can be added to extend the vendor id space to more=0A= than one byte (say by including OUI after the 1 byte vendor id)=0A= =0A= Looks good to me, except the special misspelling. I'm not sure we need = the OUI reference though --they're bigger then enterprise numbers. For ins= tance, if some reserved codes were each used to make 256 more (with one mor= e byte), I think we'd be fine for a long time. I'd just as soon we leave t= he question open (and leave out the parenthesized phrase).=0A= =0A= Andrew=0A= =0A= ________________________________=0A= From: Mani Ramasamy (mani) [mani@cisco.com]=0A= Sent: Tuesday, January 22, 2013 10:08 PM=0A= To: Knutsen, Andrew; middisc@ietf.org=0A= Subject: RE: [middisc] closure of the middisc list=0A= =0A= Thanks, Andrew. Please see inline.=0A= =0A= Hi Wes,=0A= Can you pl. update on what the next steps are to move this = draft forward?=0A= =0A= Thanks.=0A= =0A= =0A= From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On Behalf = Of Andrew Knutsen=0A= Sent: Tuesday, January 22, 2013 2:39 PM=0A= To: middisc@ietf.org=0A= Subject: Re: [middisc] closure of the middisc list=0A= =0A= =0A= Looks good to me, except I would suggest adding a note at the end of sec= tion 5 saying that if for some reason more space is needed, a "extension" v= endor code can be allocated (leaving exactly how it would work TBD).=0A= =0A= MANI =96 Sure, will add.=0A= =0A= =0A= Also, I think its worth allowing vendor codes to be allocated for inter-v= endor formats. This would allow such to be developed in fewer years than th= is draft has taken.=0A= =0A= MANI =96 Just to make sure I understand =96 are you suggesting to allow cod= es to be defined so a subset of vendors can interoperate? For example, id 5= to allow vendor A and B to interoperate, id 6 for vendor B and vendor to i= nteroperate? Or one standard code for all interoperating vendors?=0A= =0A= Mani.=0A= =0A= =0A= Thanks Mani!=0A= =0A= Andrew=0A= =0A= On 1/21/2013 9:00 AM, Mani Ramasamy (mani) wrote:=0A= =0A= =0A= All,=0A= Just posted the updated version of the draft. Please review.=0A= =0A= =0A= Thanks.=0A= Mani.=0A= =0A= =0A= =0A= =0A= A new version of I-D, draft-ananth-middisc-tcpopt-01.txt=0A= has been successfully submitted by Arivu Ramasamy and posted to the=0A= IETF repository.=0A= =0A= Filename: draft-ananth-middisc-tcpopt=0A= Revision: 01=0A= Title: TCP option for transparent Middlebox negotiation=0A= Creation date: 2013-01-21=0A= WG ID: Individual Submission=0A= Number of pages: 16=0A= URL: http://www.ietf.org/internet-drafts/draft-ananth-middisc-t= cpopt-01.txt=0A= Status: http://datatracker.ietf.org/doc/draft-ananth-middisc-tcpop= t=0A= Htmlized: http://tools.ietf.org/html/draft-ananth-middisc-tcpopt-01= =0A= Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ananth-middisc-tc= popt-01=0A= =0A= Abstract:=0A= This document describes a TCP option for use by middleboxes to=0A= facilitate transparent detection of other middleboxes along the path=0A= of the TCP connection during the connection initiation phase. The=0A= option has no effect if an appropriate middlebox is not present on=0A= the path.=0A= =0A= =0A= =0A= =0A= The IETF Secretariat=0A= =0A= Sent from my iPad=0A= =0A= On Jan 9, 2013, at 6:47 AM, "Eggert, Lars" > wrote:=0A= =0A= =0A= Hi,=0A= =0A= On Jan 9, 2013, at 3:16, Mani Ramasamy (mani) > wrote:=0A= As Anantha says, I would like to continue on this effort.=0A= I will target the completion of the revised draft by end of next week.=0A= =0A= I was AD when this effort was started, and it's been a while. I fully agree= with Wes that we need to finish this, or declare failure and disband the l= ist.=0A= =0A= If there is anything I can do to help progress this, I'd be happy to.=0A= =0A= Lars=0A= =0A= =0A= =0A= =0A= _______________________________________________=0A= =0A= middisc mailing list=0A= =0A= middisc@ietf.org=0A= =0A= https://www.ietf.org/mailman/listinfo/middisc=0A= =0A= _______________________________________________=0A= middisc mailing list=0A= middisc@ietf.org=0A= https://www.ietf.org/mailman/listinfo/middisc=0A= _______________________________________________=0A= middisc mailing list=0A= middisc@ietf.org=0A= https://www.ietf.org/mailman/listinfo/middisc=0A= From ananth@nttmcl.com Wed Jan 23 07:43:58 2013 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 76DE221F8703 for ; Wed, 23 Jan 2013 07:43:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNCSiwH7BBk7 for ; Wed, 23 Jan 2013 07:43:54 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id A187921F869F for ; Wed, 23 Jan 2013 07:43:53 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr12so5179909wgb.23 for ; Wed, 23 Jan 2013 07:43:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=fiMg2Afm4VkKgJoKvKnIZfJfdSRfwEjKSCTTi/FHIBw=; b=Vm2z2wXrZ3JoU3ofZiPL+sVEqGqphi93FanBGC3YxWHHYI2YAg1BIxm1gaNe1e2JDA BahYp08HcgacvvjKWYIBeGfIjFmO9pJZdQ0hxflKhMv/hjMgOl47JkQWxyI5/OoVXXQu p4Wk853N+I9fjYh34bxWDSd7zgHN4It8xhDMpPQaCctC7YQqmArVRo9D+5BPXTJpGp/1 4b/DeTe80g71Y/uPLAsx1u0DfR+N1IRxEk/KniTmHAFrqIedYVuN5aA9sMH/8xhLmQYW PfP/LQlJsxurrFCVJrt6Jg97l2UENT5P4hCsHxbAPCf3n5H7QHB+3oZ+b6kX5WXCjHVX wWVg== MIME-Version: 1.0 X-Received: by 10.180.93.41 with SMTP id cr9mr3363568wib.19.1358955832308; Wed, 23 Jan 2013 07:43:52 -0800 (PST) Received: by 10.180.162.165 with HTTP; Wed, 23 Jan 2013 07:43:52 -0800 (PST) In-Reply-To: References: <50ECC3EF.1020405@mti-systems.com> <50FF1520.4080901@bluecoat.com> <974FE049BD0F2E4188567FAD99DEF0331E7F6846@pwsvl-excmbx-04.internal.cacheflow.com> <974FE049BD0F2E4188567FAD99DEF0331E7F6889@pwsvl-excmbx-04.internal.cacheflow.com> Date: Wed, 23 Jan 2013 07:43:52 -0800 Message-ID: From: Anantha Ramaiah To: "Mahdavi, Jamshid" Content-Type: multipart/alternative; boundary=f46d04389357a674d004d3f68fe1 X-Gm-Message-State: ALoCoQkYEQkACH2CwdYFE7kv/iQH7cUM8g0KhWN6OCayBoQOwlshEOBvU25DUFQmLmIFsgTuiWxN Cc: "middisc@ietf.org" Subject: Re: [middisc] closure of the middisc list 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, 23 Jan 2013 15:43:58 -0000 --f46d04389357a674d004d3f68fe1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Jamshid, I used the RFC 2119 language in this draft since we are trying to define a middlebox option whose requirements are generic in nature with the use case of middle box discovery. I also assume it is ok to use RFC 2119 language for experimental specifications (which this draft is targetted towards) I would like to hear from the AD's on this usage. thanks, -Anantha On Wed, Jan 23, 2013 at 7:11 AM, Mahdavi, Jamshid < jamshid.mahdavi@bluecoat.com> wrote: > A few small nits: > > * In section 3, the use of MUST for requirements appears incorrect to me. > I believe the capitalized terms are only supposed to be used for the > actual specification of the standard that implementations need to follow; > I'd view the underlying requirements are informational. > > If you agree with that, here is suggested rewording to avoid the standard > terms. (Changes in []). > > 1) The TCP-MNO [needs to] be variable length to accommodate multiple > vendor > option formats. > > 2) The TCP-MNO [needs to] have a vendor ID which can identify the > specific > vendor as implied by 1) > > 3) The TCP option space limitation puts a burden on how flexible the > option can be. Please refer section 6 below. > > 4) TCP option numbers already in use by proprietary systems [should > not] be reused for TCP-MNO since it would create confusion. (These > option numbers would get eventually retired when all vendors > migrate to the newly allocated TCP-MNO option) > > In the last item, I'd like to slightly modify the content as we'd > definitely envision cases where end hosts want to discover middle boxes: > > 5) The TCP-MNO [is intended for use by] for middleboxes only. [End > hosts which are not participating in middlebox negotiation] are > expected to silently ignore this option. > > * In section 5, there appear to be some formatting issue with the spaces > in the diagram. The bars separating the bytes should appear at [1,8] and > [2,6]. > > * On Andrew's point below, I think it is fine to leave in the reference > to OUI. It is just an example and it is the original idea that we had. = At > some point, someone needs to solve the problem with option space and when > they do that might be feasible again. > > Otherwise, it looks great to me! > > --J > ________________________________________ > From: middisc-bounces@ietf.org [middisc-bounces@ietf.org] on behalf of > Knutsen, Andrew > Sent: Tuesday, January 22, 2013 10:32 PM > To: Mani Ramasamy (mani); middisc@ietf.org > Subject: Re: [middisc] closure of the middisc list > > Oops, I was mixing up OUI's and Ethernet addresses. 3 bytes is still > pretty big. > > Andrew > ________________________________________ > From: middisc-bounces@ietf.org [middisc-bounces@ietf.org] on behalf of > Knutsen, Andrew > Sent: Tuesday, January 22, 2013 10:28 PM > To: Mani Ramasamy (mani); middisc@ietf.org > Subject: Re: [middisc] closure of the middisc list > > I now see this in the draft; did I miss it before? > > > 1) Standard code: Standard code can be used in a such way that > multiple vendors recognize the same and are interoperable for > negotiation purposes > > 2) Extended vendor id: Should the unassigned space run out in the > future, either the reserved space can be opened up for assignment, > or a speical id can be added to extend the vendor id space to more > than one byte (say by including OUI after the 1 byte vendor id) > > Looks good to me, except the special misspelling. I'm not sure we nee= d > the OUI reference though --they're bigger then enterprise numbers. For > instance, if some reserved codes were each used to make 256 more (with on= e > more byte), I think we'd be fine for a long time. I'd just as soon we > leave the question open (and leave out the parenthesized phrase). > > Andrew > > ________________________________ > From: Mani Ramasamy (mani) [mani@cisco.com] > Sent: Tuesday, January 22, 2013 10:08 PM > To: Knutsen, Andrew; middisc@ietf.org > Subject: RE: [middisc] closure of the middisc list > > Thanks, Andrew. Please see inline. > > Hi Wes, > Can you pl. update on what the next steps are to move thi= s > draft forward? > > Thanks. > > > From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On > Behalf Of Andrew Knutsen > Sent: Tuesday, January 22, 2013 2:39 PM > To: middisc@ietf.org > Subject: Re: [middisc] closure of the middisc list > > > Looks good to me, except I would suggest adding a note at the end of > section 5 saying that if for some reason more space is needed, a > "extension" vendor code can be allocated (leaving exactly how it would wo= rk > TBD). > > MANI =96 Sure, will add. > > > Also, I think its worth allowing vendor codes to be allocated for > inter-vendor formats. This would allow such to be developed in fewer year= s > than this draft has taken. > > MANI =96 Just to make sure I understand =96 are you suggesting to allow c= odes > to be defined so a subset of vendors can interoperate? For example, id 5 = to > allow vendor A and B to interoperate, id 6 for vendor B and vendor to > interoperate? Or one standard code for all interoperating vendors? > > Mani. > > > Thanks Mani! > > Andrew > > On 1/21/2013 9:00 AM, Mani Ramasamy (mani) wrote: > > > All, > Just posted the updated version of the draft. Please review. > > > Thanks. > Mani. > > > > > A new version of I-D, draft-ananth-middisc-tcpopt-01.txt > has been successfully submitted by Arivu Ramasamy and posted to the > IETF repository. > > Filename: draft-ananth-middisc-tcpopt > Revision: 01 > Title: TCP option for transparent Middlebox negotiation > Creation date: 2013-01-21 > WG ID: Individual Submission > Number of pages: 16 > URL: > http://www.ietf.org/internet-drafts/draft-ananth-middisc-tcpopt-01.txt > Status: > http://datatracker.ietf.org/doc/draft-ananth-middisc-tcpopt > Htmlized: http://tools.ietf.org/html/draft-ananth-middisc-tcpopt-0= 1 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ananth-middisc-tcpopt-01 > > Abstract: > 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. > > > > > The IETF Secretariat > > Sent from my iPad > > On Jan 9, 2013, at 6:47 AM, "Eggert, Lars" lars@netapp.com>> wrote: > > > Hi, > > On Jan 9, 2013, at 3:16, Mani Ramasamy (mani) mani@cisco.com>> wrote: > As Anantha says, I would like to continue on this effort. > I will target the completion of the revised draft by end of next week. > > I was AD when this effort was started, and it's been a while. I fully > agree with Wes that we need to finish this, or declare failure and disban= d > the list. > > If there is anything I can do to help progress this, I'd be happy to. > > Lars > > > > > _______________________________________________ > > 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 > --f46d04389357a674d004d3f68fe1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Jamshid,
=A0 =A0 =A0 I used the RFC 2119 language in this draft sinc= e we are trying to define a middlebox option whose requirements are generic= in nature with the use case of middle box discovery. I also assume it is o= k to use RFC 2119 language for experimental specifications (which this draf= t is targetted towards) =A0I would like to hear from the AD's on this u= sage.
thanks,
-Anantha

On Wed, J= an 23, 2013 at 7:11 AM, Mahdavi, Jamshid <jamshid.mahdavi@bluec= oat.com> wrote:
A few small nits:

* In section 3, the use of MUST for requirements appears incorrect to me. = =A0I believe the capitalized terms are only supposed to be used for the act= ual specification of the standard that implementations need to follow; I= 9;d view the underlying requirements are informational.

If you agree with that, here is suggested rewording to avoid the standard t= erms. =A0(Changes in []).

=A0 =A01) The TCP-MNO [needs to] be variable length to accommodate multiple= vendor
=A0 =A0 =A0 option formats.

=A0 =A02) The TCP-MNO [needs to] have a vendor ID which can identify the sp= ecific
=A0 =A0 =A0 vendor as implied by 1)

=A0 =A03) The TCP option space limitation puts a burden on how flexible the=
=A0 =A0 =A0 option can be. =A0Please refer section 6 below.

=A0 =A04) TCP option numbers already in use by proprietary systems [should<= br> =A0 =A0 =A0 not] be reused for TCP-MNO since it would create confusion. =A0= (These
=A0 =A0 =A0 option numbers would get eventually retired when all vendors =A0 =A0 =A0 migrate to the newly allocated TCP-MNO option)

In the last item, I'd like to slightly modify the content as we'd d= efinitely envision cases where end hosts want to discover middle boxes:

=A0 =A05) The TCP-MNO [is intended for use by] for middleboxes only. =A0[En= d hosts which are not participating in middlebox negotiation] are
=A0 =A0 =A0 expected to silently ignore this option.

* In section 5, there appear to be some formatting issue with the spaces in= the diagram. =A0The bars separating the bytes should appear at [1,8] and [= 2,6].

* =A0On Andrew's point below, I think it is fine to leave in the refere= nce to OUI. =A0It is just an example and it is the original idea that we ha= d. =A0At some point, someone needs to solve the problem with option space a= nd when they do that might be feasible again.

Otherwise, it looks great to me!

--J
________________________________________
From: middisc-bounces@ietf.org<= /a> [middisc-bounces@ietf.org] on behalf of Knutsen, Andrew
Sent: Tuesday, January 22, 2013 10:32 PM
To: Mani Ramasamy (mani); middisc@ietf.org
Subject: Re: [middisc] closure of the middisc list

=A0 =A0Oops, I was mixing up OUI's and Ethernet addresses. =A03 bytes i= s still pretty big.

Andrew
________________________________________
From: middisc-bounces@ietf.org<= /a> [middisc-bounces@ietf.org] on behalf of Knutsen, Andrew
Sent: Tuesday, January 22, 2013 10:28 PM
To: Mani Ramasamy (mani); middisc@ietf.= org
Subject: Re: [middisc] closure of the middisc list

=A0 =A0 I now see this in the draft; did I miss it before?


1) Standard code: Standard code can be used in a such way that
=A0 =A0 =A0 multiple vendors recognize the same and are interoperable for =A0 =A0 =A0 negotiation purposes

=A0 =A02) Extended vendor id: Should the unassigned space run out in the =A0 =A0 =A0 future, either the reserved space can be opened up for assignme= nt,
=A0 =A0 =A0 or a speical id can be added to extend the vendor id space to m= ore
=A0 =A0 =A0 than one byte (say by including OUI after the 1 byte vendor id)=

=A0 =A0Looks good to me, except the special misspelling. =A0I'm not sur= e we need the OUI reference though --they're bigger then enterprise num= bers. =A0For instance, if some reserved codes were each used to make 256 mo= re (with one more byte), I think we'd be fine for a long time. =A0I'= ;d just as soon we leave the question open (and leave out the parenthesized= phrase).

Andrew

________________________________
From: Mani Ramasamy (mani) [mani@cisco.co= m]
Sent: Tuesday, January 22, 2013 10:08 PM
To: Knutsen, Andrew; middisc@ietf.org
Subject: RE: [middisc] closure of the middisc list

Thanks, Andrew. Please see inline.

Hi Wes,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Can you pl. update on what the next steps a= re to move this draft forward?

Thanks.


From: middisc-bounces@ietf.org<= /a> [mailto:middisc-bounces@iet= f.org] On Behalf Of Andrew Knutsen
Sent: Tuesday, January 22, 2013 2:39 PM
To: middisc@ietf.org
Subject: Re: [middisc] closure of the middisc list


=A0 =A0Looks good to me, except I would suggest adding a note at the end of= section 5 saying that if for some reason more space is needed, a "ext= ension" vendor code can be allocated (leaving exactly how it would wor= k TBD).

MANI =96 Sure, will add.


=A0 Also, I think its worth allowing vendor codes to be allocated for inter= -vendor formats. This would allow such to be developed in fewer years than = this draft has taken.

MANI =96 Just to make sure I understand =96 are you suggesting to allow cod= es to be defined so a subset of vendors can interoperate? For example, id 5= to allow vendor A and B to interoperate, id 6 for vendor B and vendor to i= nteroperate? Or one standard code for all interoperating vendors?

Mani.


=A0 =A0Thanks Mani!

Andrew

On 1/21/2013 9:00 AM, Mani Ramasamy (mani) wrote:


All,
=A0 =A0 Just posted the updated version of the draft. Please review.


Thanks.
Mani.




A new version of I-D, draft-ananth-middisc-tcpopt-01.txt
has been successfully submitted by Arivu Ramasamy and posted to the
IETF repository.

Filename: =A0 =A0 draft-ananth-middisc-tcpopt
Revision: =A0 =A0 01
Title: =A0 =A0 =A0 =A0 TCP option for transparent Middlebox negotiation
Creation date: =A0 =A0 2013-01-21
WG ID: =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 16
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/= internet-drafts/draft-ananth-middisc-tcpopt-01.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/d= raft-ananth-middisc-tcpopt
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-anan= th-middisc-tcpopt-01
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/rfcdi= ff?url2=3Ddraft-ananth-middisc-tcpopt-01

Abstract:
=A0 This document describes a TCP option for use by middleboxes to
=A0 facilitate transparent detection of other middleboxes along the path =A0 of the TCP connection during the connection initiation phase. =A0The =A0 option has no effect if an appropriate middlebox is not present on
=A0 the path.




The IETF Secretariat

Sent from my iPad

On Jan 9, 2013, at 6:47 AM, "Eggert, Lars" <lars@netapp.com<mailto:lars@netapp.com>> wrote:


Hi,

On Jan 9, 2013, at 3:16, Mani Ramasamy (mani) <mani@cisco.com<mailto:man= i@cisco.com>> wrote:
=A0 =A0 =A0 =A0 =A0 =A0 =A0As Anantha says, =A0I would like to continue on = this effort.
I will target the completion of the revised draft by end of next week.

I was AD when this effort was started, and it's been a while. I fully a= gree with Wes that we need to finish this, or declare failure and disband t= he list.

If there is anything I can do to help progress this, I'd be happy to.
Lars




_______________________________________________

middisc mailing list

middisc@ietf.org<mailto: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

--f46d04389357a674d004d3f68fe1-- From jamshid.mahdavi@bluecoat.com Wed Jan 23 08:18:08 2013 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 D243A21F8686 for ; Wed, 23 Jan 2013 08:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJTn5vQPhLG6 for ; Wed, 23 Jan 2013 08:18:07 -0800 (PST) Received: from plsvl-mailgw-02.bluecoat.com (plsvl-mailgw-02.bluecoat.com [199.91.133.12]) by ietfa.amsl.com (Postfix) with ESMTP id D044B21F85CE for ; Wed, 23 Jan 2013 08:18:07 -0800 (PST) Received: from PWSVL-EXCHTS-02.internal.cacheflow.com (unknown [10.2.2.126]) by plsvl-mailgw-02.bluecoat.com (Postfix) with ESMTP id 2E689200FD; Wed, 23 Jan 2013 08:18:05 -0800 (PST) Received: from PWSVL-EXCMBX-04.internal.cacheflow.com ([fe80::c596:c77:dd67:b72d]) by PWSVL-EXCHTS-02.internal.cacheflow.com ([fe80::4910:317f:407:6ecc%14]) with mapi id 14.01.0289.001; Wed, 23 Jan 2013 08:18:04 -0800 From: "Mahdavi, Jamshid" To: Anantha Ramaiah Thread-Topic: [middisc] closure of the middisc list Thread-Index: AQHN7gZoGzxDeTsZFk2tJjGzJZE5bJhAuhcAgAAOl4CAANHugIATAP2AgAHxIgCAAH1ZAIAABbEAgAABQ4CAAAWX5YAAlFMA//+Cw30= Date: Wed, 23 Jan 2013 16:18:04 +0000 Message-ID: References: <50ECC3EF.1020405@mti-systems.com> <50FF1520.4080901@bluecoat.com> <974FE049BD0F2E4188567FAD99DEF0331E7F6846@pwsvl-excmbx-04.internal.cacheflow.com> <974FE049BD0F2E4188567FAD99DEF0331E7F6889@pwsvl-excmbx-04.internal.cacheflow.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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "middisc@ietf.org" Subject: Re: [middisc] closure of the middisc list 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, 23 Jan 2013 16:18:08 -0000 I'm happy with whatever advice the ADs give for these clauses. My thinking was that the usage in section 4 is correct, but in section 3 we= aren't really specifying things that implementers have control over (e.g. = MUST be variable length) -- those are things that we as the authors have co= ntrol over and once this is published the correct verb would be "IS variabl= e length". --J ________________________________ From: Anantha Ramaiah [ananth@nttmcl.com] Sent: Wednesday, January 23, 2013 7:43 AM To: Mahdavi, Jamshid Cc: Knutsen, Andrew; Mani Ramasamy (mani); middisc@ietf.org Subject: Re: [middisc] closure of the middisc list Hi Jamshid, I used the RFC 2119 language in this draft since we are trying to def= ine a middlebox option whose requirements are generic in nature with the us= e case of middle box discovery. I also assume it is ok to use RFC 2119 lang= uage for experimental specifications (which this draft is targetted towards= ) I would like to hear from the AD's on this usage. thanks, -Anantha On Wed, Jan 23, 2013 at 7:11 AM, Mahdavi, Jamshid > wrote: A few small nits: * In section 3, the use of MUST for requirements appears incorrect to me. = I believe the capitalized terms are only supposed to be used for the actual= specification of the standard that implementations need to follow; I'd vie= w the underlying requirements are informational. If you agree with that, here is suggested rewording to avoid the standard t= erms. (Changes in []). 1) The TCP-MNO [needs to] be variable length to accommodate multiple ven= dor option formats. 2) The TCP-MNO [needs to] have a vendor ID which can identify the specif= ic vendor as implied by 1) 3) The TCP option space limitation puts a burden on how flexible the option can be. Please refer section 6 below. 4) TCP option numbers already in use by proprietary systems [should not] be reused for TCP-MNO since it would create confusion. (These option numbers would get eventually retired when all vendors migrate to the newly allocated TCP-MNO option) In the last item, I'd like to slightly modify the content as we'd definitel= y envision cases where end hosts want to discover middle boxes: 5) The TCP-MNO [is intended for use by] for middleboxes only. [End host= s which are not participating in middlebox negotiation] are expected to silently ignore this option. * In section 5, there appear to be some formatting issue with the spaces in= the diagram. The bars separating the bytes should appear at [1,8] and [2,= 6]. * On Andrew's point below, I think it is fine to leave in the reference to= OUI. It is just an example and it is the original idea that we had. At s= ome point, someone needs to solve the problem with option space and when th= ey do that might be feasible again. Otherwise, it looks great to me! --J ________________________________________ From: middisc-bounces@ietf.org [middisc-bo= unces@ietf.org] on behalf of Knutsen, Andr= ew Sent: Tuesday, January 22, 2013 10:32 PM To: Mani Ramasamy (mani); middisc@ietf.org Subject: Re: [middisc] closure of the middisc list Oops, I was mixing up OUI's and Ethernet addresses. 3 bytes is still pr= etty big. Andrew ________________________________________ From: middisc-bounces@ietf.org [middisc-bo= unces@ietf.org] on behalf of Knutsen, Andr= ew Sent: Tuesday, January 22, 2013 10:28 PM To: Mani Ramasamy (mani); middisc@ietf.org Subject: Re: [middisc] closure of the middisc list I now see this in the draft; did I miss it before? 1) Standard code: Standard code can be used in a such way that multiple vendors recognize the same and are interoperable for negotiation purposes 2) Extended vendor id: Should the unassigned space run out in the future, either the reserved space can be opened up for assignment, or a speical id can be added to extend the vendor id space to more than one byte (say by including OUI after the 1 byte vendor id) Looks good to me, except the special misspelling. I'm not sure we need = the OUI reference though --they're bigger then enterprise numbers. For ins= tance, if some reserved codes were each used to make 256 more (with one mor= e byte), I think we'd be fine for a long time. I'd just as soon we leave t= he question open (and leave out the parenthesized phrase). Andrew ________________________________ From: Mani Ramasamy (mani) [mani@cisco.com] Sent: Tuesday, January 22, 2013 10:08 PM To: Knutsen, Andrew; middisc@ietf.org Subject: RE: [middisc] closure of the middisc list Thanks, Andrew. Please see inline. Hi Wes, Can you pl. update on what the next steps are to move this = draft forward? Thanks. From: middisc-bounces@ietf.org [mailto:mid= disc-bounces@ietf.org] On Behalf Of Andrew= Knutsen Sent: Tuesday, January 22, 2013 2:39 PM To: middisc@ietf.org Subject: Re: [middisc] closure of the middisc list Looks good to me, except I would suggest adding a note at the end of sec= tion 5 saying that if for some reason more space is needed, a "extension" v= endor code can be allocated (leaving exactly how it would work TBD). MANI =96 Sure, will add. Also, I think its worth allowing vendor codes to be allocated for inter-v= endor formats. This would allow such to be developed in fewer years than th= is draft has taken. MANI =96 Just to make sure I understand =96 are you suggesting to allow cod= es to be defined so a subset of vendors can interoperate? For example, id 5= to allow vendor A and B to interoperate, id 6 for vendor B and vendor to i= nteroperate? Or one standard code for all interoperating vendors? Mani. Thanks Mani! Andrew On 1/21/2013 9:00 AM, Mani Ramasamy (mani) wrote: All, Just posted the updated version of the draft. Please review. Thanks. Mani. A new version of I-D, draft-ananth-middisc-tcpopt-01.txt has been successfully submitted by Arivu Ramasamy and posted to the IETF repository. Filename: draft-ananth-middisc-tcpopt Revision: 01 Title: TCP option for transparent Middlebox negotiation Creation date: 2013-01-21 WG ID: Individual Submission Number of pages: 16 URL: http://www.ietf.org/internet-drafts/draft-ananth-middisc-t= cpopt-01.txt Status: http://datatracker.ietf.org/doc/draft-ananth-middisc-tcpop= t Htmlized: http://tools.ietf.org/html/draft-ananth-middisc-tcpopt-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ananth-middisc-tc= popt-01 Abstract: 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. The IETF Secretariat Sent from my iPad On Jan 9, 2013, at 6:47 AM, "Eggert, Lars" >> wrote: Hi, On Jan 9, 2013, at 3:16, Mani Ramasamy (mani) >> wrote: As Anantha says, I would like to continue on this effort. I will target the completion of the revised draft by end of next week. I was AD when this effort was started, and it's been a while. I fully agree= with Wes that we need to finish this, or declare failure and disband the l= ist. If there is anything I can do to help progress this, I'd be happy to. Lars _______________________________________________ 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 wes@mti-systems.com Thu Jan 31 17:42:27 2013 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 5E4D821F8A14 for ; Thu, 31 Jan 2013 17:42:27 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iAYDtozmm+r for ; Thu, 31 Jan 2013 17:42:27 -0800 (PST) Received: from atl4mhob05.myregisteredsite.com (atl4mhob05.myregisteredsite.com [209.17.115.43]) by ietfa.amsl.com (Postfix) with ESMTP id 541EC21F89D8 for ; Thu, 31 Jan 2013 17:42:26 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob05.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r111gOlP032722 for ; Thu, 31 Jan 2013 20:42:24 -0500 Received: (qmail 3511 invoked by uid 0); 1 Feb 2013 01:42:23 -0000 Received: from unknown (HELO ?192.168.1.145?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 1 Feb 2013 01:42:23 -0000 Message-ID: <510B1D7B.1080704@mti-systems.com> Date: Thu, 31 Jan 2013 20:42:19 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Mani Ramasamy (mani)" References: <50ECC3EF.1020405@mti-systems.com> , In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "middisc@ietf.org" Subject: Re: [middisc] closure of the middisc list 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: Fri, 01 Feb 2013 01:42:27 -0000 On 1/21/2013 12:00 PM, Mani Ramasamy (mani) wrote: > > All, > Just posted the updated version of the draft. Please review. > If folks are generally happy with this revision, I think the path forward is that Pasi Sarolahti agreed to do a shepherd review / writeup. That was back at the Paris IETF, so he might have changed his mind by then :). If any of the authors or advocates will be in Orlando at the next IETF meeting, it would be nice to give TCPM a 5 minute recap of the current status, just so they know what happened since it left the WG as a proposal there. If nobody else will be there (or nobody wants to do it!), I'd be happy to briefly explain it's state. Since it's unclear who will replace me as AD in March, it might be a good idea to work kind of quick on this, so that I can get it as far along with the IESG as possible before March. I suspect there will be trouble in the IESG on this, as recent experience with the TCPM experimental options draft suggests ... -- Wes Eddy MTI Systems From jamshid.mahdavi@bluecoat.com Thu Jan 31 18:00:16 2013 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 A420B21F8939 for ; Thu, 31 Jan 2013 18:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bitikJGm11if for ; Thu, 31 Jan 2013 18:00:16 -0800 (PST) Received: from plsvl-mailgw-01.bluecoat.com (plsvl-mailgw-01.bluecoat.com [199.91.133.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1E27521F8906 for ; Thu, 31 Jan 2013 18:00:11 -0800 (PST) Received: from PWSVL-EXCHTS-02.internal.cacheflow.com (unknown [10.2.2.126]) by plsvl-mailgw-01.bluecoat.com (Postfix) with ESMTP id 952B381A0C5; Thu, 31 Jan 2013 18:06:52 -0900 (AKST) Received: from PWSVL-EXCMBX-04.internal.cacheflow.com ([fe80::c596:c77:dd67:b72d]) by PWSVL-EXCHTS-02.internal.cacheflow.com ([fe80::4910:317f:407:6ecc%14]) with mapi id 14.01.0289.001; Thu, 31 Jan 2013 18:00:11 -0800 From: "Mahdavi, Jamshid" To: Wesley Eddy , "Mani Ramasamy (mani)" Thread-Topic: [middisc] closure of the middisc list Thread-Index: AQHN7gZoGzxDeTsZFk2tJjGzJZE5bJhAuhcAgAAOl4CAANHugIATAP2AgBBJNID//35GQA== Date: Fri, 1 Feb 2013 02:00:09 +0000 Message-ID: References: <50ECC3EF.1020405@mti-systems.com> , <510B1D7B.1080704@mti-systems.com> In-Reply-To: <510B1D7B.1080704@mti-systems.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-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "middisc@ietf.org" Subject: Re: [middisc] closure of the middisc list 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: Fri, 01 Feb 2013 02:00:16 -0000 I had made some minor comments on the wording (MUST, SHOULD) which I believ= e we wanted advice from the AD on so Mani knew whether to accept it. I also had suggested one very minor change to the content which I hope Mani= is ok with accepting. Let me know if you need that email resent. Otherwise, very happy! --J -----Original Message----- From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On Behalf = Of Wesley Eddy Sent: Thursday, January 31, 2013 5:42 PM To: Mani Ramasamy (mani) Cc: middisc@ietf.org Subject: Re: [middisc] closure of the middisc list On 1/21/2013 12:00 PM, Mani Ramasamy (mani) wrote: >=20 > All,=20 > Just posted the updated version of the draft. Please review. >=20 If folks are generally happy with this revision, I think the path forward i= s that Pasi Sarolahti agreed to do a shepherd review / writeup. That was b= ack at the Paris IETF, so he might have changed his mind by then :). If any of the authors or advocates will be in Orlando at the next IETF meet= ing, it would be nice to give TCPM a 5 minute recap of the current status, = just so they know what happened since it left the WG as a proposal there. = If nobody else will be there (or nobody wants to do it!), I'd be happy to b= riefly explain it's state. Since it's unclear who will replace me as AD in March, it might be a good i= dea to work kind of quick on this, so that I can get it as far along with t= he IESG as possible before March. I suspect there will be trouble in the I= ESG on this, as recent experience with the TCPM experimental options draft = suggests ... -- Wes Eddy MTI Systems _______________________________________________ middisc mailing list middisc@ietf.org https://www.ietf.org/mailman/listinfo/middisc From wes@mti-systems.com Thu Jan 31 18:20:21 2013 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 1B3DC21F899F for ; Thu, 31 Jan 2013 18:20:21 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjRqSPADQ-jJ for ; Thu, 31 Jan 2013 18:20:20 -0800 (PST) Received: from atl4mhob05.myregisteredsite.com (atl4mhob05.myregisteredsite.com [209.17.115.43]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACA321F8994 for ; Thu, 31 Jan 2013 18:20:20 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob05.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r112KJQA006457 for ; Thu, 31 Jan 2013 21:20:19 -0500 Received: (qmail 20545 invoked by uid 0); 1 Feb 2013 02:20:19 -0000 Received: from unknown (HELO ?192.168.1.145?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 1 Feb 2013 02:20:19 -0000 Message-ID: <510B265E.6060003@mti-systems.com> Date: Thu, 31 Jan 2013 21:20:14 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Mahdavi, Jamshid" References: <50ECC3EF.1020405@mti-systems.com> , <510B1D7B.1080704@mti-systems.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "middisc@ietf.org" Subject: Re: [middisc] closure of the middisc list 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: Fri, 01 Feb 2013 02:20:21 -0000 On 1/31/2013 9:00 PM, Mahdavi, Jamshid wrote: > I had made some minor comments on the wording (MUST, SHOULD) which I believe we wanted advice from the AD on so Mani knew whether to accept it. > > I also had suggested one very minor change to the content which I hope Mani is ok with accepting. > > Let me know if you need that email resent. > > Otherwise, very happy! > Regarding the 2119 wording, I (personally) prefer your rewording of it, since those "requirements" are kind of just the design principles that were aimed for and (as you note) not protocol conformance requirements. However, there are many RFCs that do use 2119 capitalized words for requirements statements, and there are mixed opinions about it, even in the IESG ... so, it would be passable either way. That said, I suspect it will be smoother sailing if your suggested rewordings are applied :). -- Wes Eddy MTI Systems From mani@cisco.com Thu Jan 31 22:52:22 2013 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 D83D721F871E for ; Thu, 31 Jan 2013 22:52:22 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWSS3jczG1l2 for ; Thu, 31 Jan 2013 22:52:22 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 30F7B21F8706 for ; Thu, 31 Jan 2013 22:52:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1284; q=dns/txt; s=iport; t=1359701542; x=1360911142; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RyZRcdXvI+21IhgcQIWO4IyBTPnVTWIvmUDwc3gvfGE=; b=Ku/+OqGdPnuKvX+rmFOuhozPme2b5img2Scca8WTADFt3dmN6bVQIgCs HtQTBW/OtBUA7Jio3KQETEKG3swPzVZpoo/J2ApFIkUn/qWozAPYdq1v+ 35pCrXz0GhyMwqtJD0vsBUZQAxW8wguq+wSYHRunZQEspxmf3ngFjhtS1 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALRlC1GtJXG8/2dsb2JhbABFvygWc4IeAQEBBDo/DAQCAQgOAwQBAQEKFAkHMhQJCAIEDgUIiAnCKo0RgxphA6ZignuBbzU X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; d="scan'208";a="171364084" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 01 Feb 2013 06:52:19 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r116qJ8X031825 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Feb 2013 06:52:19 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.75]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Fri, 1 Feb 2013 00:52:18 -0600 From: "Mani Ramasamy (mani)" To: Wesley Eddy , "Mahdavi, Jamshid" Thread-Topic: [middisc] closure of the middisc list Thread-Index: AQHN7gZoJ3eDBtsU7E6OW7KrYI/u+phAmJAA//+o1tCAATevgIASnGjdgBCtyYCAAAT8gIAABZwA///m/3A= Date: Fri, 1 Feb 2013 06:52:18 +0000 Message-ID: References: <50ECC3EF.1020405@mti-systems.com> , <510B1D7B.1080704@mti-systems.com> <510B265E.6060003@mti-systems.com> In-Reply-To: <510B265E.6060003@mti-systems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.66.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "middisc@ietf.org" Subject: Re: [middisc] closure of the middisc list 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: Fri, 01 Feb 2013 06:52:23 -0000 Great. Thanks Wes and Jamshid! Will update and post a new draft tomorrow. Mani. -----Original Message----- From: Wesley Eddy [mailto:wes@mti-systems.com]=20 Sent: Thursday, January 31, 2013 6:20 PM To: Mahdavi, Jamshid Cc: Mani Ramasamy (mani); middisc@ietf.org Subject: Re: [middisc] closure of the middisc list On 1/31/2013 9:00 PM, Mahdavi, Jamshid wrote: > I had made some minor comments on the wording (MUST, SHOULD) which I beli= eve we wanted advice from the AD on so Mani knew whether to accept it. >=20 > I also had suggested one very minor change to the content which I hope Ma= ni is ok with accepting. >=20 > Let me know if you need that email resent. >=20 > Otherwise, very happy! >=20 Regarding the 2119 wording, I (personally) prefer your rewording of it, sin= ce those "requirements" are kind of just the design principles that were ai= med for and (as you note) not protocol conformance requirements. However, = there are many RFCs that do use 2119 capitalized words for requirements sta= tements, and there are mixed opinions about it, even in the IESG ... so, it= would be passable either way. That said, I suspect it will be smoother sa= iling if your suggested rewordings are applied :). -- Wes Eddy MTI Systems