On 13 Mar 2004, at 4:21 pm, John C Klensin wrote:
<snip>
(1) In your example above, I suggest that, with the amount to scrutiny
now going into getting things to Proposed, the types of problems you
identify above would be detected there and dealt with. And, if they
were not, we have a more serious problem than criteria for draft (in
today's world, not an ideal one).
(2) We need to look at the system as it exists, not in how things
might work if, e.g., everything got the perfect levels of review at
the perfect time. If we do that, our situation today is that
documents go to Proposed, with whatever quality of (typically
pre-implementation) review they get. They get published. Now,
consider what might happen next, in an environment in which, for
whatever reason (and I think both your observation about
implementation reports and mine about document-fussing and general
pain are part of the problem), we move almost nothing to Draft...
<snip>
To which I reply:
Hi John, folks,
When I pass my driving test, the Examiner doesn't consider me to be a
good driver; merely that
I'm unlikely to kill someone so readily.
I had thought that this was the analogy for Proposed, but this hasn't
been my experience; protocol quality
is often considered before we get that far.
Given the amount of time we take to raise things to Proposed, *if
people are serious about the protocol*
then there may well be implementations out there already - a number of
protocols have had interoperation
tests whilst still I-Ds, simply due to the glacial nature of the
process (i.e. people are overloaded)
and the requirement for quality (or "perfection", depending on who's
saying it).
Thus the suggestion that implementation reports alone are the key to
moves to Draft is interesting; do
we merely document the interoperation test results and (skip/fast-track
past) Proposed altogether?
Unfortunately, describing the rationale and operation of a protocol is
not easy, and IMHO one of the
main drivers for issuing a new RFC is to clarify things that were
understood differently by different implementation teams - for example
with ROHC, the first interoperation test exposed that just about
everyone interworked, but everyone had got the bit order wrong on the
checksum as they interpreted
the text that way. Note - this isn't a mistake in the protocol, so
putting this into the errata
collection is not appropriate. It is however a gotcha, so an
Implementer's Guide (i.e. when it says
this, they mean that) is useful.
It's this documentation step that is needed for some poor sot who has
to use this stuff, and it
isn't clear to me that it's the main driver for further steps "up the
standards track".
A statement that this feature in section 12.3 and that feature in
section 13.4 interworked between
implementation X and implementation Y may be true, but not necessarily
complete if someone doesn't
understand what's in section 12.3 or 13.4 in the same way.
Didn't this organisation used to be about defining protocols *and*
experience through using them?
all the best,
Lawrence