The need for smaller protocol specifications

[Harald Tveit Alvestrand]

Charlie,

clipping mercilessly from your message....

--On mandag, juni 09, 2003 11:20:52 -0700 Charlie Perkins 
<charliep at IPRG.nokia.com> wrote:

> Another way to say this, is that we are being required to specify
> entire systems instead of protocol components.  I think this is a
> very bad idea.  I think the IESG should sincerely reconsider this
> policy, and let protocol specifications be published EVEN IF
> they do not solve the entire problem domain, but just a part of it.
> Typically, the part that the original protocol specification DOES
> solve, will be implemented and tested for interoperability.  The
> other stuff that gets glued on will just sit there like a dark jungle.

The way I thought of it in the apps area 5+ years back was that a proposal 
has to document that it is good for AT LEAST ONE THING. (I failed that at 
times - for instance with TIP, which I still don't know if anyone uses).

We (the IETF) want to standardize useful protocols. If there isn't at least 
one scenario where the protocol is clearly useful, I see absolutely no 
reason to standardize it. So describing the scenario, including all the 
bits and pieces from other protocols that have to be there in order to make 
the protocol useful in that scenario, is, to my mind, a necessary part of 
documenting the protocol.

On the other hand - if a scenario is described, and it's obvious that 5 
mins after the protocol-implementing product hits the street, it will be 
used in another scenario, where the proposed "supporting bits" are clearly 
going to lead to undesirable situations (I'm thinking about SNMPv1 and the 
"community string" here, for instance), then we as a community have a 
responsibility to describe those scenarios too, and provide/reference the 
adequate mechanisms for those scenarios. For instance by saying that all 
IPv6 implementations MUST have IPSec support (the "Danvers Doctrine"), or 
saying that applications MUST behave in the face of congestion (RFC 2914).

                 Harald