--On Thursday, 01 June, 2006 10:49 -0400 Eric Rosen
<erosen@xxxxxxxxx> wrote:
>
>> The IESG plans to make a decision in the next few weeks, and
>> solicits final comments on this action.
>
> If the individual submission is approved as an Experimental
> RFC, does that mean that the IETF will adopt the proposed
> "experiment"? If so, I don't think this draft should be
> approved. (Actually, I suspect the fix is in, but for the
> record ...)
Actually, Eric, I don't have any idea what you are talking
about.
IETF doesn't "adopt" protocol experiments, regardless of how
they are "approved" (some unfortunate language about "process
experiments", which are really quite different,
notwithstanding). Of course, since individual submissions (as
distinct from independent ones) are processed, and in that sense
approved, by the IESG, the IESG can presumably pay as much or at
little attention to them as they think the community finds
appropriate. But that still has little or nothing to do with
this draft.
This draft is addressed primarily --almost exclusively-- to
publication of documents describing standards-track protocols,
not experimental or informational pieces.
> The proposal seems primarily intended to deal with the
> following "problem". Sometimes there are cases in which a
> doc is ready to become a DS, but cannot, because of the
> infamous "downref rule", which states that no DS can
> normatively reference a PS.
That is correct.
> The proposal leaves the downref rule in place, but allows it
> to be waived if the WG is willing to approve derogatory
> text about the referenced technology:
>
> "A note is included in the reference text that indicates
> that the reference is to a document of a lower maturity
> level, that some caution should be used since it may be
> less stable than the document from which it is being
> referenced,"
Until and unless the definitions of maturity levels are changed,
that text is not derogatory, but a simply statement of fact. It
carefully says "may be less stable", which is true. Now, if it
said "...caution should be used because the referenced document
is incomplete and a piece of c**p", _that_ would be derogatory.
But no such implication is present.
> 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.
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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf