Re: [middisc] closure of the middisc list
Anantha Ramaiah <ananth@nttmcl.com> Wed, 23 January 2013 15:43 UTC
Return-Path: <ananth@nttmcl.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 76DE221F8703 for <middisc@ietfa.amsl.com>; Wed, 23 Jan 2013 07:43:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.477
X-Spam-Level:
X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 qNCSiwH7BBk7 for <middisc@ietfa.amsl.com>; Wed, 23 Jan 2013 07:43:54 -0800 (PST)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id A187921F869F for <middisc@ietf.org>; Wed, 23 Jan 2013 07:43:53 -0800 (PST)
Received: by mail-wg0-f44.google.com with SMTP id dr12so5179909wgb.23 for <middisc@ietf.org>; Wed, 23 Jan 2013 07:43:52 -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=fiMg2Afm4VkKgJoKvKnIZfJfdSRfwEjKSCTTi/FHIBw=; b=Vm2z2wXrZ3JoU3ofZiPL+sVEqGqphi93FanBGC3YxWHHYI2YAg1BIxm1gaNe1e2JDA BahYp08HcgacvvjKWYIBeGfIjFmO9pJZdQ0hxflKhMv/hjMgOl47JkQWxyI5/OoVXXQu p4Wk853N+I9fjYh34bxWDSd7zgHN4It8xhDMpPQaCctC7YQqmArVRo9D+5BPXTJpGp/1 4b/DeTe80g71Y/uPLAsx1u0DfR+N1IRxEk/KniTmHAFrqIedYVuN5aA9sMH/8xhLmQYW PfP/LQlJsxurrFCVJrt6Jg97l2UENT5P4hCsHxbAPCf3n5H7QHB+3oZ+b6kX5WXCjHVX wWVg==
MIME-Version: 1.0
X-Received: by 10.180.93.41 with SMTP id cr9mr3363568wib.19.1358955832308; Wed, 23 Jan 2013 07:43:52 -0800 (PST)
Received: by 10.180.162.165 with HTTP; Wed, 23 Jan 2013 07:43:52 -0800 (PST)
In-Reply-To: <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> <DF29671EFBFC454E984F5A1AD4834F491E79A2B9@pwsvl-excmbx-04.internal.cacheflow.com>
Date: Wed, 23 Jan 2013 07:43:52 -0800
Message-ID: <CAFZUbhfcqsMbaccp50PoDWtuZ3CiDsmb1or9pLmCV0Ug0OrqqA@mail.gmail.com>
From: Anantha Ramaiah <ananth@nttmcl.com>
To: "Mahdavi, Jamshid" <jamshid.mahdavi@bluecoat.com>
Content-Type: multipart/alternative; boundary="f46d04389357a674d004d3f68fe1"
X-Gm-Message-State: ALoCoQkYEQkACH2CwdYFE7kv/iQH7cUM8g0KhWN6OCayBoQOwlshEOBvU25DUFQmLmIFsgTuiWxN
Cc: "middisc@ietf.org" <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." <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:43:58 -0000
Hi Jamshid, I used the RFC 2119 language in this draft since we are trying to define a middlebox option whose requirements are generic in nature with the use case of middle box discovery. I also assume it is ok to use RFC 2119 language for experimental specifications (which this draft is targetted towards) I would like to hear from the AD's on this usage. thanks, -Anantha On Wed, Jan 23, 2013 at 7:11 AM, Mahdavi, Jamshid < jamshid.mahdavi@bluecoat.com> wrote: > 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 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