IETF mission (RE: pausable explanation for the Document Series)

Bound, Jim Jim.Bound at
Sun Jun 8 00:22:38 CEST 2003

I vote for this.  But would need grandfather for that preceding this or
the market will feed the IETF to pigs :-)


> -----Original Message-----
> From: Eric Rosen [mailto:erosen at] 
> Sent: Friday, June 06, 2003 10:58 AM
> To: Brian E Carpenter
> Cc: problem-statement at
> Subject: Re: IETF mission (RE: pausable explanation for the 
> Document Series) 
> Perhaps we  need to  understand better  just what problem  we 
> are  trying to solve by revising the categorization of standards. 
> I'd make two observations: 
> 1. Nobody  cares  whether  the  IETF  says  that a  protocol  
> is  ready  for
>    deployment or  not.  Service providers, vendors,  
> enterprises, etc., will
>    decide this for themselves. 
>    By "nobody", I mean "nobody who is  in a position to 
> decide whether to do
>    any large scale deployments".  In the old world of the 
> ITU-T people don't
>    deploy  until the  standards  process  is finished,  which 
>  leads to  (a)
>    bizarre standards  and (b) slow progress.   That may have  
> been okay when
>    telecom providers were monopolies, but  it is not okay in 
> the competitive
>    environment of today.
> 2. People  do care  about whether  the protocol  has a  
> public specification
>    which  is sufficiently detailed  so as  to enable  
> interoperability among
>    multiple independent  implementations.  However, they will 
>  not wait (nor
>    should they) for such a specification before deployment.
> Based on these observations, there  has arisen a significant 
> constituency in the IETF  (though not seen much on  this 
> list) which believes  that the only proper  function  of  the 
>  IETF  is  to  publish  specifications  which  are 
> multi-vendor interoperable.  Members of  this constituency 
> see no benefit at all for IESG  review.  Members of this 
> constituency  would also be overjoyed
> if  all  their   specs  could  just  get  published   as  
> "Experimental"  or
> "Informational", and once the specs  get published, they have 
> no interest in moving them further along in the process.
> Most people  on this list seem  to think that there  is a 
> value  in having a category  of  "standard"  which  means  
> something  more  than  "multi-vendor interoperable."  But I  
> don't think there is a clear  consensus on just what we want 
> that to mean, and that's one of our big problems. 
> Some possible considerations are: 
> - correctly achieves the function which it is intended to achieve
> - adequately address scalability and security considerations 
> in the intended
>   scope of applicability
> - adequately (though not excessively) flexible 
> - not a lot more complicated than it needs to be
> - can be reasonably defended against alternatives
> - specification is competently and professionally done
> - impact on other areas has been addressed
> - there exists significant interest in deploying this
> etc. 
> To  me, it makes  sense to  have a  standards category  which 
> says  that the specification is not merely adequate  for 
> interoperability, but also that it has been judged against 
> these other considerations.
> Considerations often cited which I don't agree with: 
> - must not be intended for uses which violate my personal values
> - must not  be intended for uses which  violate my idea of  
> how the Internet
>   should be used
> - must not be intended for uses which allow Service Providers 
> to add value
> - must not violate some alleged philosophical principle 
> articulated 25 years
>   ago 
> - must  not  make  it  more  difficult  to  write  
> multi-party  peer-to-peer
>   applications
> - must have the highest conceivable level of security
> - guaranteed bug-free
> Based on the considerations I think are important, I don't 
> understand why we need  more than one  category of  standard, 
> so  I would  tend to  agree with
> Brian: "let's scrap it all and  have a single level (with 
> recycling in grade for corrections/updates)." 

More information about the Problem-statement mailing list