--On Thursday, 04 November, 2010 05:50 -0400 Ross Callon
<rcallon@xxxxxxxxxxx> wrote:
> Commenting on one issue from John's email from Sat 10/30/2010
> 4:18am (and ignoring the issue of what John was doing up at
> 4am):
:-)
>> However, a change to the handling of documents that are
>> candidates for Proposed Standard is ultimately in the hands of
>> the IESG. In principle, they could announce tomorrow that any
>> document submitted for processing after IETF 79 would be
>> evaluated against the criteria in 2026 and no others other
>> than reasonable document clarity. If the IESG has the will
>> --and whatever community backing is needed-- to do that, then
>> the "two-step" document is not needed. ...
>
> I don't quite agree with this. I think that if the IESG wanted
> to step back to a "closer to the wording of 2026" process for
> proposed standard documents, then we *do* need to also move to
> a two step process (rather than a three step process). The
> reason is that moving from proposed standard to draft
> standard is a step that isn't worth the trouble. This means
> that most RFCs can't ever get to full standard. If we want the
> first step to really *only be the first step*, 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 won't claim that the two-step document is actually going to
> cause the IESG to make the first step easier. However, the
> IESG has noticed the message from the community that we don't
> want many silly discuss votes to drag out document approval
> unnecessarily, and has done some serious navel gazing on the
> subject.
Ross,
We (the community) are having a serious communication problem
here -- different clusters of us are just not communicating.
In the hope of explaining at least part of the problem, let me
respond to what you said rather than what I'm quite sure you
meant.
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. 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. 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.
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.
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.
If the critical-path problem is that it is too hard to get to
Proposed, then let's address that.
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.)
If we are really going to argue that the number of documents
that move to Draft is so miniscule that whether or not they
advance to Full is irrelevant, then let's either address why
there are so few advancements to Draft or stop talking about
maturity levels entirely, moving either to one-step or to a
different model.
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.
But it has seemed to me that what the current two-step draft
says is "well, too few documents move to Draft, so let's
increase the incentives by eliminating Full"... with absolutely
no evidence that eliminating Full would change the incentives to
move to Draft, or the number of documents that are advanced, by
one iota.
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.
best,
john
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf