jari(_dot_)arkko(_at_)piuha(_dot_)net 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf