I don't see proceeding by small, incremental changes to be a
problem. Indeed, I usually consider it an advantage as long as
there is reasonable confidence that the changes that are made
won't foreclose real solutions later...
This is my understanding of what is proposed.
...That risk can never be
completely eliminated, at least without a comprehensive
long-term plan, but I'm asking only for reasonable confidence.
Such confidence would arise, for example, from a clear statement
of a particular, appropriately-narrow, problem and a logical
explanation as to why a proposed solution will focus narrowly on
it and fix it.
The document currently states:
These changes are designed to
simplify the IETF Standards Process and reduce impediments to
standards progression while preserving the benefits of the IETF
engineering approach.
Would you be happier adding some sort of statement along the lines of:
The changes proposed in this document are focused on reducing the
number of steps in the progression of standards track documents,
and to the reduction of limitations based on downrefs. This
document does not consider other changes, and is not intended to
discourage nor to prevent any additional process changes which
may be proposed and progressed independently.
I think that something along this lines might help to clarify the
intent of the document (assuming that I have correctly understood
the intent).
...Again, that explanation doesn't need to be
proof to mathematical certainty, just something that is able to
be examined logically and that seems to have a rational
cause-and-effect relationship to the problem it is intended to
solve.
Mathematical certainty is not going to happen in this area.
I also don't think there is anyone in the community who believes
there is no problem with the way maturity levels are now handled
and used, at least no one who has been awake during the last
many years.
I am concerned that there is a clear problem with the three step
process that might not get fixed because people are arguing
issues which are large orthogonal to whether we would be better
off with two steps or with three steps.
But what we have been given isn't the kind of "stated problem
and plausible solution to it" analysis suggested above. What we
have instead been given is fairly close to a statement that the
IESG gazed upon its collective navel and, in the depths of said
navel, found a revelation that eliminating full standard and
renaming Draft would cause a miracle to happen, where that
miracle is that various fairly-unspecified problems will be
solved.
I haven't noticed any statement to the effect that a miracle is
going to happen, nor that all unspecified problems will be solved
by this particular document. Nor have I noticed any statement
precluding additional orthogonal changes being proposed by others.
If the critical-path problem is that it is too hard to get to
Proposed, then let's address that.
I think that moving to a two-step process, rather than a three-
step process is *necessary* to simplify the effort to make it
easier to get to proposed. I don't think that it is *sufficient.*
If people want to propose other changes to make it easier to get
to proposed then please write up the other changes in another
document.
The problem isn't that nothing moves to Draft or Full Standard
under the current rules because some things do. Perhaps there
is an issue with the characteristics of those that do or don't
and perhaps understanding that would be a useful exercise. From
my own observations, it differs somewhat by topic area (which
may or may not align with IETF areas). If that is the case,
shouldn't we be looking both at the differences and at whether
some area-specific rules would be in order? (Note, fwiw, that
draft-klensin-isdbis explores just that option, rather than
taking the more global approach of its predecessor.)
Feel free to start this exercise. I suspect that you are probably
correct that there is some variation by area (for some definition
of "area").
Rephrased into your language, "we need a second step that will
actually be worth enough that someone will take the effort to
follow it for the vast majority of useful standards." I think
that assumes that changing the name of "Draft" to "Full" will
provide that value. I see no evidence of that whatsoever
--other than wishful thinking-- largely because I think that the
main reason things don't advance to Draft today is that there is
no real incentive to reopen documents after Proposed, especially
if the protocols are already deployed and the WG (or whatever)
process was exhausted of all energy in getting _to_ Proposed.
No evidence has been offered that eliminating Full Standard will
change that.
I agree that if we move to a two step process the incentive to take
the second step will still be small. I don't think that there is
any way to accurately predict whether this small incentive will be
sufficient to cause the second step to actually happen, unless we
try the process change and see what happens. It is pretty clear
that with a three step process the incentive to take the second
step is insufficient.
...
So, let's stop the navel-gazing and move to a realistic and
focused analysis and explanation of what problem we are trying
to solve and why any particular proposed measure will solve it.
I think that you are expecting Russ' document to solve more problems
than it is intended to solve. It solves two problems: The three step
process is obviously at least one step too many (thus two is better
than three, which does not address the issue of whether one step is
better or worse than two steps). The downref rules discourage document
advancement.
That is all that Russ' document solves. If you want to solve other
problems, you are free to propose fixes, but don't expect this one
modest document to solve a wider range of problems.
I can see that if we were to agree and put two-step into place, then
it would likely take at least a couple of years of trying it out
before we are likely to be willing to consider going from a two-step
process to a one-step process. Personally I haven't seen any consensus
that we should go directly to one-step.
Other changes to the process can be considered, should be considered
independently and we should not expect Russ's document to either
propose nor to preclude any other changes that people want to consider.
It makes sense to me to explicitly state that this document does not
preclude other orthogonal changes to the process.
Ross
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf