John, In your "choices" below, choice i and ii are not quite separable. In the "do nothing" mode i, eventual advancement required to de-queue the "would-be Draft Standard" will only happen if choice ii is in effect. In other words, choice ii is effectively the same as choice i except that the duration of the "do nothing" phase is shorter (by an arbitrary amount). -- Eric Gray --- [SNIP] --- --> (From Eric Rosen) --> --> > Frankly, I think this wavier procedure is outrageous, --> > and entirely unacceptable. The fact The fact that the --> > referenced document has not gone through some bureaucratic --> > process does not mean that it is any less stable, or that any --> > more caution is required in its use. Inserting this --> > derogatory language about technology which may be well-proven --> > and widely deployed will be extremely misleading to the --> > industry. --> --> (your response) --> --> If a WG agrees with you about a particular piece of technology, --> they have three choices: --> --> (i) Do nothing, in which case their would-be Draft --> Standard will sit in queue until that well-proven and --> widely -deployed technology is, itself, advanced to --> Draft Standard (or to not try to advance their Proposed --> Standard to Draft Standard at all). --> --> (ii) Pick up the obviously well-documented definition of --> the well-proven and widely deployed technology and --> advance it to Draft Standard. --> --> (iii) Invoke the RFC 3967 procedure for downrefs, which --> is more burdensome in terms of processing than the new --> proposal, but does not involve disclaimers. You can --> think of the RFC 3967 procedure as requiring a community --> determination that the referenced technology is stable --> enough to be referenced in a document of a given --> maturity level. --> --> So the proposed new rule adds one option to the three that are --> there already. It is up to the WG (or individual submitter) --> which one to use. This one is intended to be much more --> lightweight and quick than any of the existing options, but no --> one is forcing its use. And I assume that, if it is found too --> unpleasant or derogatory, then no one will use it and it will --> disappear after a year. Personally, that wouldn't bother me one --> bit -- you will recall that I have proposed and/or backed much --> more radical and extensive solutions to this type of problem -- --> but that is a rather different discussion. --> --> > I think that any rule which requires us to insert false --> > and misleading statements in the documents should be strongly --> > opposed. --> --> But there is no requirement that this procedure be used at all. --> If I writing a document that needed to reference a specification --> that was as well-defined, mature, and stable as you posit, I'd --> first try to get that specification advanced to the right --> maturity level or, if there was some bar to doing so, I'd invoke --> the RFC 3697 procedure. Or I might try to build consensus for --> some serious discussion and action on --> draft-ietf-newtrk-promotion-00.txt, which essentially proposes --> fast-tracking the advancement of such specifications on the --> basis of their marketplace acceptance (and which is showing --> signs of vanishing without a trace). --> --> > Even worse: --> > --> > "The IESG may, at its discretion, specify the exact text --> > to be used" --> > --> > Great, not only is the WG required to denigrate its own --> > technology, but the IESG is given free rein to insert whatever --> > derogatory remarks they feel like putting in. --> --> First, this seemed appropriate for an experiment of the type --> specified. In addition, like it or not, current procedures, as --> practiced, essentially give the IESG free rein to insert --> whatever remarks (derogatory or otherwise) they feel like --> inserting in anything. They are prevented from doing so by some --> combination of good sense and the presence of the appeals --> procedure, which is exactly what the paragraph you complain --> about below says... --> > --> > Of course, we'll be told not to worry, since: --> > --> > "If members of the community consider either the --> > downward reference or the annotation text to be --> > inappropriate, those issues can be raised at any time --> > in the document life cycle, just as with any other text --> > in the document." --> > --> > Great. Another useless thing to argue about in the WG, and --> > another useless thing to argue about with the IESG. --> --> But the assertion you are making about a (e.g.) Proposed --> Standard specification being stable, mature, well-defined, --> widely-deployed, etc., is one that presumably should get some --> community review, rather than simply being accepted as the --> result of the divine rights of the author/editor. And that --> brings us back to the three existing choices above, which the WG --> presumably needs to argue about today. The WG's only choice --> without such an argument is to not try to advance any document --> that would require a downref... and that is an opportunity to --> argue as well. --> --> > There are also other reasons why I find this --> > proposed experiment disheartening. --> > --> > For one thing, it really misses the point. We need to --> > simplify our processes, not make them more complicated. --> > Either we need the downref rule or we don't. If we want to --> > experiment, let's experiment with eliminating the rule --> > entirely, not with fine tuning it. --> --> I don't know how to do that and still get back if there is a --> conclusion that it wasn't a good idea. And, remember, I have --> proposed more radical solutions to the underlying problem here. --> It is evident at this point that they lack adequate traction --> (people who care) and consensus, so adding a lightweight option --> within the current framework seemed to be an idea worth --> exploring. --> --> > The real underlying problem of course is the the --> > multi-stage standards process is just a relic from another --> > time, and makes no sense at all in the current environment. --> > Experiments in fine tuning the process are nothing but a --> > distraction. --> --> Well, we disagree about that. Perhaps more important, there is --> little evidence of community consensus for that position --> although it certainly has several loud advocates. I suppose one --> can rationally oppose any proposal to make the current system --> work better on the grounds that it should be made to work worse --> in order to gain more traction for getting rid of maturity --> levels. Maybe, from that point of view, you should support this --> on your theory that it will create more arguments and bog things --> down further. On the other hand... --> --> john --> --> --> _______________________________________________ --> Ietf mailing list --> Ietf@xxxxxxxx --> https://www1.ietf.org/mailman/listinfo/ietf --> _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf