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(_at_)ietf(_dot_)org
--> https://www1.ietf.org/mailman/listinfo/ietf
-->
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf