FW: Choices in IETF Protocols

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

I would like to comment on a piece of an email from Eric

> -----Original Message-----
> From: Mannie, Eric [mailto:Eric.Mannie@ebone.com]
> Sent: Tuesday, February 26, 2002 6:45 PM
> To: 'Stephen Trowbridge'; Dimitri.Papadimitriou@alcatel.be
> Cc: 'Heiles Juergen'; 'mvissers@lucent.com'; 
> 'vijay@umbc.edu'; ccamp-wg;
> 'sob@harvard.edu'; 'Kireeti Kompella'
> Subject: RE: Simple solution to terminate the discussion about SONET
> versu s SDH
Eric responds to Steve Trowbridge:
> 
> 
> > To have a standard, you make a choice and write it down so 
> > you can interoperate.
> 
> you are probably not aware of what profiles or implementation 
> agreements are (you don't have the same for SDH). 
>
I don't think we have much of the above in the IETF

> GMPLS is full of choices (options).

Which I think is VERY BAD

> Which signaling are you going to use: RSVP-TE or CR-LDP?
> Which routing protocol are you going to choose?
> The IETF RFCs are full of choices (options).

Which is I think BAD too. We should try to come to agreement
as to what the best standard way of doing things is.

> You never want to believe me when I told you that GMPLS is a 
> toolbox. Pick the tools you need, forget the others.
> If you disagree with this approach it is your right,
> but it is a common approach taken by many standardization
> bodies. Your freedom stops where my freedom is starting.
>
Other standards bodies can do whatever they please.
Here we are a WG in the IETF.

We may have applicability statements that explain that possibly
we have multiple protocol choices in different environments.
But in principle we try to not define a whole set of choices
that people can pick from. We may not always have succeeded.

RFC1958, sections 3.2, 3.5, 3.8 are important points to remember.

In general we (IETF) try to minimize the number of options, because
many options reduce the chances of good interoperability. Two
boxes that implement a protocol may not interoperate if they chose
different sets of options.

Note that RFC2026 tells us that if we have options that are
not implemented in an interoperable way in at least two genetically
independent implementations, then such options must be deprecated,
obsoleted or removed when you want to advance on the standards
track (i.e from PS to DS or from DS to STD)

Bert