From mani@cisco.com Fri Feb 1 11:16: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 3060E21E805F for ; Fri, 1 Feb 2013 11:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IL2cxAhy-hEX for ; Fri, 1 Feb 2013 11:16:20 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 974C821E804E for ; Fri, 1 Feb 2013 11:16:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2144; q=dns/txt; s=iport; t=1359746180; x=1360955780; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=K7fHXe2OxZsXikPErFXBfgfo0uFbkV2dudzOORHwmTA=; b=DS6LaF17nJNV8qY8+iV9PYcN85py2OHPFO0uerrU+UORxPgYWTe8Nt3A 5rCPgYsx9y3gdxOUBsvMv+w206scBhI9xdnzIEIb2O+e3rDVHHyp0Z8Bk 7NfDL7UBXtbB9ge8GY/TJAS+6Qt5CrObPIySKZ47IL8NiCqZ3fvk/wukS w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMUTDFGtJV2c/2dsb2JhbABFvy0Wc4IeAQEBBAEBATc0CwwEAgEIDgMEAQEBChQJBycLFAkIAgQOBQgBiAgMwnqNFoNXYQOmZ4J8gW81 X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; d="scan'208";a="171891030" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 01 Feb 2013 19:16:19 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r11JGIHs003257 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Feb 2013 19:16:19 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.75]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Fri, 1 Feb 2013 13:16:17 -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/3CAAM/9NQ== Date: Fri, 1 Feb 2013 19:16:17 +0000 Message-ID: References: <50ECC3EF.1020405@mti-systems.com> , <510B1D7B.1080704@mti-systems.com> <510B265E.6060003@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.21.77.201] 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 19:16:21 -0000 =0A= =0A= New version has been posted with the suggested updates.=0A= =0A= =0A= http://www.ietf.org/internet-drafts/draft-ananth-middisc-tcpopt-02.txt=0A= =0A= Wes,=0A= Please let us know if anything else is needed to take this forward.=0A= =0A= Thanks.=0A= =0A= ________________________________________=0A= From: middisc-bounces@ietf.org [middisc-bounces@ietf.org] on behalf of Mani= Ramasamy (mani)=0A= Sent: Thursday, January 31, 2013 10:52 PM=0A= To: Wesley Eddy; Mahdavi, Jamshid=0A= Cc: middisc@ietf.org=0A= Subject: Re: [middisc] closure of the middisc list=0A= =0A= Great. Thanks Wes and Jamshid!=0A= =0A= Will update and post a new draft tomorrow.=0A= =0A= Mani.=0A= =0A= =0A= =0A= -----Original Message-----=0A= From: Wesley Eddy [mailto:wes@mti-systems.com]=0A= Sent: Thursday, January 31, 2013 6:20 PM=0A= To: Mahdavi, Jamshid=0A= Cc: Mani Ramasamy (mani); middisc@ietf.org=0A= Subject: Re: [middisc] closure of the middisc list=0A= =0A= On 1/31/2013 9:00 PM, Mahdavi, Jamshid wrote:=0A= > 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.=0A= >=0A= > I also had suggested one very minor change to the content which I hope Ma= ni is ok with accepting.=0A= >=0A= > Let me know if you need that email resent.=0A= >=0A= > Otherwise, very happy!=0A= >=0A= =0A= =0A= 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 :).=0A= =0A= --=0A= Wes Eddy=0A= MTI Systems=0A= _______________________________________________=0A= middisc mailing list=0A= middisc@ietf.org=0A= https://www.ietf.org/mailman/listinfo/middisc=0A= From jamshid.mahdavi@bluecoat.com Fri Feb 1 13:26:24 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 B2F2821E8050 for ; Fri, 1 Feb 2013 13:26:24 -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 Ep3mjaM-JcO3 for ; Fri, 1 Feb 2013 13:26:24 -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 4193E21E8056 for ; Fri, 1 Feb 2013 13:26:24 -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 92FEF81A082; Fri, 1 Feb 2013 13:33:07 -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; Fri, 1 Feb 2013 13:26:23 -0800 From: "Mahdavi, Jamshid" To: "Mani Ramasamy (mani)" , Wesley Eddy Thread-Topic: [middisc] closure of the middisc list Thread-Index: AQHN7gZoGzxDeTsZFk2tJjGzJZE5bJhAuhcAgAAOl4CAANHugIATAP2AgBBJNID//35GQIAAjFIAgABMBACAAM/egP//nhvA Date: Fri, 1 Feb 2013 21:26:21 +0000 Message-ID: References: <50ECC3EF.1020405@mti-systems.com> , <510B1D7B.1080704@mti-systems.com> <510B265E.6060003@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.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 21:26:24 -0000 This looks good to me -- thanks for getting those in! --J -----Original Message----- From: Mani Ramasamy (mani) [mailto:mani@cisco.com]=20 Sent: Friday, February 01, 2013 11:16 AM To: Wesley Eddy; Mahdavi, Jamshid Cc: middisc@ietf.org Subject: RE: [middisc] closure of the middisc list New version has been posted with the suggested updates. http://www.ietf.org/internet-drafts/draft-ananth-middisc-tcpopt-02.txt Wes, Please let us know if anything else is needed to take this forward. Thanks. ________________________________________ From: middisc-bounces@ietf.org [middisc-bounces@ietf.org] on behalf of Mani= Ramasamy (mani) Sent: Thursday, January 31, 2013 10:52 PM To: Wesley Eddy; Mahdavi, Jamshid Cc: middisc@ietf.org Subject: Re: [middisc] closure of the middisc list Great. Thanks Wes and Jamshid! Will update and post a new draft tomorrow. Mani. -----Original Message----- From: Wesley Eddy [mailto:wes@mti-systems.com] 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. > > I also had suggested one very minor change to the content which I hope Ma= ni 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, 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 _______________________________________________ middisc mailing list middisc@ietf.org https://www.ietf.org/mailman/listinfo/middisc From andrew.knutsen@bluecoat.com Sat Feb 23 14:50:48 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 4E29021F8E3A for ; Sat, 23 Feb 2013 14:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=-0.666, 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 5j46FhykMOBd for ; Sat, 23 Feb 2013 14:50: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 485F121F8E1E for ; Sat, 23 Feb 2013 14:50:46 -0800 (PST) Received: from pwsvl-exchts-03.internal.cacheflow.com (pwsvl-exchts-03.bluecoat.com [10.2.2.160]) by plsvl-mailgw-01.bluecoat.com (Postfix) with ESMTP id 0397D81A0A3; Sat, 23 Feb 2013 14:58:42 -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; Sat, 23 Feb 2013 14:50:45 -0800 From: "Knutsen, Andrew" To: "Mani Ramasamy (mani)" , Wesley Eddy , "Mahdavi, Jamshid" Thread-Topic: [middisc] closure of the middisc list Thread-Index: AQHN7gZoJkNJRcyZVkqKlI8ATneWQ5hAuhcAgAAOl4CAANHugIATAP2AgBBJNICAAAT8gIAABZwAgABMBACAAM/egIAiSHKs Date: Sat, 23 Feb 2013 22:50:44 +0000 Message-ID: <974FE049BD0F2E4188567FAD99DEF0331E801629@pwsvl-excmbx-04.internal.cacheflow.com> References: <50ECC3EF.1020405@mti-systems.com> , <510B1D7B.1080704@mti-systems.com> <510B265E.6060003@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: "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: Sat, 23 Feb 2013 22:50:48 -0000 =0A= What is the next step for this? I think we've reached consensus... Do = we have an option to publish as more than a draft?=0A= =0A= Andrew=0A= =0A= ________________________________________=0A= From: middisc-bounces@ietf.org [middisc-bounces@ietf.org] on behalf of Mani= Ramasamy (mani) [mani@cisco.com]=0A= Sent: Friday, February 01, 2013 11:16 AM=0A= To: Wesley Eddy; Mahdavi, Jamshid=0A= Cc: middisc@ietf.org=0A= Subject: Re: [middisc] closure of the middisc list=0A= =0A= New version has been posted with the suggested updates.=0A= =0A= =0A= http://www.ietf.org/internet-drafts/draft-ananth-middisc-tcpopt-02.txt=0A= =0A= Wes,=0A= Please let us know if anything else is needed to take this forward.=0A= =0A= Thanks.=0A= =0A= ________________________________________=0A= From: middisc-bounces@ietf.org [middisc-bounces@ietf.org] on behalf of Mani= Ramasamy (mani)=0A= Sent: Thursday, January 31, 2013 10:52 PM=0A= To: Wesley Eddy; Mahdavi, Jamshid=0A= Cc: middisc@ietf.org=0A= Subject: Re: [middisc] closure of the middisc list=0A= =0A= Great. Thanks Wes and Jamshid!=0A= =0A= Will update and post a new draft tomorrow.=0A= =0A= Mani.=0A= =0A= =0A= =0A= -----Original Message-----=0A= From: Wesley Eddy [mailto:wes@mti-systems.com]=0A= Sent: Thursday, January 31, 2013 6:20 PM=0A= To: Mahdavi, Jamshid=0A= Cc: Mani Ramasamy (mani); middisc@ietf.org=0A= Subject: Re: [middisc] closure of the middisc list=0A= =0A= On 1/31/2013 9:00 PM, Mahdavi, Jamshid wrote:=0A= > 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.=0A= >=0A= > I also had suggested one very minor change to the content which I hope Ma= ni is ok with accepting.=0A= >=0A= > Let me know if you need that email resent.=0A= >=0A= > Otherwise, very happy!=0A= >=0A= =0A= =0A= 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 :).=0A= =0A= --=0A= Wes Eddy=0A= MTI Systems=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 wes@mti-systems.com Sun Feb 24 19:00:56 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 76B8121F9197 for ; Sun, 24 Feb 2013 19:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, 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 HVqZL3m7DezJ for ; Sun, 24 Feb 2013 19:00:55 -0800 (PST) Received: from atl4mhob10.myregisteredsite.com (atl4mhob10.myregisteredsite.com [209.17.115.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2269F21F9195 for ; Sun, 24 Feb 2013 19:00:54 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob10.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r1P30rPt007408 for ; Sun, 24 Feb 2013 22:00:53 -0500 Received: (qmail 30634 invoked by uid 0); 25 Feb 2013 03:00:52 -0000 Received: from unknown (HELO ?192.168.1.145?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 25 Feb 2013 03:00:52 -0000 Message-ID: <512AD3D4.7000006@mti-systems.com> Date: Sun, 24 Feb 2013 22:00:36 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Knutsen, Andrew" References: <50ECC3EF.1020405@mti-systems.com> , <510B1D7B.1080704@mti-systems.com> <510B265E.6060003@mti-systems.com>, , <974FE049BD0F2E4188567FAD99DEF0331E801629@pwsvl-excmbx-04.internal.cacheflow.com> In-Reply-To: <974FE049BD0F2E4188567FAD99DEF0331E801629@pwsvl-excmbx-04.internal.cacheflow.com> Content-Type: multipart/mixed; boundary="------------040008080006010900080804" 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: Mon, 25 Feb 2013 03:00:56 -0000 This is a multi-part message in MIME format. --------------040008080006010900080804 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 2/23/2013 5:50 PM, Knutsen, Andrew wrote: > > What is the next step for this? I think we've reached consensus... Do we have an option to publish as more than a draft? > I was planning to AD-sponsor it. I sent a mail to this list on 1/31 (attached) that mentions Pasi Sarolahti had agreed to be the document shepherd. I was wondering if anyone representing the authors was going to be at the next IETF meeting (Orlando), just to give a quick update to TCPM and let them know that this has converged between the handful of companies cooperating on it. It's not strictly necessary, but I thought it would be helpful to avoid anyone being "surprised" by an IETF Last Call on it. -- Wes Eddy MTI Systems --------------040008080006010900080804 Content-Type: message/rfc822; name="Re [middisc] closure of the middisc list.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Re [middisc] closure of the middisc list.eml" X-Mozilla-Keys: 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)" CC: "Eggert, Lars" , Anantha Ramaiah , "middisc@ietf.org" , Martin Stiemerling Subject: Re: [middisc] closure of the middisc list References: <50ECC3EF.1020405@mti-systems.com> , In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 --------------040008080006010900080804-- From wes@mti-systems.com Sun Feb 24 19:03:56 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 7901121F9195 for ; Sun, 24 Feb 2013 19:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, 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 46Z1TJiRrAaa for ; Sun, 24 Feb 2013 19:03:56 -0800 (PST) Received: from atl4mhob05.myregisteredsite.com (atl4mhob05.myregisteredsite.com [209.17.115.43]) by ietfa.amsl.com (Postfix) with ESMTP id DCAC621F9174 for ; Sun, 24 Feb 2013 19:03:55 -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 r1P33tGF015253 for ; Sun, 24 Feb 2013 22:03:55 -0500 Received: (qmail 27738 invoked by uid 0); 25 Feb 2013 03:03:54 -0000 Received: from unknown (HELO ?192.168.1.145?) (wes@mti-systems.com@69.81.143.143) by 0 with ESMTPA; 25 Feb 2013 03:03:54 -0000 Message-ID: <512AD48A.5010104@mti-systems.com> Date: Sun, 24 Feb 2013 22:03:38 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Knutsen, Andrew" References: <50ECC3EF.1020405@mti-systems.com> , <510B1D7B.1080704@mti-systems.com> <510B265E.6060003@mti-systems.com>, , <974FE049BD0F2E4188567FAD99DEF0331E801629@pwsvl-excmbx-04.internal.cacheflow.com> In-Reply-To: <974FE049BD0F2E4188567FAD99DEF0331E801629@pwsvl-excmbx-04.internal.cacheflow.com> 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: Mon, 25 Feb 2013 03:03:56 -0000 On 2/23/2013 5:50 PM, Knutsen, Andrew wrote: > > What is the next step for this? I think we've reached consensus... Do we have an option to publish as more than a draft? > Just to clarify my last email, "AD-sponsoring" it is a way to get a Standards Track RFC without going through a Working Group, if you have a supportive AD. I think after my term is up next month, that Martin might be willing to finish the job. -- Wes Eddy MTI Systems From jamshid.mahdavi@bluecoat.com Sun Feb 24 19:23:28 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 3908D21F8FC5 for ; Sun, 24 Feb 2013 19:23:28 -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 nHjq4-fiZ5yF for ; Sun, 24 Feb 2013 19:23:27 -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 847E121F8FB2 for ; Sun, 24 Feb 2013 19:23:27 -0800 (PST) Received: from pwsvl-exchts-03.internal.cacheflow.com (pwsvl-exchts-03.bluecoat.com [10.2.2.160]) by plsvl-mailgw-01.bluecoat.com (Postfix) with ESMTP id 8195081A0A7; Sun, 24 Feb 2013 19:31:25 -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; Sun, 24 Feb 2013 19:23:25 -0800 From: "Mahdavi, Jamshid" To: Wesley Eddy , "Knutsen, Andrew" Thread-Topic: [middisc] closure of the middisc list Thread-Index: AQHN7gZoGzxDeTsZFk2tJjGzJZE5bJhAuhcAgAAOl4CAANHugIATAP2AgBBJNID//35GQIAAjFIAgABMBACAAM/egIAizzUAgAHYJAD//4AS0A== Date: Mon, 25 Feb 2013 03:23:23 +0000 Message-ID: References: <50ECC3EF.1020405@mti-systems.com> , <510B1D7B.1080704@mti-systems.com> <510B265E.6060003@mti-systems.com>, , <974FE049BD0F2E4188567FAD99DEF0331E801629@pwsvl-excmbx-04.internal.cacheflow.com> <512AD3D4.7000006@mti-systems.com> In-Reply-To: <512AD3D4.7000006@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: Mon, 25 Feb 2013 03:23:28 -0000 Andrew and I will not be there. --J -----Original Message----- From: Wesley Eddy [mailto:wes@mti-systems.com]=20 Sent: Sunday, February 24, 2013 7:01 PM To: Knutsen, Andrew Cc: Mani Ramasamy (mani); Mahdavi, Jamshid; middisc@ietf.org Subject: Re: [middisc] closure of the middisc list On 2/23/2013 5:50 PM, Knutsen, Andrew wrote: >=20 > What is the next step for this? I think we've reached consensus... D= o we have an option to publish as more than a draft? >=20 I was planning to AD-sponsor it. I sent a mail to this list on 1/31 (attached) that mentions Pasi Sarolahti = had agreed to be the document shepherd. I was wondering if anyone representing the authors was going to be at the n= ext IETF meeting (Orlando), just to give a quick update to TCPM and let the= m know that this has converged between the handful of companies cooperating= on it. It's not strictly necessary, but I thought it would be helpful to avoid any= one being "surprised" by an IETF Last Call on it. -- Wes Eddy MTI Systems From mani@cisco.com Sun Feb 24 22:07: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 817F321F913A for ; Sun, 24 Feb 2013 22:07: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 JxG37z5lAYju for ; Sun, 24 Feb 2013 22:07:18 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 663F421F9127 for ; Sun, 24 Feb 2013 22:07:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1359; q=dns/txt; s=iport; t=1361772438; x=1362982038; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=UzGYrcovDvfOCw9upFoDjn2bFG+2wPXSLA0RdMEZJhY=; b=SFZ1D1FTycqsbG7sCT7J1LpiH3cHopR4fNPho9HastqUb+ZO5PvAM141 tCLLqm09P0p2i47Ee1Y1ROWO/42Fm6JIL+qfwOa6JFN9YP48Mx3cqZZcj 6L1FOBDGf2BrIX6eCp1vdABfgbGEbM8AqbPjO/U2LMxV+h3g/YcJgJVoz E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAK7+KlGtJXHA/2dsb2JhbABFwVKBDRZzgh8BAQEEOj8MBAIBCBEEAQEBChQJBzIUCQgCBAENBQiIC705jU2BECYLBwaCWWEDpyKDB4FyNQ X-IronPort-AV: E=Sophos;i="4.84,732,1355097600"; d="scan'208";a="180704710" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 25 Feb 2013 06:07:18 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1P67HTv008690 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Feb 2013 06:07:17 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.23]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Mon, 25 Feb 2013 00:07:18 -0600 From: "Mani Ramasamy (mani)" To: "Mahdavi, Jamshid" , Wesley Eddy , "Knutsen, Andrew" Thread-Topic: [middisc] closure of the middisc list Thread-Index: AQHN7gZoJ3eDBtsU7E6OW7KrYI/u+phAmJAA//+o1tCAATevgIASnGjdgBCtyYCAAAT8gIAABZwA///m/3CAAM/9NYAjNBsAgAHYJACAAAZegP//yR3g Date: Mon, 25 Feb 2013 06:07:17 +0000 Message-ID: References: <50ECC3EF.1020405@mti-systems.com> , <510B1D7B.1080704@mti-systems.com> <510B265E.6060003@mti-systems.com>, , <974FE049BD0F2E4188567FAD99DEF0331E801629@pwsvl-excmbx-04.internal.cacheflow.com> <512AD3D4.7000006@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.21.100.171] 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: Mon, 25 Feb 2013 06:07:22 -0000 I will not be there as well.. Mani. -----Original Message----- From: Mahdavi, Jamshid [mailto:jamshid.mahdavi@bluecoat.com]=20 Sent: Sunday, February 24, 2013 7:23 PM To: Wesley Eddy; Knutsen, Andrew Cc: Mani Ramasamy (mani); middisc@ietf.org Subject: RE: [middisc] closure of the middisc list Andrew and I will not be there. --J -----Original Message----- From: Wesley Eddy [mailto:wes@mti-systems.com]=20 Sent: Sunday, February 24, 2013 7:01 PM To: Knutsen, Andrew Cc: Mani Ramasamy (mani); Mahdavi, Jamshid; middisc@ietf.org Subject: Re: [middisc] closure of the middisc list On 2/23/2013 5:50 PM, Knutsen, Andrew wrote: >=20 > What is the next step for this? I think we've reached consensus... D= o we have an option to publish as more than a draft? >=20 I was planning to AD-sponsor it. I sent a mail to this list on 1/31 (attached) that mentions Pasi Sarolahti = had agreed to be the document shepherd. I was wondering if anyone representing the authors was going to be at the n= ext IETF meeting (Orlando), just to give a quick update to TCPM and let the= m know that this has converged between the handful of companies cooperating= on it. It's not strictly necessary, but I thought it would be helpful to avoid any= one being "surprised" by an IETF Last Call on it. -- Wes Eddy MTI Systems From gdaley@au.logicalis.com Mon Feb 25 16:34: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 27C4E21E818F for ; Mon, 25 Feb 2013 16:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994] 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 mSkQbvVanO19 for ; Mon, 25 Feb 2013 16:34:58 -0800 (PST) Received: from smtp2.au.logicalis.com (smtp2.au.logicalis.com [203.8.7.133]) by ietfa.amsl.com (Postfix) with ESMTP id 60AD621E817A for ; Mon, 25 Feb 2013 16:34:58 -0800 (PST) Received-SPF: None (smtp2.au.logicalis.com: no sender authenticity information available from domain of gdaley@au.logicalis.com) identity=mailfrom; client-ip=203.8.7.161; receiver=smtp2.au.logicalis.com; envelope-from="gdaley@au.logicalis.com"; x-sender="gdaley@au.logicalis.com"; x-conformance=spf_only Received-SPF: None (smtp2.au.logicalis.com: no sender authenticity information available from domain of postmaster@sdcexchht.au.logicalis.com) identity=helo; client-ip=203.8.7.161; receiver=smtp2.au.logicalis.com; envelope-from="gdaley@au.logicalis.com"; x-sender="postmaster@sdcexchht.au.logicalis.com"; x-conformance=spf_only Received: from unknown (HELO sdcexchht.au.logicalis.com) ([203.8.7.161]) by smtp2.au.logicalis.com with ESMTP; 26 Feb 2013 11:34:57 +1100 Received: from SDCEXCHMS.au.logicalis.com ([10.18.196.50]) by sdcexchht.au.logicalis.com ([fe80::68b7:8880:fefb:f742%12]) with mapi id 14.02.0342.003; Tue, 26 Feb 2013 11:34:56 +1100 From: Greg Daley To: "'middisc@ietf.org'" Thread-Topic: Wan Optimization standardization problem statement/analysis? Thread-Index: Ac4TuQYO4eE8uC6sRoqt1ktiiKZ70Q== Date: Tue, 26 Feb 2013 00:34:55 +0000 Message-ID: <72381AF1F18BAE4F890A0813768D9928FCBE5B@sdcexchms.au.logicalis.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.196.182] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 25 Feb 2013 18:29:25 -0800 Subject: [middisc] Wan Optimization standardization problem statement/analysis? 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, 26 Feb 2013 00:34:59 -0000 Dear Middisc list,=20 Thanks for your work on the Middlebox Negotiation Option draft. I understand that this list and the draft are not focussed upon standardiza= tion of intercompatibility between Middleboxes, but I see it as a positive = first step. Working within the System Integration space, we are seeing significant impa= ct upon customers due to incompatibilities between WAN optimization systems= , particularly.=20 Our company resells platforms from two Wanopt vendors, and several of our l= ong term customers have deployments from further vendors. We are seeing increased operational expenses for customers from managing in= compatible systems, and difficulties in managing mergers of networks with d= ifferent heritages. Has anyone undertaken a review within the IETF of the general problem and s= cope of standardized WAN optimization? Are there any organizations other than under IETF guise where this work is = being done? I understand that there are several legal issues associated with the work, = and that some of this is before the courts. =20 Please let me know if you are interested in furthering this work, and if yo= u would be except for current legal circumstances. Sincerely, Greg Daley =A0 =A0 From ananth@nttmcl.com Mon Feb 25 23:12: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 20AA421F9652 for ; Mon, 25 Feb 2013 23:12:03 -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 xmCvkyF7I3lc for ; Mon, 25 Feb 2013 23:12:02 -0800 (PST) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 08EC021F95DA for ; Mon, 25 Feb 2013 23:12:01 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id t11so3276243wey.0 for ; Mon, 25 Feb 2013 23:12:01 -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=Oavj3n1SivVUFKJbIAlbFUUistFoUYymyfnb4LHT4J8=; b=fQ91Ih+sCdmsUDee7NeXb/eApit8iK0af69ACQCKZTfSO5yCCYz+bzJ8iKS005Djs2 IKv1OunWdVlaGzgDm0F1hajivtK3QcdPjM1BJhTdbsZ0irW9znZXG717b4ThfdbOLhs5 SYfnZ5avnurAjYvltC1Pnz1faHJtoZLgMs8znEhmbLNlpwkqWABqqyeAtyrHAP35s3pf hqal1Ek3fFl/slSkQ+Va4q+aTJ8MBP2VO8IesuBtslIZH8UgnVxXmMtuddU86DP5WzEZ FHMsgGBV19pK5R+P9XWVxt6+UpZBbK6gclcJp5zCVPw6bItQx8G/+b0WkJL3H7gVFUHG GsNQ== MIME-Version: 1.0 X-Received: by 10.180.8.4 with SMTP id n4mr17049382wia.13.1361862720445; Mon, 25 Feb 2013 23:12:00 -0800 (PST) Received: by 10.194.221.228 with HTTP; Mon, 25 Feb 2013 23:12:00 -0800 (PST) In-Reply-To: <72381AF1F18BAE4F890A0813768D9928FCBE5B@sdcexchms.au.logicalis.com> References: <72381AF1F18BAE4F890A0813768D9928FCBE5B@sdcexchms.au.logicalis.com> Date: Mon, 25 Feb 2013 23:12:00 -0800 Message-ID: From: Anantha Ramaiah To: Greg Daley Content-Type: multipart/alternative; boundary=f46d04428f18b476a304d69b5f71 X-Gm-Message-State: ALoCoQmYo3Wqb54dv7IY/Y5wdS6GyAFCGjBzgPvxxHvh1EJtEIgoIc/8+tpfTbInRKuBkC1kijgP Cc: "middisc@ietf.org" Subject: Re: [middisc] Wan Optimization standardization problem statement/analysis? 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, 26 Feb 2013 07:12:03 -0000 --f46d04428f18b476a304d69b5f71 Content-Type: text/plain; charset=ISO-8859-1 Greg, I no longer work with the same company when I initially participated during writing this draft and hence these are just my personal opinions. Comments inline :- On Mon, Feb 25, 2013 at 4:34 PM, Greg Daley wrote: > Dear Middisc list, > > > Thanks for your work on the Middlebox Negotiation Option draft. > > I understand that this list and the draft are not focussed upon > standardization of intercompatibility between Middleboxes, but I see it as > a positive first step. > Yes, I think so too. > > > Working within the System Integration space, we are seeing significant > impact upon customers due to incompatibilities between WAN optimization > systems, particularly. > Our company resells platforms from two Wanopt vendors, and several of our > long term customers have deployments from further vendors. > > We are seeing increased operational expenses for customers from managing > incompatible systems, and difficulties in managing mergers of networks with > different heritages. Doesn't come as a surprise esp., since the solutions are incompatible. > > > Has anyone undertaken a review within the IETF of the general problem and > scope of standardized WAN optimization? > Not that I am aware of. > > Are there any organizations other than under IETF guise where this work is > being done? > I don't think so. > > > I understand that there are several legal issues associated with the work, > and that some of this is before the courts. > Well, you probably hit the nail on the head. I guess, even though there are technical benefits of standardizing the protocol, lets take the case in point : auto-discovery. Firstly the legal issues needs to be sorted out and enough interest needs to be there to standardize this aspect, then running code needs to be updated, or at least the companies should be willing to accept this fact an have this factored in their development plans. > > Please let me know if you are interested in furthering this work, and if > you would be except for current legal circumstances. > Well, I may be able to provide some review/comments if there happens to be some consensus among the leading vendors to undertake this project, but in any case cannot take any active role here since this work item is of no direct benefit to my current employer. thanks, -Anantha > > Sincerely, > > Greg Daley > > > > > > > > _______________________________________________ > middisc mailing list > middisc@ietf.org > https://www.ietf.org/mailman/listinfo/middisc > --f46d04428f18b476a304d69b5f71 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Greg,

I no longer work with the same company when = I initially participated during writing this draft and hence these are just= my personal opinions. Comments inline :-=A0

On Mon, Feb 25, 2013 at 4:34 PM, Greg Daley <gdaley@au.logicalis.c= om> wrote:
Dear Middisc list,


Thanks for your work on the Middlebox Negotiation Option draft.

I understand that this list and the draft are not focussed upon standardiza= tion of intercompatibility between Middleboxes, but I see it as a positive = first step.

Yes, I think so too.
=A0


Working within the System Integration space, we are seeing significant impa= ct upon customers due to incompatibilities between WAN optimization systems= , particularly.
Our company resells platforms from two Wanopt vendors, and several of our l= ong term customers have deployments from further vendors.

We are seeing increased operational expenses for customers from managing in= compatible systems, and difficulties in managing mergers of networks with d= ifferent heritages.

Doesn't =A0come as = a surprise esp., since the solutions are incompatible.
=A0
=A0


Has anyone undertaken a review within the IETF of the general problem and s= cope of standardized WAN optimization?

= Not that I am aware of.
=A0

Are there any organizations other than under IETF guise where this work is = being done?

I don't think so.
=
=A0


I understand that there are several legal issues associated with the work, = and that some of this is before the courts.

=
Well, you probably hit the nail on the head. =A0I guess, even though t= here are technical benefits of standardizing the protocol, lets take the ca= se in point : auto-discovery. =A0Firstly the legal issues needs to be sorte= d out and enough interest needs to be there to standardize this aspect, the= n running code needs to be updated, or at least the companies should be wil= ling to accept this fact an have this factored in their development plans. = =A0=A0

Please let me know if you are interested in furthering this work, and if yo= u would be except for current legal circumstances.
Well, I may be able to provide some review/comments if there ha= ppens to be some consensus among the leading vendors to undertake this proj= ect, but in any case cannot take any active role here since this work item = is of no direct benefit to my current employer.=A0

thanks,
-Anantha
=A0

Sincerely,

Greg Daley
=A0


=A0



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

--f46d04428f18b476a304d69b5f71-- From jamshid.mahdavi@bluecoat.com Tue Feb 26 07:52:50 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 1105221F8899 for ; Tue, 26 Feb 2013 07:52:50 -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 n9qzoVdSlGPD for ; Tue, 26 Feb 2013 07:52:48 -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 832D821F8890 for ; Tue, 26 Feb 2013 07:52:47 -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 096E781A0A7; Tue, 26 Feb 2013 06:52:47 -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; Tue, 26 Feb 2013 07:52:46 -0800 From: "Mahdavi, Jamshid" To: Greg Daley , "'middisc@ietf.org'" Thread-Topic: [middisc] Wan Optimization standardization problem statement/analysis? Thread-Index: Ac4TuQYO4eE8uC6sRoqt1ktiiKZ70QAHChDA Date: Tue, 26 Feb 2013 15:52:37 +0000 Message-ID: References: <72381AF1F18BAE4F890A0813768D9928FCBE5B@sdcexchms.au.logicalis.com> In-Reply-To: <72381AF1F18BAE4F890A0813768D9928FCBE5B@sdcexchms.au.logicalis.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [middisc] Wan Optimization standardization problem statement/analysis? 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, 26 Feb 2013 15:52:50 -0000 I'd definitely be in favor of seeing standard solutions, as they would be b= etter for customers for exactly the reasons you describe. I'm happy to see= your suggestion! If I might be so bold as to offer an opinion about how such an effort might= fit into the IETF framework, there are typically two distinct parts to a W= AN Op solution: 1. A tunneling protocol in which to carry optimized traffic between symmet= ric WAN Op devices. This portion also requires application level routing c= omponent, which can be explicitly set up, or done implicitly via a discover= y technique such as we have covered in this draft. =20 In the original version of this draft, we did include an explicitly reserve= d portion of the ID space for standard protocols, and another for vendor-sp= ecific discovery protocols. At the time there did not seem to be an appeti= te for a standardized solution, so that does not appear in the current draf= t. We didn't actually suggest any standard solution, just allowed some space f= or it. And, is still easily done within the current draft by having the IE= TF claim an ID when such a standardization effort took place. The tunneling protocol includes a lot more than just discovery -- it may en= compass many of the same elements as TCP itself and may also encompass encr= yption -- and all of that would also need to be standardized. When Andrew = and I came down to Anaheim two years ago to start this, I attended the "mpt= cp" working group and remember being struck that there were a lot of simila= rities between that work and the types of tunneling protocols needed for WA= N Op. I haven't tracked how it has proceeded since then, though. I'd see all of the above elements as fitting within TSV area. 2. A compression / optimization protocol, or a series of them, which may b= e application specific. For most of the vendors this is probably where the= re is a lot of "secret sauce" and it would be hard to see practically how o= ne might move forward with standardization. However, there are a number of= published protocols which could form the basis for such a standard and pro= vide some basic cross-vendor interoperability -- perhaps not with the full = benefits of a single-vendor solution, but still valuable. I'd see such work as needing to proceed within the APP area. All told, I think this would be a heavy lift to get done, but valuable if i= t could be. I don't know of any other organization that would make more se= nse for this than IETF. However, one challenge with the IETF is that there= is a certain reluctance to standardize (or "bless" if you will) some of th= e things we need to do as middleboxes to make these type of solutions possi= ble. I think that more pull from customers, and people like you who can speak on= behalf of customers, would help work like this to gain traction. --J -----Original Message----- From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On Behalf = Of Greg Daley Sent: Monday, February 25, 2013 4:35 PM To: 'middisc@ietf.org' Subject: [middisc] Wan Optimization standardization problem statement/analy= sis? Dear Middisc list,=20 Thanks for your work on the Middlebox Negotiation Option draft. I understand that this list and the draft are not focussed upon standardiza= tion of intercompatibility between Middleboxes, but I see it as a positive = first step. Working within the System Integration space, we are seeing significant impa= ct upon customers due to incompatibilities between WAN optimization systems= , particularly.=20 Our company resells platforms from two Wanopt vendors, and several of our l= ong term customers have deployments from further vendors. We are seeing increased operational expenses for customers from managing in= compatible systems, and difficulties in managing mergers of networks with d= ifferent heritages. Has anyone undertaken a review within the IETF of the general problem and s= cope of standardized WAN optimization? Are there any organizations other than under IETF guise where this work is = being done? I understand that there are several legal issues associated with the work, = and that some of this is before the courts. =20 Please let me know if you are interested in furthering this work, and if yo= u would be except for current legal circumstances. Sincerely, Greg Daley =A0 =A0 _______________________________________________ middisc mailing list middisc@ietf.org https://www.ietf.org/mailman/listinfo/middisc From andrew.knutsen@bluecoat.com Tue Feb 26 09:57:48 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 8993D21F883A for ; Tue, 26 Feb 2013 09:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 JYB-jrUV2rP6 for ; Tue, 26 Feb 2013 09:57: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 D354021F8833 for ; Tue, 26 Feb 2013 09:57:47 -0800 (PST) Received: from PWSVL-EXCHTS-01.internal.cacheflow.com (unknown [10.2.2.122]) by plsvl-mailgw-01.bluecoat.com (Postfix) with ESMTP id 29CCE81A060; Tue, 26 Feb 2013 08:57:47 -0900 (AKST) Received: from PWSVL-EXCMBX-04.internal.cacheflow.com ([fe80::c596:c77:dd67:b72d]) by PWSVL-EXCHTS-01.internal.cacheflow.com ([fe80::5c50:e2ba:8115:4223%20]) with mapi id 14.01.0289.001; Tue, 26 Feb 2013 09:57:46 -0800 From: "Knutsen, Andrew" To: "Mahdavi, Jamshid" , Greg Daley , "'middisc@ietf.org'" Thread-Topic: [middisc] Wan Optimization standardization problem statement/analysis? Thread-Index: AQHOFDloqdVkinXPL0agLzN+95TJrZiMawbi Date: Tue, 26 Feb 2013 17:57:44 +0000 Message-ID: <974FE049BD0F2E4188567FAD99DEF0331E801F24@pwsvl-excmbx-04.internal.cacheflow.com> References: <72381AF1F18BAE4F890A0813768D9928FCBE5B@sdcexchms.au.logicalis.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 Subject: Re: [middisc] Wan Optimization standardization problem statement/analysis? 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, 26 Feb 2013 17:57:48 -0000 =0A= Well put... I'll just reiterate that the more people who support this s= ort of technology within the IETF, the closer it will come to representing = the needs of the users (and thus staying relevant). While I do have respec= t for the purist end-to-end model, we've found that it can be taken too far= .=0A= =0A= Andrew=0A= =0A= ________________________________________=0A= From: middisc-bounces@ietf.org [middisc-bounces@ietf.org] on behalf of Mahd= avi, Jamshid=0A= Sent: Tuesday, February 26, 2013 7:52 AM=0A= To: Greg Daley; 'middisc@ietf.org'=0A= Subject: Re: [middisc] Wan Optimization standardization problem statement/a= nalysis?=0A= =0A= I'd definitely be in favor of seeing standard solutions, as they would be b= etter for customers for exactly the reasons you describe. I'm happy to see= your suggestion!=0A= =0A= If I might be so bold as to offer an opinion about how such an effort might= fit into the IETF framework, there are typically two distinct parts to a W= AN Op solution:=0A= =0A= 1. A tunneling protocol in which to carry optimized traffic between symmet= ric WAN Op devices. This portion also requires application level routing c= omponent, which can be explicitly set up, or done implicitly via a discover= y technique such as we have covered in this draft.=0A= =0A= In the original version of this draft, we did include an explicitly reserve= d portion of the ID space for standard protocols, and another for vendor-sp= ecific discovery protocols. At the time there did not seem to be an appeti= te for a standardized solution, so that does not appear in the current draf= t.=0A= =0A= We didn't actually suggest any standard solution, just allowed some space f= or it. And, is still easily done within the current draft by having the IE= TF claim an ID when such a standardization effort took place.=0A= =0A= The tunneling protocol includes a lot more than just discovery -- it may en= compass many of the same elements as TCP itself and may also encompass encr= yption -- and all of that would also need to be standardized. When Andrew = and I came down to Anaheim two years ago to start this, I attended the "mpt= cp" working group and remember being struck that there were a lot of simila= rities between that work and the types of tunneling protocols needed for WA= N Op. I haven't tracked how it has proceeded since then, though.=0A= =0A= I'd see all of the above elements as fitting within TSV area.=0A= =0A= 2. A compression / optimization protocol, or a series of them, which may b= e application specific. For most of the vendors this is probably where the= re is a lot of "secret sauce" and it would be hard to see practically how o= ne might move forward with standardization. However, there are a number of= published protocols which could form the basis for such a standard and pro= vide some basic cross-vendor interoperability -- perhaps not with the full = benefits of a single-vendor solution, but still valuable.=0A= =0A= I'd see such work as needing to proceed within the APP area.=0A= =0A= All told, I think this would be a heavy lift to get done, but valuable if i= t could be. I don't know of any other organization that would make more se= nse for this than IETF. However, one challenge with the IETF is that there= is a certain reluctance to standardize (or "bless" if you will) some of th= e things we need to do as middleboxes to make these type of solutions possi= ble.=0A= =0A= I think that more pull from customers, and people like you who can speak on= behalf of customers, would help work like this to gain traction.=0A= =0A= --J=0A= =0A= -----Original Message-----=0A= From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On Behalf = Of Greg Daley=0A= Sent: Monday, February 25, 2013 4:35 PM=0A= To: 'middisc@ietf.org'=0A= Subject: [middisc] Wan Optimization standardization problem statement/analy= sis?=0A= =0A= Dear Middisc list,=0A= =0A= =0A= Thanks for your work on the Middlebox Negotiation Option draft.=0A= =0A= I understand that this list and the draft are not focussed upon standardiza= tion of intercompatibility between Middleboxes, but I see it as a positive = first step.=0A= =0A= =0A= Working within the System Integration space, we are seeing significant impa= ct upon customers due to incompatibilities between WAN optimization systems= , particularly.=0A= Our company resells platforms from two Wanopt vendors, and several of our l= ong term customers have deployments from further vendors.=0A= =0A= We are seeing increased operational expenses for customers from managing in= compatible systems, and difficulties in managing mergers of networks with d= ifferent heritages.=0A= =0A= =0A= Has anyone undertaken a review within the IETF of the general problem and s= cope of standardized WAN optimization?=0A= =0A= Are there any organizations other than under IETF guise where this work is = being done?=0A= =0A= =0A= I understand that there are several legal issues associated with the work, = and that some of this is before the courts.=0A= =0A= Please let me know if you are interested in furthering this work, and if yo= u would be except for current legal circumstances.=0A= =0A= Sincerely,=0A= =0A= Greg Daley=0A= =0A= =0A= =0A= =0A= =0A= =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 gdaley@au.logicalis.com Tue Feb 26 15:05:42 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 1694C21F86E3 for ; Tue, 26 Feb 2013 15:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994] 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 v1J-UVEjMyfo for ; Tue, 26 Feb 2013 15:05:41 -0800 (PST) Received: from smtp2.au.logicalis.com (smtp2.au.logicalis.com [203.8.7.133]) by ietfa.amsl.com (Postfix) with ESMTP id B272421F8654 for ; Tue, 26 Feb 2013 15:05:40 -0800 (PST) Received-SPF: None (smtp2.au.logicalis.com: no sender authenticity information available from domain of gdaley@au.logicalis.com) identity=mailfrom; client-ip=203.8.7.161; receiver=smtp2.au.logicalis.com; envelope-from="gdaley@au.logicalis.com"; x-sender="gdaley@au.logicalis.com"; x-conformance=spf_only Received-SPF: None (smtp2.au.logicalis.com: no sender authenticity information available from domain of postmaster@sdcexchht.au.logicalis.com) identity=helo; client-ip=203.8.7.161; receiver=smtp2.au.logicalis.com; envelope-from="gdaley@au.logicalis.com"; x-sender="postmaster@sdcexchht.au.logicalis.com"; x-conformance=spf_only Received: from unknown (HELO sdcexchht.au.logicalis.com) ([203.8.7.161]) by smtp2.au.logicalis.com with ESMTP; 27 Feb 2013 10:05:39 +1100 Received: from SDCEXCHMS.au.logicalis.com ([10.18.196.50]) by sdcexchht.au.logicalis.com ([fe80::68b7:8880:fefb:f742%12]) with mapi id 14.02.0342.003; Wed, 27 Feb 2013 10:05:39 +1100 From: Greg Daley To: "'Knutsen, Andrew'" , "Mahdavi, Jamshid" , "'middisc@ietf.org'" Thread-Topic: [middisc] Wan Optimization standardization problem statement/analysis? Thread-Index: AQHOFErSndpMQHlrSUuvkpmczTr6AJiMtgIQ Date: Tue, 26 Feb 2013 23:05:37 +0000 Message-ID: <72381AF1F18BAE4F890A0813768D9928FCD51F@sdcexchms.au.logicalis.com> References: <72381AF1F18BAE4F890A0813768D9928FCBE5B@sdcexchms.au.logicalis.com>, <974FE049BD0F2E4188567FAD99DEF0331E801F24@pwsvl-excmbx-04.internal.cacheflow.com> In-Reply-To: <974FE049BD0F2E4188567FAD99DEF0331E801F24@pwsvl-excmbx-04.internal.cacheflow.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.196.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [middisc] Wan Optimization standardization problem statement/analysis? 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, 26 Feb 2013 23:05:42 -0000 Hi,=20 Thanks for your responses. I agree that there is a lot of deployed technology, which vendors have been= deploying to gain optimizations. I'm thinking that cataloguing existing deployed approaches could be one par= t of the a Problem Statement. =20 Given the variety of approaches applied in even one vendors solution (Tunne= ls, TCP optimization, Compression/Dedup, Application specific optimizations= ), it may still be that any future solution doesn't bite off all of these a= t once. I agree that there will be a lot of interaction between TSV and APP. For l= atter versions of the problem statement, we may need to work in specific co= ncerns from these areas. My focus is currently getting a discussion level= document out in the near future.=20 With respect to the end-to-end model, we can explicitly address differences= in the deployments from transparent/pure environments to middlebox arbitra= ted ones. =20 I'd guess it's explicit goal of the WAN accelerators to present identical a= pplication data though, and present behaviour compatible with existing edge= device TCP/IP stacks.=20 Personally, I will not be at IETF, but will start working on a draft for wh= en the submissions open up again. I'm interested in input if people have hallway conversations during the mee= ting. Sincerely,=20 Greg -----Original Message----- From: Knutsen, Andrew [mailto:andrew.knutsen@bluecoat.com]=20 Sent: Wednesday, 27 February 2013 4:58 AM To: Mahdavi, Jamshid; Greg Daley; 'middisc@ietf.org' Subject: RE: [middisc] Wan Optimization standardization problem statement/a= nalysis? Well put... I'll just reiterate that the more people who support this s= ort of technology within the IETF, the closer it will come to representing = the needs of the users (and thus staying relevant). While I do have respec= t for the purist end-to-end model, we've found that it can be taken too far= . Andrew ________________________________________ From: middisc-bounces@ietf.org [middisc-bounces@ietf.org] on behalf of Mahd= avi, Jamshid Sent: Tuesday, February 26, 2013 7:52 AM To: Greg Daley; 'middisc@ietf.org' Subject: Re: [middisc] Wan Optimization standardization problem statement/a= nalysis? I'd definitely be in favor of seeing standard solutions, as they would be b= etter for customers for exactly the reasons you describe. I'm happy to see= your suggestion! If I might be so bold as to offer an opinion about how such an effort might= fit into the IETF framework, there are typically two distinct parts to a W= AN Op solution: 1. A tunneling protocol in which to carry optimized traffic between symmet= ric WAN Op devices. This portion also requires application level routing c= omponent, which can be explicitly set up, or done implicitly via a discover= y technique such as we have covered in this draft. In the original version of this draft, we did include an explicitly reserve= d portion of the ID space for standard protocols, and another for vendor-sp= ecific discovery protocols. At the time there did not seem to be an appeti= te for a standardized solution, so that does not appear in the current draf= t. We didn't actually suggest any standard solution, just allowed some space f= or it. And, is still easily done within the current draft by having the IE= TF claim an ID when such a standardization effort took place. The tunneling protocol includes a lot more than just discovery -- it may en= compass many of the same elements as TCP itself and may also encompass encr= yption -- and all of that would also need to be standardized. When Andrew = and I came down to Anaheim two years ago to start this, I attended the "mpt= cp" working group and remember being struck that there were a lot of simila= rities between that work and the types of tunneling protocols needed for WA= N Op. I haven't tracked how it has proceeded since then, though. I'd see all of the above elements as fitting within TSV area. 2. A compression / optimization protocol, or a series of them, which may b= e application specific. For most of the vendors this is probably where the= re is a lot of "secret sauce" and it would be hard to see practically how o= ne might move forward with standardization. However, there are a number of= published protocols which could form the basis for such a standard and pro= vide some basic cross-vendor interoperability -- perhaps not with the full = benefits of a single-vendor solution, but still valuable. I'd see such work as needing to proceed within the APP area. All told, I think this would be a heavy lift to get done, but valuable if i= t could be. I don't know of any other organization that would make more se= nse for this than IETF. However, one challenge with the IETF is that there= is a certain reluctance to standardize (or "bless" if you will) some of th= e things we need to do as middleboxes to make these type of solutions possi= ble. I think that more pull from customers, and people like you who can speak on= behalf of customers, would help work like this to gain traction. --J -----Original Message----- From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On Behalf = Of Greg Daley Sent: Monday, February 25, 2013 4:35 PM To: 'middisc@ietf.org' Subject: [middisc] Wan Optimization standardization problem statement/analy= sis? Dear Middisc list, Thanks for your work on the Middlebox Negotiation Option draft. I understand that this list and the draft are not focussed upon standardiza= tion of intercompatibility between Middleboxes, but I see it as a positive = first step. Working within the System Integration space, we are seeing significant impa= ct upon customers due to incompatibilities between WAN optimization systems= , particularly. Our company resells platforms from two Wanopt vendors, and several of our l= ong term customers have deployments from further vendors. We are seeing increased operational expenses for customers from managing in= compatible systems, and difficulties in managing mergers of networks with d= ifferent heritages. Has anyone undertaken a review within the IETF of the general problem and s= cope of standardized WAN optimization? Are there any organizations other than under IETF guise where this work is = being done? I understand that there are several legal issues associated with the work, = and that some of this is before the courts. Please let me know if you are interested in furthering this work, and if yo= u would be except for current legal circumstances. Sincerely, Greg Daley _______________________________________________ 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