Re: [middisc] closure of the middisc list
"Mahdavi, Jamshid" <jamshid.mahdavi@bluecoat.com> Wed, 23 January 2013 15:11 UTC
Return-Path: <jamshid.mahdavi@bluecoat.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 014EE21F86A8 for <middisc@ietfa.amsl.com>; 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 <middisc@ietfa.amsl.com>; 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 <middisc@ietf.org>; 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" <jamshid.mahdavi@bluecoat.com>
To: "Knutsen, Andrew" <andrew.knutsen@bluecoat.com>, "Mani Ramasamy (mani)" <mani@cisco.com>, "middisc@ietf.org" <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: <DF29671EFBFC454E984F5A1AD4834F491E79A2B9@pwsvl-excmbx-04.internal.cacheflow.com>
References: <50ECC3EF.1020405@mti-systems.com> <CAFZUbhfVGwZQLA+cn_MKoM1GLHBddxGTnOfwtksPWs4+P2p0hg@mail.gmail.com> <CD6E74FCC0FE024BB73C6B483F6706FE0FC0FCD3@xmb-rcd-x07.cisco.com>, <D4D47BCFFE5A004F95D707546AC0D7E91F5D2AA9@SACEXCMBX06-PRD.hq.netapp.com> <D22144CF-6E2B-40F0-9DF1-8EF551B93D17@cisco.com> <50FF1520.4080901@bluecoat.com>, <CD6E74FCC0FE024BB73C6B483F6706FE0FC3EED7@xmb-rcd-x07.cisco.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." <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: Wed, 23 Jan 2013 15:11:57 -0000
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 need the OUI reference though --they're bigger then enterprise numbers. For instance, if some reserved codes were each used to make 256 more (with one 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 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 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). MANI – 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 years than 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 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-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<mailto:lars@netapp.com>> wrote: Hi, On Jan 9, 2013, at 3:16, Mani Ramasamy (mani) <mani@cisco.com<mailto: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<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] closure of the middisc list Wesley Eddy
- Re: [middisc] closure of the middisc list Anantha Ramaiah
- Re: [middisc] closure of the middisc list Mani Ramasamy (mani)
- Re: [middisc] closure of the middisc list Eggert, Lars
- Re: [middisc] closure of the middisc list Mark Day
- Re: [middisc] closure of the middisc list Martin Stiemerling
- Re: [middisc] closure of the middisc list Mark Day
- Re: [middisc] closure of the middisc list Mahdavi, Jamshid
- Re: [middisc] closure of the middisc list Mani Ramasamy (mani)
- Re: [middisc] closure of the middisc list Anantha Ramaiah
- Re: [middisc] closure of the middisc list Andrew Knutsen
- Re: [middisc] closure of the middisc list Mani Ramasamy (mani)
- Re: [middisc] closure of the middisc list Knutsen, Andrew
- Re: [middisc] closure of the middisc list Knutsen, Andrew
- Re: [middisc] closure of the middisc list Mahdavi, Jamshid
- Re: [middisc] closure of the middisc list Anantha Ramaiah
- Re: [middisc] closure of the middisc list Mahdavi, Jamshid
- Re: [middisc] closure of the middisc list Wesley Eddy
- Re: [middisc] closure of the middisc list Mahdavi, Jamshid
- Re: [middisc] closure of the middisc list Wesley Eddy
- Re: [middisc] closure of the middisc list Mani Ramasamy (mani)
- Re: [middisc] closure of the middisc list Mani Ramasamy (mani)
- Re: [middisc] closure of the middisc list Mahdavi, Jamshid
- Re: [middisc] closure of the middisc list Knutsen, Andrew
- Re: [middisc] closure of the middisc list Wesley Eddy
- Re: [middisc] closure of the middisc list Wesley Eddy
- Re: [middisc] closure of the middisc list Mahdavi, Jamshid
- Re: [middisc] closure of the middisc list Mani Ramasamy (mani)
- Re: [middisc] closure of the middisc list Anantha Ramaiah
- Re: [middisc] closure of the middisc list Wesley Eddy
- Re: [middisc] closure of the middisc list Eggert, Lars
- Re: [middisc] closure of the middisc list Wesley Eddy
- Re: [middisc] closure of the middisc list Anantha Ramaiah
- Re: [middisc] closure of the middisc list Wesley Eddy
- Re: [middisc] closure of the middisc list Eggert, Lars
- Re: [middisc] closure of the middisc list Scharf, Michael (Michael)
- Re: [middisc] closure of the middisc list Eggert, Lars
- Re: [middisc] closure of the middisc list Andrew Knutsen
- Re: [middisc] closure of the middisc list Eggert, Lars
- Re: [middisc] closure of the middisc list Anantha Ramaiah