Subject: [middisc] closure of the middisc list

From: Wesley Eddy <[email-masked]>
Date: Tue, 08 Jan 2013 20:12:15 -0500

I believe that this mailing list is pretty much dead as well as the
associated effort to get a codepoint reserved for vendors to share a
legitimate TCP option number across the various middlebox discovery
mechanisms.

Since this list was setup by the IETF TSV ADs in order to facilitate
discussion and help to resolve the issue, seeing no discussion or
progress, Martin and I are ready to close the list.

I plan to request the IESG Secretary to close this list sometime
next week.  If there are still people interested in progressing some
flavor of the specification we all were working on, please contact
Martin or myself for possible AD-sponsoring.

-- 
Wes Eddy
MTI Systems

---

From: Anantha Ramaiah <[email-masked]>
Date: Tue, 8 Jan 2013 17:24:06 -0800

Hi, Wes,
     After I left Cisco, I am no longer able to work on this any further
(sorry I should have finished it before thart...).  However I believe Mani
from Cisco (already in the list)  may be interested get the review comments
incorporated and push this forward. IMO, this draft is ready for
publication and getting a TCP option number reserved for middlebox
discovery.
thanks,
-Anantha

On Tue, Jan 8, 2013 at 5:12 PM, Wesley Eddy <[email-masked]> wrote:

> _______________________________________________
> middisc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/middisc
>

---

From: "Mani Ramasamy (mani)" <[email-masked]>
Date: Wed, 9 Jan 2013 02:16:19 +0000

Hi Wes,
                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.

Thanks,
Mani.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Anantha Ramaiah
Sent: Tuesday, January 08, 2013 5:24 PM
To: Wesley Eddy
Cc: [email-masked]
Subject: Re: [middisc] closure of the middisc list

Hi, Wes,
     After I left Cisco, I am no longer able to work on this any further (sorry I should have finished it before thart...).  However I believe Mani from Cisco (already in the list)  may be interested get the review comments incorporated and push this forward. IMO, this draft is ready for publication and getting a TCP option number reserved for middlebox discovery.
thanks,
-Anantha
On Tue, Jan 8, 2013 at 5:12 PM, Wesley Eddy <[email-masked]<mailto:[email-masked]>> wrote:
I believe that this mailing list is pretty much dead as well as the
associated effort to get a codepoint reserved for vendors to share a
legitimate TCP option number across the various middlebox discovery
mechanisms.

--
Wes Eddy
MTI Systems
_______________________________________________
middisc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/middisc

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 9 Jan 2013 14:47:41 +0000

Hi,

> 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

---

From: Mark Day <[email-masked]>
Date: Wed, 9 Jan 2013 15:00:11 +0000

In principle this is still an important area to get right.  Unfortunately there are currently dueling patent lawsuits between my company and a competitor, where one of the patents in the dispute is potentially relevant to this technical issue.  

Until that dispute ends (currently scheduled for trial this September) I am unlikely to be able to contribute in any forum unrelated to the suits.

--Mark 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eggert, Lars
Sent: Wednesday, January 09, 2013 9:48 AM
To: Mani Ramasamy (mani)
Cc: Wesley Eddy; [email-masked]
Subject: Re: [middisc] closure of the middisc list

Hi,

Lars

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 9 Jan 2013 16:10:35 +0100

So this would mean that an IPR disclosure about the draft is due, isn't it?

On 01/09/2013 04:00 PM, Mark Day wrote:
> In principle this is still an important area to get right.
> Unfortunately there are currently dueling patent lawsuits between my
> company and a competitor, where one of the patents in the dispute is
> potentially relevant to this technical issue.
>
> Until that dispute ends (currently scheduled for trial this
> September) I am unlikely to be able to contribute in any forum
> unrelated to the suits.
>
> --Mark
>
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Eggert, Lars Sent:
> Wednesday, January 09, 2013 9:48 AM To: Mani Ramasamy (mani) Cc:
> Wesley Eddy; [email-masked] Subject: Re: [middisc] closure of the
> middisc list
>
> Hi,
>
>> 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.
>
> Lars _______________________________________________ middisc mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/middisc
> _______________________________________________ middisc mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/middisc
>

-- 
[email-masked]

NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283

---

From: Mark Day <[email-masked]>
Date: Wed, 9 Jan 2013 15:12:50 +0000

No, I didn't participate in the development of the current draft because of this problem.  Just wanted to be clear that my non-participation is not caused by lack of interest.

-----Original Message-----
From: Martin Stiemerling [mailto:[email-masked]] 
Sent: Wednesday, January 09, 2013 10:11 AM
To: Mark Day
Cc: Eggert, Lars; Mani Ramasamy (mani); Wesley Eddy; [email-masked]
Subject: Re: [middisc] closure of the middisc list

NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283

---

From: "Mahdavi, Jamshid" <[email-masked]>
Date: Wed, 9 Jan 2013 15:18:45 +0000

I have been moved on to other projects at Blue Coat, but if all we are looking at is review and approval of the latest draft, I should be able to do that (or have someone else here do it) as soon as Mani publishes it.

It would be very nice to see this done!

--J

________________________________________
From: [email-masked] [[email-masked]] on behalf of Eggert, Lars [[email-masked]]
Sent: Wednesday, January 09, 2013 6:47 AM
To: Mani Ramasamy (mani)
Cc: Wesley Eddy; [email-masked]
Subject: Re: [middisc] closure of the middisc list

Hi,

Lars

---

From: "Mani Ramasamy (mani)" <[email-masked]>
Date: Mon, 21 Jan 2013 17:00:09 +0000

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" <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

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

Lars

---

From: Anantha Ramaiah <[email-masked]>
Date: Mon, 21 Jan 2013 09:05:25 -0800

I did work with Mani and reviewed this already.  IMO this addresses all
the review comments received so far and it is all set to go to the next
stages.  Thanks for taking the lead, Mani.

thanks,
-Anantha

On Mon, Jan 21, 2013 at 9:00 AM, Mani Ramasamy (mani) <[email-masked]>wrote:

> URL:
> http://www.ietf.org/internet-drafts/draft-ananth-middisc-tcpopt-01.txt
> Status:
> http://datatracker.ietf.org/doc/draft-ananth-middisc-tcpopt
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-ananth-middisc-tcpopt-01
>
> Abstract:
> On Jan 9, 2013, at 6:47 AM, "Eggert, Lars" <[email-masked]> wrote:
>
> Hi,
>
>
> agree with Wes that we need to finish this, or declare failure and disband
> the list.
>
>

---

From: Andrew Knutsen <[email-masked]>
Date: Tue, 22 Jan 2013 14:39:28 -0800

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).

   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.

    Thanks Mani!

Andrew

---

From: "Mani Ramasamy (mani)" <[email-masked]>
Date: Wed, 23 Jan 2013 06:08:06 +0000

Thanks, Andrew. Please see inline.

Hi Wes,
                Can you pl. update on what the next steps are to move this draft forward?

Thanks.

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

All,

Thanks.
Mani.

Abstract:

The IETF Secretariat

Sent from my iPad

Hi,

Lars

middisc mailing list

---

From: "Knutsen, Andrew" <[email-masked]>
Date: Wed, 23 Jan 2013 06:28:28 +0000

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) [[email-masked]]
Sent: Tuesday, January 22, 2013 10:08 PM
To: Knutsen, Andrew; [email-masked]
Subject: RE: [middisc] closure of the middisc list

Hi Wes,

Thanks.

MANI – Sure, will add.

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

All,

Thanks.
Mani.

Abstract:

The IETF Secretariat

Sent from my iPad

Hi,

Lars

middisc mailing list

---

From: "Knutsen, Andrew" <[email-masked]>
Date: Wed, 23 Jan 2013 06:32:59 +0000

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

Andrew
________________________________________
From: [email-masked] [[email-masked]] on behalf of Knutsen, Andrew
Sent: Tuesday, January 22, 2013 10:28 PM
To: Mani Ramasamy (mani); [email-masked]
Subject: Re: [middisc] closure of the middisc list

Andrew

Hi Wes,

Thanks.

MANI – Sure, will add.

Mani.

   Thanks Mani!

Andrew

All,

Thanks.
Mani.

Abstract:

The IETF Secretariat

Sent from my iPad

Hi,

Lars

middisc mailing list

---

From: "Mahdavi, Jamshid" <[email-masked]>
Date: Wed, 23 Jan 2013 15:11:48 +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
Sent: Tuesday, January 22, 2013 10:32 PM

Andrew

Andrew

Hi Wes,

Thanks.

MANI – Sure, will add.

Mani.

   Thanks Mani!

Andrew

All,

Thanks.
Mani.

Abstract:

The IETF Secretariat

Sent from my iPad

Hi,

Lars

middisc mailing list

---

From: Anantha Ramaiah <[email-masked]>
Date: Wed, 23 Jan 2013 07:43:52 -0800

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 <
[email-masked]> 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.
>
> 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
> * 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.
>
>    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
>
> "extension" vendor code can be allocated (leaving exactly how it would work
> TBD).
>
> MANI – Sure, will add.
>
>
> 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
>

---

From: "Mahdavi, Jamshid" <[email-masked]>
Date: Wed, 23 Jan 2013 16:18:04 +0000

I'm happy with whatever advice the ADs give for these clauses.

My thinking was that the usage in section 4 is correct, but in section 3 we aren't really specifying things that implementers have control over (e.g. MUST be variable length) -- those are things that we as the authors have control over and once this is published the correct verb would be "IS variable length".

--J

________________________________
From: Anantha Ramaiah [[email-masked]]
Sent: Wednesday, January 23, 2013 7:43 AM
To: Mahdavi, Jamshid
Cc: Knutsen, Andrew; Mani Ramasamy (mani); [email-masked]
Subject: Re: [middisc] closure of the middisc list

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 <[email-masked]<mailto:[email-masked]>> wrote:
A few small nits:

--J
________________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] on behalf of Knutsen, Andrew
Sent: Tuesday, January 22, 2013 10:32 PM
To: Mani Ramasamy (mani); [email-masked]<mailto:[email-masked]>
Subject: Re: [middisc] closure of the middisc list

Andrew
________________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] on behalf of Knutsen, Andrew
Sent: Tuesday, January 22, 2013 10:28 PM
To: Mani Ramasamy (mani); [email-masked]<mailto:[email-masked]>
Subject: Re: [middisc] closure of the middisc list

Andrew

________________________________
From: Mani Ramasamy (mani) [[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, January 22, 2013 10:08 PM
To: Knutsen, Andrew; [email-masked]<mailto:[email-masked]>
Subject: RE: [middisc] closure of the middisc list

Hi Wes,

Thanks.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Andrew Knutsen
Sent: Tuesday, January 22, 2013 2:39 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [middisc] closure of the middisc list

MANI – Sure, will add.

Mani.

   Thanks Mani!

Andrew

All,

Thanks.
Mani.

Abstract:

The IETF Secretariat

Sent from my iPad

On Jan 9, 2013, at 6:47 AM, "Eggert, Lars" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:

Hi,

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

Lars

middisc mailing list

[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 31 Jan 2013 20:42:19 -0500

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

If folks are generally happy with this revision, I think the
path forward is that Pasi Sarolahti agreed to do a shepherd
review / writeup.  That was back at the Paris IETF, so he
might have changed his mind by then :).

If any of the authors or advocates will be in Orlando at the
next IETF meeting, it would be nice to give TCPM a 5 minute
recap of the current status, just so they know what happened
since it left the WG as a proposal there.  If nobody else
will be there (or nobody wants to do it!), I'd be happy to
briefly explain it's state.

Since it's unclear who will replace me as AD in March, it
might be a good idea to work kind of quick on this, so that
I can get it as far along with the IESG as possible before
March.  I suspect there will be trouble in the IESG on this,
as recent experience with the TCPM experimental options
draft suggests ...

-- 
Wes Eddy
MTI Systems

---

From: "Mahdavi, Jamshid" <[email-masked]>
Date: Fri, 1 Feb 2013 02:00:09 +0000

I had made some minor comments on the wording (MUST, SHOULD) which I believe we wanted advice from the AD on so Mani knew whether to accept it.

I also had suggested one very minor change to the content which I hope Mani is ok with accepting.

Let me know if you need that email resent.

Otherwise, very happy!

--J

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Wesley Eddy
Sent: Thursday, January 31, 2013 5:42 PM
To: Mani Ramasamy (mani)
Cc: [email-masked]
Subject: Re: [middisc] closure of the middisc list

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

If folks are generally happy with this revision, I think the path forward is that Pasi Sarolahti agreed to do a shepherd review / writeup.  That was back at the Paris IETF, so he might have changed his mind by then :).

If any of the authors or advocates will be in Orlando at the next IETF meeting, it would be nice to give TCPM a 5 minute recap of the current status, just so they know what happened since it left the WG as a proposal there.  If nobody else will be there (or nobody wants to do it!), I'd be happy to briefly explain it's state.

Since it's unclear who will replace me as AD in March, it might be a good idea to work kind of quick on this, so that I can get it as far along with the IESG as possible before March.  I suspect there will be trouble in the IESG on this, as recent experience with the TCPM experimental options draft suggests ...

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 31 Jan 2013 21:20:14 -0500

> Let me know if you need that email resent.

Regarding the 2119 wording, I (personally) prefer your rewording
of it, since those "requirements" are kind of just the design
principles that were aimed for and (as you note) not protocol
conformance requirements.  However, there are many RFCs that
do use 2119 capitalized words for requirements statements, and
there are mixed opinions about it, even in the IESG ... so, it
would be passable either way.  That said, I suspect it will be
smoother sailing if your suggested rewordings are applied :).

-- 
Wes Eddy
MTI Systems

---

From: "Mani Ramasamy (mani)" <[email-masked]>
Date: Fri, 1 Feb 2013 06:52:18 +0000

Great. Thanks Wes and Jamshid!

Will update and post a new draft tomorrow.

Mani.

-----Original Message-----
From: Wesley Eddy [mailto:[email-masked]] 
Sent: Thursday, January 31, 2013 6:20 PM
To: Mahdavi, Jamshid
Cc: Mani Ramasamy (mani); [email-masked]
Subject: Re: [middisc] closure of the middisc list

> Let me know if you need that email resent.

Regarding the 2119 wording, I (personally) prefer your rewording of it, since those "requirements" are kind of just the design principles that were aimed for and (as you note) not protocol conformance requirements.  However, there are many RFCs that do use 2119 capitalized words for requirements statements, and there are mixed opinions about it, even in the IESG ... so, it would be passable either way.  That said, I suspect it will be smoother sailing if your suggested rewordings are applied :).

--
Wes Eddy
MTI Systems