The need for smaller protocol specifications

[Charlie Perkins]

Hello Jim,

I tried to make this short.

My belief is that the IESG demands full-blown system specifications
because anything less "could" be implemented inside systems that
have features they don't like.  Some would say that such demands
are characteristic of "control freaks".  I won't go that far, but it's
certainly an interesting point.

A good example is key distribution. If a protocol requires authentication,
but does not specify a key distribution mechanism, then the security AD
can ask "How can I use this without key distribution?".  The answer could
be by manual configuration, proprietary protocols, IKE, something new
under development in 3GPP$%*, or whatever.  But, by imposing the
(undocumented anywhere!) requirement for a key distribution adjunct,
the IESG
1) delays the specification
2) puts the design responsibility in a perhaps unprepared working
     group
3) discourages future development of appropriate key distribution,
4) causes protocol bloat, and
5) has a harder time judging the resulting document.
It is my belief that the IESG has to bite the bullet and stop causing
those effects.  The cure is worse than the disease they tried to heal.

Separate protocol specifications are better, and more workable if
allowed to progress towards deployment and market acceptance
at different rates.  Perhaps early system implementations won't do
the absolutely shiniest best thing, but anyway they will provide good
experience for later implementations.

We have _got_ to stop thinking that everything has to be perfect
before it is useful.  It's not like a space shuttle where we only
get one chance.  And even the best engineering has mistakes.
That's life!  The IESG can never change that.

Very similar complaints could be lodged against requiring
discovery protocols to be part of base specifications.
In the cases I am most familiar with, this was not an imposition
from the IESG, but a response to a feared response from the
IESG.  In fact, as the number of potential protocol interactions
grows nonlinearly in the Internet, we can no longer demand that
every protocol must have its interactions with other protocols
documented and specified completely -- at least for Proposed
Standard!!  We have to have a process more friendly towards
incremental refinement.

And, finally, to reiterate for emphasis in hopes that no one
would forget, this is not a black and white thing.  It's a matter
of balance, and lately the results have become terribly unbalanced
towards unmanageable protocol complexity.

Regards,
Charlie P.



Bound, Jim wrote:

>I agree with Charlie but not hearing anyone comment?
>
>Maybe I am paranoid but here is what I hear happening:
>
>1.  Bob Hinden suggested an idea for time to market.  Not one IESG
>person said this is a good idea not as IESG person but folks who have
>IESG experience.
>
>2.  Charlie gives below I think accurate description at a minimum a
>problem we face. Again no IESG response here.
>
>It could be we are still in define problem space so discussion solution
>is not time.  Or anything we propose that fixes anything other than an
>intergalitic high level process will not be discussed and esp by the
>IESG members not as IESG members but as persons in that role with
>experience.
>
>Chairs I have to ask where are you at with the above two bullets if
>adopted they clearly require a change and action by the IESG.  It feels
>to me the IESG and even past IESG persons don't want to do anything that
>causes that?  Thats my read of all these threads.
>We are experiencing the same problems on this mail list we are
>discussing.
>What are your thoughts?  If we are just going to flirt with fixing
>problems again I see not point in continuing.  This is exactly what the
>ADs do too. A member makes a very logical base statement as the two
>above and then we get silence from ADs.  Why?  IMO because it shows a
>problem in their ranks and they won't admit it.  But all here are more
>than willing to blast WGs, Chairs, and Authors.  This list is proving
>there is a problem real time.  It is happening before your eyes.
>Another IESG member blasted vendors twice this weekend.  I asked them
>will you stop this?  No answer and none privately.  If I was not a nice
>guy I would send that mail directly to Sr. VPs I know in those companies
>and say here is what IESG member said about you on a public mail list.
>But I am trying to be a nice guy.  The key problem with IESG is they
>think they are beyond the rules and basic codes of engineering
>discussion and responding to questions.  Or they don't answer the
>question as engineers but as politicians with quip mores and folkways
>that are not answers to the questions.  How do we document this problem?
>I simply do not know.
>
>thanks
>/jim
>
>  
>
>>-----Original Message-----
>>From: Charlie Perkins [mailto:charliep at IPRG.nokia.com] 
>>Sent: Monday, June 09, 2003 3:28 PM
>>To: Harald Tveit Alvestrand
>>Cc: problem-statement at alvestrand.no
>>Subject: Re: The need for smaller protocol specifications
>>
>>
>>
>>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
>>>
>>>
>>>
>>>
>>>
>>>      
>>>
>>
>>    
>>