Thanks for the comments, some replies inline.
On Fri, Sep 17, 2010 at 1:39 PM, SM <sm(_at_)resistor(_dot_)net> wrote:
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.
Thanks for letting me know.
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.
This is a good point. It is really late-stage processing that works mostly by
resolving issues (especially the IESG processing, but to a lesser extent the
Last Call processing). I will update the description in the next version.
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.
Any review that produces useful input is generally accepted by the document
authors. But only objections really change the processing from that
point on, but creating a requirement to resolve them before moving on.
In other words, the document processing state machine can only change
here if an objection is lodged.
"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.
Noted.
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".
Agreed. But the shepherding and initial document and shepherding
the resolution of an objection are a bit different. Perhaps a different
term is needed to make this clear. What I propose is that
after an objection is lodged to advancement, that the IESG will determine
whether it is a valid objection, based on input from the objector and
the work of the shepherd.
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.
This proposal does not require an interoperablity report.
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.
I think this proposal is closer to Keith's thinking than mine. My personal
belief is that neither the carrot nor the stick has been particularly effective
in eliciting interoperability reports and efforts to move to draft. Given that,
we can rest on a single-stage system in the common case or use something
else to signal to the larger community how mature a standard is.
This proposal uses a time-and-consensus call approach.
If you believe that there is energy to use the interoperability-test based
current system, then there is no need for the the change this proposes
"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.
I think if no community member is interested in resolving an objection, then
the document is not needed. I understand the issue that the author may
be an interested party and may offer to shepherd. That could set up
an unfortunate author-vs-object dynamic. The IESG still judges,
however, and can determine
whether the objection should be sustained.
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.
Do you think the presence of serious errata would currently prevent an
AD from taking an existing document through the advancement process,
even if implementation reports were received? I do, but this may be
a question of interpreting "serious".
"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.
Noted, but this still leaves the final decision in the hands of the IESG.
The upshot, though, is that any mechanism which shifts most drafts
up the ladder will increase the overall workload. I've tried to lower
the friction for the "easy" cases and distribute it for all cases. But
that doesn't create new energy. If too much of the new energy
required comes from the IESG, this will obviously have other bad
effects. Further input on how to better distribute the load is welcome.
regards,
Ted
Regards,
-sm
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf