Re: Conclusion of the last call on draft-housley-two-maturity-levels

[Mykyta Yevstifeyev <[e-mail]>]

10.09.2011 17:44, Russ Housley wrote:
> Mykyta:
>
>> Taking into account the controversy we all are able to observe on the mailing list, I'd like to point out several points.
>>
>> 1) Did the IESG consider processing this as RFC 3933 process experiment?  (I actually don't know whether such approach has already been proposed during the discussions, and whether there has been some outcome, so, if this has already been proposed, just re-consider.)  I personally see no "consensus" or "rough consensus" for this document being approved as BCP, i. e., on the permanent basis, but as some people claimed that this might be useful, processing the document as Experimental process RFC will allow to make the final judgment based on the actual experience, not the assumptions.  As soon as we find out that two-tier maturity levels system works, the BCP will be simple to be written and published; if we reach the agreement that "this is a bad idea", then the proposed experimental change will be rescinded, and the maturity system will be returned to the 2026 model.
> I do not recall the whole IESG discussing this idea, but I did consider it.  I did not consider it a good fit, and until now, no one else seemed to even consider it.

See my previous message.

>
>> 2) How do we make the consensus judgment (in this particular case)?  As IETF is based on "rough consensus" model, rough consensus may only be claimed if the consensus-qualifier (a WG chair or Sponsoring AD, in case of Individual Submission) reaches the inner conviction that the idea proposed in the document satisfies the community, or at least its predominant part.  Since IETF has no formal membership, the "community" size may not be determined precisely, and we take into account those folks who participate in the discussion (who, correspondingly, found themselves interested in the discussed topic and are assumed to be knowledgeable in it) in the WG, or elsewhere.  So now, when many of the most experienced and most knowledgeable members of our community claim that the proposed change is not a good idea, or is a bad idea, or there is no actual problem, or there is a problem but its proposed solution isn't fine and has some omissions, or there are a number of other problems which are also to be fixed, or something else, I actually have no idea how the consensus-qualifier (in our case, Sponsoring AD - Jari Arkko) may claim "consensus" or "rough consensus" for, at least, adopting it as BCP.  (I'm not following the thread closely, but this is what I see from those messages I eventually read.)
> I think that Jari explained his thought process, at least twice.

Well, what Jari explained is that (how I understand), there were 
thoughts like "good minor change", and other thoughts that don't support 
the change but, due to lack of "reasonable reasons" for people opposed 
to the change to think so, such thoughts may be overlooked.  Whereas 
there might have been such positions, I don't think such approach is 
good to claim "community consensus".

"Status of This Memo" boilerplate for BCPs include the following statement:

> It represents the consensus of the IETF community.

Does that mean "IETF community consensus"?

>
>> 3) Do we actually need to make cosmetic changes to our process documentation?  RFC 2026 was published in 1996, and precisely 15 years have passed.  RFC 2026 is really morally obsolete, and, in presence of RFC 4844, that defines RFC submission streams, was to be revised closely after it was published.  I see a number of drafts proposing revisions of RFC 2026 at<https://datatracker.ietf.org/doc/search/?name=Internet+Standards+Process&rfcs=on&activeDrafts=on&oldDrafts=on>, but none of them were processed.
>>
>> BTW, RFC 1310 was published in 1992, RFC 1602 - in 1994, and RFC 2026 - in 1996.  I don't believe something happened in 1996 which made the procedures unnecessary to be aligned with the current practice.  The only changes made were IPR documents, PS->DS reports reqs, and IESG procedures for review of Independent Submissions and IRTF stream submissions.
>>
>> More precisely, don't we need to revise RFC 2026 rather than make separate changes to it?
> Please take a look at the minutes of the PUFI BOF held at IETF 71.  The IETF community seems to think that process changes fall into one of two piles.  Either they are too insignificant to be worth the trouble or they are too big and onerous to consider.  The experience with this draft does not disprove those results.
>
> That said, at the plenary at IETF 81, Harald suggested that we have waited so long that incremental improvements may not be the right approach, rather it was time for 2026bis.  I agree that it is needed, but I am not sure the IETF community is willing to tackle a project of that size and complexity.

I concur here entirely.  (Were we revising process documentation on the 
regular basis, this wouldn't be a problem, though.)

Mykyta Yevstifeyev

>
> Russ
>
>