Joel,
Please see my comments below...
--
Eric
--> -----Original Message-----
--> From: Joel M. Halpern [mailto:jmh(_at_)joelhalpern(_dot_)com]
--> Sent: Wednesday, May 24, 2006 4:11 PM
--> To: ietf(_at_)ietf(_dot_)org
--> Subject: Re: LC on draft-mankin-pub-req-08.txt
-->
--> Reading this, a few items caught my eye.
-->
--> The POSTEDIT requirements seem to be worded as if it is desirable
--> to minimize the changes that the document editor makes, or even the
--> changes the document editor can make. The general tone of "don't
--> mess with the words we have carefully honed" is understandable.
--> However, in practice many of the words have not been carefully
--> honed. And they need to be. For example, there is a document I
--> just reviewed to which my personal reaction is "this needs massive
--> editing." It is not technically wrong. But the language use makes
--> it hard for the reader to understand what is intended. I would
--> sincerely hope that if it is approved as-is by the IESG that the RFC
--> Editor would edit the document.
-->
I believe that people are leaning in the direction of
requiring authors to do a better job before gaining approval
required to put the remainder of the job on the RFC Editor's
desk.
As worded now, it seems as if the cases to which higher
numbered requirements (in the series under discussion - i.e.
- requirements Req-POSTEDIT-3, 4 and 5) have progressively (or
incrementally) greater restrictions on their applicability to
documents generally. I think this is as it should be and it
may well be the case that future IESG approvals may include a
note as to which levels of editing may be applied to a given
draft document.
-->
--> In general the editor has little or no way to tell which words are
--> "carefully crafted." I would hate to have a presumption that all
--> the words a sacrosanct.
-->
I am reasonably sure that this is not as difficult as
it sounds. For one thing, if the current draft revision is
-23, we can be reasonably sure that tweaking anything that
is not clearly a typo or spelling error will be a case of
modifying "carefully crafted" wording.
On the other hand, modifying wording of a revision -02
(or lower) document that is laced with typos, spelling and
grammatical errors from end to end (the "massive editing"
example you gave) is unlikely to fall in the same category.
I believe we can expect a technical editor to use their
own judgement between these two extremes - at least in most
cases.
-->
--> I realize that the text calls out the special case of "don't touch a
--> letter of this", and even acknowledges that it is a rare case. But
--> the wording of the earlier text is not in line with that.
--> Specifically, POSTEDIT-4 reads "The IETF Technical editor should
--> refrain from changes to improve readability that may change
--> technical and consensus wording." This appears to be a directive
--> that prohibits almost all changes, since in a formal sense all the
--> words in an WG and IETF LC approved document are "consensus wording."
--> That leads to what I consider a bad situation where we have
--> essentially prohibited the editor from editing.
-->
Bearing in mind that asking someone to "refrain from"
doing something is a far cry from "prohibiting" it, see my
comment above.
-->
--> On a related note, POSTEDIT-3 seems to be inadvertently worded too
--> strongly. It prohibits changes which "introduce a substantial
--> review load but only provides incremental increase in the clarity
--> of the specification." However, by definition any change at all,
--> even a significant change that transforms a document from
--> unintelligible to highly readable, is always an "incremental
--> increase in the clarity of the specification."
-->
Here I must confess to some sympathy. Like me, you
probably cringe when you here the phrase "more granular"
because this usage is just wrong. However, in this case,
one of the established definitions of "incremental" is:
"A slight, often barely perceptible augmentation."
It might be better to choose a less ambiguous word,
but I believe the meaning is clear.
-->
--> With regard to the metrics, [...]
--- [SNIP] ---
I agree with your other observations and suggestions.
-->
--> Yours,
--> Joel M. Halpern
-->
-->
--> _______________________________________________
--> Ietf mailing list
--> Ietf(_at_)ietf(_dot_)org
--> https://www1.ietf.org/mailman/listinfo/ietf
-->
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf