> Re: Uneccesary slowness. > Date: 2005-05-30 14:15 > From: Eliot Lear <lear@xxxxxxxxx> > 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf