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

[Eric Rosen]

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