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
>