IETF mission (RE: pausable explanation for the Document Series)
Bound, Jim
Jim.Bound at hp.com
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 :-)
/jim
> -----Original Message-----
> From: Eric Rosen [mailto:erosen at cisco.com]
> Sent: Friday, June 06, 2003 10:58 AM
> To: Brian E Carpenter
> Cc: problem-statement at alvestrand.no
> 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