The need for smaller protocol specifications

Charles E. Perkins charliep at IPRG.nokia.com
Tue Jun 10 11:50:29 CEST 2003


Hello John,

I think your reformulation will help to refine the problem.
Comments below.

John C Klensin wrote:

>        ..........               I think there is
> another, balancing, problem.  Perhaps there are differences by
> area or topic, but I think it would be equally accurate to say:
> 
>         -- The IESG has tended to approve simple component
>         protocol specifications without an adequate
>         understanding of the systems and contexts in which those
>         protocols will be used.  If vendors or users adopt the
>         protocols without adequate consideration of those system
>         and contexts, this may create considerable risks for the
>         overall operation of the Internet.  While protocol
>         specifications should not be expected about every
>         possible application and context, they should include
>         documentation that describes which contexts have been
>         thought out and evaluated and which ones, if any, are
>         known to be inappropriate.
> 
> There is obviously a balance that should be found and kept here.

Exactly.  This is an engineering problem, not a mathematical
problem, and I have tried to emphasize the need for balance.

Your suggested solution (eek!  solution space!) seems workable
to me, but notably it does NOT imply that the partcular contexts
are codified as necessary parts of the base specification.
Indeed, once again we may be asked to upgrade the "applicability"
part of the specfication.  This should be understood as
a _possible_ application of the protocol, and not the _only_
application of the protocol.

> Slogans like "complete systems only" and "small components only"
> are unlikely to lead us to progress, quality, or understanding.

One person's "slogan" is another person's "engineering guideline".
I do not believe that understanding good engineering guidelines
is a hindrance.  Perhaps you meant to suggest that no such guidelines
are immutable, but have to reflect current practice and understanding.

I am suggesting that the current trend towards demanding complete
system specifications is itself a mighty hindrance.

> Note that I don't think you have been invoking such slogans
> --I've found your notes helpful and thoughtful-- but it is only
> a small step from what you have said, or my response above, to
> them.

Thank you very much for the encouragement, and I hope we can
continue to refine this particular problem statement.

Regards,
Charlie P.


More information about the Problem-statement mailing list