> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf