Subject: Out of the box proposal

From: Eric Burger <[email-masked]>
Date: Fri, 15 May 2009 14:16:38 -0400

If we really think the problem is 80% of the documents are not ready  
for IESG submission when the WG thinks it is, and if 80% of those  
documents have "classic" bugs, I would offer we do the (gasp) ITU-T  
thing and hire 3-4 full-time, PAID (i.e., IETF/IAD/ISOC staff) experts  
to review submissions before they get to the IESG.

A week or two lag in Editor Purgatory(tm) would be well worth it if it  
saves 50-100 days of AD/Author cycling.

---

From: John C Klensin <[email-masked]>
Date: Fri, 15 May 2009 14:34:41 -0400

--On Friday, May 15, 2009 14:16 -0400 Eric Burger
<[email-masked]> wrote:

> If we really think the problem is 80% of the documents are not
> ready for IESG submission when the WG thinks it is, and if 80%
> of those documents have "classic" bugs, I would offer we do
> the (gasp) ITU-T thing and hire 3-4 full-time, PAID (i.e.,
> IETF/IAD/ISOC staff) experts to review submissions before they
> get to the IESG. 

> A week or two lag in Editor Purgatory(tm) would be well worth
> it if it saves 50-100 days of AD/Author cycling.

That model could also help get documents edited into
intelligible and coherent form before they go into Last Call,
reducing the number of changes that are made in either IESG
notes to the RFC Editor or by the RFC Editor at AUTH48.  That
might take more than a week or two in Editor Purgatory, but
would considerably streamline the process elsewhere and
eliminate several of the risk factors our model of approving
documents for publication.

However...

(1) The possibility of having professional staff do this sort of
evaluation and possible tune-up was why a few of us fought for
more flexibility when BCP 101 was done and again for a
Secretariat model that could contribute more directly to the
IETF's work (I think we tried to make a distinction between
administrative/meeting planning Secretariat and Standards
Secretariat functions at the time).  Without trying to review
the reasons, we lost and lost fairly clearly.  It may or may not
be the right time to reopen the question, but it is a very basic
one.

(2) There are some very significant interactions between what
you suggest and the RFC Editor model and allocation of tasks.
In the present arrangement, where what we are now calling the
ISE (a role that inherently requires considerable technical
understanding) is part of the same organization as the
"Production House" and RSE activities and the three are hosted
in a definitely technical and sophisticated engineering
organization, one can easily imagine shifting some of the
vetting and editing activities from the current "back end" model
to a "partially front end" one.  However, going forward, the
"RFC Production" operation may not be sophisticated enough
technically to perform the sort of evaluation you suggest.  That
would suggest needing to adopt an entirely new structure to
handle the evaluation (remember that BCP 101 requires that the
IASA have only one employee) and to sort out interactions
between that pre-IESG evaluation process and the RFC Editor
(certainly, one would not want to have that evaluation process
make some changes that the RFC Editor function would want to
change back).  If you see  that as a problem, you are running
out of time to complain about it.

    john

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 15 May 2009 11:59:55 -0700

If the process, tools, responsibility and incentives for IESG Approval
are unchanged, then I believe this editor cycle would not materially
reduce the number of issues found by the IESG.  Like code, one can
always find more bugs.  And the importance of a "bug" always looms
large in the eye of the finder.

Perhaps if we suggested to NomCom to select less conscientious ADs?

Lisa

On Fri, May 15, 2009 at 11:16 AM, Eric Burger
<[email-masked]> wrote:
> If we really think the problem is 80% of the documents are not ready for
> IESG submission when the WG thinks it is, and if 80% of those documents have
> "classic" bugs, I would offer we do the (gasp) ITU-T thing and hire 3-4
> full-time, PAID (i.e., IETF/IAD/ISOC staff) experts to review submissions
> before they get to the IESG.
>
> A week or two lag in Editor Purgatory(tm) would be well worth it if it saves
> 50-100 days of AD/Author cycling.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 15 May 2009 21:27:02 +0100

> IETF/IAD/ISOC staff) experts to review submissions before they

I am not clear why you suggest this is an ITU-T thing.

The ITU-T do, indeed, have an editorial staff. They operate on documents 
after they have received the equivalent of IETF last call (that is consent 
at a plenary meeting). This is pretty much the equivalent of the RFC Editor.

It seems that you are proposing an earlier pass by a professional staff. 
Sounds expensive, but maybe the authors/WGs would be willing to see this 
happen to speed up their documents.

I wonder whether there is a volunteer staff who could do this. After all, we 
have several area directorates (including GenArt) who review documents, and 
we have several enthusiasts who like to look at RFCs and raise errata.

Adrian

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 15 May 2009 16:54:40 -0400

On May 15, 2009, at 4:27 PM, Adrian Farrel wrote:

> The ITU-T do, indeed, have an editorial staff. They operate on  
> documents after they have received the equivalent of IETF last call  
> (that is consent at a plenary meeting). This is pretty much the  
> equivalent of the RFC Editor.
>
> It seems that you are proposing an earlier pass by a professional  
> staff. Sounds expensive, but maybe the authors/WGs would be willing  
> to see this happen to speed up their documents.
>

That money would have to be found, obviously, which would be tough in  
the current economic climate.

Regards
Marshall

> I wonder whether there is a volunteer staff who could do this. After  
> all, we have several area directorates (including GenArt) who review  
> documents, and we have several enthusiasts who like to look at RFCs  
> and raise errata.
>
> Adrian
>
>
>

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 15 May 2009 16:56:33 -0500

We have discussed doing the reviews earlier in Gen-ART for the same
reason that folks don't want IESG comments so late -  some folks don't
like some of the Gen-ART comments arriving at IETF-LC time. And, Gen-ART
did move their initial reviews earlier as originally they were only done
when a doc got on the telechat agenda.  The problem we have with moving
the reviews any earlier than IETF-LC is that there is no automatic
trigger to assign the documents - the onus would have to be on the WG
chairs (or relevant AD) to ask for an "early review", which we have done
in the past and that works just fine.   But, triggering that
automatically would be problematic and inefficient in my opinion as many
documents go through WGLC multiple times in the WGs in which I've been
involved. And, the number of review cycles would increase for each
reviewer. So, it does come back to a resource issue - we would need a
whole lot more Gen-ART reviewers, for example, for this to work
effectively. And, folks that have the bandwidth for this volunteer
activity are difficult to come by these days. I had no luck in
recruiting one of the RFC errata enthusiasts to review documents BEFORE
they're published as RFCs. To me this re-enforces that some folks just
really seem to enjoy finding errors in other people's work ;)

Regards,
Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Friday, May 15, 2009 3:27 PM
To: Working Group Chairs
Subject: Re: [IAB] Out of the box proposal

The ITU-T do, indeed, have an editorial staff. They operate on documents
after they have received the equivalent of IETF last call (that is
consent at a plenary meeting). This is pretty much the equivalent of the
RFC Editor.

I wonder whether there is a volunteer staff who could do this. After
all, we have several area directorates (including GenArt) who review
documents, and we have several enthusiasts who like to look at RFCs and
raise errata.

Adrian

---

From: Ross Callon <[email-masked]>
Date: Fri, 15 May 2009 18:00:08 -0400

> large in the eye of the finder.

I agree. Professional staff can be very good at finding editorial /
grammatical problems. However, the RFC editor's staff already does a
good job of this, and I don't think that these are the sorts of issues
that are causing delays in IESG review of documents. 

> Perhaps if we suggested to NomCom to select less conscientious ADs?

;-)

Ross

> If we really think the problem is 80% of the documents are not ready
for
> A week or two lag in Editor Purgatory(tm) would be well worth it if it
saves

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 15 May 2009 16:08:52 -0700

> Perhaps if we suggested to NomCom to select less conscientious ADs?

The NomCom starts from the job descriptions provided to it by the IESG.  

Those job descriptions (accurately) cite a workload that is sufficient to scare away the vast majority of nominees. 

As a result, the only people who are left are those who are willing to
consider such a workload, and whose management is willing to support
them.

So if the desire is to enable the IETF to produce high quality documents without requiring the ADs to act as heroes, then this will require a major restructuring. 

One of the first principles taught in quality control is that quality is everyone's job -- and until that principle is assimilated and integrated that high levels of quality cannot be achieved. 

In particular, this would require WG chairs would need to take on more responsibility for quality control than they do now. 

There are SDOs in which much of the responsbility for quality is given to the WG chairs (e.g. IEEE 802 has no equivalent of the IESG, although they do have "sponsor ballot").  The results suggest that high quality documents are produced by WGs whose chairs take the role seriously, and that low quality documents are produced by WGs that do not.  

Whether that outcome is satisfactory depends on one's view on what should be done with low quality documents.  Should they be "improved" or do we take a more darwinian view? 

Mike O'Dell was a classic darwinist, often arguing that "improving" atrocious documents to mediocrity was a dis-service to the community.

---

From: Ray Pelletier <[email-masked]>
Date: Fri, 15 May 2009 21:47:37 -0400

> out of time to complain about it.

I would just like to note that the current RFC Production Center SOW
provides for an optional Pre-Approval Editorial Review, as follows:

E. Pre-Approval Editorial Review (Optional)

The Production Center should be capable of performing an editorial  
review of stable Internet-Drafts upon request by a stream  
representative.  Such review should take place early enough to allow  
any changes to be reviewed within the technical review process.  This  
is an optional service that may or may not be required.  If it is  
required, it will be separately priced.  For example, for the IETF  
standards process stream this review is expected to be performed  
before WG Last Call to provide feedback to the authors to improve  
quality of the documents.

Perhaps this might address a future requirement.
Ray

---

From: Henk Uijterwaal <[email-masked]>
Date: Sat, 16 May 2009 19:09:18 +0200

> that are causing delays in IESG review of documents. 

If the RFC editor will find these errors, then I suggest to move their
review to an earlier stage and/or instruct the IESG to focus on the
content, not editorial issues.

Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

Belgium: an unsolvable problem, discussed in endless meetings, with no
          hope for a solution, where everybody still lives happily.

---

From: Al Morton <[email-masked]>
Date: Sat, 16 May 2009 14:13:46 -0400

At 07:08 PM 5/15/2009, Bernard Aboba wrote:
>...
>Whether that outcome is satisfactory depends on one's view on what 
>should be done with low quality documents.  Should they be 
>"improved" or do we take a more darwinian view?
>
>Mike O'Dell was a classic darwinist, often arguing that "improving" 
>atrocious documents to mediocrity was a dis-service to the community.

"Atrocious"

Is it a new I-D Tracker State, or additional AD Evaluation option?

At least the presence of alternative like "Atrocious" would
recognize (what I suspect is) a fairly wide range of document
qualities that the IESG ends-up reviewing.

Al

---

From: Jari Arkko <[email-masked]>
Date: Sat, 16 May 2009 22:16:34 +0300

Henk,

> content, not editorial issues.

All end of the process reviews (IESG, LC, directorate, etc) already 
focus on content. As several people read a document, some editorial 
issues are bound to come up and they get reported. In fact, I think we 
get plenty of them for each document. However, they are not blocking. 
 From an AD perspective they would result in a Comment, not a Discuss. 
The authors are informed of the issues, but there is no requirement to 
fix such problems.

By the way, we had an experiment couple of years ago where RFC Editor 
edits were performed before IETF LC. My personal sense of it was that it 
wasn't all that useful for a couple of reasons. First of all, if we are 
just talking about editorial issues, they could easily be done in the 
RFC Editor stage, too. Secondly, we realized that a number of changes 
were still being made at and after IETF LC, so any editorial cleanup 
would in any case have to be done later for the changed parts. Finally, 
the RFC Editor process speed increased significantly, so there was no 
reason to attempt to parallelize the editing process and other 
activities. The early copy editing effort might pay off if the editorial 
problems were so severe that readers cannot understand the document. 
However, I wonder if the document is truly ready to exit the WG at such 
a stage.

My advice: we already pay the RFC Editor for editorial work. Let them do 
it. Authors may fix the editorial problems they have, particularly if 
they are issuing a new version. However, I think we all would be better 
off if reviews focused on content, and AD/author time was focused on 
that as well. Is something important -- such as congestion control -- 
missing? ABNF compiles? Behaviour rules are complete and consistent? Are 
the health warnings about the implications of this specification in 
place? And so on. I do see a lot of people typing up even editorial 
review comments. It may or may not be useful; something like a spelling 
mistake will be caught by the RFC Editor. And ADs should make absolutely 
sure that they really are raising blocking issues only for truly 
technical matters.

Jari

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 17 May 2009 00:17:19 +0300

Hi Jari,

I've seen I-Ds that are in very bad editorial shape, primarily produced by
non-native English speakers. Such documents are hard to read and obviously
hard to review in depth - people get distracted by the editorial issues. If
such documents survive WGLC (maybe they shouldn't, but it's a possible
outcome), it would be nice if at the discretion of the document shepherd
they could get an early editorial review by the RFC Editor, so that IESG and
directorate reviewers can do a better job reviewing the content.

Thanks,
	Yaron

> Behalf Of Jari Arkko
> Sent: Saturday, May 16, 2009 22:17
> To: Henk Uijterwaal
> Cc: Working Group Chairs
> Subject: Re: Out of the box proposal
> 
> Henk,
> 
> Scanned by Check Point Total Security Gateway.

---

From: Marshall Eubanks <[email-masked]>
Date: Sat, 16 May 2009 17:29:58 -0400

> directorate reviewers can do a better job reviewing the content.

In the new RFC editing system (draft-iab-rfc-editor-model) could this  
be done by the
RFC Production Center ? (In other words, are you asking for optional  
copy-editing, or would
a higher level of engagement be required ?)

Regards
Marshall

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 17 May 2009 00:44:26 +0300

Yes, it could. And yes, I am asking for optional copy editing, in
exceptional cases.

Thanks,
	Yaron

> From: Marshall Eubanks [mailto:[email-masked]]
> Sent: Sunday, May 17, 2009 0:30
> To: Yaron Sheffer
> Cc: Jari Arkko; Henk Uijterwaal; Working Group Chairs

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 16 May 2009 18:16:46 -0700

At 5:29 PM -0400 5/16/09, Marshall Eubanks wrote:
>In the new RFC editing system (draft-iab-rfc-editor-model) could this be done by the
>RFC Production Center ? (In other words, are you asking for optional copy-editing, or would

As Ray pointed out, this is covered optionally in the upcoming contract for the RFC Production Center. It was also in the last round of bidding three years ago.

--Paul Hoffman, Director
--VPN Consortium

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 18 May 2009 11:30:10 +0200

Further the number of staff suggested would not be sufficient. You'd need to at least double it to do the function Eric suggests.

And the ITU-T staff don't come with technical knowledge - at the publication stage they are more concerned about whether the document is translatable and means the same in all the official languages - or at least that was the case a few years back.

regards

Keith

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Friday, May 15, 2009 9:27 PM
> To: Working Group Chairs
> The ITU-T do, indeed, have an editorial staff. They operate 
> on documents after they have received the equivalent of IETF 
> last call (that is consent at a plenary meeting). This is 
> pretty much the equivalent of the RFC Editor.
> 
> Sounds expensive, but maybe the authors/WGs would be willing 
> I wonder whether there is a volunteer staff who could do 
> this. After all, we have several area directorates (including 
> GenArt) who review documents, and we have several enthusiasts 
> who like to look at RFCs and raise errata.
> 
> Adrian
> 
> 
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 18 May 2009 11:55:19 +0200

I would argue we don't need the state.

What should happen with such documents is that they go (quickly) back to the working group to be fixed.

If the document is important, the WG will fix it. If it is not, it will die.

My general position remains that the IESG is a review body, not a fixing body. Either it agrees the document is acceptable, or it is not. 

regards

Keith

> [mailto:[email-masked]] On Behalf Of Al Morton
> Sent: Saturday, May 16, 2009 7:14 PM
> To: Bernard Aboba; [email-masked]; 
> [email-masked]
> Cc: [email-masked]
> Subject: RE: Out of the box proposal
>

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 18 May 2009 11:04:58 -0400

> content, not editorial issues.

In my opinion, that is a form/content distinction that won't fly.
Sticky points of grammar and useage are, alas, not mere bangles
hanging on the prose.

When published, an RFC must meet two criteria:

     1.  It must be comprehensible to someone who wasn't around when
     the document was written.

     2.  It must actually express the consensus of the WG.

If you leave "editorial issues" to someone who doesn't understand the
content, then my experience tells me (2) will be violated: a
well-meaning copy editor will change the prose to make it "clearer"
and acidentally change the meaning in the process.  (I have now seen
as much happen so many times that it approaches the status of natural
law in my mind.)

The upshot is that, even though it is hard for engineers to do so, we
have to send to the IESG only those drafts with precise and clear
(even if not elegant) prose.  It is unfortunately hard work to produce
such prose.  But no amount of technique and process can relieve the WG
editors of that responsibility, because only the WG knows what it is
trying to say.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 18 May 2009 08:56:46 -0700

>as much happen so many times that it approaches the status of natural

This is why all editorial changes made by the RFC Editor are reviewed by the authors before the RFC is published. Those changes are also sent to the WG chairs. If there is an early copy edit, that diff review would still be there.

Note, however, that we may not want early copy edits even if they are "free" (that is, even if ISOC wants to pay for them). There are many WG chairs on this list who are also book authors. It is very common in book publishing for authors to see at least two rounds of copy edits. Almost universally, we authors pay much more attention to the first round (which is heavier) than the second, yet each edit on the the second round has just as much likelihood of changing the intended meaning. The two-round model works well in professional publishing, but it is definitely not a cure for preventing unintentional meaning changes.

--Paul Hoffman, Director
--VPN Consortium

---

From: John C Klensin <[email-masked]>
Date: Sat, 16 May 2009 14:35:52 -0400

--On Saturday, May 16, 2009 19:09 +0200 Henk Uijterwaal
<[email-masked]> wrote:

> review to an earlier stage and/or instruct the IESG to focus
> on the content, not editorial issues.

I favor an earlier editorial pass, both because I think it would
lead to better-quality documents and because I'm very concerned
about the interaction between rising IESG workload and the
Nomcom's range of choices of "volunteer" nominees.  

As we reduce the skill level of the portion of the RFC Editor
function that actually edits documents (something I believe to
be almost inevitable under the new model and proposed RFP), it
is likely to become ever more important that the approval bodies
are reviewing something as close to final text as possible.  At
least during the start-up months of the new RFC Editor system,
leaving something to the RFC Editor post-approval and assuming
that they will catch things and correctly fix them will probably
be unwise for all concerned.

However, we should understand two things if we move in this
direction:

(1) It will certainly increase costs (see Marshall's note).  It
is common for significant technical edits to occur during and
after Last Call.  If the RFC Editor does a pre-Last Call edit,
significant changes to the text will (still) require a
post-approval comprehensive editing pass to be sure the document
still hangs together (as well as ensuring that editorial
problems have not been introduced along with the new text).

(2) If the IESG is operating on the model of "there will always
be bugs" and ADs don't feel that they are doing their jobs
unless they find some and insist that they be fixed, then there
will be no saving of either calendar time or IESG time.    I
think we need to be working much more on a model of "is this
adequate" rather than "can we find some bugs in it" if the IETF
is to survive and be effective, but, as far as I can tell, only
the IESG is able to make the decision to make that shift in
practice.

    john

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 18 May 2009 15:31:22 -0400 (Eastern Daylight Time)

> Note, however, that we may not want early copy edits even if they are "free" (that is, even if ISOC wants to pay for them). There are many WG chairs on this list who are also book authors. It is ve…

I agree with Andrew that copy editors doing usage level editing will 
sometimes change meaning.  (My own personal experience involved an IEEE 
editor who disliked passive voice and so changed all occurrences to active 
voice, inventing an active subject for each.  Hilarious results.)

I agree with Paul that the current RFC Editor changes are reviewed by the 
authors, giving an opportunity for meaning changes to be reversed.

And I agree that the changes in IESG review are substantial enough, often 
enough, that an early review would on average be OBE.  I can see that it
might be useful if a systemic problem was noted - e.g., the editors have
significant problems and could use lots of help.  That might not need
significant resources.  (That might not need the RFC Editor.)

Note that "editorial changes" can mean various levels of changes:

   changes at the character or word level: correcting usage errors, such as
   spelling, diction, grammar, punctuation, capitalization, etc.

   changes at the sentence level: correcting sentence structure to make
   meaning clear or improve reading.

   changes at the level of overall document structure: An example might be
   "You describe motivating examples of the problem in detail, but do not
   describe how your proposed solution would solve the problem for each
   example."  (Adding "... and it is not clear how it would." would be a
   comment about content.)  Or "Topic A is discussed at length but is
   not a part of the solution."  Or "Topic A is introduced late in the
   document and should be discussed much earlier."

In my experience, the RFC Editor review is restricted to the first two 
levels of editing only.  Obviously, last call reviewers and the IESG can 
detect any usage or sentence structure problems that obscure meaning and 
should also be responsible for pointing those out.

I don't know who is responsible for the overall document structure type of 
editorial changes.  As long as the document is clear enough to implement 
or understand, maybe the IETF is satisfied. (I've seen document structure 
issues in RFCs that would not pass muster in standard academic 
publishing.) And leaving such structural changes to the final RFC Editor 
review would seem to require a pass back through the working group, as it 
is likely to produce extensive changes.

--Sandy

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 19 May 2009 12:40:23 +0900

> The authors are informed of the issues, but there is no requirement to

Yes. For some people, it's possible to review a document only for 
content issues, and read over all editorial issues such as typos. Other 
people (such as me) can't easily do that; if they review a document, 
they see everything, and don't want editorial issues go unreported 
because not all o6 them might get caught in later reviews, and fixing 
them soon will avoid that others also have to notice them.

Also, editorial and content issues are often linked. A difficult-to-read 
sentence may be just that, or it may hide a content problem, and so on. 
A typo may be obvious to fix, or it may turn out that what was intended 
was a completely different word.

Regards,    Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 19 May 2009 11:20:52 +0200

Sandra wrote

> I agree with Andrew that copy editors doing usage level 
> editing will sometimes change meaning.  (My own personal 
> experience involved an IEEE editor who disliked passive voice 
> and so changed all occurrences to active voice, inventing an 
> active subject for each.  Hilarious results.)
>  

Passive voice is one of my pet hates, as implementors and conformance testives need to understand the active voice. In terms of conversion, I find that when working on a standard for which I have no prior technical knowledge, I get it about 80% - 90% right. 

(This is usually because the passive voice manages to omit other essential parts of the requirement that should have been in the specification in the first place).

That means the poor implementor has a 80% - 90% chance of understanding the original requirement.

But we do need to get this fixed by PROTO writeup at the absolute latest - finding the passive voice is a fairly mechanical excercise.

regards

Keith

> [mailto:[email-masked]] On Behalf Of Sandra Murphy
> Sent: Monday, May 18, 2009 8:31 PM
> To: [email-masked]
> >>> If the RFC editor will find these errors, then I suggest to move 
> >>> their review to an earlier stage and/or instruct the IESG 
> to focus 
> > This is why all editorial changes made by the RFC Editor 
> are reviewed by the authors before the RFC is published. 
> Those changes are also sent to the WG chairs. If there is an 
> early copy edit, that diff review would still be there.
> >
> > Note, however, that we may not want early copy edits even 
> if they are "free" (that is, even if ISOC wants to pay for 
> them). There are many WG chairs on this list who are also 
> book authors. It is very common in book publishing for 
> authors to see at least two rounds of copy edits. Almost 
> universally, we authors pay much more attention to the first 
> round (which is heavier) than the second, yet each edit on 
> the the second round has just as much likelihood of changing 
> the intended meaning. The two-round model works well in 
> professional publishing, but it is definitely not a cure for 
> preventing unintentional meaning changes.
> >
> > --Paul Hoffman, Director
> > --VPN Consortium
> >
> 
> I agree with Andrew that copy editors doing usage level 
> editing will sometimes change meaning.  (My own personal 
> experience involved an IEEE editor who disliked passive voice 
> and so changed all occurrences to active voice, inventing an 
> active subject for each.  Hilarious results.)
> 
> I agree with Paul that the current RFC Editor changes are 
> reviewed by the authors, giving an opportunity for meaning 
> changes to be reversed.
> 
> And I agree that the changes in IESG review are substantial 
> enough, often enough, that an early review would on average 
> be OBE.  I can see that it might be useful if a systemic 
> problem was noted - e.g., the editors have significant 
> problems and could use lots of help.  That might not need 
> In my experience, the RFC Editor review is restricted to the 
> first two levels of editing only.  Obviously, last call 
> reviewers and the IESG can detect any usage or sentence 
> structure problems that obscure meaning and should also be 
> responsible for pointing those out.
> 
> I don't know who is responsible for the overall document 
> structure type of editorial changes.  As long as the document 
> is clear enough to implement or understand, maybe the IETF is 
> satisfied. (I've seen document structure issues in RFCs that 
> would not pass muster in standard academic
> publishing.) And leaving such structural changes to the final 
> RFC Editor review would seem to require a pass back through 
> the working group, as it is likely to produce extensive changes.
> 
> --Sandy
> 
>

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 19 May 2009 02:46:36 -0700

> (This is usually because the passive voice manages to omit other essential parts of the requirement that should have been in the specification in the first place).

We ought to be mature enough to realize that 20th century polemicists
notwithstanding that the passive voice isn't out of place in technical
writing.

---

From: Eric Burger <[email-masked]>
Date: Thu, 28 May 2009 07:16:54 -0400

Sitting back, it is interesting to see the comments fly. It looks like  
they range from "Edit early and often" through "it is as good as it  
gets."

Mea culpa for mentioning ITU-T.  My thoughts were drawn to the ITU-T  
as I always see a staffer in the room. Note that I have only ever been  
to a handful of ITU-T meetings, and that was a few years ago.

My thought, which a few folks saw, was to hire technical editors.  In  
a sense, money is no object - let us figure out what we need and then  
we can figure out if we can find the money.

One last comment: the ONLY time passive voice is acceptable is when  
one purposely needs to hide the guilty party.  For example, if I  
needed to hide the IETF's need for clear protocols, I would write,  
"Passive voice is allowed."

On May 19, 2009, at 5:46 AM, Joel Jaeggli wrote:

>> Passive voice is one of my pet hates, as implementors and  
>> conformance testives need to understand the active voice. In terms  
>> of conversion, I find that when working on a standard for which I  
>> have no prior technical knowledge, I get it about 80% - 90% right.
>>
>> (This is usually because the passive voice manages to omit other  
>> essential parts of the requirement that should have been in the  
>> specification in the first place).
>
>> But we do need to get this fixed by PROTO writeup at the absolute  
>> latest - finding the passive voice is a fairly mechanical excercise.
>>
>> regards
>>
>> Keith
>>

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 28 May 2009 08:20:46 -0400 (Eastern Daylight Time)

On Thu, 28 May 2009, Eric Burger wrote:

> Sitting back, it is interesting to see the comments fly. It looks like they 
> range from "Edit early and often" through "it is as good as it gets."
>
> Mea culpa for mentioning ITU-T.  My thoughts were drawn to the ITU-T as I 
> always see a staffer in the room. Note that I have only ever been to a 
> handful of ITU-T meetings, and that was a few years ago.
>
> My thought, which a few folks saw, was to hire technical editors.  In a 
> sense, money is no object - let us figure out what we need and then we can 
> figure out if we can find the money.
>
> One last comment: the ONLY time passive voice is acceptable is when one 
> purposely needs to hide the guilty party.  For example, if I needed to hide 
> the IETF's need for clear protocols, I would write, "Passive voice is 
> allowed."

Hardly "ONLY".  Perhaps "ONLY" in prescriptive documents, like protocol 
standards.  Even in the IETF, informational RFCs might not need the active 
voice.

In the case I mentioned, it was a journal article.  When one is describing 
the capabilities of a system in a journal article, one doesn't always want 
to describe them in terms of who performs every action, only that the 
actions are possible.  So one might say (indeed, I did say) "policies can 
be modified dynamically".  If someone wanted to change that to active 
voice and invented an actor, someone might say (and indeed, someone did) 
"Designers can change policies dynamically".

Oiy.

And thank you for the opening that allows me to vent about that 
experience.

--Sandy

>>> Passive voice is one of my pet hates, as implementors and conformance 
>>> testives need to understand the active voice. In terms of conversion, I 
>>> find that when working on a standard for which I have no prior technical 
>>> knowledge, I get it about 80% - 90% right.
>>> 
>>> (This is usually because the passive voice manages to omit other essential 
>>> parts of the requirement that should have been in the specification in the 
>>> first place).
>> 
>>> But we do need to get this fixed by PROTO writeup at the absolute latest - 
>>> finding the passive voice is a fairly mechanical excercise.
>>> 
>>> regards
>>> 
>>> Keith
>>>

---

From: John C Klensin <[email-masked]>
Date: Fri, 29 May 2009 08:36:36 -0400

--On Thursday, May 28, 2009 08:20 -0400 Sandra Murphy
<[email-masked]> wrote:

>> One last comment: the ONLY time passive voice is acceptable
>> is when one  purposely needs to hide the guilty party.  For
>> example, if I needed to hide  the IETF's need for clear
>> protocols, I would write, "Passive voice is  allowed."
> 
> 
> Hardly "ONLY".  Perhaps "ONLY" in prescriptive documents, like
> protocol standards.  Even in the IETF, informational RFCs
> might not need the active voice.
> 
> In the case I mentioned, it was a journal article.  When one
> is describing the capabilities of a system in a journal
> article, one doesn't always want to describe them in terms of
> who performs every action, only that the actions are possible.
> So one might say (indeed, I did say) "policies can be modified
> dynamically".  If someone wanted to change that to active
> voice and invented an actor, someone might say (and indeed,
> someone did) "Designers can change policies dynamically".

Concur.

And let me generalize: Blanket rules like that one tend to turn
into Procrustean beds and excuses for bad and stilted writing.
In addition to examples of the type Sandy mentions, I've often
observed that a prohibition on passive voice leads to sentence
constructions in which inanimate objects are animated (leaving
the actual actor as, or more, unidentified than the passive
does) and verbs are "nouned".  I find it difficult to argue that
those practices are less offensive than selectively used and
well-constructed passive voice constructions.

    john

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 1 Jun 2009 02:24:29 +0200

At the moment I don't think anyone is being prohibitive. What is being pointed out is that most requirements (i.e. those that need RFC 2119 language - no one has been referring to surrounding informative text) are better written in the form

	<entity performing the action> MUST <verb> <action>

because that form indicates clearly what has to perform what action. Too many times readers are left guessing.

That form also says that text of the form:

	The xyz message shall contain abc 

can be equally bad. The problem here is that it hides two potential requirements, the sending requirement (to include abc), and the receiving requirement. What to do if abc is not there, and what to do with it if it is there. In many cases the receiving requirement is handled by generic requirements elsewhere, but the absence of the correct drafting of the requirement leads to confusion.

Keith

> [mailto:[email-masked]] On Behalf Of John C Klensin
> Sent: Friday, May 29, 2009 1:37 PM
> To: Sandra Murphy; Eric Burger
> Cc: Working Group Chairs
> > protocol standards.  Even in the IETF, informational RFCs might not 
> > need the active voice.
> > 
> > In the case I mentioned, it was a journal article.  When one is 
> > describing the capabilities of a system in a journal article, one 
> > doesn't always want to describe them in terms of who performs every 
> > action, only that the actions are possible.
> > dynamically".  If someone wanted to change that to active voice and 
> > invented an actor, someone might say (and indeed, someone did) 
> And let me generalize: Blanket rules like that one tend to 
> turn into Procrustean beds and excuses for bad and stilted writing.
> In addition to examples of the type Sandy mentions, I've 
> often observed that a prohibition on passive voice leads to 
> sentence constructions in which inanimate objects are 
> animated (leaving the actual actor as, or more, unidentified 
> than the passive
> does) and verbs are "nouned".  I find it difficult to argue 
> that those practices are less offensive than selectively used 
> and well-constructed passive voice constructions.
> 
>     john
> 
>

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 1 Jun 2009 06:38:43 +0300

The example does not prove anything about passive voice,
it simply points out that we should not forget to address both transmit and receive actions.

I could say
  Upon receiving X the receiver MUST perform Y
or
  Received Xs are handled by performing Y
and although the second is in passive voice it means exactly the same thing.

Judicial use of passive voice breaks the monotony and may make the document more "reader - friendly".

BTW, pseudocode included in RFCs tends to be in procedural (imperative) languages or pseudolanguages,
and is thus in active voice.

Were we to use a functional or declarative language
then the specification would be in passive voice.

Both imperative and declarative code can be unambiguous descriptions
of the desired functionality.

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
Sent: Monday, June 01, 2009 03:24
To: John C Klensin; Sandra Murphy; Eric Burger
Cc: Working Group Chairs
Subject: RE: [IAB] Out of the box proposal

Keith