The need for smaller protocol specifications

[John C Klensin]

--On Monday, 09 June, 2003 21:14 +0200 Harald Tveit Alvestrand 
<harald at alvestrand.no> 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.
>...

Harald,

I would add one thing to this, which is that the description of 
a protocol that is to be approved on the basis that it does One 
Thing usefully must be quite clear about what that One Thing is. 
In other words, the narrower the focus of a protocol, the more 
important it is that its description describe what it is good 
for (and, if necessary, what it is not good for).  And that is 
an area in which I think we have fallen down on the job several 
times recently.

        john