Re: [middisc] closure of the middisc list

"Knutsen, Andrew" <> Wed, 23 January 2013 06:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 23BC821F87AC for <>; Tue, 22 Jan 2013 22:33:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qaC9OVR-VNu5 for <>; Tue, 22 Jan 2013 22:33:02 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8408621F8799 for <>; Tue, 22 Jan 2013 22:33:02 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id AB54181A0A3; Tue, 22 Jan 2013 22:39:11 -0900 (AKST)
Received: from ([fe80::c596:c77:dd67:b72d]) by ([fe80::a508:17dc:1550:e9f6%12]) with mapi id 14.01.0355.002; Tue, 22 Jan 2013 22:32:59 -0800
From: "Knutsen, Andrew" <>
To: "Mani Ramasamy (mani)" <>, "" <>
Thread-Topic: [middisc] closure of the middisc list
Date: Wed, 23 Jan 2013 06:32:59 +0000
Message-ID: <>
References: <> <> <>, <> <> <>, <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
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-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussions on TCP option for middlebox discovery." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 Jan 2013 06:33:03 -0000

   Oops, I was mixing up OUI's and Ethernet addresses.  3 bytes is still pretty big.

From: [] on behalf of Knutsen, Andrew
Sent: Tuesday, January 22, 2013 10:28 PM
To: Mani Ramasamy (mani);
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).


From: Mani Ramasamy (mani) []
Sent: Tuesday, January 22, 2013 10:08 PM
To: Knutsen, Andrew;
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?


From: [] On Behalf Of Andrew Knutsen
Sent: Tuesday, January 22, 2013 2:39 PM
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?


   Thanks Mani!


On 1/21/2013 9:00 AM, Mani Ramasamy (mani) wrote:

    Just posted the updated version of the draft. Please review.


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

  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" <<>> wrote:


On Jan 9, 2013, at 3:16, Mani Ramasamy (mani) <<>> 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.



middisc mailing list<>

middisc mailing list