Re: [middisc] middisc specification update

["Anantha Ramaiah (ananth)" <[e-mail]>]

Hi Lars,
 
 I missed this email and just got to this. Comments inline..

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Eggert, Lars
> Sent: Monday, March 05, 2012 1:32 AM
> To: [e-mail]
> Cc: Martin Stiemerling
> Subject: Re: [middisc] middisc specification update
> 
> Hi,
> 
> On Mar 3, 2012, at 1:42, Anantha Ramaiah (ananth) wrote:
> > I just posted a draft (draft-ananth-middisc-tcpopt-00.txt) which is
a
> > result of all the discussions we have had among the stakeholders.
> 
> a few comments on the ID. (Also CC'ing Martin as the incoming AD.)
> 
> Lars
> 
> 
>   I think you need to add some text that says that although TCP is
>   end-to-end and therefore network infrastructure was supposed to not
>   mess with the TCP headers, current deployment practice has resulted
> in
>   middleboxes that do in fact "violate" the original architecture in
>   order to address a perceived need. This shouldn't say whether that's
>   good or bad, but merely acknowledges reality and encourages use of a
>   shared documented option number for such uses.

Right, to my reply to Wes's other email, I acknowledged that there is
need to add text to cover the aspect of option poaching etc.,

> 
> 
> INTRODUCTION, paragraph 1:
> > Intended status: Informational
> 
>   You need to make this PS. Or do you want to ask for IESG Approval of
>   the option number?

Wes's response to my comment was to make it Experimental. So we have 3
choices : info (current), experimental and PS.
I am not sure, whichever is the fastest route in getting the TCP option
allocated, I'll take that :-) Of course, this is just my opinion. Other
stakeholders may have different opinion.

> 
> 
> INTRODUCTION, paragraph 5:
> >    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.
> 
>   I'd move all the rest of the abstract to the introduction; not
> appropriate
>   for the abstract.

Good point. I'll move the rest to the introduction section.

> 
> 
> Section 6., paragraph 4:
> >    The TCP-MDO option is incompatible with TCP options which aim to
> >    protect the integrity of the TCP SYN.  An example of such an
> option
> >    is the TCP MD5 signature option[RFC2385].  Such TCP options are
> not
> >    commonly seen by current WAN optimization systems, so the
> restriction
> >    should not pose any worries.
> 
>   Also, more importantly, TCP-AO.

Right, I just gave an example. I can also list AO as reference.

> 
> 
> Section 7., paragraph 3:
> >    IANA is also requested to assign an 8 bit vendor code that can be
> >    used to differentiate multiple vendors and to maintain an
> associated
> >    registry.
> 
>   Insufficient information to define the registry. Please read RFC5226
>   on how to write an IANA considerations section.

Ok.

> 
> 
> Section 7., paragraph 5:
> >        Vendor               TCP option number
> >        --------------------------------------
> >        Bluecoat             253
> >        Cisco                33
> 
>   I thought we also knew about Riverbed and Citrix?

Right, I know Riverbed's option usage, not sure about Citrix. Does
anyone have a contact point for Citrix?


Thanks,
-Anantha
>