Re: Uneccesary slowness.
Date: 2005-05-30 14:15
From: Eliot Lear <lear(_at_)cisco(_dot_)com>
While recognizing that good is the enemy of great, I would hate if a WG
felt so under the gun to complete in order to get shlock out the door.
I can demonstrate several examples of that.
Hear, hear.
Bob Braden also suggested that it might be useful to talk about
necessary slowness.
We've heard plenty from a few about the need for timeliness, but
the gist of much suggests not mere timeliness, but extreme haste.
There is also the issue of carelessness or worse in pursuit of
haste. For example, in preparing an Implementation Report
regarding a specification in a Proposed Standard RFC WXYZ (the
numbers have been changed to letters to protect the guilty), an
author, or WG Chair might do something like:
grep -l WXYZ rfc[W-9]???.txt
and use the resulting numbers in a statement such as "RFC WXYZ
has been referenced by at least N different RFCs:".
Now it is no state secret that in certain ranges of RFCs, RFCs
numbered ending in 99 are summaries of RFCs, and those ending in
00 are summary lists of Standards Track RFCs. Neither of which
actually *reference* RFC WXYZ's specification per se if WXYZ
happens to be listed in those summaries.
Nor does an RFC which happens to include some text such as
"11:42:07.7WXYZ8" or "(21WXYZ56794567,9738234567)" necessarily
reference RFC WXYZ.
What is claimed, viz. that "N different RFCs" "referenced" RFC WXYZ,
is not in fact what is hastily found, viz. that N RFCs contain the
string WXYZ in some context which may or may not be relevant to use
of RFC WXYZ's specification (admittedly, the accurate latter statement
sounds less impressive, but then Implementation Reports aren't supposed
to be marketing blurbs). At best that is carelessness in formulating
a regular expression, compounded by carelessness in checking the output
of grep, further compounded by a misleading claim about what is
presented.
When such an Implementation Report goes on to make a claim, based on
that bogus number N, such as "M% of the RFCs published since RFC WXYZ
have seen fit to reference it!" (yes, including the exclamation point),
the original distortion of facts is yet again compounded.
Now it's clear that xy00 and xy99 RFCs shouldn't have been included in
such a list, nor should those RFCs which merely happen to have "WXYZ"
appear in some string be included unless those RFCs *actually* do
reference RFC WXYZ. A mere *moment* of thought should have convinced
the preparer that something was awry.
It would be amusing, were it not sad, that such a list of RFCs includes
an April 1 RFC (3092) whose only "reference" to WXYZ is to point out
that the sequence of characters "foo" appears in RFC WXYZ (and RFC WXYZ
is not listed in any way as a reference).
It is not at all amusing that such an Implementation Report passes IESG
review with apparently nary a comment about the xy00, xy99, and April 1
RFC bogons listed. So much for the theory that the IESG acts as an
effective quality control backstop.
It certainly looks like WGs aren't the only groups cutting corners "to
get schlock out the door".
I think Bob Braden was on the right track. Sometimes it does take a
millisecond or two to make sure that we're doing things properly.
I certainly hope that those focusing hard on wall clock time wouldn't
suggest that the case study above (definitely not hypothetical) is the
sort of low-quality work that we should be shoving out the proverbial
door.
Not only is good the enemy of great, lousy is the enemy of good.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf