The need for smaller protocol specifications

[Charlie Perkins]

Hello Harald,

I agree with your statements, and I wonder if you see the value
of my argument.

Do you think that protocol specifications today are (generally
speaking) too complicated, about right, or not yet complicated
enough?

Regarding "good for AT LEAST ONE THING", does it
mean there has to be a killer app?  What about IPv6--?

Regards,
Charlie P.



Harald Tveit Alvestrand wrote:

> 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
>
>
>
>
>