Re: [middisc] middisc specification update

Wesley Eddy <wes@mti-systems.com> Tue, 13 March 2012 16:25 UTC

Return-Path: <wes@mti-systems.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 96C4B21E803D for <middisc@ietfa.amsl.com>; Tue, 13 Mar 2012 09:25:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pou3oSSJfOQy for <middisc@ietfa.amsl.com>; Tue, 13 Mar 2012 09:24:37 -0700 (PDT)
Received: from omr16.networksolutionsemail.com (omr16.networksolutionsemail.com [205.178.146.66]) by ietfa.amsl.com (Postfix) with ESMTP id 69C8621E8034 for <middisc@ietf.org>; Tue, 13 Mar 2012 09:24:34 -0700 (PDT)
Received: from cm-omr12 (mail.networksolutionsemail.com [205.178.146.50]) by omr16.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q2DGOWHg022362 for <middisc@ietf.org>; Tue, 13 Mar 2012 12:24:32 -0400
Authentication-Results: cm-omr12 smtp.user=wes@mti-systems.com; auth=pass (PLAIN)
X-Authenticated-UID: wes@mti-systems.com
Received: from [107.50.175.168] ([107.50.175.168:43530] helo=[192.168.43.65]) by cm-omr12 (envelope-from <wes@mti-systems.com>) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 7B/BC-16767-EB47F5F4; Tue, 13 Mar 2012 12:24:32 -0400
Message-ID: <4F5F74BB.2020306@mti-systems.com>
Date: Tue, 13 Mar 2012 12:24:27 -0400
From: Wesley Eddy <wes@mti-systems.com>
Organization: MTI Systems
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
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>
In-Reply-To: <0C53DCFB700D144284A584F54711EC580EA21B77@xmb-sjc-21c.amer.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: middisc@ietf.org
Subject: Re: [middisc] middisc specification update
X-BeenThere: middisc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussions on TCP option for middlebox discovery." <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 16:25:04 -0000

On 3/5/2012 2:44 PM, Anantha Ramaiah (ananth) wrote:
> 
> Right, from vendors pov, experimental may sound fine. But from IETF
> standards pov, this sort of an effort is aimed at reducing unauthorized
> TCP option poaching and if such a draft exists it would both act as a
> recommendation and for vendors to not use unauthorized options. In such
> cases would experimental convey the "strong" message. May be some text
> needs to be added to the draft echoing what you alluded above...


I have a real problem with Standards Track, given that the middlebox
association seemed to introduce a combination of distaste and
eventual disinterest in TCPM.  Also, based on the slow progress in
getting this specification done, I have some doubt that it will
quickly be integrated into products and deployed.  I think that given
the options we have, Experimental is a reasonable fit, and if it does
wind up in wide use by multiple vendors, we can look at advancing it.


> I am not sure these things are spelled out clearly in the draft, but the
> message is spread across and may be if there is a need for making it
> more clear, please let us know.


I would like it to be very clear.


> Also if the status is experimental, I am assuming that we would still
> get a regular TCP option code point and not the TCP experimental option
> code point. I am assuming when you said experiment above it is more on
> the lines of multiple vendors dis-continuing and using the standard TCP
> option number that is allocated for this purpose.


With IESG approval, a regular option can be allocated, regardless of
whether the document status is Experimental.

-- 
Wes Eddy
MTI Systems