ietf
[Top] [All Lists]

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

2011-09-10 09:44:30
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.

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 w
 hich 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.

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.

Russ

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf