+1 to the proposed rules for reclassifying DS to IS. I think they offer a
reasonable balance between expediency and quality.
Ned
On 1/24/2011 12:37 PM, Russ Housley wrote:
> draft-housley-two-maturity-levels-03 was just posted. ...
Overall I find this spec to be an improvement over the previous version.
Here are a few areas where improvements can be made.
====
This phrase in Section 1:
In addition,
IETF working groups and IESG members providing much more scrutiny
than is called for by RFC 2026 [1] prior to publication as Proposed
Standard.
is not a sentence. Should it be "provide"? Should it be "have been
providing"? Something else?
====
The sentence in Section 1
One desired outcome is to provide an environment where the
IETF community is able to publish Proposed Standards as soon
as rough consensus is achieved.
and these sentences in Section 2.1:
The intention of the two-tier maturity
ladder is to restore the requirements for Proposed Standard from RFC
2026. No new requirements are introduced; no existing published
requirements are relaxed.
together lay out what is required for PS. Disregarding the other
arguments over the word "restore", these sentences are otherwise fine
and dandy.
But I think there needs to be further guidance provided to the IESG and
Working Groups on how they should change their behavior. What is wrong
with how the WGs and IESG are currently interpreting the rules of 2026
for PS? What current behaviors differ or have gone beyond what 2026
requires, and hence need to be changed to restore those requirements?
Without such guidance, nothing changes.
====
One major section that has been removed from the previous version of
this I-D is what to do with documents currently in the Draft Standard
status. I know that there was significant disagreement with the
"automatic reclassification to Internet Standard" proposed before, with
good reason.
I'm going to letter the the rules in section 2.2 as follows. I'm also
going to indicate how these sort of map into the old classifications:
a) technical maturity (DS => FS)
b) belief in significant benefit to Internet community (DS => FS)
c) significant number of implementations with successful
operational experience (DS => FS)
d) no unresolved errata (PS => DS)
e) no unused features that increases implementation complexity (PS
=> DS)
Some people have argued that having a significant number of
implementations (c) is sufficient to demonstrate both technical maturity
(a) and the belief in benefit (b). The (d) and (e) requirements have
already been demonstrated by virtue of those RFCs already being at DS
status, although additional errata may have been filed against the DS.
So I'm going to suggest that the following be applied to documents that
are currently in Draft Standard status:
Any protocol or service that is currently in Draft Standard status,
without
significant unresolved errata, may be reclassified as an Internet
Standard
as soon as it can be demonstrated to have a significant number of
implementations with successful operational experience.
This reclassification may be accomplished by filing a request with
the IESG,
detailing the Implementation and Operational Experience. After
review, the
IESG will hold an IETF-wide Last Call on the reclassification. If
there is consensus
for the reclassification, the RFC will be reclassified without
being reissued.
Protocols and services that have significant unresolved errata will
need to be
re-issued to resolve the errata before the above criteria can be
applied.
Of course, there is still an open question what it means to have a
"significant number", which will remain as subjective as it was before
with the 2026 rules.
Tony Hansen
tony@xxxxxxx
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf