ietf
[Top] [All Lists]

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

2011-05-06 11:22:16
I am strongly opposed to this 2 document maturity level proposal.

The real problem tha the IETF is regularly facing are constituencies that
will fight hard against specifications getting updated, improved or fixed,
once they have been published as RFC. 


Dave Cridland wrote:

Dave CROCKER wrote:

Dave Cridland wrote:

1) This document radically lowers the quality of Proposed  
Standards.

What, specifically, are the parts of the proposal that you believe  
will lower the quality of a Proposed Standard?

2.1. The First Maturity Level: Proposed Standard

                            The intention of the two-tier maturity
   ladder is to restore practice to the requirements for Proposed
   Standard from RFC 2026, and stop performing more scrutiny than
   intended in IETF working groups and the IESG.

The proposal literally says "stop performing more scurtiny than
intended".  The lower quality of the documents at Proposed is
an explicit goal of this proposal.  When this proposal is adopted,
good quality for documents at Proposed is only going to happen
by accident, but no longer by peer review and scrutiny.



I believe that this proposal is based on a premise that is inverse
to reality.

The real causality is:

  - very few Working Groups go through the effort on fixing or
    improving documents once they're published as RFCs, which,
    for standards track documents usually means, they stay at
    proposed for years

  - the widespread adoption of protocols & specifications on the
    internet happens based on specification that are at Proposed,
    if it happens at all.


And the logical consequence of Working Groups not updating and fixing
Proposed Document specification within a year after publication as RFC,
in order to improve interoperability and the quality of the specification
on which the software is based that runs the internet -- is to apply
more thorough peer review and scrutiny at that point of the
standardization process that can not be evaded by WG constituencies,
before the adoption of the specification as Proposed Standard.


I recently saw a proposal (by a WG chair) to adopt a new charter item
following a list of 3 WG documents at or heading for PS:

  The WG will attempt to avoid gratuitous changes to these protocols.

I do not believe that such a statement is motivated by the three
maturity levels for documents, but rather caused by constituencies
and emotional engagement by individuals with documents they authored
or contributed to, that do not want specification to be updated,
fixed or changed after these have been published as RFC.



I don't think this reflects the current status quo in the slightest.  
I think our current PS maturity is essentially considered production  
quality, although we anticipate that clarifications in the  
specification may be required, and consultation with other  
implementors is likely to be beneficial.

Some IETF participants do, some don't, which results in controversy.

My understanding of the IETF standardization process, in particular
with respect to specification at PS is "updating a spec to improve
interoperability is good, reducing complexity is good, i.e.
making stuff optional that is hardly used or creates interop
problems.  And when there are several different extensibility
options in a protocol, some of which with very high interop
in the installed base and some of which with poor interop in the
installed base, then redefining useful features to use the
more interoperable extensibility is useful.

However, there sometimes are constituencies in IETF WGs that take the
position "the PS spec MUST NOT be updated or changed, unless proven
beyound all doubt, that the spec does not work at all".



In particular, for better or worse, the wider internet technical  
community - ie, the people who are aware of, but not involved in, the  
IETF - expect our PS documents to have high quality, and would be  
caught unawares by a sudden shift back to this stance.

+1

I assume that for every IETF spec implementer within the IETF, there
are 10 or more implementors that do not participate the IETF.
And it is for those others that we should produce, and update/improve
our specifications, at least once in a while.



So to make this clear, I think that as the requirements and scrutiny  
of PS documents have increased, the quality has as a result, and -  
undoubtedly more important - the expected quality has also. I am  
suprised that you don't see this as quite apparent.

We have, in general, raised the bar over the years for PS documents,  
and - whether or not you think this was a good idea - this horse has  
left the station, and it's too late to put the lid back on - the  
wider world now expects this.

+1


-Martin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf