Yes, it could. And yes, I am asking for optional copy editing, in exceptional cases. Thanks, Yaron > -----Original Message----- > From: Marshall Eubanks [mailto:tme at americafree.tv] > Sent: Sunday, May 17, 2009 0:30 > To: Yaron Sheffer > Cc: Jari Arkko; Henk Uijterwaal; Working Group Chairs > Subject: Re: Out of the box proposal > > > On May 16, 2009, at 5:17 PM, Yaron Sheffer wrote: > > > 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. > > 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 > > > > > > > > Thanks, > > Yaron > > > >> -----Original Message----- > >> From: wgchairs-bounces at ietf.org [mailto:wgchairs-bounces at ietf.org] On > >> 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, > >> > >>> 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. > >> > >> 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 > >> > >> > >> Scanned by Check Point Total Security Gateway. > > > Scanned by Check Point Total Security Gateway.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature