Re: [middisc] middisc specification update

"Anantha Ramaiah (ananth)" <ananth@cisco.com> Tue, 13 March 2012 17:16 UTC

Return-Path: <ananth@cisco.com>
X-Original-To: middisc@ietfa.amsl.com
Delivered-To: middisc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF55121E8045 for <middisc@ietfa.amsl.com>; Tue, 13 Mar 2012 10:16:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vdkkk8ZQfKi2 for <middisc@ietfa.amsl.com>; Tue, 13 Mar 2012 10:16:18 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6556C21E8043 for <middisc@ietf.org>; Tue, 13 Mar 2012 10:16:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ananth@cisco.com; l=3049; q=dns/txt; s=iport; t=1331658978; x=1332868578; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=AEZwAVIWvsqnKkZkWsXvfb3e+rglRMNpIulJWPIO8wY=; b=kAKj6PaE6w2ToSUGHED6IhK4TIVS38M1ZMG1INvMZTYqCKwsITEkje+g YrWg6ISlifdwIpBxYAKjJR7GfYFmTVxTqLs0c/OEc8u807sDQFPX6DB48 Xo1z+w9C1hsjlrdFrv2Jw88onbq6+gfiXrcWFxfkM/s0WUld7k0Q1merx U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAPB/X0+rRDoG/2dsb2JhbABDtWSBB4IJAQEBBBIBHQo/DAQCAQgOAwQBAQEKBhcBBgFFCQgBAQQTCBqHZwGdMgGfE5ACYwSIVZ0egwWBPA
X-IronPort-AV: E=Sophos;i="4.73,577,1325462400"; d="scan'208";a="35940184"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 13 Mar 2012 17:16:18 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2DHGHwM001845; Tue, 13 Mar 2012 17:16:17 GMT
Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Mar 2012 10:16:18 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 13 Mar 2012 10:16:16 -0700
Message-ID: <1F8E0A684D3FF54680294BCFE57A7DB504A5B564@xmb-sjc-23e.amer.cisco.com>
In-Reply-To: <4F5F74BB.2020306@mti-systems.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [middisc] middisc specification update
Thread-Index: Ac0BNccSFIAmoasxRQCi5mfk9Az5LgABbtCg
References: <4E9241F7.5090406@mti-systems.com><2AE215BDC76842F885AC7E9D34BD2CA4@davidPC><0C53DCFB700D144284A584F54711EC580E546254@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EA21847@xmb-sjc-21c.amer.cisco.com> <C304DB494AC0C04C87C6A6E2FF5603DB5ACE4EFBB5@NDJSSCC01.ndc.nasa.gov> <0C53DCFB700D144284A584F54711EC580EA21B2D@xmb-sjc-21c.amer.cisco.com> <C304DB494AC0C04C87C6A6E2FF5603DB5ACE4EFC02@NDJSSCC01.ndc.nasa.gov> <0C53DCFB700D144284A584F54711EC580EA21B77@xmb-sjc-21c.amer.cisco.com> <4F5F74BB.2020306@mti-systems.com>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: Wesley Eddy <wes@mti-systems.com>
X-OriginalArrivalTime: 13 Mar 2012 17:16:18.0126 (UTC) FILETIME=[00C696E0:01CD013D]
Cc: middisc@ietf.org
Subject: Re: [middisc] middisc specification update
X-BeenThere: middisc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussions on TCP option for middlebox discovery." <middisc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/middisc>, <mailto:middisc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/middisc>
List-Post: <mailto:middisc@ietf.org>
List-Help: <mailto:middisc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/middisc>, <mailto:middisc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Mar 2012 17:16:19 -0000

Hi Wes,
    Ok, I am on page with the process now and I am fine with the status
being experimental ( I guess it should be ok with others as well). So,
the next steps are I guess is to revise the draft with the comments
received so far, put the intended status to "experimental" and re-submit
it. I guess the IETF submission re-opens after IETF meeting, so I'll
have some time to do this. I'll be coming to IETF this time and we can
chat sometime when you are free.

   Just to add (in response to your concern below): From the various
email discussions there is a lot of interest among multiple vendors
(Bluecoat, Riverbed and Cisco) to move towards the new TCP option when
it gets allocated, but the obvious challenge is going to be backwards
compatibility and eventual EOL of boxes doing the unassigned options. It
will take time for sure but it should eventually happen I guess.

-Anantha

> -----Original Message-----
> From: Wesley Eddy [mailto:wes@mti-systems.com]
> Sent: Tuesday, March 13, 2012 9:24 AM
> To: Anantha Ramaiah (ananth)
> Cc: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]; David Harrington;
> middisc@ietf.org
> Subject: Re: [middisc] middisc specification update
> 
> On 3/5/2012 2:44 PM, Anantha Ramaiah (ananth) wrote:
> >
> > Right, from vendors pov, experimental may sound fine. But from IETF
> > standards pov, this sort of an effort is aimed at reducing
> unauthorized
> > TCP option poaching and if such a draft exists it would both act as
a
> > recommendation and for vendors to not use unauthorized options. In
> such
> > cases would experimental convey the "strong" message. May be some
> text
> > needs to be added to the draft echoing what you alluded above...
> 
> 
> I have a real problem with Standards Track, given that the middlebox
> association seemed to introduce a combination of distaste and
> eventual disinterest in TCPM.  Also, based on the slow progress in
> getting this specification done, I have some doubt that it will
> quickly be integrated into products and deployed.  I think that given
> the options we have, Experimental is a reasonable fit, and if it does
> wind up in wide use by multiple vendors, we can look at advancing it.
> 
> 
> > I am not sure these things are spelled out clearly in the draft, but
> the
> > message is spread across and may be if there is a need for making it
> > more clear, please let us know.
> 
> 
> I would like it to be very clear.
> 
> 
> > Also if the status is experimental, I am assuming that we would
still
> > get a regular TCP option code point and not the TCP experimental
> option
> > code point. I am assuming when you said experiment above it is more
> on
> > the lines of multiple vendors dis-continuing and using the standard
> TCP
> > option number that is allocated for this purpose.
> 
> 
> With IESG approval, a regular option can be allocated, regardless of
> whether the document status is Experimental.
> 
> --
> Wes Eddy
> MTI Systems