Re: [middisc] status?

["David Harrington" <[e-mail]>]

Hi, 

> Requirements of this TCP option :
> 
> - There has to be a vendor ID (OUI) which would identify the
specific
> vendor. This is needed because every vendors option format is going
to
> be
> different.

This is a recurring theme in my twenty years of IETF work.
The purpose of the IETF is to establish **a standard** so different
vendor's equipment can interoperate.
The purpose of the IETF is NOT to develop a standard that allows every
vendor to do things differently, to not interoperate, yet to be able
to claim compliance to a "standard".

You should be careful about designing a complex solution when a simple
one would do.
It should NOT be a goal to define a standard "bucket" to support
non-interoperable vendor-specific features.
and if you design it that way, you should definitely expect strong
pushback during IESG evaluation.

As I recall, the purpose of this group was to agree on a single
standard option number for middisc, not to design an extensible
approach to vendor-specific options. I see mission creep in this list
of requirements.

A note from the list administrator: this mailing list was created to
allow you guys to resolve the unauthorized use of option numbers for
middisc, preferably by agreeing on a standard option number. The IESG
finds that these non-WG mailing lists can diverge into "shadow working
groups" where the list members think they can devise whole new
features with limited input from the IETF community. That is not the
purpose of this mailing list. If you want to develop a new feature for
TCP, then this should be discussed in a working group. I am asking you
to **focus** on solving the existing problem, which is eliminating the
unauthorized use of option numbers for middisc, not on possible future
extensions.

David Harrington
Director, IETF Transport Area
[e-mail] (preferred for ietf)
[e-mail]
[phone] (cell)

> 
> - Already existing non-standardized option numbers (TCP option 33,
> riverbed's options no's) for doing auto discovery should not be
> allocated for this new TCP option. This is to prevent any confusion.
> 
> - The TCP option needs to be variable length to permit multiple
option
> formats since the option size may vary depending on the vendor.
> 
> - This TCP option should be advocated for use only by middleboxes.
> 
> ---------------
> 
>      The only changes to these requirements I'm aware of were:
> 
> - Make the overhead minimal
> 
> - Allow evolution to vendor-independent formats
> 
> - Allow options to be sent mid-stream
> 
>      These requirements were discussed and led to the current 
> proposal.
> 
>      The "NAT reveal" option, while intended for consumption by the 
> destination server rather than a middlebox, could use the current 
> proposed format as far as I can tell (adding 1 or 2 bytes). 
> However we 
> may want to tighten up the allowed uses a bit, to be more 
> specific than 
> "used by middleboxes". Perhaps something regarding communicating the

> state of the middlebox, or information which has been hidden by the 
> middlebox. (This would permit our and the NAT-reveal uses, as 
> far as I 
> know).
> 
> Andrew
> 
> 
> 
> 
> On 11/7/2010 10:32 PM, Anantha Ramaiah (ananth) wrote:
> > Lars,
> >     From my side, it has been real crazy at work and I 
> couldn't devote
> > any time for this effort. I did follow the last few email 
> exchanges on
> > this. Few thoughts I had in mind was :-
> >
> >   - to have a generic middle box option, which not only 
> caters to the
> > needs of middle box discovery, but also to stuff like the 
> following :-
> >
> > http://tools.ietf.org/html/draft-wing-nat-reveal-option-00
> >
> > (When I did an internal review of Dan's draft, I had suggested the
> > same.)
> >
> > -  Have a requirements document for the middisc TCP option. 
> It appears
> > to me that, there is a need for a precursor document to 
> establish some
> > common needs and a rationale for a midisc option. This 
> would great help
> > in getting to a faster consensus and would also help some 
> new vendors
> > who may be want to join this effort to come to the same 
> page as the rest
> > of us.
> >
> > Also, during the initial meeting, I am remembering that you were
> > planning to send an email to the various IETF mailing lists 
> citing this
> > effort and asking if there are any other vendors who do 
> this middisc and
> > may be interested in joining this effort.. any progress on 
> that front?
> >
> > thoughts?
> >
> > Thanks,
> > -Anantha
> >
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
On
> > Behalf Of Lars Eggert
> > Sent: Sunday, November 07, 2010 9:25 PM
> > To: [e-mail]
> > Subject: [middisc] status?
> >
> > Hi, folks,
> >
> > I'm wondering what the status of this effort is - the list has
been
> > silent in the last months.
> >
> > Thanks,
> > Lars
> > _______________________________________________
> > middisc mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/middisc
> 
> _______________________________________________
> middisc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/middisc
>