The need for smaller protocol specifications

[John C Klensin]

--On Tuesday, 10 June, 2003 10:50 -0700 "Charles E. Perkins" 
<charliep at IPRG.nokia.com> wrote:

> 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
>>...
>> 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!)

Sorry.  Too much experience/context in optimization-related 
techniques, which were, in my experience, engineering tools and 
disciplines (see below).

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

Absolutely.   But that formulation, which I think is the correct 
one, suggests that we ought to be prepared to update statements 
about applicability (or lack thereof) as often, or more often, 
than we update the protocols themselves.

>> 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 can accept that definition.

Part of the tension I'm feeling is that I heard what was, for 
me, a wonderful definition of "the engineering discipline" many 
years ago, and it featured "tinkering" as the key element. 
"Tinkering"-based definitions are entirely consistent with 
"smaller pieces" models and incremental development of many 
sorts.  The author believed that, if a problem had a single 
possible solution that could be derived uniquely from 
well-established (or provable) principles, it might be "science" 
or "mathematics", but it wasn't engineering.   Engineering 
problems, in that view, were characterized by collections of 
goals and constraints and the processed used to find a solution 
that was a reasonable match to them (with "economics" and "how 
long do we really have to do this, and how much does more time 
'cost'?" typically being part of the constraint set).

The difficulty is that, while many of those same issues apply to 
standardization processes, they are intrinsically a bit 
different.  In some ways, standardization is about determining a 
constraint set --or part of it-- against which engineering can 
occur.  If that wasn't the case, we wouldn't need to worry as 
much about interoperable implementations, because only one 
narrowly-defined class of implementation solutions would be 
possible for a given standard.  So, in writing a standard, we 
need to determine how to define an acceptable solution, at least 
partially in terms of the constraints on it.    That is a bit 
different from "engineering problem" and even more different 
from "engineering solution".  And I think we need to keep the 
differences and similarities clear, lest we accidentally go too 
far in one direction or the other and find ourselves hamstrung.

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

And we agree about that as well.

    regards,
      john