Re: Last Call: <draft-housley-two-maturity-levels-08.txt> (Reducing the Standards Track to Two Maturity Levels) to BCP

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

 



jari.arkko@xxxxxxxxx wrote:
Keith,

However, as with most things I don't think there are hard and fast
rules.
I agree that such things need to be described, but I don't think this
description should be gated on, or wait for, advancement in grade.  The
errata mechanism can be used to report some kinds of vulnerabilities;
separate RFCs for others.

Right now we have this expectation that we're going to rewrite the entire
RFC just to declare something as DS.

I do not think we currently have that expectation. I do realize that we've
debated several cases and the need or lack thereof for additional changes.
But in general, a document that advanced is not expected to be rewritten.
At least not in my opinion. When I review -bis or -ds documents I usually
focus on the rfcdiff output between the old RFC and the new draft.

I also do acknowledge that we (the working groups and the IESG) have made
several errors in this respect, sometimes doing more than should really
have been done. But I do not think we have the expectation that all -ds
documents should be rewritten. That would be wrong.

It is good to read this is recognized, especially for people who wish to remain on the sideline as online participants and depend on engineering common sense an faith among their peers and the IETF/IESG leaders and really don't have the time to be getting involved deeply in the IETF process.

I don't think anything is cut and dry, but I will note an increasing concern that in the name of fast tracking, politics and "who you know," there have been a perception of "rubber stamping" BIS work. Overall, not necessarily a bad thing, but serious care should be taken when existing base of protocol users are now asked to change again. When done at the expense of ignoring input as watered down concerns using "rough" consensus to exclude what is otherwise a less than 50%, but nonetheless significant weight of people, then the real losers is the IETF process and the IETF future. [I personally believe, the Rough Consensus model needs a serious review on how its applied today.]

I personally can recognize the need to move documents faster, but if only to serve as a reminder, it should not come at the expense of the long held guidelines the IETF/IESG has followed to make sure "errors" are not made. If anything, the two-maturity level proposal should increase the engineering expertise and scrutiny requirements for reviewers.

--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com




_______________________________________________
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]