Hi John,
On 12/03/2012 12:29 PM, John C Klensin wrote:
--On Monday, December 03, 2012 11:28 +0000 Stephen Farrell
<stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie> wrote:
Encouraging running code is a Good Thing. Publishing sloppy
specifications is a Bad Thing.
Sure. I guess I'd hope that we push back on sloppy specs as
usual, but that the running code might make that less likely,
or at least more likely to be just editorial.
Stephen,
I agree with Brian, but want to reinforce thinking about this a
little differently and in a way that may draw several other
sub-threads together. The IETF is functioning here as a
standards body, not an certification body for implementability.
Knowing that something can be implemented, and implemented at
production quality, has traditionally been an IETF hallmark (and
hence part of Dave Clark's slogan) relative to other bodies who
have standardized the un-implementable. IMO, when we approve
something as a Proposed Standard, it suggests that we have
evaluated and approved it along three quite separate dimensions:
(1) Utility of the idea as something that should be
implemented (or at least as a decent and reasonable way
to do something)
(2) Quality of the protocol and whether the
specification adequately describes it.
(3) Whether the specification can be implemented
Failures are possible on any of the three. It is possible for a
well-specified and implementable idea to be utterly useless. It
is possible to have a useful and well-designed protocol, with
implementations by insiders, to be so badly described that it is
unlikely that anyone else could figure out how to implement it.
It is, as Brian pointed out in his recent note, possibly to have
a hack-level implementation and/or one that doesn't work in the
edge cases.
Using any of those three in a way that enables shortcuts around
the other two puts us at risk or creating bad standards. Even a
few bad standards could be used to hold the IETF up to ridicule
in ways that would weaken everything else that we do for a long
time... and the fact that we saw them as the result of a process
experience would be no protection at all. Worse from the
standpoint of a speed-up procedure, someone's discovering a
problem after a hasty IESG approval could easily lead to an
appeal on the grounds that the process used did not allow for
adequate review, a result that would cost far more time than the
difference between the current and proposed procedure.
As others have pointed out, there are lots of other ways to
speed things up, most of which fall within the discretion of
individual WGs, ADs, and the IESG without any changes at all.
At least a few of them would involve "changes" back to what RFC
2026 already specifies, including treating Proposed Standards as
Proposed Standards, and eliminating, e.g., days or weeks or
post-IETF-Last-Call AD nitpicking over text in favor of
practicing the intent of the "no known technical defects" rule
of 2026 and letting the RFC Editor do their job. But "you claim
to have done consideration 3, therefore you get to shortcut
considerations 1 and 2" should not be one of them.
So are "hasty" and "shortcut" maybe pejorative ways of
saying that we cut out some of the "nitpicking" ;-)
Anyway, I'm not suggesting we forget #1 or #2 at all and
yes some or maybe all of what's proposed could already
be done but I think its notable that that is not being
done, so the proposal is a 3933 experiment to see if
putting some more emphasis on #3 will work or not.
So I do hope we run the experiment.
S.
best,
john