Re: draft-housley-two-maturity-levels-00

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dave CROCKER wrote:
> 
> Interoperability testing used to be an extremely substantial demonstration
> of industry interest and of meaningful learning. The resulting repair and 
> streamlining of specifications was signficant.  If that's still happening,
> I've been missing the reports about lessons learned, as well as
> indications that significant protocol simplifications have resulted.
> While the premise of streamlining specifications, based on
> interoperability testing, is a good one, where is the indication that
> it is (still) of interest to industry?  (I believe that most protocols
> reaching Proposed these days already have some implementation
> experience; it's still not required, but is quite common, no?)
> 
> My own proposal was to have the second status level simply take note of
> industry acceptance.  It would be a deployment and use acknowledgement,
> rather than a technical assessment.  That's not meant to lobby for it,
> but rather give an example of a criterion for the second label that is
> different, cheap and meaningful.  By contrast, history has demonstrated
> that Draft is expensive and of insufficient community interest.
> We might wish otherwise, but community rough consensus on the point
> is clear.  We should listen to it.

I would prefer if the IETF retains the third level and puts an emphasis
on cutting down on protocol feature bloat when going from draft to
full standard.

What I see happening is that Proposed Standards often start out with
a lot of (unnecessary) features, and some of them even inappropriately
labelled as "MUST implement".

The draft standard only does some interop testing on a small number
of implementations, not unlikely those participating the standardization
process.  It neither addresses what subset other implementations implement
and what subset is actually necessary for the general use case in the
installed base.

One of the worst feature bloat examples is PKIX.

It contains an awkward huge number of features that a number of
implementations do not support -- and work happily without.
There should either be a split of e.g. 5280 into a "basic profile"
and a "advanced feature profile", or the status for some of the
extensions should be fixed from "MUST implement" to "SHOULD implement"
to match the real world and real necessity.


-Martin
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]