Re: Discussion of draft-hardie-advance-mechanics-00.txt

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

 



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


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