Subject: RE: The need for smaller protocol specifications

From: "Bound, Jim" <[email-masked]>
Date: Mon, 9 Jun 2003 19:35:50 -0400

Charlie,

I hear you.  I don't think control freaks is where I am going.  I think
you present a good balance and its good you and others are around.  My
view is key distribution is not our concern here and IPsec would work
with Mobile IPv6 as it was because I know how a market would make it
work and how a vendor can build it.  But I admit I am extreme and also
believe our protocols should do much less and state the security issues
but not hold up progress.  For mission critical environments what we do
here will not be used as is anyway for security where lives and such are
at stake.  Not at all.  Cryptographers give those requirements to the
vendor and will not use IETF stuff.  Sure Ipsec base will be used but
not as we defined it regarding key distribution and
encryption/authentication algorithms.

/jim

> -----Original Message-----
> From: Charlie Perkins [mailto:[email-masked]] 
> Sent: Monday, June 09, 2003 5:24 PM
> To: Bound, Jim
> Cc: Harald Tveit Alvestrand; [email-masked]
> Subject: Re: The need for smaller protocol specifications
> 
> 
> 
> 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:[email-masked]]
> >>Sent: Monday, June 09, 2003 3:28 PM
> >>To: Harald Tveit Alvestrand
> >>Cc: [email-masked]
> >>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 
> >>><[email-masked]> 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
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>      
> >>>
> >>
> >>    
> >>
> 
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 10 Jun 2003 00:58:33 -0400

Harald,

That was a good example below.  A very good one.  It gets to the
engineering trade off and I do think there is a responsibility to fix
that which can break in some way with other sceanrios.  Where we may be
failing is that we have to ship for the one scenario and we document
better the failure modes in other scenarios or where we simply do not
know. But I think it good to ship it and tell the market do it this way
any other way is at your own risk.  I feel fine and comfortable with
that risk its their trip and they own the trip not us.  The market will
always find dumb things to do with what we produce and also smart things
to do with what we produce.  If we keep trying to redue the risk for the
market by missing time lines for technology the market will not support
us.  That is one of our customers.

This is where we may have divergance on the list here and important
point of discussion.

/jim

> From: Harald Tveit Alvestrand [mailto:[email-masked]] 
> Sent: Monday, June 09, 2003 3:15 PM
> To: Charlie Perkins; [email-masked]
> > 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.
> 
> 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
> 
> 
> 
> 
> 
>