From techspec-bounces@ietf.org Wed Nov 02 00:08:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXArV-0001ob-Mz; Wed, 02 Nov 2005 00:08:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXArT-0001mz-99 for techspec@megatron.ietf.org; Wed, 02 Nov 2005 00:08:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10802 for ; Wed, 2 Nov 2005 00:08:14 -0500 (EST) Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXB60-0005fG-20 for techspec@ietf.org; Wed, 02 Nov 2005 00:23:36 -0500 Received: from [172.20.101.216] ([::ffff:207.47.24.2]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Wed, 02 Nov 2005 00:08:15 -0500 id 01588024.436849BF.000023BA Message-ID: <436849B7.2050100@thinkingcat.com> Date: Wed, 02 Nov 2005 00:08:07 -0500 From: Leslie Daigle User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman Subject: Re: [Techspec] Proposed additional requirement: change history and provenance for RFCs References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org Not answering, but adding to the question: these sound like reasonably easily implemented requirements. So, a question is whether they are actually requirements or low-hanging fruit -- wish list items that seem easy to throw in the basket. (N.B.: I'm *not* trying to prejudice the discussion of the requirements; I think these are the criteria we need to apply to all proposed requirements in order to avoid a situation of having a well-decorated wish, not a plan, for our technical publications). Leslie. Paul Hoffman wrote: > Greetings again. One thing that many people in the IETF have needed, and > have often only found through heavy research, is important metadata for > RFCs. Two important types of metadata come to mind: > > - The change history for an RFC that updates or obsoletes an earlier > RFC. Some RFCs are very good about listing this type of information, but > many (particularly those that update instead of obsolete) are not. This > type of information needs to be available to implementers who are handed > a pile of RFCs and told to implement the "current standard". > > - The provenance information, namely what caused the document to be > published as an RFC. For example, if you are looking at an informational > RFC, it is nearly impossible to tell whether it was a self-submitted RFC > or one that came from a WG action, unless you know exactly which > different boilerplate text was used at which time relative to when the > RFC was published. Similarly, knowing if an older standards-track RFC > was an individual submission or a WG item can help an implementer look > for mailing lists where the RFC was discussed. > > I see that making these both public and easily findable as requirements > for our documentation process. Do others agree? > > --Paul Hoffman, Director > --VPN Consortium > > _______________________________________________ > Techspec mailing list > Techspec@ietf.org > https://www1.ietf.org/mailman/listinfo/techspec > _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Nov 02 07:29:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXHkR-0001CB-6y; Wed, 02 Nov 2005 07:29:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXHkP-0001C3-Bv for techspec@megatron.ietf.org; Wed, 02 Nov 2005 07:29:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02229 for ; Wed, 2 Nov 2005 07:29:23 -0500 (EST) Message-Id: <200511021229.HAA02229@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXHyy-0007K9-Ua for techspec@ietf.org; Wed, 02 Nov 2005 07:44:50 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EXHkG-000Mag-2o; Wed, 02 Nov 2005 12:29:36 +0000 To: Leslie Daigle Subject: Re: [Techspec] Proposed additional requirement: change history and provenance for RFCs Date: Wed, 02 Nov 2005 04:29:36 -0800 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Paul Hoffman , techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org Hi, Leslie and Paul, There are two points in the draft that have some reference reference to these, one not there yet :) 4.8 the publisher's maintenance of the catalog 4.9 the IETF's potential requirements for information encoded in the stable permanent identifier; provenance would be a reasonable word for this info. > - The change history for an RFC that updates or obsoletes an earlier > RFC. Some RFCs are very good about listing this type of information, but > many (particularly those that update instead of obsolete) are not. This > type of information needs to be available to implementers who are handed > a pile of RFCs and told to implement the "current standard". The current intent is that any approved i-ds must document internally what it obsoletes and updates, and that the WG and IESG together ensure this information is in there. The technical publisher territory here is only that the tech pub has to show it correctly in their catalog, the other work is all done by the IETF. > - The provenance information, namely what caused the document to be > published as an RFC. For example, if you are looking at an informational > RFC, it is nearly impossible to tell whether it was a self-submitted RFC > or one that came from a WG action, unless you know exactly which > different boilerplate text was used at which time relative to when the > RFC was published. Similarly, knowing if an older standards-track RFC > was an individual submission or a WG item can help an implementer look > for mailing lists where the RFC was discussed. How we signal the provenance - in the stable permanent identifier, in the catalog - I think this is in the realm of the tech spec requirements, and needs the higher requirement - that we want to do it, and then specific ones. Allison _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Nov 02 14:34:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXOMy-0003sk-EZ; Wed, 02 Nov 2005 14:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXOMw-0003rf-Q8 for techspec@megatron.ietf.org; Wed, 02 Nov 2005 14:33:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03343 for ; Wed, 2 Nov 2005 14:33:36 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXObZ-00030l-QK for techspec@ietf.org; Wed, 02 Nov 2005 14:49:07 -0500 Received: from [10.20.30.249] (dsl2-63-249-109-231.cruzio.com [63.249.109.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id jA2JXq6h053573; Wed, 2 Nov 2005 11:33:53 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <436849B7.2050100@thinkingcat.com> References: <436849B7.2050100@thinkingcat.com> Date: Wed, 2 Nov 2005 11:28:21 -0800 To: Leslie Daigle From: Paul Hoffman Subject: Re: [Techspec] Proposed additional requirement: change history and provenance for RFCs Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org At 12:08 AM -0500 11/2/05, Leslie Daigle wrote: >Not answering, but adding to the question: these sound like >reasonably easily implemented requirements. So, a question >is whether they are actually requirements or low-hanging >fruit -- wish list items that seem easy to throw in the basket. The are both. They are requirements in the sense that, without them, our publishing process does not meet the needs of the IETF. They are low-hanging fruit in that they are requirements that should not be hard to meet. >(N.B.: I'm *not* trying to prejudice the discussion of the >requirements; I think these are the criteria we need to apply >to all proposed requirements in order to avoid a situation of >having a well-decorated wish, not a plan, for our technical >publications). Understood. But maybe it is too early to start having us try to only list the "ambitious" requirements. We don't know yet what is ambitious, and we don't know yet which of the ambitious requirements would subsume the low-hanging fruit. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Thu Nov 03 14:32:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXkoj-0002n7-0K; Thu, 03 Nov 2005 14:32:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXkoi-0002n2-1H for techspec@megatron.ietf.org; Thu, 03 Nov 2005 14:32:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21591 for ; Thu, 3 Nov 2005 14:31:45 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXl3W-0001fB-RA for techspec@ietf.org; Thu, 03 Nov 2005 14:47:29 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 03 Nov 2005 11:31:56 -0800 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jA3JVsZ3028884 for ; Thu, 3 Nov 2005 11:31:54 -0800 (PST) Received: from 10.21.121.120 ([10.21.121.120]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 3 Nov 2005 19:32:28 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 03 Nov 2005 11:31:52 -0800 From: Cullen Jennings To: "techspec@ietf.org" Message-ID: Thread-Topic: Comments on mankin-pub-req-01 and stable references Thread-Index: AcXgrT3BfJeERkygEdqVHAARJEEJ/A== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Subject: [Techspec] Comments on mankin-pub-req-01 and stable references X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org On the open issue, I agree with the thoughts that normative reference need to be "done" before works that depends on them is "done" (for some meaning of "done"). My proposal to deal with this would be in section 5.2 where there is a list of 7 bullet points steps, we insert a new step right before step 4 where the IESG assigns the stable reference. This step would read something like: o Wait for normative references to all have a stable permanent identifier assigned to them. I feel that failure to do something like this will result in publication of "Wrapper" documents that just wrap some unfinished work so that other standard organization can reference the wrapper document. We will then be put in the position of hoping that the unfinished work finishes in a way that does not harm the "done" documents that refer to it. This will result in constraints on solutions WG can use because of "future compatibility" concerns with products that have not even been produced yet. It would be a nightmare and we should avoid it. Cullen _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Fri Nov 04 15:49:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY8VD-0000iq-75; Fri, 04 Nov 2005 15:49:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY8VB-0000ii-Dr for techspec@megatron.ietf.org; Fri, 04 Nov 2005 15:49:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12661 for ; Fri, 4 Nov 2005 15:49:09 -0500 (EST) Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY8kE-000232-7z for techspec@ietf.org; Fri, 04 Nov 2005 16:05:07 -0500 Received: from [171.71.208.212] ([::ffff:171.71.208.212]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Fri, 04 Nov 2005 15:49:02 -0500 id 01588001.436BC93E.00004802 Message-ID: <436BC93D.9030003@thinkingcat.com> Date: Fri, 04 Nov 2005 15:49:01 -0500 From: Leslie Daigle User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman Subject: Re: [Techspec] Proposed additional requirement: change history and provenance for RFCs References: <436849B7.2050100@thinkingcat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org One point of perspective/clarification: > Understood. But maybe it is too early to start having us try to only > list the "ambitious" requirements. We don't know yet what is ambitious, > and we don't know yet which of the ambitious requirements would subsume > the low-hanging fruit. I think we need to list the absolute requirements (not wishes), whether or not they are ambitious or low-hanging. We will then confirm we have or find ways to implement answers to the requirements. If there is other low-hanging fruit along the way, we may toss that in, but the more rigor we can apply in separating that out now will make our lives easier. Leslie. Paul Hoffman wrote: > At 12:08 AM -0500 11/2/05, Leslie Daigle wrote: > >> Not answering, but adding to the question: these sound like >> reasonably easily implemented requirements. So, a question >> is whether they are actually requirements or low-hanging >> fruit -- wish list items that seem easy to throw in the basket. > > > The are both. They are requirements in the sense that, without them, our > publishing process does not meet the needs of the IETF. They are > low-hanging fruit in that they are requirements that should not be hard > to meet. > >> (N.B.: I'm *not* trying to prejudice the discussion of the >> requirements; I think these are the criteria we need to apply >> to all proposed requirements in order to avoid a situation of >> having a well-decorated wish, not a plan, for our technical >> publications). > > > Understood. But maybe it is too early to start having us try to only > list the "ambitious" requirements. We don't know yet what is ambitious, > and we don't know yet which of the ambitious requirements would subsume > the low-hanging fruit. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Sat Nov 05 22:04:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYapI-0003m2-PC; Sat, 05 Nov 2005 22:04:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYapG-0003kh-HT for techspec@megatron.ietf.org; Sat, 05 Nov 2005 22:04:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05011 for ; Sat, 5 Nov 2005 22:03:46 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYb4a-0002kb-8h for techspec@ietf.org; Sat, 05 Nov 2005 22:20:00 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jA6340218150 for ; Sun, 6 Nov 2005 05:04:00 +0200 Date: Sun, 6 Nov 2005 05:04:00 +0200 (EET) From: Pekka Savola To: techspec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Techspec] pubreq-01 comment or two X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org Just re-read this. My earlier opinion on the permanent identifier stands; we should rather try to figure out how to turn the crank sufficiently fast that these would not be needed. One comment on early copy editing experiment: we need to involve documents which go through heavy editing after WGLC, IETF LC or IESG review to get a grip how the RFC-editor would handle these cases (if copy edits would be done prior to WGLC). While the time spent on AUTH48 could be minimized, the total time RFC-editor would have to spend on a document could get much larger (would RFC-editor just be happy with rechecking the diffs after the changes?) There were a couple of dozen typos etc. which I can send if it's believed to be worth the effort. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Tue Nov 08 02:15:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZNi0-0001n2-Fj; Tue, 08 Nov 2005 02:15:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZNhy-0001mU-TK for techspec@megatron.ietf.org; Tue, 08 Nov 2005 02:15:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15823 for ; Tue, 8 Nov 2005 02:15:28 -0500 (EST) Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZNxj-0001iK-Ai for techspec@ietf.org; Tue, 08 Nov 2005 02:32:12 -0500 Received: from [10.100.11.180] ([::ffff:128.107.248.220]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Tue, 08 Nov 2005 02:15:35 -0500 id 01588001.43705097.0000198B Message-ID: <43705098.6050005@thinkingcat.com> Date: Tue, 08 Nov 2005 02:15:36 -0500 From: Leslie Daigle User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: techspec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Subject: [Techspec] scribe, minutes taker -- volunteers? X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org Howdy, I'm looking for volunteer jabber scribe and minutes taker for our Wednesday morning meeting. I am aware of at least one remote participant, so jabber will be particularly important. Please let me know if you're willing to do one of the above. (It's possible the same person could do both, but not necessarily obvious). Thanks, Leslie. _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Nov 09 14:25:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvZU-0005TD-In; Wed, 09 Nov 2005 14:25:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvZS-0005T3-3i for techspec@megatron.ietf.org; Wed, 09 Nov 2005 14:25:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02390 for ; Wed, 9 Nov 2005 14:24:54 -0500 (EST) Received: from rwcrmhc14.comcast.net ([204.127.198.54] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZvpV-0006rn-Up for techspec@ietf.org; Wed, 09 Nov 2005 14:41:58 -0500 Received: from s73602 (pp104-231.bctel.ca[209.52.104.231]) by comcast.net (rwcrmhc14) with SMTP id <20051109192509014005j7nhe>; Wed, 9 Nov 2005 19:25:09 +0000 Message-ID: <009d01c5e563$36c9e050$e76834d1@china.huawei.com> From: "Spencer Dawkins" To: Date: Wed, 9 Nov 2005 11:24:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 Content-Transfer-Encoding: 7bit Subject: [Techspec] Notes from Techspec X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org My notes follow - please let me know if you have corrections for the proceedings. Thanks! Spencer BoF: TechSpec -- Requirements for IETF Technical Specification Publication Chair: Leslie Daigle Notes: Spencer Dawkins Mailing list: techspec@ietf.org Agenda ------ a.. ; Sat, 12 Nov 2005 14:04:46 -0500 (EST) Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eb0xJ-0000pc-LA for techspec@ietf.org; Sat, 12 Nov 2005 14:22:31 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id jACJ567V199294 for ; Sat, 12 Nov 2005 19:05:06 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id jACJ55v6137572 for ; Sat, 12 Nov 2005 20:05:05 +0100 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id jACJ55Wk020805 for ; Sat, 12 Nov 2005 20:05:05 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id jACJ55G4020787 for ; Sat, 12 Nov 2005 20:05:05 +0100 Received: from zurich.ibm.com (sig-9-145-248-195.de.ibm.com [9.145.248.195]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id UAA45192 for ; Sat, 12 Nov 2005 20:05:02 +0100 Message-ID: <4376271F.4030801@zurich.ibm.com> Date: Sat, 12 Nov 2005 18:32:15 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: techspec@ietf.org Subject: Re: [Techspec] publication times & stable identifiers References: <4DCBC973AF0D6E4FAF9CD998CE1C0038F77905@eusrcmw720.eamcs.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org Paul Hoffman wrote: > At 1:38 PM -0500 10/27/05, Stephen Hayes (TX/EUS) wrote: > >> Note that even though 3GPP can achieve fast publication by relying on >> support staff, this does not mean IETF can. 3GPP membership is >> composed of companies and these companies have the resources to >> respond in a timely manner to questions and editing requests. This >> may not be possible when the involved parties are volunteer individuals. > > > The current RFC Editor is paid under a contract with ISOC; they are not > volunteers. Chiming in late... In my mind I link this to the whole question of making WGs more responsible for quality control of their output. The early copy-edit experiment is still young, but I think it's shown that the contractor can work effectively with the WG itself to fix up text quality *before* approval. That will help everybody - as an AD, I don't like having to review a document with incomplete sentences. In one recent case, the incomplete sentence was in at least 4 successive versions of the draft, and I couldn't tell whether it was a technical omission or just an editing glitch. Early editing can speed up IESG review as well as RFC publication. In other words, if WGs want their drafts to be approved quickly and published quickly, the WGs have to care about document quality - and IMHO the publication service needs to help them. Brian _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Tue Nov 15 15:58:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec7tI-00058Z-Nf; Tue, 15 Nov 2005 15:58:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec7tI-000571-59 for techspec@megatron.ietf.org; Tue, 15 Nov 2005 15:58:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25965 for ; Tue, 15 Nov 2005 15:58:23 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec8Ab-0003IX-1Q for techspec@ietf.org; Tue, 15 Nov 2005 16:16:49 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jAFKweHf026140 for ; Tue, 15 Nov 2005 14:58:41 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 15 Nov 2005 21:58:39 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155088C86F1@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: techspec@ietf.org Date: Tue, 15 Nov 2005 21:58:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Techspec] Requirement about pre-aaproved (or consensus reached) text in doc uments X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org Not sure how to word this. But I think we have a requirement that the RFC-editing/publication function does leave alone text in approved internet-drafts that has been "pre-approved" or has reached "wide consensus" before the doc gets to the Approved state. Examples are MIB boilerplate or Security Considerations for MIB documents. Other examples could be text that has been agreed in a WG after serious discussions on the exact wording. Yet other examples are text that has been reviewied and "approved" of "OK-ed" by for example Jorge (in case of legal text). Bert p.s. We may need to specify (at some point after we agree on the requirements) that we want to specifically tag such text, or have some means to convey the fact of such text in a specific document. _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Nov 16 07:33:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcMU7-0006Fw-GA; Wed, 16 Nov 2005 07:33:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcMU5-0006Fq-5Y for techspec@megatron.ietf.org; Wed, 16 Nov 2005 07:33:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21570 for ; Wed, 16 Nov 2005 07:33:16 -0500 (EST) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcMlS-0006G7-VF for techspec@ietf.org; Wed, 16 Nov 2005 07:51:52 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id jAGCXb12171172 for ; Wed, 16 Nov 2005 12:33:37 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id jAGCXbKD230628 for ; Wed, 16 Nov 2005 13:33:37 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id jAGCXaGU014491 for ; Wed, 16 Nov 2005 13:33:36 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id jAGCXa6J014478 for ; Wed, 16 Nov 2005 13:33:36 +0100 Received: from zurich.ibm.com (sig-9-145-250-7.de.ibm.com [9.145.250.7]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA35928 for ; Wed, 16 Nov 2005 13:33:35 +0100 Message-ID: <437B271F.2030606@zurich.ibm.com> Date: Wed, 16 Nov 2005 13:33:35 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: techspec@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Subject: [Techspec] Non-Author Editing X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org I'd like to ask a question related to section 4.4. "Non-Author Editing" in draft-mankin-pub-req-01. As far as the quality of the English goes, is there a significant subset of our documents for which "good enough" is good enough? I mean, can we say that for a significant fraction of our drafts, we'd rather get them published more quickly, and skip any editing for style and grammar? Another way to view it is Can we calibrate the copy-editors to say "good enough, I won't waste my time on this one" when appropriate? Brian _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Nov 16 12:49:50 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcRPq-0002sm-0G; Wed, 16 Nov 2005 12:49:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcRPn-0002oY-VO for techspec@megatron.ietf.org; Wed, 16 Nov 2005 12:49:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12931 for ; Wed, 16 Nov 2005 12:49:14 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcRhG-00020x-Ph for techspec@ietf.org; Wed, 16 Nov 2005 13:07:52 -0500 Received: from ewe.isi.edu (ewe.isi.edu [128.9.160.219]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jAGHn1E20137; Wed, 16 Nov 2005 09:49:01 -0800 (PST) Message-Id: <5.2.1.1.2.20051116093323.00ad7a08@boreas.isi.edu> X-Sender: braden@boreas.isi.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 16 Nov 2005 09:45:24 -0800 To: Brian E Carpenter From: Bob Braden Subject: Re: [Techspec] Non-Author Editing In-Reply-To: <437B271F.2030606@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org At 01:33 PM 11/16/2005 +0100, Brian E Carpenter wrote: >I'd like to ask a question related to section 4.4. "Non-Author Editing" >in draft-mankin-pub-req-01. > >As far as the quality of the English goes, is there a significant subset >of our documents for which "good enough" is good enough? > >I mean, can we say that for a significant fraction of our drafts, >we'd rather get them published more quickly, and skip any >editing for style and grammar? Why would want the IETF to get a reputation for publishing| publish cruddy* documents? When a document is in good shape, the cost of minor editing is minor . The draft talks about 40 corrections as if that's a big deal; since the average document is 30 pages, that is slightly more than one correction per page. Presumably each document will be read by 100s of people over the next five years; why do you want to give them junky documents? About 1% of the documents have no grammatical errors or inconsistencies; many have minor errors that are easily caught and fixed. More often the editing process uncovers real ambiguities and muddiness. The insistent noise from the IETF plus the present backlog has forced the RFC Editor to significantly reduce the amount of editing. Based upon my observation, I would guess we now catch 30% fewed real errors in documents as a result. Why would you want to reduce it further? I don't understand this push towards mediocrity in IETF output. Of course, there is a small minority of RFC authors who have an emotional thing about having ANYTHING changed, even blatant errors, in their documents. They should get over it, IMHO. The rest of us have. I would personally ALWAYS want a competant editor go over my RFC. Bob Braden *Cruddy: Technical term meaing bad grammar, confusing or ambiguous punctuation, ambiguities, inconsistencies, ... >Another way to view it is > > Can we calibrate the copy-editors to say "good enough, I won't waste > my time on this one" when appropriate? > > Brian > > > > > >_______________________________________________ >Techspec mailing list >Techspec@ietf.org >https://www1.ietf.org/mailman/listinfo/techspec _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Nov 16 14:36:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcT5Q-0002Au-Us; Wed, 16 Nov 2005 14:36:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcT5O-00029y-Nz for techspec@megatron.ietf.org; Wed, 16 Nov 2005 14:36:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19303 for ; Wed, 16 Nov 2005 14:36:16 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcTMs-0005pM-Ix for techspec@ietf.org; Wed, 16 Nov 2005 14:54:55 -0500 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jAGJa6E29439; Wed, 16 Nov 2005 11:36:06 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id LAA19566; Wed, 16 Nov 2005 11:36:05 -0800 (PST) Date: Wed, 16 Nov 2005 11:36:05 -0800 (PST) Message-Id: <200511161936.LAA19566@gra.isi.edu> To: techspec@ietf.org, bwijnen@lucent.com Subject: Re: [Techspec] Requirement about pre-aaproved (or consensus reached) text in doc uments X-Sun-Charset: US-ASCII X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org *> *> Not sure how to word this. But I think we have a requirement that *> the RFC-editing/publication function does leave alone text in *> approved internet-drafts that has been "pre-approved" or has reached *> "wide consensus" before the doc gets to the Approved state. *> I don't see what's hard. Pre-approved IETF boilerplate should not be further edited. This is one of those "yes, of course" requirements, that seem to go without saying. It is equivalent to "Don't do anything stupid". And of course the RFC Editor (for example ;-)) follows this policy (except when we screw up, but we already apologized to you for the most recent case and corrected it). Does every error the RFC Editor makes have to be made into a federal case? Is that the function of this group? Bob Braden _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Nov 16 14:59:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcTRT-0007ST-HW; Wed, 16 Nov 2005 14:59:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcTRR-0007SJ-Rz for techspec@megatron.ietf.org; Wed, 16 Nov 2005 14:59:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20481 for ; Wed, 16 Nov 2005 14:59:05 -0500 (EST) Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcTiw-0006Xj-1J for techspec@ietf.org; Wed, 16 Nov 2005 15:17:43 -0500 Received: from [10.1.155.41] ([::ffff:171.71.18.2]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Wed, 16 Nov 2005 14:59:07 -0500 id 01588023.437B8F90.00004A2F Message-ID: <437B8F92.8090109@thinkingcat.com> Date: Wed, 16 Nov 2005 14:59:14 -0500 From: Leslie Daigle User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Braden Subject: Function of this group Re: [Techspec] Requirement about pre-aaproved (or consensus reached) text in doc uments References: <200511161936.LAA19566@gra.isi.edu> In-Reply-To: <200511161936.LAA19566@gra.isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org Bob wrote: > Does every error the RFC Editor makes have to be made into a federal > case? Is that the function of this group? Bob, please understand "this isn't about you". Using recent experience to capture another requirement is a case of making the implicit knowledge explicit. Which is useful for a number of reasons, no the least of which is raising IETF awareness to what is required and making sure (for eg) it's easier to transition from one AD to the next without having to do a Vulcan mind-meld. Leslie. Bob Braden wrote: > > *> > *> Not sure how to word this. But I think we have a requirement that > *> the RFC-editing/publication function does leave alone text in > *> approved internet-drafts that has been "pre-approved" or has reached > *> "wide consensus" before the doc gets to the Approved state. > *> > > I don't see what's hard. Pre-approved IETF boilerplate should not > be further edited. This is one of those "yes, of course" requirements, > that seem to go without saying. It is equivalent to "Don't do anything > stupid". And of course the RFC Editor (for example ;-)) follows this > policy (except when we screw up, but we already apologized to you > for the most recent case and corrected it). > > Does every error the RFC Editor makes have to be made into a federal > case? Is that the function of this group? > > Bob Braden > > > _______________________________________________ > Techspec mailing list > Techspec@ietf.org > https://www1.ietf.org/mailman/listinfo/techspec > _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Nov 16 14:59:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcTRj-0007Uf-Le; Wed, 16 Nov 2005 14:59:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcTRi-0007Ua-97 for techspec@megatron.ietf.org; Wed, 16 Nov 2005 14:59:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20488 for ; Wed, 16 Nov 2005 14:59:21 -0500 (EST) Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcTjB-0006YD-DS for techspec@ietf.org; Wed, 16 Nov 2005 15:17:59 -0500 Received: from s73602 (unknown[209.82.80.118]) by comcast.net (sccrmhc12) with SMTP id <20051116195929012001fr4be>; Wed, 16 Nov 2005 19:59:33 +0000 Message-ID: <0e8901c5eae8$2d58e540$f00a10ac@china.huawei.com> From: "Spencer Dawkins" To: References: <437B271F.2030606@zurich.ibm.com> Subject: Re: [Techspec] Non-Author Editing Date: Wed, 16 Nov 2005 11:58:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org Hi, Brian, >As far as the quality of the English goes, is there a significant subset >of our documents for which "good enough" is good enough? > >I mean, can we say that for a significant fraction of our drafts, >we'd rather get them published more quickly, and skip any >editing for style and grammar? As a Gen-ART reviewer, I do see very well-written specifications, and the percentage is "significant", but I don't think it's a majority. I'm questioning, based on current practice, whether we can bypass the copy-editing step, but I suspect that we may be able to move it earlier in the process. I thought you were closer to the mark in your previous post: > In my mind I link this to the whole question of making WGs more > responsible for quality control of their output. The early copy-edit > experiment is still young, but I think it's shown that the contractor > can work effectively with the WG itself to fix up text quality *before* > approval. That will help everybody - as an AD, I don't like having to > review a document with incomplete sentences. In one recent case, the > incomplete sentence was in at least 4 successive versions of the draft, > and I couldn't tell whether it was a technical omission or just an > editing glitch. Early editing can speed up IESG review as well as > RFC publication. I really liked this point of view. This was why I was asking the experiment team to include one or two drafts that were close to being adopted as a WG draft ("just adopted" may be easiest, but that's a detail), in order to see if having competent copy-editing early, before a lot of WG tuning happens, allows the working group to produce better quality output text (since they aren't starting with sloppy text). But I do understand why you're asking the question you asked above. If I might make a proposal: JohnK has spent the last two years reminding me that we do best when we don't assume one size fits all. Is there an opportunity to have the IESG review forward an approved document to two queues: "we are comfortable publishing this specification as-is", and "this excellent specification isn't quite readable enough to publish as-is, please fix it before publishing"? Working groups that care about publishing quickly, can spend the effort. Working groups that don't care, don't have to. Spencer _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Nov 16 15:07:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcTZ1-0000MJ-GT; Wed, 16 Nov 2005 15:07:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcTYz-0000ME-NB for techspec@megatron.ietf.org; Wed, 16 Nov 2005 15:07:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20799 for ; Wed, 16 Nov 2005 15:06:53 -0500 (EST) Received: from [63.240.77.82] (helo=sccrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcTqT-0006nX-T4 for techspec@ietf.org; Wed, 16 Nov 2005 15:25:31 -0500 Received: from s73602 (unknown[209.82.80.118]) by comcast.net (sccrmhc12) with SMTP id <20051116200713012001ff7fe>; Wed, 16 Nov 2005 20:07:13 +0000 Message-ID: <0e9401c5eae9$3fbd0940$f00a10ac@china.huawei.com> From: "Spencer Dawkins" To: References: <437B271F.2030606@zurich.ibm.com> Subject: OT: but it started out ON-topic (Re: [Techspec] Non-Author Editing) Date: Wed, 16 Nov 2005 12:06:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org I apologize for the OT, and graciously accept redirection requests, because this is bleeding over into Newtrk, or maybe PESCI, ... but it started out here, and I think the same people are reading all three lists, so ... > As far as the quality of the English goes, is there a significant subset > of our documents for which "good enough" is good enough? > > I mean, can we say that for a significant fraction of our drafts, > we'd rather get them published more quickly, and skip any > editing for style and grammar? We have known for several years that a majority of our Internet Drafts are slam-dunked within a week or two of meeting cutoff dates. I can't imagine that this practice IMPROVES the quality of the text. Would we end up with better text if we didn't start out with text that was done at the last minute? Spencer _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Nov 16 18:28:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcWh6-0006du-3o; Wed, 16 Nov 2005 18:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcWh4-0006dj-Oe for techspec@megatron.ietf.org; Wed, 16 Nov 2005 18:27:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06955 for ; Wed, 16 Nov 2005 18:27:24 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcWya-0006vA-Da for techspec@ietf.org; Wed, 16 Nov 2005 18:46:05 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id jAGNRgHx002545; Wed, 16 Nov 2005 17:27:43 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 17 Nov 2005 00:27:40 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550897ED09@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Bob Braden Subject: RE: [Techspec] Requirement about pre-aaproved (or consensus reach ed) text in doc uments Date: Thu, 17 Nov 2005 00:27:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: "Techspec \(E-mail\)" X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org Bob, sorry to hear you read this as an "attack or accusation of RFC-Editor". That is totally not the intend of my posting. I appologize if my choice of words made you think I was poiting fingers. Clearly we have had several cases where such editing does happen. Some of it were accidents/errors (those can always happen, no matter what requirements or procedures we formulate), but some of it happen because the RFC-Editor does not know. So I think we have a requirement that - such text blocks that MUST NOT be edited/changed do exist (and not just boiler plate) - we can specify to the publisher which these blocks are in an authoritative manner Bert > -----Original Message----- > From: Bob Braden [mailto:braden@ISI.EDU] > Sent: Wednesday, November 16, 2005 20:36 > To: techspec@ietf.org; bwijnen@lucent.com > Subject: Re: [Techspec] Requirement about pre-aaproved (or consensus > reached) text in doc uments > > > > > *> > *> Not sure how to word this. But I think we have a requirement that > *> the RFC-editing/publication function does leave alone text in > *> approved internet-drafts that has been "pre-approved" or > has reached > *> "wide consensus" before the doc gets to the Approved state. > *> > > I don't see what's hard. Pre-approved IETF boilerplate should not > be further edited. This is one of those "yes, of course" > requirements, > that seem to go without saying. It is equivalent to "Don't > do anything > stupid". And of course the RFC Editor (for example ;-)) follows this > policy (except when we screw up, but we already apologized to you > for the most recent case and corrected it). > > Does every error the RFC Editor makes have to be made into a federal > case? Is that the function of this group? > > Bob Braden > _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Thu Nov 17 08:55:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EckEb-0000it-QL; Thu, 17 Nov 2005 08:55:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EckEY-0000gk-EI for techspec@megatron.ietf.org; Thu, 17 Nov 2005 08:55:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24869 for ; Thu, 17 Nov 2005 08:54:49 -0500 (EST) Received: from e2.ny.us.ibm.com ([32.97.182.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EckW7-0002gh-Kb for techspec@ietf.org; Thu, 17 Nov 2005 09:13:39 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAHDtAPO003124 for ; Thu, 17 Nov 2005 08:55:10 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAHDtBLZ119068 for ; Thu, 17 Nov 2005 08:55:11 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jAHDtAxb029265 for ; Thu, 17 Nov 2005 08:55:10 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-201-67.mts.ibm.com [9.65.201.67]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jAHDt9qj029190; Thu, 17 Nov 2005 08:55:10 -0500 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id jAHDt7Av012515; Thu, 17 Nov 2005 08:55:08 -0500 Message-Id: <200511171355.jAHDt7Av012515@cichlid.raleigh.ibm.com> To: "Wijnen, Bert (Bert)" Subject: Re: [Techspec] Requirement about pre-aaproved (or consensus reach ed) text in doc uments In-Reply-To: Message from "Wijnen, Bert (Bert)" of "Thu, 17 Nov 2005 00:27:41 +0100." <7D5D48D2CAA3D84C813F5B154F43B1550897ED09@nl0006exch001u.nl.lucent.com> Date: Thu, 17 Nov 2005 08:55:07 -0500 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Bob Braden , "Techspec \(E-mail\)" X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org > So I think we have a requirement that > - such text blocks that MUST NOT be edited/changed do exist > (and not just boiler plate) > - we can specify to the publisher which these blocks are in > an authoritative manner I think this is a bad approach. Too complicated in practice and extra work. Plus, I suspect there will be a temptation to flag too much text in this manner (i.e., easier to flag it than deal with potentially changing it). What I suspect would work better in practice is for the author/editor/AD to be able to come back after the fact and say "this was contentious text, please revert it back to the original, if imperfect form". And have that be the end of it. A key question here are "how often does this happen in practice" (i.e., occasionally, on some text, or frequently and with much text). If the former, I think we'd be better off dealing with such occurances after the fact (as exceptions) rather than as the common case that must be proactively anticipated. Thomas _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Thu Nov 17 09:23:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EckfH-0000G8-BC; Thu, 17 Nov 2005 09:23:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EckfG-0000Ef-AN for techspec@megatron.ietf.org; Thu, 17 Nov 2005 09:23:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26662 for ; Thu, 17 Nov 2005 09:22:27 -0500 (EST) Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eckwu-0003iz-Nq for techspec@ietf.org; Thu, 17 Nov 2005 09:41:17 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAHEMqH3025324 for ; Thu, 17 Nov 2005 09:22:52 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAHEMrCc101688 for ; Thu, 17 Nov 2005 09:22:53 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jAHEMqWu020808 for ; Thu, 17 Nov 2005 09:22:52 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-201-67.mts.ibm.com [9.65.201.67]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jAHEMqPf020779; Thu, 17 Nov 2005 09:22:52 -0500 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id jAHEMl4r013141; Thu, 17 Nov 2005 09:22:48 -0500 Message-Id: <200511171422.jAHEMl4r013141@cichlid.raleigh.ibm.com> To: Brian E Carpenter Subject: Re: [Techspec] Non-Author Editing In-Reply-To: Message from Brian E Carpenter of "Wed, 16 Nov 2005 13:33:35 +0100." <437B271F.2030606@zurich.ibm.com> Date: Thu, 17 Nov 2005 09:22:47 -0500 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org > I'd like to ask a question related to section 4.4. "Non-Author Editing" > in draft-mankin-pub-req-01. > As far as the quality of the English goes, is there a significant subset > of our documents for which "good enough" is good enough? > I mean, can we say that for a significant fraction of our drafts, > we'd rather get them published more quickly, and skip any > editing for style and grammar? > Another way to view it is > Can we calibrate the copy-editors to say "good enough, I won't waste > my time on this one" when appropriate? I can't help but wonder if this is asking the wrong question. I doubt anyone objects to the principle of copy editing so long as its done in a timely and efficient manner. And the IETF prides itself on technical excellence in written form. So taking as a starting point that no further improvements are appropriate/necessary for some documents, just doesn't sound right as a general principle. I think the key question is "how much" is appropriate and "at what cost" (in time and author/AD/WG effort). So long as the cost is not onerous (i.e., doesn't add significant time to the overall publication process), I wouldn't want to have a blanket bypass of the copy editing. Or stated another way, I suspect that the real requirement being raised above is "are there some documents for which quick (or effectively immediate) publication is more important than significant delay in order to improve the quality of the English text"? I believe the answer to that question is yes. But there may be other ways of dealing with that question than just saying "good enough, skip editing", and I suspect it will be hard to identify which documents qualify and which don't... And if we get back to 4.2 (Post-approval timeframe), I think that is one of the most important principles. Anything that gets in the way of, say: > Req-4 Stable permanent reference one or two months after > approval > Req-5 Published document at a predictable time after approval Needs to be considered carefully. If copy-editing (in practice) prevents us from being able to meet the need to get a document published quickly, I'd say its less important to have it be done (at the tail end of the process). And I'd say that most IETF documents (especially STD/BCP docs) need to get published in a timely fashion. Thomas _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Thu Nov 17 11:22:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcmWQ-0007Bn-EW; Thu, 17 Nov 2005 11:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcmWN-0007BT-BS for techspec@megatron.ietf.org; Thu, 17 Nov 2005 11:22:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03589 for ; Thu, 17 Nov 2005 11:21:25 -0500 (EST) Received: from smtp.enginuiti.com ([216.147.203.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecmnh-0007vD-Td for techspec@ietf.org; Thu, 17 Nov 2005 11:40:15 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.enginuiti.com (Postfix) with ESMTP id 3C9DB5B4ED; Thu, 17 Nov 2005 11:21:16 -0500 (EST) Received: from smtp.enginuiti.com ([127.0.0.1]) by localhost (smtp.enginuiti.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05719-09; Thu, 17 Nov 2005 11:21:14 -0500 (EST) Received: from ceili (unknown [65.89.152.135]) by smtp.enginuiti.com (Postfix) with SMTP id 205CE5B4E8; Thu, 17 Nov 2005 11:21:09 -0500 (EST) From: "Margaret Wasserman" To: "'Thomas Narten'" , "'Wijnen, Bert (Bert)'" Subject: RE: [Techspec] Requirement about pre-aaproved (or consensus reach ed)text in doc uments Date: Thu, 17 Nov 2005 11:20:22 -0500 Message-ID: <001101c5eb92$e5d018a0$3712280a@instant802.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcXrfuT7WC7v9B2/T1KeAsZb+LqS/QAAnoeQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <200511171355.jAHDt7Av012515@cichlid.raleigh.ibm.com> X-Virus-Scanned: by amavisd-new at enginuiti.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: 'Bob Braden' , "'Techspec \(E-mail\)'" X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org Actually, I think that there is a more positive/constructive approach to the particular case of IETF-mandated boilerplate. In this case, we should be able to tell the RFC editor which boilerplate is required in which types of documents. The RFC editor should be able to add this information to the style guide that is communicated to our copy editors, and the copy editors should be instructed not to change the template text. On a related note -- would the RFC Editor be willing to share that style guide with the community? I think that this would have two benefits: (1) author/editors could attempt to comply with the style guide, resulting in fewer changes later, and (2) the community might be able to provide some feedback on the style guide to help us avoid repeated problems (like this one) in the future. Margaret > -----Original Message----- > From: techspec-bounces@ietf.org [mailto:techspec-bounces@ietf.org] On > Behalf Of Thomas Narten > Sent: Thursday, November 17, 2005 8:55 AM > To: Wijnen, Bert (Bert) > Cc: Bob Braden; Techspec (E-mail) > Subject: Re: [Techspec] Requirement about pre-aaproved (or consensus reach > ed)text in doc uments > > > So I think we have a requirement that > > - such text blocks that MUST NOT be edited/changed do exist > > (and not just boiler plate) > > - we can specify to the publisher which these blocks are in > > an authoritative manner > > I think this is a bad approach. Too complicated in practice and extra > work. Plus, I suspect there will be a temptation to flag too much text > in this manner (i.e., easier to flag it than deal with potentially > changing it). > > What I suspect would work better in practice is for the > author/editor/AD to be able to come back after the fact and say "this > was contentious text, please revert it back to the original, if > imperfect form". And have that be the end of it. > > A key question here are "how often does this happen in practice" > (i.e., occasionally, on some text, or frequently and with much > text). If the former, I think we'd be better off dealing with such > occurances after the fact (as exceptions) rather than as the common > case that must be proactively anticipated. > > Thomas > > _______________________________________________ > Techspec mailing list > Techspec@ietf.org > https://www1.ietf.org/mailman/listinfo/techspec _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Thu Nov 17 11:57:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecn4G-0005uK-VY; Thu, 17 Nov 2005 11:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecn4F-0005ts-It for techspec@megatron.ietf.org; Thu, 17 Nov 2005 11:56:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06284 for ; Thu, 17 Nov 2005 11:56:25 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcnLv-0000ts-B4 for techspec@ietf.org; Thu, 17 Nov 2005 12:15:15 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id E4F4E4C237 for ; Thu, 17 Nov 2005 17:56:49 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 07914-10; Thu, 17 Nov 2005 17:56:48 +0100 (CET) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id 7EB484C208; Thu, 17 Nov 2005 17:56:48 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 0A96852BF8F; Thu, 17 Nov 2005 17:56:46 +0100 (CET) Date: Thu, 17 Nov 2005 17:56:46 +0100 From: Juergen Schoenwaelder To: techspec@ietf.org Message-ID: <20051117165646.GB11245@boskop.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [Techspec] request for version control throughout document lifetimes X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org This is an extract from a discussion on the ietf mailing list. I stronly propose to implement the following to support document authors/editors: a) There should be an IETF controlled version control system which can be used by WGs to maintain the documents they are working on. The currently favored systems is "subversion". It supports WebDAV (an IETF standards-track technology :) and is generally seen as the CVS replacement in the open source community. The WebDAV implementation allows to specify detailed access control rules. b) Since document life does not end when a document is shipped to the RFC editor, I would request that the RFC editor accesses the same repository to make any editorial changes to the document during the publication process. The idea here is that all editorial changes are kept in a single version controlled repository so that later revisions and updates to a document (when the document is opened up again after a few years) do not require to manually apply editorial changes made during the RFC publication back to the versions maintained by authors (as it is often the case these days). c) Working with a version controlled repository makes it easier to communicate changes. Rather than sending (sometimes lengthy) OLD NEW instructions, it is possible to simply checkout a document revision, edit it and post the machine generated diff. Adopting a diff/patch style is likely to streamline the communication during the RFC editing and AUTH48 periods. /js P.S. It seems that the open source community much better understands what it means to edit documents and how important it is to agree on formats and style guidelines in order to be efficient. I hope the IETF can catch up to their standards of productivity. So I welcome this effort (and of course the great work the tools group is doing). -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Thu Nov 17 13:41:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecohl-0005jA-UO; Thu, 17 Nov 2005 13:41:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecohi-0005iS-Db for techspec@megatron.ietf.org; Thu, 17 Nov 2005 13:41:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13132 for ; Thu, 17 Nov 2005 13:41:15 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcozO-0004Vv-4b for techspec@ietf.org; Thu, 17 Nov 2005 14:00:07 -0500 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jAHIf5E27591; Thu, 17 Nov 2005 10:41:05 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id KAA20651; Thu, 17 Nov 2005 10:41:04 -0800 (PST) Date: Thu, 17 Nov 2005 10:41:04 -0800 (PST) Message-Id: <200511171841.KAA20651@gra.isi.edu> To: narten@us.ibm.com, bwijnen@lucent.com, margaret@thingmagic.com Subject: RE: [Techspec] Requirement about pre-aaproved (or consensus reach ed)text in doc uments X-Sun-Charset: US-ASCII X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: braden@ISI.EDU, techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org *> *> Actually, I think that there is a more positive/constructive approach to the *> particular case of IETF-mandated boilerplate. In this case, we should be *> able to tell the RFC editor which boilerplate is required in which types of *> documents. The RFC editor should be able to add this information to the *> style guide that is communicated to our copy editors, and the copy editors *> should be instructed not to change the template text. *> I don't understand this discussion. Yes, of course, and we already do this. *> On a related note -- would the RFC Editor be willing to share that style *> guide with the community? I think that this would have two benefits: (1) *> author/editors could attempt to comply with the style guide, resulting in *> fewer changes later, and (2) the community might be able to provide some *> feedback on the style guide to help us avoid repeated problems (like this *> one) in the future. *> Writing and maintaining a formal style guide is a non-trivial task in itself, which requires resources we don't presently have (and according to the IAD, are unlikely to EVER have.) Nice idea, though. Bob Braden *> Margaret *> *> > -----Original Message----- *> > From: techspec-bounces@ietf.org [mailto:techspec-bounces@ietf.org] On *> > Behalf Of Thomas Narten *> > Sent: Thursday, November 17, 2005 8:55 AM *> > To: Wijnen, Bert (Bert) *> > Cc: Bob Braden; Techspec (E-mail) *> > Subject: Re: [Techspec] Requirement about pre-aaproved (or consensus reach *> > ed)text in doc uments *> > *> > > So I think we have a requirement that *> > > - such text blocks that MUST NOT be edited/changed do exist *> > > (and not just boiler plate) *> > > - we can specify to the publisher which these blocks are in *> > > an authoritative manner *> > *> > I think this is a bad approach. Too complicated in practice and extra *> > work. Plus, I suspect there will be a temptation to flag too much text *> > in this manner (i.e., easier to flag it than deal with potentially *> > changing it). *> > *> > What I suspect would work better in practice is for the *> > author/editor/AD to be able to come back after the fact and say "this *> > was contentious text, please revert it back to the original, if *> > imperfect form". And have that be the end of it. *> > *> > A key question here are "how often does this happen in practice" *> > (i.e., occasionally, on some text, or frequently and with much *> > text). If the former, I think we'd be better off dealing with such *> > occurances after the fact (as exceptions) rather than as the common *> > case that must be proactively anticipated. *> > *> > Thomas *> > *> > _______________________________________________ *> > Techspec mailing list *> > Techspec@ietf.org *> > https://www1.ietf.org/mailman/listinfo/techspec *> _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Thu Nov 17 13:43:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecojf-0006cU-0j; Thu, 17 Nov 2005 13:43:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecojc-0006Xx-Rw for techspec@megatron.ietf.org; Thu, 17 Nov 2005 13:43:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13301 for ; Thu, 17 Nov 2005 13:43:14 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecp1J-0004aw-Mo for techspec@ietf.org; Thu, 17 Nov 2005 14:02:06 -0500 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jAHIgoE28002; Thu, 17 Nov 2005 10:42:50 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id KAA20654; Thu, 17 Nov 2005 10:42:49 -0800 (PST) Date: Thu, 17 Nov 2005 10:42:49 -0800 (PST) Message-Id: <200511171842.KAA20654@gra.isi.edu> To: braden@ISI.EDU, techspec@ietf.org X-Sun-Charset: US-ASCII X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Subject: [Techspec] Another proposed requirement X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org The technical publisher for the IETF should be required to ensure that every sentence ends with a period. With exceptions to be worked out and carefully documented, of course. Bob Braden _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Fri Nov 18 07:44:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed5bL-0006cu-EM; Fri, 18 Nov 2005 07:44:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed5bJ-0006bc-5X for techspec@megatron.ietf.org; Fri, 18 Nov 2005 07:44:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14782 for ; Fri, 18 Nov 2005 07:43:46 -0500 (EST) Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed5t8-0006nN-CK for techspec@ietf.org; Fri, 18 Nov 2005 08:02:47 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id jAICi1ZB124690 for ; Fri, 18 Nov 2005 12:44:01 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id jAICi1OT209602 for ; Fri, 18 Nov 2005 13:44:01 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id jAICi1OI004168 for ; Fri, 18 Nov 2005 13:44:01 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id jAICi0wV004149; Fri, 18 Nov 2005 13:44:00 +0100 Received: from zurich.ibm.com (sig-9-146-220-232.de.ibm.com [9.146.220.232]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA31808; Fri, 18 Nov 2005 13:43:59 +0100 Message-ID: <437DCC8E.4040208@zurich.ibm.com> Date: Fri, 18 Nov 2005 13:43:58 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Bob Braden Subject: Re: [Techspec] Requirement about pre-aaproved (or consensus reached) text in documents References: <200511161936.LAA19566@gra.isi.edu> In-Reply-To: <200511161936.LAA19566@gra.isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org Bob Braden wrote: > > *> > *> Not sure how to word this. But I think we have a requirement that > *> the RFC-editing/publication function does leave alone text in > *> approved internet-drafts that has been "pre-approved" or has reached > *> "wide consensus" before the doc gets to the Approved state. > *> > > I don't see what's hard. Pre-approved IETF boilerplate should not > be further edited. Actually, I don't think that standard boilerplate was the issue. Barring human error, that's already taken care of. It is more that sometimes, consensus in a WG or between the IESG and WG has been very hard won, and even a comma can make a difference in such a case. So some pieces of text may become the moral equivalent of embedded code and MUST NOT [RFC 2119] be edited. I don't think this is hard. It could simply be handled by [Note to RFC Editor: the following paragraph is consensus text and must not be edited for style or content.] Brian _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Fri Nov 18 08:03:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed5u5-0005Ep-9o; Fri, 18 Nov 2005 08:03:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed5u3-0005Ek-7X for techspec@megatron.ietf.org; Fri, 18 Nov 2005 08:03:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16217 for ; Fri, 18 Nov 2005 08:03:06 -0500 (EST) Received: from mtagate1.uk.ibm.com ([195.212.29.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed6Bq-0007X6-Fw for techspec@ietf.org; Fri, 18 Nov 2005 08:22:08 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id jAID36D4110860 for ; Fri, 18 Nov 2005 13:03:08 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id jAID36Hn240392 for ; Fri, 18 Nov 2005 13:03:06 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id jAID36I1021233 for ; Fri, 18 Nov 2005 13:03:06 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id jAID35AB021223; Fri, 18 Nov 2005 13:03:06 GMT Received: from zurich.ibm.com (sig-9-146-220-232.de.ibm.com [9.146.220.232]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA36284; Fri, 18 Nov 2005 14:03:05 +0100 Message-ID: <437DD108.4030004@zurich.ibm.com> Date: Fri, 18 Nov 2005 14:03:04 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Bob Braden Subject: Re: [Techspec] Non-Author Editing References: <5.2.1.1.2.20051116093323.00ad7a08@boreas.isi.edu> In-Reply-To: <5.2.1.1.2.20051116093323.00ad7a08@boreas.isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org Bob Braden wrote: > At 01:33 PM 11/16/2005 +0100, Brian E Carpenter wrote: > >> I'd like to ask a question related to section 4.4. "Non-Author Editing" >> in draft-mankin-pub-req-01. >> >> As far as the quality of the English goes, is there a significant subset >> of our documents for which "good enough" is good enough? >> >> I mean, can we say that for a significant fraction of our drafts, >> we'd rather get them published more quickly, and skip any >> editing for style and grammar? > > > Why would want the IETF to get a reputation for publishing| publish cruddy* > documents? When a document is in good shape, the cost of minor editing > is minor . The draft talks about 40 corrections as if that's a big > deal; since > the average document is 30 pages, that is slightly more than one correction > per page. Presumably each document will be read by 100s of people over > the next five years; why do you want to give them junky documents? I don't. But ending a sentence with a proposition is something up with which I personally will put, if that saves a couple of months of real time. Hence my question: is there a significant subset of our documents that are good enough as they are? I fully agree with Thomas that our goal is good quality and I agree with Spencer and myself that WGs should be held responsible for quality. But that doesn't obviate my question. Brian _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Fri Nov 18 08:09:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed5zC-0006Gh-Ir; Fri, 18 Nov 2005 08:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed5zB-0006GX-JC for techspec@megatron.ietf.org; Fri, 18 Nov 2005 08:09:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16796 for ; Fri, 18 Nov 2005 08:08:26 -0500 (EST) Received: from mtagate1.uk.ibm.com ([195.212.29.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed6H2-0007mO-0o for techspec@ietf.org; Fri, 18 Nov 2005 08:27:28 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id jAID8VD4240248 for ; Fri, 18 Nov 2005 13:08:36 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id jAID8VHn238418 for ; Fri, 18 Nov 2005 13:08:31 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id jAID8VEE032516 for ; Fri, 18 Nov 2005 13:08:31 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id jAID8UgB032505; Fri, 18 Nov 2005 13:08:31 GMT Received: from zurich.ibm.com (sig-9-146-220-232.de.ibm.com [9.146.220.232]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA41820; Fri, 18 Nov 2005 14:08:30 +0100 Message-ID: <437DD242.6090405@zurich.ibm.com> Date: Fri, 18 Nov 2005 14:08:18 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Spencer Dawkins Subject: Re: OT: but it started out ON-topic (Re: [Techspec] Non-Author Editing) References: <437B271F.2030606@zurich.ibm.com> <0e9401c5eae9$3fbd0940$f00a10ac@china.huawei.com> In-Reply-To: <0e9401c5eae9$3fbd0940$f00a10ac@china.huawei.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org Spencer Dawkins wrote: > I apologize for the OT, and graciously accept redirection requests, > because this is bleeding over into Newtrk, or maybe PESCI, > > ... but it started out here, and I think the same people are reading all > three lists, so ... > > >> As far as the quality of the English goes, is there a significant subset >> of our documents for which "good enough" is good enough? >> >> I mean, can we say that for a significant fraction of our drafts, >> we'd rather get them published more quickly, and skip any >> editing for style and grammar? > > > We have known for several years that a majority of our Internet Drafts > are slam-dunked within a week or two of meeting cutoff dates. I can't > imagine that this practice IMPROVES the quality of the text. > > Would we end up with better text if we didn't start out with text that > was done at the last minute? It's Leslie's list, but this feels on topic to me. Unfortunately most geeks are driven by deadlines. So while your observation is certainly correct, I suspect there's little we can do - raw text is always going to be written against some deadline or other. To my mind the question is not whether editing is needed, but how we can avoid it being a late-stage bottleneck. Brian _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Fri Nov 18 10:14:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed7wd-0006dY-3W; Fri, 18 Nov 2005 10:14:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed7wb-0006Xz-Ve for techspec@megatron.ietf.org; Fri, 18 Nov 2005 10:14:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22836 for ; Fri, 18 Nov 2005 10:13:54 -0500 (EST) Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed8ET-00037b-BV for techspec@ietf.org; Fri, 18 Nov 2005 10:32:58 -0500 Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id jAIFGULi003849; Fri, 18 Nov 2005 09:16:30 -0600 Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72) id ; Fri, 18 Nov 2005 09:14:02 -0600 Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C003801355002@eusrcmw720.eamcs.ericsson.se> From: "Stephen Hayes (TX/EUS)" To: Brian E Carpenter , Bob Braden Subject: RE: [Techspec] Non-Author Editing Date: Fri, 18 Nov 2005 09:13:59 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org Just an additional data point. The 3GPP technical editor does no editing for grammar or spelling. There are post approval processes that they are such as verifying correct references and filling in identifiers, but changing the body text is not one of them. The 3GPP process for ensuring readability is probably closest to the early copy-editing experiment where feedback goes in before the document is approved and with group consensus. Part of the reason for not allowing text to be edited post-approval is that it is difficult to identify which text is sensitive and which is not, even for the authors. So far in all my time with 3GPP I have never had anyone come back to me and say that a specification is unimplementable due to hanging prepositions. Furthermore, readability is subjective in an international world. If we use English spelling, the Americans think words are mispelled and if we use American spelling the English think the words are mispelled. Due to international readership, the focus should be on clarity instead of enforcing specific style guidelines. Regards, Stephen > -----Original Message----- > From: techspec-bounces@ietf.org [mailto:techspec-bounces@ietf.org]On > Behalf Of Brian E Carpenter > Sent: Friday, November 18, 2005 7:03 AM > To: Bob Braden > Cc: techspec@ietf.org > Subject: Re: [Techspec] Non-Author Editing > > > Bob Braden wrote: > > At 01:33 PM 11/16/2005 +0100, Brian E Carpenter wrote: > > > >> I'd like to ask a question related to section 4.4. > "Non-Author Editing" > >> in draft-mankin-pub-req-01. > >> > >> As far as the quality of the English goes, is there a > significant subset > >> of our documents for which "good enough" is good enough? > >> > >> I mean, can we say that for a significant fraction of our drafts, > >> we'd rather get them published more quickly, and skip any > >> editing for style and grammar? > > > > > > Why would want the IETF to get a reputation for publishing| > publish cruddy* > > documents? When a document is in good shape, the cost of > minor editing > > is minor . The draft talks about 40 corrections as if > that's a big > > deal; since > > the average document is 30 pages, that is slightly more > than one correction > > per page. Presumably each document will be read by 100s of > people over > > the next five years; why do you want to give them junky documents? > > I don't. But ending a sentence with a proposition is something up with > which I personally will put, if that saves a couple of months > of real time. > Hence my question: is there a significant subset of our > documents that are > good enough as they are? > > I fully agree with Thomas that our goal is good quality and I > agree with > Spencer and myself that WGs should be held responsible for > quality. But that > doesn't obviate my question. > > Brian > > > _______________________________________________ > Techspec mailing list > Techspec@ietf.org > https://www1.ietf.org/mailman/listinfo/techspec > _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Fri Nov 18 14:00:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdBTY-000865-3A; Fri, 18 Nov 2005 14:00:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdBTU-00082T-5D for techspec@megatron.ietf.org; Fri, 18 Nov 2005 14:00:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04598 for ; Fri, 18 Nov 2005 14:00:04 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdBlM-0000iU-JI for techspec@ietf.org; Fri, 18 Nov 2005 14:19:10 -0500 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jAIIxCE27157; Fri, 18 Nov 2005 10:59:12 -0800 (PST) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id KAA21421; Fri, 18 Nov 2005 10:59:12 -0800 (PST) Date: Fri, 18 Nov 2005 10:59:12 -0800 (PST) Message-Id: <200511181859.KAA21421@gra.isi.edu> To: braden@ISI.EDU, brc@zurich.ibm.com Subject: Re: [Techspec] Non-Author Editing X-Sun-Charset: US-ASCII X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: braden@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org *> *> I don't. But ending a sentence with a proposition is something up with *> which I personally will put, if that saves a couple of months of real time. More like 15 seconds of real time. Bob _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Mon Nov 21 14:12:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeH5q-0002IM-J2; Mon, 21 Nov 2005 14:12:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeH5q-0002IB-16 for techspec@megatron.ietf.org; Mon, 21 Nov 2005 14:12:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25081 for ; Mon, 21 Nov 2005 14:12:07 -0500 (EST) Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeHOJ-0004xj-KR for techspec@ietf.org; Mon, 21 Nov 2005 14:31:53 -0500 Received: from [64.100.227.251] ([::ffff:64.100.227.251]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Mon, 21 Nov 2005 14:12:06 -0500 id 0158802F.43821C06.000020E8 Message-ID: <43821C12.8040600@thinkingcat.com> Date: Mon, 21 Nov 2005 14:12:18 -0500 From: Leslie Daigle User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Stephen Hayes (TX/EUS)" Subject: Re: [Techspec] Non-Author Editing References: <4DCBC973AF0D6E4FAF9CD998CE1C003801355002@eusrcmw720.eamcs.ericsson.se> In-Reply-To: <4DCBC973AF0D6E4FAF9CD998CE1C003801355002@eusrcmw720.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: 7bit Cc: Bob Braden , techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org (Commenting as an individual) > The 3GPP technical editor does no editing for grammar or spelling. There > are post approval processes that they are such as verifying correct > references and filling in identifiers, but changing the body text is not > one of them. The 3GPP process for ensuring readability is probably > closest to the early copy-editing experiment where feedback goes in > before the document is approved and with group consensus. Part of the Right -- exactly what we hoped to achieve with the early editing process. > reason for not allowing text to be edited post-approval is that it is > difficult to identify which text is sensitive and which is not, even for > the authors. Agree again. So, your example is supporting that the path to "no post approval changes" is "pre-approval editing", not "no editing". Leslie. Stephen Hayes (TX/EUS) wrote: > Just an additional data point. > > The 3GPP technical editor does no editing for grammar or spelling. There are post approval processes that they are such as verifying correct references and filling in identifiers, but changing the body text is not one of them. The 3GPP process for ensuring readability is probably closest to the early copy-editing experiment where feedback goes in before the document is approved and with group consensus. Part of the reason for not allowing text to be edited post-approval is that it is difficult to identify which text is sensitive and which is not, even for the authors. > > So far in all my time with 3GPP I have never had anyone come back to me and say that a specification is unimplementable due to hanging prepositions. Furthermore, readability is subjective in an international world. If we use English spelling, the Americans think words are mispelled and if we use American spelling the English think the words are mispelled. Due to international readership, the focus should be on clarity instead of enforcing specific style guidelines. > > Regards, Stephen > > >>-----Original Message----- >>From: techspec-bounces@ietf.org [mailto:techspec-bounces@ietf.org]On >>Behalf Of Brian E Carpenter >>Sent: Friday, November 18, 2005 7:03 AM >>To: Bob Braden >>Cc: techspec@ietf.org >>Subject: Re: [Techspec] Non-Author Editing >> >> >>Bob Braden wrote: >> >>>At 01:33 PM 11/16/2005 +0100, Brian E Carpenter wrote: >>> >>> >>>>I'd like to ask a question related to section 4.4. >> >>"Non-Author Editing" >> >>>>in draft-mankin-pub-req-01. >>>> >>>>As far as the quality of the English goes, is there a >> >>significant subset >> >>>>of our documents for which "good enough" is good enough? >>>> >>>>I mean, can we say that for a significant fraction of our drafts, >>>>we'd rather get them published more quickly, and skip any >>>>editing for style and grammar? >>> >>> >>>Why would want the IETF to get a reputation for publishing| >> >>publish cruddy* >> >>>documents? When a document is in good shape, the cost of >> >>minor editing >> >>>is minor . The draft talks about 40 corrections as if >> >>that's a big >> >>>deal; since >>>the average document is 30 pages, that is slightly more >> >>than one correction >> >>>per page. Presumably each document will be read by 100s of >> >>people over >> >>>the next five years; why do you want to give them junky documents? >> >>I don't. But ending a sentence with a proposition is something up with >>which I personally will put, if that saves a couple of months >>of real time. >>Hence my question: is there a significant subset of our >>documents that are >>good enough as they are? >> >>I fully agree with Thomas that our goal is good quality and I >>agree with >>Spencer and myself that WGs should be held responsible for >>quality. But that >>doesn't obviate my question. >> >> Brian >> >> >>_______________________________________________ >>Techspec mailing list >>Techspec@ietf.org >>https://www1.ietf.org/mailman/listinfo/techspec >> > > > _______________________________________________ > Techspec mailing list > Techspec@ietf.org > https://www1.ietf.org/mailman/listinfo/techspec > _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Tue Nov 22 06:02:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeVux-000846-HD; Tue, 22 Nov 2005 06:02:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeVuv-00083L-Io for techspec@megatron.ietf.org; Tue, 22 Nov 2005 06:02:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02678 for ; Tue, 22 Nov 2005 06:01:49 -0500 (EST) Received: from mtagate2.uk.ibm.com ([195.212.29.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeWDW-0004Op-5j for techspec@ietf.org; Tue, 22 Nov 2005 06:21:43 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id jAMB1djG141446 for ; Tue, 22 Nov 2005 11:01:40 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAMB1cmp220786 for ; Tue, 22 Nov 2005 11:01:38 GMT Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id jAMB1cro007799 for ; Tue, 22 Nov 2005 11:01:38 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id jAMB1b6P007789 for ; Tue, 22 Nov 2005 11:01:37 GMT Received: from zurich.ibm.com (sig-9-145-133-2.de.ibm.com [9.145.133.2]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id MAA46076 for ; Tue, 22 Nov 2005 12:01:36 +0100 Message-ID: <4382FA8E.7000003@zurich.ibm.com> Date: Tue, 22 Nov 2005 12:01:34 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: techspec@ietf.org Subject: Re: [Techspec] Non-Author Editing References: <4DCBC973AF0D6E4FAF9CD998CE1C003801355002@eusrcmw720.eamcs.ericsson.se> <43821C12.8040600@thinkingcat.com> In-Reply-To: <43821C12.8040600@thinkingcat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org Leslie Daigle wrote: > > (Commenting as an individual) ditto > So, your example is supporting that the path to "no post approval > changes" is "pre-approval editing", not "no editing". This sounds like a good principle to me, and it creates the possibility of parallelism during the editing stage, as long as it stays under the responsibility of each WG. Brian _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Nov 23 19:41:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef5Ae-0007ao-8G; Wed, 23 Nov 2005 19:41:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef5Ac-0007aQ-Rx for techspec@megatron.ietf.org; Wed, 23 Nov 2005 19:41:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23020 for ; Wed, 23 Nov 2005 19:40:23 -0500 (EST) Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ef5Ta-0007UW-66 for techspec@ietf.org; Wed, 23 Nov 2005 20:00:38 -0500 Received: from [192.168.0.101] ([::ffff:64.102.254.33]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Wed, 23 Nov 2005 19:40:38 -0500 id 01588065.43850C06.00001F1D Message-ID: <43850C12.2010603@thinkingcat.com> Date: Wed, 23 Nov 2005 19:40:50 -0500 From: Leslie Daigle User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Spencer Dawkins Subject: Re: [Techspec] Notes from Techspec References: <009d01c5e563$36c9e050$e76834d1@china.huawei.com> In-Reply-To: <009d01c5e563$36c9e050$e76834d1@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24 Content-Transfer-Encoding: 7bit Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org Spencer, Thanks again for taking notes from the session! I've uploaded the HTML version as (draft) minutes. I note that there seem to be some last names missing. Are there any updates people can provide before I post final minutes? (FYI -- see the HTML-formatted version at http://www3.ietf.org/proceedings/05nov/minutes/techspec.html -- it's easier to read the sub-bulleting). Leslie. Spencer Dawkins wrote: > My notes follow - please let me know if you have corrections for the > proceedings. > > Thanks! > > Spencer > > BoF: TechSpec -- Requirements for IETF Technical Specification Publication > > Chair: Leslie Daigle > Notes: Spencer Dawkins > Mailing list: techspec@ietf.org > > Agenda > ------ > > a.. these days?. > > Overview & Introduction [BoF Chair] > > a.. BOF description didn't pass through an editor, of course... > > b.. Want to enumerate IETF publication requirements (BCP or otherwise) > c.. See list of "what we are not doing" in the BOF description > d.. Bob Braden - document formats should be discussed (somewhere, and > why not here?) Document lifecycle should also include the part where > people actually read documents? > ?. Update from experiment in early copy editing [Bert Wijnen, RFC Editor] > > a.. ops.ietf.org/ece for documents that have gone through the > experiment, description, etc. > b.. Initiated by IAB, IESG, RFC-Editor > c.. Alice Hagens did the actual work... > d.. WGs participating are from OPS, TSV, SEC, and documents include a MIB > e.. This was a very, very, very limited initial experiment with six > documents - need to draw conclusions carefully > f.. Hoping for positive impact on following steps, less copy-editing, > shortened AUTH-48 > g.. Experiment does not mean documents have priority in queue > h.. We have documents in AUTH-48 for six months now, this is not good, > and changes cause churn late in the process > i.. Bert serialized the experiment inputs/outputs to track timings, > number of changes, etc. > > j.. RFC Editor committed to one-week turnaround > k.. Using XML as format for the experiment > l.. Average data points - 3 days at RFC Editor, 1 hour per 8/9 pages by > RFC-Editor, 1149 changed lines, 1360 changes by authors after the > authors got documents back (311 were for verb tense, 860 caused by > author error submitting wrong version of document) > m.. Still need to check number of changes after WGLC (only one doc has > completed WGLC) > n.. We skipped the source control steps, may need an IETF service for this > o.. Positive experience, great turnaround, cannot serialize in > production, need to be careful what gets shipped in each direction, need > to follow what happens in the rest of the process > p.. Next steps - follow up, do more experiments, figure out how to > un-serialize > q.. Aaron - "commodity copy-editors" - RFC Editor is using these now. > Not IETF people, maybe not even computer scientists. They do lots of > markups, but these get filtered before going to the authors. Alice has > done both tasks in this experiment - think about what happens when > authors interact with commidity copy-editors, who may be handing you > changes on a sheet of paper and not new XML, for instance. > r.. Pete - commodity copy editors may make a lot more changes and slow > down the process? > > s.. Aaron - "yes", but even technical editors aren't familiar with > document structure at the IETF > t.. Bob - copy editors make stylistic changes, RFC Editor has been > discouraged from doing this - this is "early editing", not "early > copy-editing" - "agreement" substituted for "consensus" > Alice - take on experiment > > a.. Using paper, then entering edits into XML, add questions for > authors and major revisions > b.. Differences between documents - we only edit description clauses in > MIBs, but in other documents we're figuring out how to do VSPACE and > even looking at the wrong version of the document. 8-9 pages/hour seems > typical > c.. Patrik - VSPACE in lists is context-dependent - do you summarize > problems you encounter with the tools? If Alice doesn't think the > problem is learning experience.. > d.. Need to do some additional measures from RFC Editor perspective - > time/changes, issues not resolved, AUTH48 progress > Miguel Garcia - editor for Diameter application for SIP draft > > a.. Document is 80 pages > b.. Did two formal revisions over about 30 days > c.. Some suggestions result in a large number of changed lines > (inconsistent terminology, for example) > d.. Still doing some changes at the end of the process (some technical, > some formatting, etc.) > e.. All suggestions were editorial, not technical > f.. Very positive experience, especially not making global changes in > AUTH48 with OLD/NEW > g.. WG always had opportunity to see changes > h.. No slowdown detected > i.. Some documents have lots of dependencies - this may be a drawback > for something like GRUU > Elwyn - editor for NAT-PT-to-Experimental draft > > a.. Had actually been through WGLC, perhaps this was a misunderstanding > b.. Did about a three-day cycle, with lots of small changes ("which" > instead of "that", commas). Almost all changes were editorial, did > identify terminology overload and one other non-editorial issue > c.. One "false positive" editorially, but we fixed the sentence in a > better way anyhow > d.. Resulting document is a lot better when it hits IETF LC (with > Gen-ART reviewing hat on) > e.. Not sure how much parallelization is possible > f.. Bert - can't wait six months for a doc, can't pay $5M, it's a tradeoff > g.. Allison - working group text is stable makes it better - what > happens if the WG is still making lots of diffs? WGLC is when people > read documents, need to take this into account > h.. Bert - this document went through WGLC and was still difficult to > read - process helped > > Jari - co-chair of MOBIKE > a.. Also went quite smoothly, had to wait in queue a little > b.. Focus resources on documents that DO need the changes > c.. Elwyn - would be easy for copy editors to do this, Gen-ART isn't > copy editors > d.. Bob - "some documents need few changes, therefore there should be > no changes?" > Discussion > > a.. Spencer - Really like opportunity for global suggestions "early". > Matches my Gen-ART experience - maybe experiment with one or two > documents BEFORE WGLC? and sets of documents need to be consistent > internally, too > > b.. David Black - Also Gen-ART - copy editors can clean up language, > not technical lack of clarity > c.. RFC Editor - global changes in AUTH48 - prefer NEW/OLD because many > douments have sets of similar text, want to know exactly where the text > is - and we keep sets of documents with one copy editor > . 3. Review and discussion of draft-mankin-pub-req [Allison Mankin] > > a.. Have never really thought about document lifetime in the IETF > before - we pick up readers early because of "running code", so adding > readers to the lifecycle isn't easy to think about > b.. Bob - at least add readers to the diagram? > c.. (Req-3) - Detailed visibility into Tech Pub tracking > d.. Aaron - what does Req-3 actually mean? for example? Correspondence > with editors visible to WG, like correspondence with ADs - copying the > WG mailing list would be sufficient? > e.. Brian - to clarify the clarification - we are working toward > interaction visibility with IESG, don't do as we do, do as we say > f.. Aaron - want to know what the RFC Editor does now? > g.. Leslie - yes, but not in this meeting, we're focused on what our > requirements are first > h.. Allison - are we ready to talk about adopting these requirements yet? > i.. Bob - RFC Editor is part of the community and agrees with Req-2 and > Req-3 strongly - need to think about resources required > j.. Bert - sort of agree, but first requirement is that we hit a button > and the document appears (applause in the room). How much time are we > prepared to accept? We don't need detailed visiblity if the document > appears in two weeks. > k.. Leslie - we can move work, but it doesn't go away, and if we need > visibility, we need it no matter where the work is > l.. (Req-2) - do we want seamless tracking of document movement into > Tech Pub? > m.. Bert - why not one tracking system? > n.. Eric - do we need detailed visibility of line-by-line editing? May > not be appropriate > o.. (Pre-Req-7) One coordinator for the editor process? > p.. Bob - what's the issue here? > q.. Allison - dealing with five authors, or one of them, or ... > r.. Bob - we contact all authors to make sure they all exist and are > still alive - want us to change our policy? > s.. Leslie - have been on IAB telechats for years - there is lack of > clarity about who is doing what > t.. Pekka - sometimes one author isn't responsive, and it's not clear > who steps up when that happens > u.. Thomas - yes, we want to have one person. The current system works > pretty well most of the time. We don't really have authors anymore with > WG text, we have WG editors and the other names shouldn't be slowing > down the process > v.. Scott - no-brainer that either authors or ADs should pick one > contact. Final signoff still needs to be by each author > w.. Leslie - IETF decision for this is a requirement, need to have > discussion about what we decide > x.. Margaret - mix together concepts of credit and control. If an > author dies, they deserve credit but don't have control (except maybe > Bert, who will come back to haunt us). This is the extreme case, not the > only case. Steve Deering deserves IPv6 credit but not IPv6 control, at > this point. Don't know whose names go on the front page, and maybe we > shouldn't even put names on the first page. > y.. David - moving a lot of docs through this process, what Scott said > was correct (masthead signs off). Proto shepherd is the right victim, > and should be able to exempt and remove authors > z.. Bob - more comfortable with ADs making this decision - is "DOES" in > requirement MUST, MAY, or SHOULD? Margaret is right - first page is > tending toward "control", with acknowledgements in a separate section. > > aa.. (Pre-Req-8) Non-author editing affecting consensus wording > ab.. Bob - what happens if consensus wording is grammatically incorrect? > ac.. Allison - discuss bigger changes on WG mailing list > ad.. Leslie - when non-author editing affects wording, we need to > resolve this > ae.. (Req-9) No style changes? > > af.. (Req-10) Small technical changes submitted in a narrow window > following approval, not at time of publication > > ag.. Document shepard and AD can filter these > ah.. Jari - queuing takes time, things happen, people implement after > approval. These changes show up at AUTH48. > ai.. Margaret - after approval, something comes up - what should > happen? We don't know what to do when something comes up. WG should > decide how to handle large flaws. We have pulled documents out of editor > queue - need to know what to do, in a process sense. > aj.. Allison - WGs are terrible at saying "no". Trust the shepherd to > determine what's a show-stopper? We have finished the process and are > collecting issues towards a -bis version. Ask the working group "broken > beyond repair?" - don't go through process multiple times for small things. > ak.. Leslie - need to socialize our process from multiple perspectives, > but can't do that in next 43 minutes. Need to discuss on the list, need > to move on now. We will revise the document - we know that. Discuss > creating a working group? > al.. Bob - document is scattershot > am.. Allison - someone else will be holding the pen > an.. Bob - needs to address more issues and provide more context - not > the basis for a working group yet > ao.. John - this document is part of our game of "whack-a-mole" - we're > off to the land of requirements, not solutions. This topic is worth > working on, this document is not the right way to go > ap.. Scott - there is a pony underneath the poop someplace. Some of > this document is OK, but it's the problem set, not the document. > aq.. Dan Burnett - process question - also need to know who is going to > do the work > ar.. Bert - yes, we combined both questions (should work on it, will > work on it). A lot of this is darned complex. What happens before IESG > approval is a lot cheaper than what happens after IESG approval, and > part of the cost is delay. > as.. Margaret - I don't have enough information (not in evidence). Lots > of interaction with other short-term efforts. Do short-term efforts, at > least in parallel. > > at.. Leslie - if we are doing competitive bids, we need to know what > we're asking for > au.. Margaret - we paid $800K based on an SOW, do we need more? > av.. Leslie - SOW is what tasks are carried out, not what we WANT > carried out > aw.. Brian - What Leslie said, plus - need general description text > that we don't have in the SOW today > ax.. Bob, as member of community - please focus on readership! What an > implementor has to focus on to implement anything. That was supposed to > happen in Newtrk, but it's not. It's a big elephant. > ay.. Allison - what the document is supposed to do, is figure out what > we really want, not just what we do, document by document, area by area, > with no consistency. We are trying to guide IASA, and they don't know > what we want them to do with their dollars > az.. Leslie - need to reel all this back in ... for further work, we > need more information about purpose, which is known as a charter in > these parts > ba.. Bert - not trying to pick on our problems, we are putting forth > requirements for fixing problems, not for producing documents > bb.. David - consistently publishing bug fixes, before and after > approval, is a requirement > bc.. Margaret - we have substantial requirements for publication, not > just for editing (archival quality, etc). In this document, or elsewhere? > bd.. Allison - "Cataloging" in the slide deck (which we didn't get to). > be.. Thomas - must attach errata to the document in an obvious way > bf.. Sam - we need a low-overhead publication path - as part of what > the IETF needs. We are trying to raise the bar for what goes into a > working group - excluding work that needs to be published. > bg.. Harald - I'm worried (perhaps not for the first time, but) - > technical publication means getting documents to the public so they can > be referenced quickly. Need to know who to talk to in order to do > something - open process - and how violently to talk to them. We have > major issues with getting documents out, and making sure what comes out > is what we approved. Two years to make up our minds isn't part of the > process - don't use tech publishing as a holding queue > bh.. Pasi - Errata - if our documents took two weeks to publication, we > wouldn't need errata > bi.. Allison - find a problem a year later, don't want to publish a new > RFC to correct an RFC > bj.. Pasi - if it was easy and fast to publish a new RFC... > bk.. Leslie - interesting... counterpoint is that discussion also shows > things down > bl.. Bob - the less editing you do, the more errata you publish. One > guy in Germany reads all the RFCs and sends in "by the way, have you > noticed?" - often up to 10 or so per RFC > bm.. Eric - why focus on errors that appear in RFCs? Knuth has an error > on every third page and he's one of the most careful authors ever. We > have to live with this > bn.. Leslie - please continue discussion on the mailing list. > > 5. Determination of where from here for requirements documentation. > > a.. (did we actually do this?) > > > > _______________________________________________ > Techspec mailing list > Techspec@ietf.org > https://www1.ietf.org/mailman/listinfo/techspec > _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec