Re: [middisc] TCP middlebox option requirements

I am in the process of forming a outline for the new draft which I'll be
sharing soon. That said, response to the comment inline :-

> -----Original Message-----
> From: middisc-bounces@ietf.org [mailto:middisc-bounces@ietf.org] On
> Behalf Of Knutsen, Andrew
> Sent: Wednesday, June 08, 2011 2:44 PM
> To: middisc@ietf.org
> Subject: [middisc] TCP middlebox option requirements
> 
> 
>    While we're waiting for any more details that may help us reach
> consensus on the format of the option, I've been thinking about the
> text we'll use to restrict its uses.  This text would be guidance to
> the IANA (or other assigning authority) to determine when to assign a
> vendor or standard code.  It could also be used for policing after
> assignment, but thats a bit more problematic (although that's all that
> would be possible in the OUI/PEN case).
> 
>    There are a few details to be considered, but I'm curious about one
> thing which is perhaps fundamental:
> 
>    Do we anticipate any use of this option where the intended consumer
> of the option is the actual host at the destination IP address?
> (Excepting responses).

I would think the answer is : yes. But, we want to accommodate such an
use case if possible without burning a lot of cycles and making
modifications. I believe this shouldn't be a problem.

> 
>    To me, this is a pretty clear discriminator for a "middlebox
> option".  My impression is that we want a minimum of requirements in
> the text, so that we can all use this for the things we need it for;
> however we also want to make sure its not a "catch-all", like the old
> SNAP option.

Agreed.

-Anantha
> 
> Andrew
> 
> _______________________________________________
> middisc mailing list
> middisc@ietf.org
> https://www.ietf.org/mailman/listinfo/middisc