Re: [middisc] middisc specification update

"Eggert, Lars" <lars@netapp.com> Mon, 05 March 2012 09:32 UTC

Return-Path: <lars@netapp.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 A818221F8725 for <middisc@ietfa.amsl.com>; Mon, 5 Mar 2012 01:32:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.079
X-Spam-Level:
X-Spam-Status: No, score=-10.079 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ndsm8YCYQ-3q for <middisc@ietfa.amsl.com>; Mon, 5 Mar 2012 01:32:44 -0800 (PST)
Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9C11721F8704 for <middisc@ietf.org>; Mon, 5 Mar 2012 01:32:41 -0800 (PST)
X-IronPort-AV: E=Sophos; i="4.73,533,1325491200"; d="p7s'?scan'208"; a="630708727"
Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 05 Mar 2012 01:32:26 -0800
Received: from vmwexceht05-prd.hq.netapp.com (vmwexceht05-prd.hq.netapp.com [10.106.77.35]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q259WPZU006409; Mon, 5 Mar 2012 01:32:25 -0800 (PST)
Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.92]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0247.003; Mon, 5 Mar 2012 01:32:24 -0800
From: "Eggert, Lars" <lars@netapp.com>
To: "middisc@ietf.org" <middisc@ietf.org>
Thread-Topic: [middisc] middisc specification update
Thread-Index: AcyG5wLVJKtf0Y74SiSodjFq7qJ2lxObcJ+QAAJE5sAI3dxCQACIKKiA
Date: Mon, 05 Mar 2012 09:32:24 +0000
Message-ID: <DB9B280D-B61E-4E4C-A7CC-7BCB08FD361E@netapp.com>
References: <4E9241F7.5090406@mti-systems.com><2AE215BDC76842F885AC7E9D34BD2CA4@davidPC> <0C53DCFB700D144284A584F54711EC580E546254@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC580EA21847@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <0C53DCFB700D144284A584F54711EC580EA21847@xmb-sjc-21c.amer.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.106.53.51]
Content-Type: multipart/signed; boundary="Apple-Mail=_FC2D73C2-07FB-41E2-A01D-87D471BB48B0"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Cc: Martin Stiemerling <Martin.Stiemerling@neclab.eu>
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: Mon, 05 Mar 2012 09:32:45 -0000

Hi,

On Mar 3, 2012, at 1:42, Anantha Ramaiah (ananth) wrote:
> I just posted a draft (draft-ananth-middisc-tcpopt-00.txt) which is a
> result of all the discussions we have had among the stakeholders.

a few comments on the ID. (Also CC'ing Martin as the incoming AD.)

Lars


  I think you need to add some text that says that although TCP is
  end-to-end and therefore network infrastructure was supposed to not
  mess with the TCP headers, current deployment practice has resulted in
  middleboxes that do in fact "violate" the original architecture in
  order to address a perceived need. This shouldn't say whether that's
  good or bad, but merely acknowledges reality and encourages use of a
  shared documented option number for such uses.


INTRODUCTION, paragraph 1:
> Intended status: Informational

  You need to make this PS. Or do you want to ask for IESG Approval of
  the option number?


INTRODUCTION, paragraph 5:
>    This document describes a TCP option for use by middleboxes to
>    facilitate transparent detection of other middleboxes along the path
>    of the TCP connection during the connection initiation phase.  The
>    option has no effect if an appropriate middlebox is not present on
>    the path.

  I'd move all the rest of the abstract to the introduction; not appropriate
  for the abstract.


Section 6., paragraph 4:
>    The TCP-MDO option is incompatible with TCP options which aim to
>    protect the integrity of the TCP SYN.  An example of such an option
>    is the TCP MD5 signature option[RFC2385].  Such TCP options are not
>    commonly seen by current WAN optimization systems, so the restriction
>    should not pose any worries.

  Also, more importantly, TCP-AO.


Section 7., paragraph 3:
>    IANA is also requested to assign an 8 bit vendor code that can be
>    used to differentiate multiple vendors and to maintain an associated
>    registry.

  Insufficient information to define the registry. Please read RFC5226
  on how to write an IANA considerations section.


Section 7., paragraph 5:
>        Vendor               TCP option number
>        --------------------------------------
>        Bluecoat             253
>        Cisco                33

  I thought we also knew about Riverbed and Citrix?