Hi Ted,
At 16:25 16-09-10, Ted Hardie wrote:
The attached draft is part of the discussion Russ started up
with draft-housley-two-maturity-levels. It is compatible with,
but does not require a reduction in maturity levels. If you
The -00 draft passes ID-nits. There is a mistake in the XML template
(see Requirements) used to generate the draft. This problem is
apparent in other drafts as well.
In Section 2:
"In practice, IETF document processing has evolved to a model which
can be described as "objection based processing".
I'll only consider WG submissions for simplicity and I have reduced
the "processing" to two stages, the Working Group Last Call and the
IETF Last Call. The Working Group Last Call generally does not use
the "lazy consensus" approach. In other words, there should be
support for a draft for its adoption as a Working Group item and for
it to get through the working group stage. It can be argued that the
IETF Last Call, in general, tends to be "lazy consensus" as there
aren't that many, if any, comments about WG drafts at that stage. I
don't see the model as one of "objection based processing" because to
the first stage.
"The IETF Last Call is, in practice, a way for the larger community
to object to a document or elements within it."
The IETF Last Call is about getting cross-area review. There is a
subtle difference between that and "a way for the larger community to
object". The latter presumes that someone within the IETF community
which is not in the working group has the time and energy to review the draft.
"It is also relatively clear that the energy to object can always
be found in the IETF, even when the energy to sponsor or shepherd
a document is absent."
"Consensus by exhaustion" works well within the IETF. It can be used
to drive away other IETF participants.
I'll open a parenthesis to comment about shepherding. One of the
questions asked is:
"Does the Document Shepherd have any concerns about the depth
or breadth of the reviews that have been performed?"
If the shepherd is chosen by the author of the draft, it is highly
unlikely that the answer will be a "yes".
In Section 3:
"All documents which are published as Proposed Standard RFCs shall be
entered in queue for advancement to Draft Standard, with automatic
advancement to take place two years from the issue date of the RFC."
The requirement for an interoperability report is not mentioned
here. The proposal does not specify what happens if an
interoperability report is not submitted.
I would have suggested the following:
All documents which are published as Proposed Standard RFCs and which
have not advanced to Draft Standard, within two years from the issue
date of the RFC, will be moved to Historic status.
The onus is on the proponents of the RFC to submit an
interoperability report. There should be an option for the author to
ask for Informational instead of Historic if the specification is still in use.
"If no document shepherd comes forward, the objections are
automatically sustained and the document remains at Proposed
Standard."
That would keep some documents at Proposed Standard for a long
time. One question that comes to mind is whether it is the
responsibility of the IETF to find a shepherd or if it is for the
author to do so. This is similar to the problem of how authors can
get reviews for their draft. I'll elaborate on that even though it
is not relevant to the discussion.
A person writes a draft. He or she does not know how to get people
to review the draft. As the person has not reviewed other drafts
before, he or she might find it difficult to convince someone to
write a review. As the saying goes, I scratch your back and you
scratch mine. In plain English, if you review other people's drafts,
it would be easier for you to get people to review your draft. If
you don't have the time or energy to do so and everybody does that,
the mechanics won't work.
In Section 4:
"Those who are entering errata for a published RFC should indicate
whether they believe the issue raised is sufficient to block
advancement."
That turns an errata into a DISCUSS. I don't think that the errata
mechanism should be used like that as it is going to create more
problems than it will solve. If errata becomes a discussion forum,
it will be more work for the Area Directors.
"Any individual who has been banned from the IETF main list may not
post an objection, and repeated frivolous objections should be
considered grounds for removal of posting rights."
If this draft moves forward, that sentence will probably be
removed. I am not going to comment on that point for now but I understand it.
In Section 8:
"If the broader Internet community is judging protocol maturity based on
standards level, there is some risk that changing the mechanism by
which documents advance along the standards track may require that
judgement to change."
If the broader Internet community is judging protocol maturity based
on the RFC brand, there is nothing the IETF can do about it. Some
people view "Proposed Standard" as being a level above "Draft
Standard". Some authors do not even read BCP 78 even though they
state compliance in their draft.
There is an presumption of mutually assured destruction in the
current discussion model. Those that have nothing to lose have
nothing to fear.
Regards,
-sm
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf