From techspec-bounces@ietf.org Mon Feb 06 04:43:26 2006 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 1F62u6-0000pp-Cj; Mon, 06 Feb 2006 04:43:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F62u4-0000or-OM for techspec@megatron.ietf.org; Mon, 06 Feb 2006 04:43:24 -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 EAA02272 for ; Mon, 6 Feb 2006 04:41:38 -0500 (EST) Received: from mtagate1.uk.ibm.com ([195.212.29.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6366-0004h1-RG for techspec@ietf.org; Mon, 06 Feb 2006 04:55:52 -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 k169h6rm167452 for ; Mon, 6 Feb 2006 09:43:06 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k169gj7P218494 for ; Mon, 6 Feb 2006 09:42:45 GMT Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id k169gjpL025856 for ; Mon, 6 Feb 2006 09:42:45 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id k169giKL025843 for ; Mon, 6 Feb 2006 09:42:44 GMT Received: from zurich.ibm.com (sig-9-145-129-63.de.ibm.com [9.145.129.63]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA50938 for ; Mon, 6 Feb 2006 10:42:43 +0100 Message-ID: <43E71A13.8030403@zurich.ibm.com> Date: Mon, 06 Feb 2006 10:42:43 +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 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: [Techspec] IRTF in scope? [Re: I-D ACTION:draft-mankin-pub-req-04.txt] 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 Scope nit: > This draft only addresses those documents submitted to the IETF via > the IAB, IESG, or IRTF. There is no mention of IRTF documents, and in fact I would think that's probably out of scope. Brian _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Mon Feb 06 04:49:51 2006 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 1F630I-0003OL-EZ; Mon, 06 Feb 2006 04: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 1F630G-0003NW-Us for techspec@megatron.ietf.org; Mon, 06 Feb 2006 04:49:49 -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 EAA02667 for ; Mon, 6 Feb 2006 04:48:09 -0500 (EST) Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F63CP-00068h-Rz for techspec@ietf.org; Mon, 06 Feb 2006 05:02:23 -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 k169nbQk036112 for ; Mon, 6 Feb 2006 09:49: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.8) with ESMTP id k169nbHY191462 for ; Mon, 6 Feb 2006 10:49: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 k169nasU013773 for ; Mon, 6 Feb 2006 10:49: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 k169namc013770 for ; Mon, 6 Feb 2006 10:49:36 +0100 Received: from zurich.ibm.com (sig-9-145-129-63.de.ibm.com [9.145.129.63]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA51440 for ; Mon, 6 Feb 2006 10:49:35 +0100 Message-ID: <43E71BAD.4070701@zurich.ibm.com> Date: Mon, 06 Feb 2006 10:49:33 +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 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Subject: [Techspec] IAB path [Re: I-D ACTION:draft-mankin-pub-req-04.txt] 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 Scope nit: > This draft only addresses those documents submitted to the IETF via > the IAB, IESG, or IRTF. In fact nothing substantive is said about IAB documents. Perhaps it needs to be stated as a requirement that the technical publisher shall accept for publication, as IETF documents, only drafts that have been approved by the IESG, or drafts from the IAB (which do not require IESG approval). Brian _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Mon Feb 06 13:31:02 2006 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 1F6B8g-0002WC-En; Mon, 06 Feb 2006 13:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6B8f-0002U5-4l for techspec@megatron.ietf.org; Mon, 06 Feb 2006 13:31: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 NAA10513 for ; Mon, 6 Feb 2006 13:29:20 -0500 (EST) Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6BKt-0005R1-2O for techspec@ietf.org; Mon, 06 Feb 2006 13:43:40 -0500 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 12A1122241D for ; Mon, 6 Feb 2006 10:32:18 -0800 (PST) To: techspec@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 18) Date: Mon, 06 Feb 2006 10:30:51 -0800 From: Eric Rescorla Message-Id: <20060206183218.12A1122241D@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Techspec] Editing consistency 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'm currently working on the Auth-48 version of RFC 4346 (TLS 1.1), which is a very light revision to TLS 1.0 (RFC 2246). During this review, I noticed that RFC Ed had made a number of stylistic edits to text that was in RFC 2246. For instance, all heads have been changed from "text style" to "title style". E.g., From: 3. Goals of this document To: 3. Goals of This Document A bunch of copy-edit changes have also been made. I don't want to start an argument here about the desirability of this type of change in general (though think that's a discussion worth having at some point) but I think it's worth discussing the relative importance of different kinds of consistency, in particular: * Stylistic consistency across documents published contemporaneously * Stylistic consistency across time, especially for documents that are clearly related. In particular, it seems to me that there are some clear drawbacks to making this kind of stylistic change in successive versions of the same document, both in terms of effort consumed by editors and authors and in terms of the effort required to figure out "what changed" by those using automated difference tools. It's worth noting that although capitalization differences are easy to suppress, there are other stylistic changes that are less so. What do people think about this? -Ekr _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Mon Feb 06 16:54:41 2006 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 1F6EJl-0008Fu-6n; Mon, 06 Feb 2006 16:54:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6EJj-0008Eu-0t for techspec@megatron.ietf.org; Mon, 06 Feb 2006 16:54:39 -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 QAA08810 for ; Mon, 6 Feb 2006 16:52:49 -0500 (EST) Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6EVq-0004Gn-Pi for techspec@ietf.org; Mon, 06 Feb 2006 17:07:12 -0500 Received: from s73602 (unknown[65.104.224.98]) by comcast.net (sccrmhc11) with SMTP id <20060206215415011002hig1e>; Mon, 6 Feb 2006 21:54:16 +0000 Message-ID: <081601c62b67$ac9416d0$3703a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: <20060206183218.12A1122241D@laser.networkresonance.com> Subject: Re: [Techspec] Editing consistency Date: Mon, 6 Feb 2006 15:52:49 -0600 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.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 Well, speaking only for myself: - I am very excited by the introduction of copy editors earlier in the process, because I really see how that can improve things for IETF standards. - I am not excited by stylistic editing late in the process, because I don't see how that really improves things for IETF standards. - If there is any chance that editing resources that could be doing copy editing early in the process are doing stylistic editing late in the process, I'm very un-excited about that. Re "consistency": if you look at RFC 793 and any recent RFC side-by-side, you can tell the difference from across the room - I'm sorry, but you can. I don't think that's bad. Given that we won't have consistency across all time, I don't know why consistency across all documents published in a given month or year matters. ... especially if it means that the changes need to be made repeatedly across updated documents, and especially stylistic changes make it more difficult to spot what "really" changed between versions. The current diff tools do everything except send up flares to help you spot differences - why would we make it harder to find "real" differences? If we care, we should have stylistic stuff coming out of the working group correctly, and I can't see how that's going to happen unless a program can enforce a style (probably by formatting text to conform to it). I am not a genius of this stuff, but, since you asked... Thanks, Spencer > I'm currently working on the Auth-48 version of RFC 4346 (TLS 1.1), > which is a very light revision to TLS 1.0 (RFC 2246). During this > review, I noticed that RFC Ed had made a number of stylistic > edits to text that was in RFC 2246. For instance, all heads have > been changed from "text style" to "title style". E.g., > > From: > 3. Goals of this document > > To: > 3. Goals of This Document > > A bunch of copy-edit changes have also been made. > > I don't want to start an argument here about the desirability of this > type of change in general (though think that's a discussion worth having > at some point) but I think it's worth discussing the relative importance > of different kinds of consistency, in particular: > > * Stylistic consistency across documents published contemporaneously > * Stylistic consistency across time, especially for documents that > are clearly related. > > In particular, it seems to me that there are some clear drawbacks to > making this kind of stylistic change in successive versions of the same > document, both in terms of effort consumed by editors and authors and > in terms of the effort required to figure out "what changed" by those > using automated difference tools. It's worth noting that although > capitalization differences are easy to suppress, there are other > stylistic changes that are less so. > > What do people think about this? > > -Ekr _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Mon Feb 06 17:30:07 2006 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 1F6Es2-0007hA-Vk; Mon, 06 Feb 2006 17:30:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Es1-0007ew-S2 for techspec@megatron.ietf.org; Mon, 06 Feb 2006 17:30:05 -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 RAA13651 for ; Mon, 6 Feb 2006 17:28:09 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6F41-000751-Bf for techspec@ietf.org; Mon, 06 Feb 2006 17:42:30 -0500 Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id k16MTjQm017276; Mon, 6 Feb 2006 14:29:46 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <081601c62b67$ac9416d0$3703a8c0@china.huawei.com> References: <20060206183218.12A1122241D@laser.networkresonance.com> <081601c62b67$ac9416d0$3703a8c0@china.huawei.com> Date: Mon, 6 Feb 2006 14:29:44 -0800 To: "Spencer Dawkins" , From: Paul Hoffman Subject: Re: [Techspec] Editing consistency Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 At 3:52 PM -0600 2/6/06, Spencer Dawkins wrote: >Given that we won't have consistency across all time, I don't know >why consistency across all documents published in a given month or >year matters. I don't think that was Eric's point. He showed that a *revised RFC* had stylistic changes such as capitalization in the headings and copy-editing changes (for example, changing "that" for "which", or changing "since" to "because"). He pointed out a real mechanical problem: it is hard to use a diff-style tool to determine the relevant changes. Thus, there may be a Techspec requirement here that the publisher not make purely stylistic changes on RFC revisions. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Mon Feb 06 17:51:25 2006 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 1F6FCf-0004bb-99; Mon, 06 Feb 2006 17:51:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6FCZ-0004Wm-RB for techspec@megatron.ietf.org; Mon, 06 Feb 2006 17:51: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 RAA17506 for ; Mon, 6 Feb 2006 17:49:23 -0500 (EST) Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6FOZ-0000KZ-Vn for techspec@ietf.org; Mon, 06 Feb 2006 18:03:45 -0500 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 39BCE22241D; Mon, 6 Feb 2006 14:52:16 -0800 (PST) To: Paul Hoffman Subject: Re: [Techspec] Editing consistency In-reply-to: Your message of "Mon, 06 Feb 2006 14:29:44 PST." X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 18) Date: Mon, 06 Feb 2006 14:50:49 -0800 From: Eric Rescorla Message-Id: <20060206225216.39BCE22241D@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Paul Hoffman wrote: > At 3:52 PM -0600 2/6/06, Spencer Dawkins wrote: > > Given that we won't have consistency across all time, I don't know > > why consistency across all documents published in a given month or > > year matters. > > I don't think that was Eric's point. He showed that a *revised RFC* > had stylistic changes such as capitalization in the headings and > copy-editing changes (for example, changing "that" for "which", or > changing "since" to "because"). He pointed out a real mechanical > problem: it is hard to use a diff-style tool to determine the relevant > changes. > > Thus, there may be a Techspec requirement here that the publisher not > make purely stylistic changes on RFC revisions. That's exactly the question I think is appropriate to be considering. -Ekr _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Fri Feb 10 06:59:44 2006 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 1F7WwC-0004aP-0I; Fri, 10 Feb 2006 06:59:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7WwB-0004aK-FD for techspec@megatron.ietf.org; Fri, 10 Feb 2006 06:59: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 GAA12960 for ; Fri, 10 Feb 2006 06:57:59 -0500 (EST) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7X9A-00066U-7V for techspec@ietf.org; Fri, 10 Feb 2006 07:13:09 -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 k1ABxWHm245664 for ; Fri, 10 Feb 2006 11:59:32 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k1ABxWC3238760 for ; Fri, 10 Feb 2006 12:59:32 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k1ABxVTo015022 for ; Fri, 10 Feb 2006 12:59:31 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k1ABxVAL015019; Fri, 10 Feb 2006 12:59:31 +0100 Received: from zurich.ibm.com (sig-9-145-253-49.de.ibm.com [9.145.253.49]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id MAA34718; Fri, 10 Feb 2006 12:59:27 +0100 Message-ID: <43EC801D.4090901@zurich.ibm.com> Date: Fri, 10 Feb 2006 12:59:25 +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: "Stephen Hayes (TX/EUS)" Subject: Re: [Techspec] Questions on draft-mankin-techspec-pubreq-03 References: <4DCBC973AF0D6E4FAF9CD998CE1C003801CB1D2B@eusrcmw720.eamcs.ericsson.se> In-Reply-To: <4DCBC973AF0D6E4FAF9CD998CE1C003801CB1D2B@eusrcmw720.eamcs.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 ... >>- In 3.12, we say "used sparingly" for expedited handling, >>but we do pick >>numbers for metrics elsewhere. Would it make sense to name a >>percentage of >>documents that may be expedited in normal operation? > > > SH: Glad to put in a number, does anybody want to volunteer a number? How about 1%? I was hoping that if we can get the publication time down, we could remove this requirement all together. > Personal opinion: I think we can't put a number on this. 1% is too low on recent experience, and since the need for this is in inverse relationship to average processing time, we can't even determine the correct target. Brian _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Feb 15 16:52:48 2006 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 1F9UZs-0006E3-Q7; Wed, 15 Feb 2006 16:52:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9UZm-0005z6-8G for techspec@megatron.ietf.org; Wed, 15 Feb 2006 16:52:47 -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 QAA10497 for ; Wed, 15 Feb 2006 16:50:56 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9Unr-0003t2-D2 for techspec@ietf.org; Wed, 15 Feb 2006 17:07:16 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4303F25972F; Wed, 15 Feb 2006 22:51:09 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21945-09; Wed, 15 Feb 2006 22:51:05 +0100 (CET) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 715132596EA; Wed, 15 Feb 2006 22:51:05 +0100 (CET) Date: Wed, 15 Feb 2006 22:52:26 +0100 From: Harald Tveit Alvestrand To: Brian E Carpenter , techspec@ietf.org Subject: Re: [Techspec] IAB path [Re: I-D ACTION:draft-mankin-pub-req-04.txt] Message-ID: In-Reply-To: <43E71BAD.4070701@zurich.ibm.com> References: <43E71BAD.4070701@zurich.ibm.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit 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 --On mandag, februar 06, 2006 10:49:33 +0100 Brian E Carpenter wrote: > Scope nit: > >> This draft only addresses those documents submitted to the IETF via >> the IAB, IESG, or IRTF. > > In fact nothing substantive is said about IAB documents. Perhaps it needs > to be stated as a requirement that the technical publisher shall accept > for publication, as IETF documents, only drafts that have been approved > by the IESG, or drafts from the IAB (which do not require IESG approval). I'd state flatly that the techspec requirements apply to documents from the IETF that are published with IETF approval, as decided by the IESG. If, as I think, we want the publication mechanism to be applicable to other documents (which includes independent submissions, IAB documents, IRTF documents and IAOC documents, if any), I think the requirements for those classes of documents need to be separate. Trying to merge them makes the process of writing them down FAR too convoluted. Harald _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Feb 15 17:28:36 2006 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 1F9V8W-0002eQ-Kg; Wed, 15 Feb 2006 17:28:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9V8U-0002d6-Ho for techspec@megatron.ietf.org; Wed, 15 Feb 2006 17:28:34 -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 RAA12713 for ; Wed, 15 Feb 2006 17:26:47 -0500 (EST) Received: from rwcrmhc14.comcast.net ([216.148.227.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9VMZ-00052z-1F for techspec@ietf.org; Wed, 15 Feb 2006 17:43:08 -0500 Received: from s73602 (unknown[65.104.224.98]) by comcast.net (rwcrmhc14) with SMTP id <20060215222822m1400pu836e>; Wed, 15 Feb 2006 22:28:22 +0000 Message-ID: <075d01c6327e$e95d6d00$0500a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: <43E71BAD.4070701@zurich.ibm.com> Subject: Re: [Techspec] IAB path [Re: I-D ACTION:draft-mankin-pub-req-04.txt] Date: Wed, 15 Feb 2006 16:26:48 -0600 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: 97adf591118a232206bdb5a27b217034 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 From: "Harald Tveit Alvestrand" > > I'd state flatly that the techspec requirements apply to documents from > the IETF that are published with IETF approval, as decided by the IESG. > > If, as I think, we want the publication mechanism to be applicable to > other documents (which includes independent submissions, IAB documents, > IRTF documents and IAOC documents, if any), I think the requirements for > those classes of documents need to be separate. > > Trying to merge them makes the process of writing them down FAR too > convoluted. > > Harald Hi, Harald, On this same topic - aren't direct submissions, IETF documents, IAB documents, IRTF documents, and IAOC documents are all submitted and approved for publication in different ways? If so, it seems unhelpful to put procedures for all of these documents into a single draft - wouldn't that mean that the draft would be approved by all the different approving bodies before it could be published? I think I'm agreeing and just trying to make sure I understand all the reasons why you're right :-) Thanks, Spencer _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Feb 15 18:38:45 2006 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 1F9WEP-0008NX-Bm; Wed, 15 Feb 2006 18:38:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9WEM-0008L1-Nz for techspec@megatron.ietf.org; Wed, 15 Feb 2006 18:38: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 SAA18357 for ; Wed, 15 Feb 2006 18:36:56 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9WSQ-0007GC-PY for techspec@ietf.org; Wed, 15 Feb 2006 18:53:18 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 113EF25973C; Thu, 16 Feb 2006 00:37:08 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24951-01; Thu, 16 Feb 2006 00:37:04 +0100 (CET) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id EB7D325973B; Thu, 16 Feb 2006 00:37:03 +0100 (CET) Date: Thu, 16 Feb 2006 00:38:25 +0100 From: Harald Tveit Alvestrand To: Spencer Dawkins , techspec@ietf.org Subject: Re: [Techspec] IAB path [Re: I-D ACTION:draft-mankin-pub-req-04.txt] Message-ID: <43D18DE022A8EFDBE633B4C0@svartdal.hjemme.alvestrand.no> In-Reply-To: <075d01c6327e$e95d6d00$0500a8c0@china.huawei.com> References: <43E71BAD.4070701@zurich.ibm.com> <075d01c6327e$e95d6d00$0500a8c0@china.huawei.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit 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 --On onsdag, februar 15, 2006 16:26:48 -0600 Spencer Dawkins wrote: > From: "Harald Tveit Alvestrand" > >> >> I'd state flatly that the techspec requirements apply to documents from >> the IETF that are published with IETF approval, as decided by the IESG. >> >> If, as I think, we want the publication mechanism to be applicable to >> other documents (which includes independent submissions, IAB documents, >> IRTF documents and IAOC documents, if any), I think the requirements for >> those classes of documents need to be separate. >> >> Trying to merge them makes the process of writing them down FAR too >> convoluted. >> >> Harald > > Hi, Harald, > > On this same topic - aren't direct submissions, IETF documents, IAB > documents, IRTF documents, and IAOC documents are all submitted and > approved for publication in different ways? > > If so, it seems unhelpful to put procedures for all of these documents > into a single draft - wouldn't that mean that the draft would be approved > by all the different approving bodies before it could be published? > > I think I'm agreeing and just trying to make sure I understand all the > reasons why you're right :-) that makes eminent sense to me, so I guess we understand each other :-) otoh, in the end the continuation (or not) of the RFC series has to be reduced in the end to a single statement of work under a single contract - but I think the IETF standard process should make *its* input into that process now, and let the other pieces come along later. Harald _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Feb 15 19:08:40 2006 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 1F9WhM-00083L-2L; Wed, 15 Feb 2006 19:08:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9WhK-000825-FN for techspec@megatron.ietf.org; Wed, 15 Feb 2006 19:08: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 TAA23400 for ; Wed, 15 Feb 2006 19:06:51 -0500 (EST) Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9WvO-0000lj-IB for techspec@ietf.org; Wed, 15 Feb 2006 19:23:10 -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 k1G0F4Jt028768; Wed, 15 Feb 2006 18:15:04 -0600 Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72) id <1FXKHPBC>; Wed, 15 Feb 2006 18:08:23 -0600 Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C003801FC8734@eusrcmw720.eamcs.ericsson.se> From: "Stephen Hayes (TX/EUS)" To: Harald Tveit Alvestrand , Spencer Dawkins , techspec@ietf.org Subject: RE: [Techspec] IAB path [Re: I-D ACTION:draft-mankin-pub-req-04.t xt] Date: Wed, 15 Feb 2006 18:08:17 -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: 6cca30437e2d04f45110f2ff8dc1b1d5 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 > -----Original Message----- > From: techspec-bounces@ietf.org [mailto:techspec-bounces@ietf.org]On > Behalf Of Harald Tveit Alvestrand > Sent: Wednesday, February 15, 2006 5:38 PM > To: Spencer Dawkins; techspec@ietf.org > Subject: Re: [Techspec] IAB path [Re: I-D > ACTION:draft-mankin-pub-req-04.txt] > > > > > --On onsdag, februar 15, 2006 16:26:48 -0600 Spencer Dawkins > wrote: > > > From: "Harald Tveit Alvestrand" > > > >> > >> I'd state flatly that the techspec requirements apply to > documents from > >> the IETF that are published with IETF approval, as decided > by the IESG. > >> > >> If, as I think, we want the publication mechanism to be > applicable to > >> other documents (which includes independent submissions, > IAB documents, > >> IRTF documents and IAOC documents, if any), I think the > requirements for > >> those classes of documents need to be separate. > >> > >> Trying to merge them makes the process of writing them down FAR too > >> convoluted. > >> > >> Harald > > > > Hi, Harald, > > > > On this same topic - aren't direct submissions, IETF documents, IAB > > documents, IRTF documents, and IAOC documents are all submitted and > > approved for publication in different ways? > > > > If so, it seems unhelpful to put procedures for all of > these documents > > into a single draft - wouldn't that mean that the draft > would be approved > > by all the different approving bodies before it could be published? > > > > I think I'm agreeing and just trying to make sure I > understand all the > > reasons why you're right :-) > > that makes eminent sense to me, so I guess we understand each > other :-) > > otoh, in the end the continuation (or not) of the RFC series > has to be > reduced in the end to a single statement of work under a > single contract - > but I think the IETF standard process should make *its* input > into that > process now, and let the other pieces come along later. > > Harald > > I also think it makes sense to narrow the scope to only IETF documents, as decided by the IESG. This does not prevent many of these requirements from being adopted for documents arriving via other channels. This document so far mainly addresses the technical publisher part of the publication process. As indicated in section 5 there are complementary processes that need to be developed on the IETF side. These processes will probably be unique to documents going through the IESG. Stephen > _______________________________________________ > 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 Feb 15 19:46:28 2006 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 1F9XHw-0001as-Er; Wed, 15 Feb 2006 19:46:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9XHu-0001YL-6v for techspec@megatron.ietf.org; Wed, 15 Feb 2006 19:46:26 -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 TAA29780 for ; Wed, 15 Feb 2006 19:44:39 -0500 (EST) Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9XVy-0003Ot-Nx for techspec@ietf.org; Wed, 15 Feb 2006 20:01:02 -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 k1G0qpce000404 for ; Wed, 15 Feb 2006 18:52:54 -0600 Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72) id <1FXKHPKB>; Wed, 15 Feb 2006 18:46:10 -0600 Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C003801FC874C@eusrcmw720.eamcs.ericsson.se> From: "Stephen Hayes (TX/EUS)" To: techspec@ietf.org Date: Wed, 15 Feb 2006 18:45:58 -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: 08170828343bcf1325e4a0fb4584481c Subject: [Techspec] Pre vs Post approval 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 mankin-pub-req currently has requirements for both pre approval (Potential Req-PREEDIT-1) and post approval (Req-POSTEDIT-1). We need to decide which requirements stay and which ones go. I think both requirements are needed, however each document should only have to pass through either pre-approval editing or post-approval editing but not both. This will allow the IETF to migrate to a methodology using pre-approval editing over time. Usage of pre-approval editing should be encouraged. In addition an additional requirement should be added along the lines of: o Potential Req-TIMEFRAMES-3 - The IETF technical publisher should have a goal of an average time for completing the pre-approval editorial review of no more than 2 weeks and at least 98% of all documents should be reviewed within 4 weeks. The review interval starts when the editorial review is requested and ends when the review results are provided. This is to prevent simply shifting the long queuing delay from the post-approval phase to the pre-approval phase. I would also propose that we add text prohibiting stylistic changes in the post-approval editing (but permit it in pre-approval editing). Stephen Hayes _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Feb 15 19:47:33 2006 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 1F9XIz-0002iQ-1R; Wed, 15 Feb 2006 19:47:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9XIw-0002fl-OI for techspec@megatron.ietf.org; Wed, 15 Feb 2006 19:47: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 TAA29835 for ; Wed, 15 Feb 2006 19:45:43 -0500 (EST) Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9XX3-0003QE-CW for techspec@ietf.org; Wed, 15 Feb 2006 20:02:06 -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 k1G0s0BW000575 for ; Wed, 15 Feb 2006 18:54:01 -0600 Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72) id <1FXKHPKH>; Wed, 15 Feb 2006 18:47:19 -0600 Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C003801FC874E@eusrcmw720.eamcs.ericsson.se> From: "Stephen Hayes (TX/EUS)" To: techspec@ietf.org Date: Wed, 15 Feb 2006 18:47:10 -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: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Techspec] Referencing by external organizations 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 of the goals of re-engineering the technical publication process is to solve the problems with providing references to external organizations. Outside organizations often want to reference IETF specifications, but are frustrated by their unavailability since they cannot be formally referenced until they exit the RFC queue. Three approaches have been proposed to address this issue: 1. Expedited handling - moving some critically needed documents to the top of the queue o Current Req-EXPEDITE-1 - The IETF technical publisher shall expedite the processing of specific documents at the request of the IESG. 2. Early allocation of permanent identifiers - this allows outside documents to complete their specifications (populated with the correct references) with the expectation that the document will eventually pop out. o Potential Req-PERMID-2 - The IETF technical publisher should permit early allocation of stable identifiers for or by the IESG to satisfy referencing requirements of external bodies. 3. Tighten the overall publication timelines so there is not a long wait before publication o Potential Req-TIMEFRAMES-1 - The IETF technical publisher should have a goal of an average publication time of no more than 4 weeks and at least 98% of all documents should be published within 8 weeks. Documents held up due to references or due to a protocol action should be excluded from this statistic. I would propose that we focus on approachs 2 & 3 and drop 1. Approach 3 by itself is hard to guarantee (especially with the references loophole). If an identifier can be provided early, with an expectation that the final document will appear within a reasonable time, then I suspect most external organizations will be satisfied. Most standards organizations will accept the risk that the published document could be delayed or possibly never appear. I would also propose to tighten up the requirement of the allocation of stable identifiers from 4 weeks to 1 week and remove the exclusions for references and protocol actions. o Potential Req-TIMEFRAMES-2 - The IETF technical publisher should have a goal of an average stable identifier allocation time of no more than 1 week and at least 98% of documents should have a stable identifier allocated within 2 weeks of approval. Stephen Hayes _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Thu Feb 16 15:41:06 2006 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 1F9pw2-0003IK-0A; Thu, 16 Feb 2006 15:41:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9pw1-0003Hb-3f for techspec@megatron.ietf.org; Thu, 16 Feb 2006 15:41:05 -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 PAA02549 for ; Thu, 16 Feb 2006 15:39:16 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9qAI-0007hh-DZ for techspec@ietf.org; Thu, 16 Feb 2006 15:55:51 -0500 Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id k1GKesRS092070; Thu, 16 Feb 2006 12:40:56 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4DCBC973AF0D6E4FAF9CD998CE1C003801FC874C@eusrcmw720.eamcs.ericsson.se> References: <4DCBC973AF0D6E4FAF9CD998CE1C003801FC874C@eusrcmw720.eamcs.ericsson.se> Date: Thu, 16 Feb 2006 12:40:53 -0800 To: "Stephen Hayes (TX/EUS)" , techspec@ietf.org From: Paul Hoffman Subject: Re: [Techspec] Pre vs Post approval editing Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 At 6:45 PM -0600 2/15/06, Stephen Hayes (TX/EUS) wrote: >mankin-pub-req currently has requirements for both pre approval >(Potential Req-PREEDIT-1) and post approval (Req-POSTEDIT-1). We >need to decide which requirements stay and which ones go. > >I think both requirements are needed, however each document should >only have to pass through either pre-approval editing or >post-approval editing but not both. There is a significant problem with have a document edited pre-approval and then not re-editing post-approval, namely the changes that get introduced during the approval process itself. A typical change is "add a section to the Security Considerations talking about how Wxyz interacts with this protocol." Unless the authors use exactly the same spelling, capitalization, reference format, and so on, that new section will not match the rest of the document. There is also the very real issue of document authors not doing some of the proposed edits, either intentionally or unintentionally. If the document has had pre-approval editing, when it goes into post-approval editing, one would hope that the editor would look at the diffs from the earlier edit and only edit the changed sections. >Usage of pre-approval editing should be encouraged. Fully agree. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Fri Feb 17 09:52:14 2006 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 1FA6xy-0002fV-4B; Fri, 17 Feb 2006 09:52:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA6xw-0002eu-Dy for techspec@megatron.ietf.org; Fri, 17 Feb 2006 09:52:12 -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 JAA14862 for ; Fri, 17 Feb 2006 09:50:23 -0500 (EST) Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA7CL-0002od-I6 for techspec@ietf.org; Fri, 17 Feb 2006 10:07:08 -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 k1HEpxVV237808 for ; Fri, 17 Feb 2006 14:51:59 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k1HEq5Vs241846 for ; Fri, 17 Feb 2006 15:52:05 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k1HEpwpW006721 for ; Fri, 17 Feb 2006 15:51:58 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k1HEpvhN006679; Fri, 17 Feb 2006 15:51:57 +0100 Received: from zurich.ibm.com (sig-9-146-216-246.de.ibm.com [9.146.216.246]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA49378; Fri, 17 Feb 2006 15:51:53 +0100 Message-ID: <43F5E2FE.1020807@zurich.ibm.com> Date: Fri, 17 Feb 2006 15:51:42 +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: "Stephen Hayes (TX/EUS)" Subject: Re: [Techspec] IAB path [Re: I-D ACTION:draft-mankin-pub-req-04.t xt] References: <4DCBC973AF0D6E4FAF9CD998CE1C003801FC8734@eusrcmw720.eamcs.ericsson.se> In-Reply-To: <4DCBC973AF0D6E4FAF9CD998CE1C003801FC8734@eusrcmw720.eamcs.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db 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 Stephen Hayes (TX/EUS) wrote: > >>-----Original Message----- >>From: techspec-bounces@ietf.org [mailto:techspec-bounces@ietf.org]On >>Behalf Of Harald Tveit Alvestrand >>Sent: Wednesday, February 15, 2006 5:38 PM >>To: Spencer Dawkins; techspec@ietf.org >>Subject: Re: [Techspec] IAB path [Re: I-D >>ACTION:draft-mankin-pub-req-04.txt] >> >> >> >> >>--On onsdag, februar 15, 2006 16:26:48 -0600 Spencer Dawkins >> wrote: >> >> >>>From: "Harald Tveit Alvestrand" >>> >>>>I'd state flatly that the techspec requirements apply to >> >>documents from >> >>>>the IETF that are published with IETF approval, as decided >> >>by the IESG. >> >>>>If, as I think, we want the publication mechanism to be >> >>applicable to >> >>>>other documents (which includes independent submissions, >> >>IAB documents, >> >>>>IRTF documents and IAOC documents, if any), I think the >> >>requirements for >> >>>>those classes of documents need to be separate. >>>> >>>>Trying to merge them makes the process of writing them down FAR too >>>>convoluted. >>>> >>>> Harald >>> >>>Hi, Harald, >>> >>>On this same topic - aren't direct submissions, IETF documents, IAB >>>documents, IRTF documents, and IAOC documents are all submitted and >>>approved for publication in different ways? >>> >>>If so, it seems unhelpful to put procedures for all of >> >>these documents >> >>>into a single draft - wouldn't that mean that the draft >> >>would be approved >> >>>by all the different approving bodies before it could be published? >>> >>>I think I'm agreeing and just trying to make sure I >> >>understand all the >> >>>reasons why you're right :-) >> >>that makes eminent sense to me, so I guess we understand each >>other :-) >> >>otoh, in the end the continuation (or not) of the RFC series >>has to be >>reduced in the end to a single statement of work under a >>single contract - >>but I think the IETF standard process should make *its* input >>into that >>process now, and let the other pieces come along later. >> >> Harald >> >> > > I also think it makes sense to narrow the scope to only IETF documents, as decided by the IESG. This does not prevent many of these requirements from being adopted for documents arriving via other channels. > > This document so far mainly addresses the technical publisher part of the publication process. As indicated in section 5 there are complementary processes that need to be developed on the IETF side. These processes will probably be unique to documents going through the IESG. However (in answer to Harald), the other pieces have to be available, together with the techspec piece, in time for the IAOC to write an RFP, so they actually do have to be worked on in parallel - but not here. I'm not sure that the IAOC will be generating enough RFCs to justify a special process, BTW. The only one we generated so far needed to be a BCP anyway, so it went to the IESG in the normal way. Brian _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Fri Feb 17 10:15:03 2006 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 1FA7Cf-0002io-29; Fri, 17 Feb 2006 10:07:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA7Ba-0001o1-Vs for techspec@megatron.ietf.org; Fri, 17 Feb 2006 10:06:19 -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 KAA18330 for ; Fri, 17 Feb 2006 10:04:30 -0500 (EST) Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA7Q0-0004De-1b for techspec@ietf.org; Fri, 17 Feb 2006 10:21:14 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k1HF63TJ173224 for ; Fri, 17 Feb 2006 15:06:03 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 k1HF68Xr190866 for ; Fri, 17 Feb 2006 15:06:08 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 k1HF63HW019991 for ; Fri, 17 Feb 2006 15:06:03 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 k1HF62dL019980; Fri, 17 Feb 2006 15:06:02 GMT Received: from zurich.ibm.com (sig-9-146-216-246.de.ibm.com [9.146.216.246]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA36094; Fri, 17 Feb 2006 16:04:45 +0100 Message-ID: <43F5E607.5040306@zurich.ibm.com> Date: Fri, 17 Feb 2006 16:04:39 +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: "Stephen Hayes (TX/EUS)" Subject: Re: [Techspec] Pre vs Post approval editing References: <4DCBC973AF0D6E4FAF9CD998CE1C003801FC874C@eusrcmw720.eamcs.ericsson.se> In-Reply-To: <4DCBC973AF0D6E4FAF9CD998CE1C003801FC874C@eusrcmw720.eamcs.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.2 (++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Stephen Hayes (TX/EUS) wrote: > mankin-pub-req currently has requirements for both pre approval (Potential Req-PREEDIT-1) and post approval (Req-POSTEDIT-1). We need to decide which requirements stay and which ones go. > > I think both requirements are needed, however each document should only have to pass through either pre-approval editing or post-approval editing but not both. This will allow the IETF to migrate to a methodology using pre-approval editing over time. Usage of pre-approval editing should be encouraged. What about cases where (e.g. due to major issues during IESG processing), significant new text has appeared? I think we need the option of a post approval edit pass in such cases, but it should be the exception. > > In addition an additional requirement should be added along the lines of: > > o Potential Req-TIMEFRAMES-3 - The IETF technical publisher should have a goal of an average time for completing the pre-approval editorial review of no more than 2 weeks and at least 98% of all documents should be reviewed within 4 weeks. The review interval starts when the editorial review is requested and ends when the review results are provided. I'm leery of specifying the times here. I think we should make the requirement that there *should* be target times, but leave the actual values to the RFP process. These times can have a direct effect on cost, and I don't think it's appropriate to fix them a priori. It would be OK to say The IETF technical publisher should have a defined goal for the average time for completing the pre-approval editorial review and for the 90th percentile. Suggested target times are two and four weeks respectively. Honestly, I think a 98th percentile target is unreasonable for this kind of work. And these comments apply elsewhere in the draft too. > This is to prevent simply shifting the long queuing delay from the post-approval phase to the pre-approval phase. > > I would also propose that we add text prohibiting stylistic changes in the post-approval editing (but permit it in pre-approval editing). Yes, but even in pre-approval I see no reason why editing should change the tone, for example by removing intentional informality. Brian _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Fri Feb 17 10:19:43 2006 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 1FA7OZ-0001UW-FD; Fri, 17 Feb 2006 10:19:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA7OX-0001TN-Dm for techspec@megatron.ietf.org; Fri, 17 Feb 2006 10:19:41 -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 KAA22233 for ; Fri, 17 Feb 2006 10:17:52 -0500 (EST) Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA7cv-0005qu-HM for techspec@ietf.org; Fri, 17 Feb 2006 10:34:37 -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 k1HFJRQk155194 for ; Fri, 17 Feb 2006 15:19:27 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k1HFJXVs212284 for ; Fri, 17 Feb 2006 16:19:33 +0100 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k1HFJQlC005833 for ; Fri, 17 Feb 2006 16:19:26 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k1HFJPP7005818; Fri, 17 Feb 2006 16:19:26 +0100 Received: from zurich.ibm.com (sig-9-146-216-246.de.ibm.com [9.146.216.246]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA35994; Fri, 17 Feb 2006 16:19:25 +0100 Message-ID: <43F5E977.3000905@zurich.ibm.com> Date: Fri, 17 Feb 2006 16:19:19 +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: "Stephen Hayes (TX/EUS)" Subject: Re: [Techspec] Referencing by external organizations References: <4DCBC973AF0D6E4FAF9CD998CE1C003801FC874E@eusrcmw720.eamcs.ericsson.se> In-Reply-To: <4DCBC973AF0D6E4FAF9CD998CE1C003801FC874E@eusrcmw720.eamcs.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.2 (++) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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 below... Stephen Hayes (TX/EUS) wrote: > One of the goals of re-engineering the technical publication > process is to solve the problems with providing references to > external organizations. Outside organizations often want to > reference IETF specifications, but are frustrated by their > unavailability since they cannot be formally referenced until > they exit the RFC queue. > > Three approaches have been proposed to address this issue: 1. > Expedited handling - moving some critically needed documents > to the top of the queue > > o Current Req-EXPEDITE-1 - The IETF technical publisher shall > expedite the processing of specific documents at the request > of the IESG. > > 2. Early allocation of permanent identifiers - this allows > outside documents to complete their specifications (populated > with the correct references) with the expectation that the > document will eventually pop out. > > o Potential Req-PERMID-2 - The IETF technical publisher > should permit early allocation of stable identifiers for or > by the IESG to satisfy referencing requirements of external > bodies. > > 3. Tighten the overall publication timelines so there is not > a long wait before publication > > o Potential Req-TIMEFRAMES-1 - The IETF technical publisher > should have a goal of an average publication time of no more > than 4 weeks and at least 98% of all documents should be > published within 8 weeks. Documents held up due to references > or due to a protocol action should be excluded from this > statistic. > > I would propose that we focus on approachs 2 & 3 and drop 1. I don't think we can drop 1. Even if we reach perfection with 2 and 3, I'm not prepared to assert that we will never need expedited publishing. So it should be part of the statement of work, even if we very rarely need it in the new world, IMHO. > Approach 3 by itself is hard to guarantee (especially with > the references loophole). If an identifier can be provided > early, with an expectation that the final document will > appear within a reasonable time, then I suspect most external > organizations will be satisfied. Most standards > organizations will accept the risk that the published > document could be delayed or possibly never appear. There is a *reason* for requiring references at this time. We don't want to generate citations of documents that may not be released from the reference state for an indefinite period. That would miss the point of why we hold documents for normative references in the first place. Ditto if it's waiting for an approval. > > I would also propose to tighten up the requirement of the > allocation of stable identifiers from 4 weeks to 1 week and > remove the exclusions for references and protocol actions. I agree to shorten the target time but I don't agree about the exclusions. > > o Potential Req-TIMEFRAMES-2 - The IETF technical publisher > should have a goal of an average stable identifier allocation > time of no more than 1 week and at least 98% of documents > should have a stable identifier allocated within 2 weeks of > approval. As in my previous message, I think the actual definition of the target times is a matter for the RFP. In this case, the 98th percentile seems attainable, but if I was responding to an RFP, I'd price it up to pay for vacation and sickness cover. So even here, I'd suggest the 90th percentile. Brian _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Fri Feb 17 10:39:59 2006 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 1FA7iB-0003DM-GS; Fri, 17 Feb 2006 10:39:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA7i7-0003Au-Mc for techspec@megatron.ietf.org; Fri, 17 Feb 2006 10:39: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 KAA27464 for ; Fri, 17 Feb 2006 10:38:06 -0500 (EST) Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA7wY-000816-S8 for techspec@ietf.org; Fri, 17 Feb 2006 10:54:52 -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 k1HFkU4F001348; Fri, 17 Feb 2006 09:46:30 -0600 Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72) id <1FXKH0KW>; Fri, 17 Feb 2006 09:39:44 -0600 Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C003801FC8DD9@eusrcmw720.eamcs.ericsson.se> From: "Stephen Hayes (TX/EUS)" To: Paul Hoffman , techspec@ietf.org Subject: RE: [Techspec] Pre vs Post approval editing Date: Fri, 17 Feb 2006 09:35:04 -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: 9182cfff02fae4f1b6e9349e01d62f32 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 > There is a significant problem with have a document edited > pre-approval and then not re-editing post-approval, namely the > changes that get introduced during the approval process itself. A > typical change is "add a section to the Security Considerations > talking about how Wxyz interacts with this protocol." Unless the > authors use exactly the same spelling, capitalization, reference > format, and so on, that new section will not match the rest of the > document. Does this mean that you would permit stylistic changes as part of the post-approval editing? > > There is also the very real issue of document authors not doing some > of the proposed edits, either intentionally or unintentionally. If there is a problem with review suggestions not being done or being mangled, wouldn't it be better to have a recheck done as part of the pre-approval review? > > If the document has had pre-approval editing, when it goes into > post-approval editing, one would hope that the editor would look at > the diffs from the earlier edit and only edit the changed sections. > I have no problem with all documents passing through post-approval editing as a safety net, but for those documents already pre-approval reviewed, wouldn't it be better to only correct major flaws (missing boilerplate, etc.). Stylistic consistency is a nice goal, and reasonable people can disagree on how much effort to put into it. I have heard a lot more complaints about IETF publication delays than IETF publication quality. Stephen Hayes _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Fri Feb 17 10:44:01 2006 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 1FA7m4-0005hs-Ub; Fri, 17 Feb 2006 10:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA7m4-0005hf-1h for techspec@megatron.ietf.org; Fri, 17 Feb 2006 10:44:00 -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 KAA28805 for ; Fri, 17 Feb 2006 10:42:11 -0500 (EST) Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA80V-0008VE-Dr for techspec@ietf.org; Fri, 17 Feb 2006 10:58:56 -0500 Received: from s73602 (unknown[65.104.224.98]) by comcast.net (sccrmhc11) with SMTP id <20060217154347011004c00fe>; Fri, 17 Feb 2006 15:43:47 +0000 Message-ID: <050201c633d8$b8b770a0$66087c0a@china.huawei.com> From: "Spencer Dawkins" To: References: <4DCBC973AF0D6E4FAF9CD998CE1C003801FC874C@eusrcmw720.eamcs.ericsson.se> <43F5E607.5040306@zurich.ibm.com> Subject: Re: [Techspec] Pre vs Post approval editing Date: Fri, 17 Feb 2006 09:42:11 -0600 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: 769a46790fb42fbb0b0cc700c82f7081 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 Two (fairly distinct) points... Spencer From: "Brian E Carpenter" > Stephen Hayes (TX/EUS) wrote: >> mankin-pub-req currently has requirements for both pre approval >> (Potential Req-PREEDIT-1) and post approval (Req-POSTEDIT-1). We need to >> decide which requirements stay and which ones go. >> >> I think both requirements are needed, however each document should only >> have to pass through either pre-approval editing or post-approval editing >> but not both. This will allow the IETF to migrate to a methodology using >> pre-approval editing over time. Usage of pre-approval editing should be >> encouraged. > > What about cases where (e.g. due to major issues during IESG processing), > significant new text has appeared? I think we need the option of a post > approval edit pass in such cases, but it should be the exception. OK, this is the IETF side of techspec, which is likely a newtrk responsibility, but ... if a working group forwards out a working group-consensus draft, and then "significant new text appears", we probably need more than a "post approval edit pass" in most cases, don't we? Given that this stuff really *should* be running through the working group before publication, why do we need a post-approval edit pass? I agree that significant new text during approval processing should be the exception. >> I would also propose that we add text prohibiting stylistic changes in >> the post-approval editing (but permit it in pre-approval editing). > > Yes, but even in pre-approval I see no reason why editing should change > the tone, for example by removing intentional informality. Agree, and suggest that the wording say something like "proposed" when we talk about stylistic changes, so that it's perhaps more obvious that stylistic changes aren't gating for document approval and/or publication - if Brian and Elwyn spell the word as "colour" in their drafts, and don't want to accept a proposed change from "colour" to "color", that's OK within techspec. Thanks, Spencer _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Fri Feb 17 11:10:24 2006 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 1FA8Bc-0007wA-GY; Fri, 17 Feb 2006 11:10:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA8Ba-0007vp-UA for techspec@megatron.ietf.org; Fri, 17 Feb 2006 11:10:22 -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 LAA05180 for ; Fri, 17 Feb 2006 11:08:34 -0500 (EST) Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA8Q2-0002QW-CP for techspec@ietf.org; Fri, 17 Feb 2006 11:25:19 -0500 Received: from s73602 (unknown[65.104.224.98]) by comcast.net (sccrmhc12) with SMTP id <20060217161009012005id18e>; Fri, 17 Feb 2006 16:10:10 +0000 Message-ID: <057201c633dc$67d08ba0$66087c0a@china.huawei.com> From: "Spencer Dawkins" To: "Stephen Hayes \(TX/EUS\)" , "Paul Hoffman" , References: <4DCBC973AF0D6E4FAF9CD998CE1C003801FC8DD9@eusrcmw720.eamcs.ericsson.se> Subject: Re: [Techspec] Pre vs Post approval editing Date: Fri, 17 Feb 2006 10:08:34 -0600 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.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit 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 From: "Stephen Hayes (TX/EUS)" To: "Paul Hoffman" ; >> There is also the very real issue of document authors not doing some >> of the proposed edits, either intentionally or unintentionally. > > If there is a problem with review suggestions not being done or being > mangled, wouldn't it be better to have a recheck done as part of the > pre-approval review? I would think so... >> If the document has had pre-approval editing, when it goes into >> post-approval editing, one would hope that the editor would look at >> the diffs from the earlier edit and only edit the changed sections. >> > > I have no problem with all documents passing through post-approval editing > as a safety net, but for those documents already pre-approval reviewed, > wouldn't it be better to only correct major flaws (missing boilerplate, > etc.). Stylistic consistency is a nice goal, and reasonable people can > disagree on how much effort to put into it. I have heard a lot more > complaints about IETF publication delays than IETF publication quality. :-) Thanks, Spencer _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Fri Feb 17 11:13:51 2006 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 1FA8Ex-0000c5-AQ; Fri, 17 Feb 2006 11:13:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA8Ev-0000b9-LH for techspec@megatron.ietf.org; Fri, 17 Feb 2006 11:13:49 -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 LAA05829 for ; Fri, 17 Feb 2006 11:12:00 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA8TN-0002fF-Tu for techspec@ietf.org; Fri, 17 Feb 2006 11:28:46 -0500 Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id k1HGDdRW070417; Fri, 17 Feb 2006 08:13:40 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4DCBC973AF0D6E4FAF9CD998CE1C003801FC8DD9@eusrcmw720.eamcs.ericsson.se> References: <4DCBC973AF0D6E4FAF9CD998CE1C003801FC8DD9@eusrcmw720.eamcs.ericsson.se> Date: Fri, 17 Feb 2006 08:13:38 -0800 To: "Stephen Hayes (TX/EUS)" , techspec@ietf.org From: Paul Hoffman Subject: RE: [Techspec] Pre vs Post approval editing Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 At 9:35 AM -0600 2/17/06, Stephen Hayes (TX/EUS) wrote: > > There is a significant problem with have a document edited >> pre-approval and then not re-editing post-approval, namely the >> changes that get introduced during the approval process itself. A >> typical change is "add a section to the Security Considerations >> talking about how Wxyz interacts with this protocol." Unless the >> authors use exactly the same spelling, capitalization, reference >> format, and so on, that new section will not match the rest of the >> document. > >Does this mean that you would permit stylistic changes as part of >the post-approval editing? Only to match any stylistic changes that were introduced in the pre-approval editing (or that the document authors were trying to follow themselves). If a document has had pre-approval editing, the post-approval editing really should only be on the diffs. > > There is also the very real issue of document authors not doing some >> of the proposed edits, either intentionally or unintentionally. > >If there is a problem with review suggestions not being done or >being mangled, wouldn't it be better to have a recheck done as part >of the pre-approval review? Maybe, but maybe not. It really depends on the purpose of the edits and how intrusive the Publisher is allowed to be in making changes. Some authors are quite graceful about being edited, while others are not so graceful. Giving the Publisher the ability to prevent a document from even getting to the approval stage because the authors don't want to implement some editorial changes may or may not be what the IETF wants. For that matter, giving the Publisher the unilateral right to make editorial changes in post-approval editing may or may not be what the IETF wants. A possible way to frame it is that pre-approval editing be considered a polite foreshadowing of what the authors should expect in the post-approval editing. The authors should either incorporate all of the pre-approval editing (the norm) or do most of it and tell the Publisher why they didn't do some of it. That input could be used in the post-approval editing. >I have no problem with all documents passing through post-approval >editing as a safety net, but for those documents already >pre-approval reviewed, wouldn't it be better to only correct major >flaws (missing boilerplate, etc.). If it takes only a few minutes to correct minor flaws in the text that has changed during review, there seems like no good reason not to do so. > Stylistic consistency is a nice goal, and reasonable people can >disagree on how much effort to put into it. Fully agree. That's why pre-approval editing is valuable: bring up the changes when there feels like less urgency. >I have heard a lot more complaints about IETF publication delays >than IETF publication quality. Absolutely right. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Fri Feb 17 19:15:20 2006 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 1FAFku-000537-Ao; Fri, 17 Feb 2006 19:15:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAFkq-00052L-32 for techspec@megatron.ietf.org; Fri, 17 Feb 2006 19:15:18 -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 TAA03127 for ; Fri, 17 Feb 2006 19:13:27 -0500 (EST) Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAFzL-0004TC-DI for techspec@ietf.org; Fri, 17 Feb 2006 19:30:16 -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; Fri, 17 Feb 2006 19:14:23 -0500 id 015880C5.43F666DF.00006CF5 Message-ID: <43F66703.3030104@thinkingcat.com> Date: Fri, 17 Feb 2006 19:14:59 -0500 From: Leslie Daigle User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harald Tveit Alvestrand Subject: Re: [Techspec] IAB path [Re: I-D ACTION:draft-mankin-pub-req-04.txt] References: <43E71BAD.4070701@zurich.ibm.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: c0bedb65cce30976f0bf60a0a39edea4 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 Having mulled it over a bit (and strictly as an individual contributor here): I agree about the complexity of trying to capture the needs of all potential IETF-constellation publication paths. However, I am concerned that having each (IAB, IRTF) define their own requirements independently will create something of an implementation quagmire for the publisher. ("If it's a Tuesday, and it's an IAB document, I have 3 days remaining to get this out"). So, while requirements relating to approval may be inapplicable to IAB documents (eg), format (conversion) and publication tracking had better be consistent across all paths. I suggest that may mean separating requirements in the document to be clear about which ones are invariant across all IETF-group-produced documents, and which ones are specific to WGs. Or, call out the "approval" steps and make it clear they are for IETF WG process, and that other approval requirements may be created. Or something. Leslie. Harald Tveit Alvestrand wrote: > > > --On mandag, februar 06, 2006 10:49:33 +0100 Brian E Carpenter > wrote: > >> Scope nit: >> >>> This draft only addresses those documents submitted to the IETF via >>> the IAB, IESG, or IRTF. >> >> >> In fact nothing substantive is said about IAB documents. Perhaps it needs >> to be stated as a requirement that the technical publisher shall accept >> for publication, as IETF documents, only drafts that have been approved >> by the IESG, or drafts from the IAB (which do not require IESG approval). > > > I'd state flatly that the techspec requirements apply to documents from > the IETF that are published with IETF approval, as decided by the IESG. > > If, as I think, we want the publication mechanism to be applicable to > other documents (which includes independent submissions, IAB documents, > IRTF documents and IAOC documents, if any), I think the requirements for > those classes of documents need to be separate. > > Trying to merge them makes the process of writing them down FAR too > convoluted. > > Harald > > > _______________________________________________ > 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 Sat Feb 18 12:01:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAVSY-0002MN-7R; Sat, 18 Feb 2006 12:01:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAUzv-0002BM-6C for techspec@ietf.org; Sat, 18 Feb 2006 11:31:51 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAUXu-0002Vo-5Q for techspec@ietf.org; Sat, 18 Feb 2006 11:02:54 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FAU2U-0000uV-Qk for techspec@ietf.org; Sat, 18 Feb 2006 10:30:27 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1FAU2O-000Bmh-Qc; Sat, 18 Feb 2006 10:30:21 -0500 Date: Sat, 18 Feb 2006 10:30:20 -0500 From: John C Klensin To: Eric Rescorla Subject: Re: [Techspec] Editing consistency Message-ID: <438B3BBDDAA95F409CAF4B51@p3.JCK.COM> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -1.1 (-) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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: , Errors-To: techspec-bounces@ietf.org --On Monday, 06 February, 2006 14:50 -0800 Eric Rescorla wrote: > Paul Hoffman wrote: > >> At 3:52 PM -0600 2/6/06, Spencer Dawkins wrote: >> > Given that we won't have consistency across all time, I >> > don't know why consistency across all documents published >> > in a given month or year matters. >> >> I don't think that was Eric's point. He showed that a >> *revised RFC* had stylistic changes such as capitalization in >> the headings and copy-editing changes (for example, changing >> "that" for "which", or changing "since" to "because"). He >> pointed out a real mechanical problem: it is hard to use a >> diff-style tool to determine the relevant changes. >> >> Thus, there may be a Techspec requirement here that the >> publisher not make purely stylistic changes on RFC revisions. > > That's exactly the question I think is appropriate to be > considering. While I agree with your reasoning about editing consistency for document versions, I think the question / recommendation is too narrow. My impression is that the RFC Editor adopted (incrementally and perhaps not explicitly) a policy/procedural change around six years ago. Prior to that time, the style rule was for both submissions and output was, approximately "look at other RFCs that seem to be similar to this one in content, weighted by more recent ones, and do something similar". Stylistic changes were generally made in editing only when they were necessary for clarity, when the submitted style was just wrong, or to improve stylistic consistency within the document itself. The more recent trend has been to make significant stylistic changes during editing, apparently to enforce conformance with a style manual that no one has really seen (see below). While there is a plausible alternative (again, see below), I believe that _any_ purely stylistic editing that goes beyond the traditional (significantly pre 1999) practice is a bad idea. The comments about diff tools applies equally well to I-D -> RFC changes as it does to revised RFCs. Increasing the number of changes made in editing increases the risk of errors slipping in undetected (e.g., we discovered last week that a substantive error had been introduced into a key procedural document, apparently because the copy editor, in trying to transform "a, b, and c" constructions to "a, b and c" ones, repositioned a comma in a qualifying phrase. Because of the list changes, he authors' eyes glazed over in AUTH48 and stopped looking at comma changes. And, of course, making changes that do not need to be made consumes resources --both in the editing process and by the authors in checking, etc., -- that could presumably be used in other ways. "Below": On the other hand, there is another way to accomplish the same goal. The IETF community should make a choice and then be careful about what is wished for. The traditional, permissive, style conventions actually pose a problem. In my experience, if one hires professional copy editors without a history with the document series, their first question is "to which style manual are we editing?". If the answer is "we don't have one", then each such editor will tend to apply his or her own rules. The types of changes Eric and Spencer identify are then almost inevitable. So the other alternative is to charge the editor with creating a formal, publishable, style manual for technical documents and then to insist that everyone conform to it. The main disadvantages of doing so are that creating and agreeing on one would also consume resources, getting technical specification authors to conform to a particular style manual shifts resources from the specification editing process to volunteers, which is probably not a shift we want to make, and the flexibility inherent in our traditional approach is often A Good Thing. On the other hand, a single, specific style is much easier to permit and enforce with generic document markup and similar tools than the more flexible tradition. Again, one should be careful about one wishes for -- some years ago, at least one publisher decided to solve the "a, b [,] and c" problem by insisting on SGML markup of the character of a b c and then treating the presentation of the construction as a formatting matter. While that actually has some significant advantages, such as permitting "a, b, c, d, e, and f" to be turned into a bulleted list if some conditions are met, it can get extremely tedious for the person creating the document and doing the generic markup. john _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Sat Feb 18 12:01:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAVSf-0002RL-RX; Sat, 18 Feb 2006 12:01:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAUzv-0002BM-Ph for techspec@ietf.org; Sat, 18 Feb 2006 11:31:51 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAUXd-0002Vo-4o for techspec@ietf.org; Sat, 18 Feb 2006 11:02:37 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FAUGu-00015a-Pj for techspec@ietf.org; Sat, 18 Feb 2006 10:45:21 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1FAUGt-000Bnr-IY; Sat, 18 Feb 2006 10:45:19 -0500 Date: Sat, 18 Feb 2006 10:45:18 -0500 From: John C Klensin To: Brian E Carpenter Subject: Re: [Techspec] Pre vs Post approval editing Message-ID: <59D65C7DB1DC6343C2BA939E@p3.JCK.COM> In-Reply-To: <43F5E607.5040306@zurich.ibm.com> References: <4DCBC973AF0D6E4FAF9CD998CE1C003801FC874C@eusrcmw720.e amcs.ericsson.se> <43F5E607.5040306@zurich.ibm.com> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -1.8 (-) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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: , Errors-To: techspec-bounces@ietf.org --On Friday, 17 February, 2006 16:04 +0100 Brian E Carpenter wrote: >> I think both requirements are needed, however each document >> should only have to pass through either pre-approval editing >> or post-approval editing but not both. This will allow the >> IETF to migrate to a methodology using pre-approval editing >> over time. Usage of pre-approval editing should be >> encouraged. > > What about cases where (e.g. due to major issues during IESG > processing), significant new text has appeared? I think we > need the option of a post approval edit pass in such cases, > but it should be the exception. Brian, To repeat a comment of Spencer's, but with a different slant, it seems to me that, for this reason, the entire pre- versus post-approval editing question cannot be answered except in the context of evolution of the standards process. Our friends with more traditional standards processes (and a larger infestation of [real] lawyers, have firm "the document that is approved is the document that is published" rules for what seem to them to be obvious reasons. Such rules effectively require that any document changes of a technical or editorial nature occur before the formal decision (ballot in their case) point. The only post-approval editing that is possible involves formatting and attachment of final boilerplate and, typically, very little of the former. Their idea of "approval" involves some complex dealings that are called a "ballot resolution process" in ISO-speak (other groups have other procedures and other terminology). Were we to adopt a similar model without making major structural changes, "major issues during IESG processing" would require return of the document to the WG with suggested text. The WG would then do its thing and then return the document to the IESG via a second-round pre-approval editing process. We have had "discussions" before about the issue of whether it is really appropriate for the IESG to alter a document, perhaps negotiate the changes with a document editor and/or WG chair, and then send the document on to the RFC Editor without formal WG signoff. I don't think I saw clear consensus either way, but it was clear that some non-trivial portion of the community has been unhappy with that procedure in some number of cases. But I think the IETF decision about this needs to be made first and then decisions about pre- or post-approval editing made in that context. While I personally favor pre-approval editing, it seems to me that it is justified/ appropriate only if it serves one of two functions: (1) Improving the presentation quality of a document, not to approximately-final form, but so that its technical/ protocol intent is completely clear. This is certainly not required for all documents that emerge from every WG, but we have all seen I-Ds whose presentation is sufficiently poor that it was obvious that the intent of the protocol provisions could not be interpreted unambiguously. Today, those documents are typically handled by AD intervention prior to Last Call. There is a case to be made that we should have better rules, better mechanisms, and a more organized way to get that level of editing and document approval done. It is not clear that having the Publisher do that work is the most efficient approach. (2) Making sure that the document that is Last Called and approved will be the one that is published, with very small deviations and only of varieties that are well-understood procedurally. And whether we want either of those (or more of them) and what to do about them are, I believe, IETF standards process decisions, not technical-specification-handling ones. john _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Sat Feb 18 12:06:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAVXp-0003Lp-51; Sat, 18 Feb 2006 12:06:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAUzv-0002Bg-Ie for techspec@ietf.org; Sat, 18 Feb 2006 11:31:51 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAUYX-0002Vo-5u for techspec@ietf.org; Sat, 18 Feb 2006 11:03:33 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FARSw-0007xb-SH for techspec@ietf.org; Sat, 18 Feb 2006 07:45:35 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1FARSu-000BXU-G9; Sat, 18 Feb 2006 07:45:32 -0500 Date: Sat, 18 Feb 2006 07:45:31 -0500 From: John C Klensin To: Leslie Daigle , Harald Tveit Alvestrand Subject: Re: [Techspec] IAB path [Re: I-D ACTION:draft-mankin-pub-req-04.txt] Message-ID: In-Reply-To: <43F66703.3030104@thinkingcat.com> References: <43E71BAD.4070701@zurich.ibm.com> <43F66703.3030104@thinkingcat.com> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -1.1 (-) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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: , Errors-To: techspec-bounces@ietf.org Leslie, This is getting fairly far from what I've understood to be techspec's non-charter, but two additional observations... --On Friday, 17 February, 2006 19:14 -0500 Leslie Daigle wrote: > > Having mulled it over a bit (and strictly as an individual > contributor here): > > I agree about the complexity of trying to capture the > needs of all potential IETF-constellation publication paths. > > However, I am concerned that having each (IAB, IRTF) define > their own requirements independently will create something of > an implementation quagmire for the publisher. ("If it's a > Tuesday, and it's an IAB document, I have 3 days remaining > to get this out"). > > So, while requirements relating to approval may be > inapplicable to IAB documents (eg), format (conversion) and > publication tracking had better be consistent across all > paths. > > I suggest that may mean separating requirements in the document > to be clear about which ones are invariant across all > IETF-group-produced documents, and which ones are specific to > WGs. Or, call out the "approval" steps and make it clear > they are for IETF WG process, and that other approval > requirements may be created. I think this is exactly right. From the standpoint of an RFP, the right organization should be something like: N. Documents will originate from different sources, each with its own approval process. All but N.3 are non-discretionary in terms of publication, although the RFC Editor may return them to the authorizing body if they are incomprehensible. N.1 The IETF (IESG) approval process N.2 IAB-authorized approval processes N.3 Independent submissions N.4 Other processes approved from time to time by the IAB and IAOC. N+1. Technical Editing N+2. Copy editing N+3. Formatting ... And, if one gets to this level of detail, the RFP or contract must address one other issue that arises naturally from multiple paths: who has the right to set processing priorities and by what mechanism. We have recently had a situation in which one body has, from time to time, nearly starved other paths for resources simply by insisting that its documents come first. That may be reasonable, or may not, but, if two bodies make the same demands... john _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Feb 22 02:41:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBod6-0008Iu-JN; Wed, 22 Feb 2006 02:41:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBod5-0008Id-SS for techspec@ietf.org; Wed, 22 Feb 2006 02:41:43 -0500 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBod4-00052Q-CE for techspec@ietf.org; Wed, 22 Feb 2006 02:41:43 -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 k1M7ffHm224622 for ; Wed, 22 Feb 2006 07:41:41 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.8) with ESMTP id k1M7fpHl234690 for ; Wed, 22 Feb 2006 08:41:51 +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 k1M7feqE008975 for ; Wed, 22 Feb 2006 08:41:40 +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 k1M7fegs008966; Wed, 22 Feb 2006 08:41:40 +0100 Received: from zurich.ibm.com (sig-9-146-220-210.de.ibm.com [9.146.220.210]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id IAA29586; Wed, 22 Feb 2006 08:41:39 +0100 Message-ID: <43FB5BCC.6040501@zurich.ibm.com> Date: Tue, 21 Feb 2006 19:28:28 +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: John C Klensin Subject: Re: [Techspec] Pre vs Post approval editing References: <4DCBC973AF0D6E4FAF9CD998CE1C003801FC874C@eusrcmw720.e amcs.ericsson.se> <43F5E607.5040306@zurich.ibm.com> <59D65C7DB1DC6343C2BA939E@p3.JCK.COM> In-Reply-To: <59D65C7DB1DC6343C2BA939E@p3.JCK.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db 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: , Errors-To: techspec-bounces@ietf.org In answer both to Spencer and John, it's elementary that if IESG review throws up things that need to get changes, and that are substantive, they go back to the WG and maybe even through another last call cycle. But that can happen quite quickly sometimes, and I wouldn't want to inject delay in the form of an edit cycle right then. Sometimes it's only a paragraph or a sentence but it can still need copy editing. Brian John C Klensin wrote: > > --On Friday, 17 February, 2006 16:04 +0100 Brian E Carpenter > wrote: > > >>>I think both requirements are needed, however each document >>>should only have to pass through either pre-approval editing >>>or post-approval editing but not both. This will allow the >>>IETF to migrate to a methodology using pre-approval editing >>>over time. Usage of pre-approval editing should be >>>encouraged. >> >>What about cases where (e.g. due to major issues during IESG >>processing), significant new text has appeared? I think we >>need the option of a post approval edit pass in such cases, >>but it should be the exception. > > > Brian, > > To repeat a comment of Spencer's, but with a different slant, it > seems to me that, for this reason, the entire pre- versus > post-approval editing question cannot be answered except in the > context of evolution of the standards process. Our friends with > more traditional standards processes (and a larger infestation > of [real] lawyers, have firm "the document that is approved is > the document that is published" rules for what seem to them to > be obvious reasons. Such rules effectively require that any > document changes of a technical or editorial nature occur before > the formal decision (ballot in their case) point. The only > post-approval editing that is possible involves formatting and > attachment of final boilerplate and, typically, very little of > the former. Their idea of "approval" involves some complex > dealings that are called a "ballot resolution process" in > ISO-speak (other groups have other procedures and other > terminology). > > Were we to adopt a similar model without making major structural > changes, "major issues during IESG processing" would require > return of the document to the WG with suggested text. The WG > would then do its thing and then return the document to the IESG > via a second-round pre-approval editing process. > > We have had "discussions" before about the issue of whether it > is really appropriate for the IESG to alter a document, perhaps > negotiate the changes with a document editor and/or WG chair, > and then send the document on to the RFC Editor without formal > WG signoff. I don't think I saw clear consensus either way, but > it was clear that some non-trivial portion of the community has > been unhappy with that procedure in some number of cases. But I > think the IETF decision about this needs to be made first and > then decisions about pre- or post-approval editing made in that > context. While I personally favor pre-approval editing, it > seems to me that it is justified/ appropriate only if it serves > one of two functions: > > (1) Improving the presentation quality of a document, not to > approximately-final form, but so that its technical/ protocol > intent is completely clear. This is certainly not required for > all documents that emerge from every WG, but we have all seen > I-Ds whose presentation is sufficiently poor that it was obvious > that the intent of the protocol provisions could not be > interpreted unambiguously. Today, those documents are > typically handled by AD intervention prior to Last Call. There > is a case to be made that we should have better rules, better > mechanisms, and a more organized way to get that level of > editing and document approval done. It is not clear that having > the Publisher do that work is the most efficient approach. > > (2) Making sure that the document that is Last Called and > approved will be the one that is published, with very small > deviations and only of varieties that are well-understood > procedurally. > > And whether we want either of those (or more of them) and what > to do about them are, I believe, IETF standards process > decisions, not technical-specification-handling ones. > > john > > > _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Feb 22 18:16:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC3DT-00072B-Vo; Wed, 22 Feb 2006 18:16:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC3DT-000725-9R for techspec@ietf.org; Wed, 22 Feb 2006 18:16:15 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC3DS-0001OP-0d for techspec@ietf.org; Wed, 22 Feb 2006 18:16:15 -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 k1MNNEDd020165 for ; Wed, 22 Feb 2006 17:23:14 -0600 Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72) id <1FXKJR9P>; Wed, 22 Feb 2006 17:16:13 -0600 Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C00380206B898@eusrcmw720.eamcs.ericsson.se> From: "Stephen Hayes (TX/EUS)" To: techspec@ietf.org Date: Wed, 22 Feb 2006 17:16:04 -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: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Techspec] Summary of pub-req scope discussions and proposals 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: , Errors-To: techspec-bounces@ietf.org The issue being discussed is whether the mankin-pub-req draft should address IESG approved documents or have a wider scope. It has been pointed out that it is useful to have a common set of requirements on the technical publisher, but that the client organizations may well have differing processes that may be impossible to coordinate. mankin-pub-req currently deals mainly with requirements on the technical publisher. The need for further process work within the IETF is recognized within section 5, but is not fully dealt with. So, with the exception of section 5, the technical publisher requirements should apply to all the client organizations. It is recommended that: 1. The scope of pub-req be clarified to indicate that it applies to documents within the IETF family including IETF documents processed by the IESG, IAB documents processed by the IETF, and IRTF documents processed by the IRTF (other wording happily accepted). 2. Ensure that these organizations which use the technical publisher service have the opportunity to review mankin-pub-req so that it represents the consensus of the IETF family. 3. Modify section 5 to indicate that processes for working with and feeding documents into the technical publisher needs to be developed in the respective organizations, however indicate that this will be documented in companion documents which can be generated by the respective organizations. 4. Processes for arbitrating between competing resource requests by organizations within the IETF family needs to be dealt with, but mankin-pub-req does not seem like an appropriate place for documenting the priorities. So this would not be covered in mankin-pub-req. Regards, Stephen _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Feb 22 18:16:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC3Dj-00073e-2L; Wed, 22 Feb 2006 18:16:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC3Di-00073U-8r for techspec@ietf.org; Wed, 22 Feb 2006 18:16:30 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC3Dg-0001OZ-VB for techspec@ietf.org; Wed, 22 Feb 2006 18:16:30 -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 k1MNNTQG020209 for ; Wed, 22 Feb 2006 17:23:29 -0600 Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72) id <1FXKJR94>; Wed, 22 Feb 2006 17:16:28 -0600 Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C00380206B899@eusrcmw720.eamcs.ericsson.se> From: "Stephen Hayes (TX/EUS)" To: techspec@ietf.org Date: Wed, 22 Feb 2006 17:16:14 -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: d6b246023072368de71562c0ab503126 Subject: [Techspec] Summary of pre vs post editing discussions and proposals 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: , Errors-To: techspec-bounces@ietf.org There seemed to be general consensus on shifting emphasis from post to pre approval editing. The contentious issue seems to be how to deal with changes to the documents that occur after a pre-approval review. Although there were many warnings about the dangers of changing carefully crafted compromise text introduced during the IESG review, no one (except me) said it should be prohibited. Most voices seemed to accept that some light consistency editing could be performed in the final review provided that great discipline was used. The processes (or procedures) to decide when the IESG introduced changes warrant sending it back to the WG and when it can go forward are IETF processes (or procedures) so are not requirements on the technical publisher. In general, there seemed to also be agreement that stylistic changes for document consistency should be done sparingly. Recommendations: 1. Emphasis be placed on shifting from post-approval to pre-approval editing 2. Both pre and post approval editing are kept as requirements on the technical publisher. 3. Wording be added to the requirement on post approval editing indicating that the technical publisher should make minimal changes in the post approval edit since there are limited opportunities to catch any errors introduced by the technical publisher. 4. Changes for stylistic consistency should be done only when there are major problems with the quality of a document. Stephen _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Feb 22 18:16:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC3Dp-00074S-5I; Wed, 22 Feb 2006 18:16:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC3Dn-00074J-8F for techspec@ietf.org; Wed, 22 Feb 2006 18:16:35 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC3Dl-0001Oj-VR for techspec@ietf.org; Wed, 22 Feb 2006 18:16:35 -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 k1MNNYDK020217 for ; Wed, 22 Feb 2006 17:23:34 -0600 Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72) id <1FXKJR9W>; Wed, 22 Feb 2006 17:16:33 -0600 Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C00380206B89A@eusrcmw720.eamcs.ericsson.se> From: "Stephen Hayes (TX/EUS)" To: techspec@ietf.org Date: Wed, 22 Feb 2006 17:16:21 -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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Techspec] Summary of referencing by external org discussions and proposals 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: , Errors-To: techspec-bounces@ietf.org The issue was which mechanisms to use to allow external organizations to reference IETF specs. The mechanisms proposed were: 1. expedited handling 2. early allocation of permanent, stable IDs 3. getting documents published in a timely manner Situations will arise where publication of a document will be delayed (such as for pending references) [mechanism 3]. In this case it is inappropriate to publicize a permanent, stable ID since the IETF cannot guarantee the document will be published soon [mechanism 2]. However in this case expedited handling will not work either [mechanism 1]. So there are just some cases, where the IETF cannot get the document out in time. Expedited document handling is however probably needed for a while at least until the methodology for early allocation of permanent IDs is established. There was also discussion of what the stable ID was and if it could be used to identify a document throughout its lifecycle from draft to published RFC. This was not the intent of the permanent, stable ID. From the view of the outside world, RFCs are the stable identifiers for IETF publications and there needs to be a significant reason to change this. Tracing of a document throughout it's life cycle can be done without having a constant identifier from begin to end. Recommendations: 1. All 3 requirements are kept, however expedited handling is kept to allow a transition to early allocation of permanent stable IDs. 2. The phasing out of expedited handling is recommended 3. Allocation of permanent IDs should have an exclusion for documents held up due to references or due to a protocol action. Stephen _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Feb 22 18:18:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC3Fq-0007BL-9j; Wed, 22 Feb 2006 18:18:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC3Fo-0007BB-Ro for techspec@ietf.org; Wed, 22 Feb 2006 18:18:40 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC3Fn-0001Qp-HT for techspec@ietf.org; Wed, 22 Feb 2006 18:18:40 -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 k1MNPdED020460 for ; Wed, 22 Feb 2006 17:25:39 -0600 Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72) id <1FXKJR0W>; Wed, 22 Feb 2006 17:18:39 -0600 Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C00380206B89C@eusrcmw720.eamcs.ericsson.se> From: "Stephen Hayes (TX/EUS)" To: techspec@ietf.org Date: Wed, 22 Feb 2006 17:18:32 -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: de4f315c9369b71d7dd5909b42224370 Subject: [Techspec] Summary of performance values discussions and proposals 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: , Errors-To: techspec-bounces@ietf.org Several suggestions have been made regarding the quantitative performance goals in mankin-pub-req. It was recommended to remove the numeric values and simply indicate that the values will be determined in the contract with the technical publisher. However, there was some desire to keep the quantitative values but indicate (with a note) that these represent targets desired by the IETF community with the understanding that the actual values are subject to negotiation and will be determined as part of contractual agreements. It was recommended (offline) that the targets for pre-approval editing be tightened to 10 days (average) and 15 days (90%) since turnaround time is critical in this phase of the work. It was recommended that the upper percentiles be changed from 98% to 90%. Recommendations: 1. Keep the quantitative values but add notes indicating that these represent targets desired by the IETF community with the understanding that the actual values are subject to negotiation and will be determined as part of contractual agreements. 2. Change the targets for pre-approval editing be tightened to 10 days (average) and 15 days (90%). 3. Change the upper percentils from 98% to 90%. Stephen _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Feb 22 18:18:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC3Ft-0007Bs-Cu; Wed, 22 Feb 2006 18:18:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC3Fr-0007Bn-TG for techspec@ietf.org; Wed, 22 Feb 2006 18:18:43 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC3Fq-0001Qv-IY for techspec@ietf.org; Wed, 22 Feb 2006 18:18:43 -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 k1MNPgl3020464 for ; Wed, 22 Feb 2006 17:25:42 -0600 Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72) id <1FXKJR0X>; Wed, 22 Feb 2006 17:18:42 -0600 Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C00380206B89D@eusrcmw720.eamcs.ericsson.se> From: "Stephen Hayes (TX/EUS)" To: techspec@ietf.org Date: Wed, 22 Feb 2006 17:18:38 -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: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Techspec] New requirement for early permanent ID allocation 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: , Errors-To: techspec-bounces@ietf.org Early permanent ID allocation is not something currently done in the IETF. Although there is already a potential requirement to do this, implementing it will imply yet another new potential requirement on the technical publisher. o Potential Req-INDEX-7 - When an permanent ID is allocated early, the technical publisher must provide a disclaimer and pointer in the index to resolve searches on that permanent ID. The post approval version of the draft must be stored until the document is published since it could expire before publication. The text of the disclaimer that comes up could be something like: "RFC xxxx is currently in publication. A preliminary version of this specification is available at . This draft is believed to be technically stable and has been approved by the IETF. Please ignore the expiration date on the draft as no further versions of this draft are expected prior to publication of the RFC. However, technical changes and delays in publication of this RFC are possible and the user should be aware of the inherent dangers of using pre-publication versions of documents. and any other disclaimers, blah, blah, blah" It is also recommended that the technical publisher retains control of the allocation of permanent identifiers. This is especially true when multiple organizations (IESG, IAB, IRTF) share a single identifier sequence. One way that this might work is for the IESG to request "publication" or "publication with early allocation" Stephen _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Feb 22 21:02:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC5o5-0001b8-Q4; Wed, 22 Feb 2006 21:02:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC5o4-0001b3-Iu for techspec@ietf.org; Wed, 22 Feb 2006 21:02:12 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC5o3-0007c8-8E for techspec@ietf.org; Wed, 22 Feb 2006 21:02:12 -0500 Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k1N220YX030565; Wed, 22 Feb 2006 19:02:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4DCBC973AF0D6E4FAF9CD998CE1C00380206B89D@eusrcmw720.eamcs.ericsson.se> References: <4DCBC973AF0D6E4FAF9CD998CE1C00380206B89D@eusrcmw720.eamcs.ericsson.se> Date: Wed, 22 Feb 2006 18:01:56 -0800 To: "Stephen Hayes (TX/EUS)" , techspec@ietf.org From: Paul Hoffman Subject: Re: [Techspec] New requirement for early permanent ID allocation Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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: , Errors-To: techspec-bounces@ietf.org At 5:18 PM -0600 2/22/06, Stephen Hayes (TX/EUS) wrote: >Early permanent ID allocation is not something currently done in the >IETF. Although there is already a potential requirement to do this, >implementing it will imply yet another new potential requirement on >the technical publisher. Given the complexity you describe, and the rareness of the need, might it not be better to change the requirement to "quick highest-priority publication"? The permanent identifier comes with that for free, of course. As long as this only comes up a few times a year (and I think that is more than has been seen to date), the IESG could tell the technical publisher to stick a particular document at the top of the editing queue. The outside organizations that "need" the identifier will get it more slowly than "just make one up", but they would get the full document. Further, there would be no confusion about what the contents that the identifier point to. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Feb 22 23:47:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC8NY-0004z4-9T; Wed, 22 Feb 2006 23:47:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC8NX-0004yx-1j for techspec@ietf.org; Wed, 22 Feb 2006 23:46:59 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC8NV-0005k0-QP for techspec@ietf.org; Wed, 22 Feb 2006 23:46:59 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FC8NT-000OjZ-PF; Thu, 23 Feb 2006 04:46:55 +0000 To: Paul Hoffman Subject: Re: [Techspec] New requirement for early permanent ID allocation Date: Wed, 22 Feb 2006 20:46:55 -0800 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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: , Errors-To: techspec-bounces@ietf.org Message-Id: Paul, > Given the complexity you describe, and the rareness of the need, > might it not be better to change the requirement to "quick > highest-priority publication"? The permanent identifier comes with > that for free, of course. As long as this only comes up a few times a > year (and I think that is more than has been seen to date) It's more than a few times a year. There were 14 documents processed for Expedited Publication in December through February (so far) - The total RFCs published in this time (my count, may not be perfect) was about 130, so the Expedited documents were about 10%. Expedited documents entail significant extra effort by the RFC Editor and the authors, AD, and WG Chair shepherds, as well as affecting the queue. Want more? Some SDOs which use our work a lot, 3GPP, OMA, 3GPP2, have sites with lists of the drafts and when these drafts need to be citable because the SDO's work gets finished. IETF folks and folks from the SDO hold discussions to adjust the expectations in both directions, but these lists have over 50 documents and dates. "Quick highest priority publication" is what we're doing now, but it's pretty painful. Allison _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Thu Feb 23 10:04:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCI0j-0002MZ-N1; Thu, 23 Feb 2006 10:04:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCI0i-0002MR-MY for techspec@ietf.org; Thu, 23 Feb 2006 10:04:04 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCI0h-0005pQ-9H for techspec@ietf.org; Thu, 23 Feb 2006 10:04:04 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1FCI0f-0002J3-Um; Thu, 23 Feb 2006 10:04:02 -0500 Date: Thu, 23 Feb 2006 10:04:01 -0500 From: John C Klensin To: "Stephen Hayes (TX/EUS)" , techspec@ietf.org Subject: Re: [Techspec] New requirement for early permanent ID allocation Message-ID: <8D4E53DE040CB457E29FAE5E@p3.JCK.COM> In-Reply-To: <4DCBC973AF0D6E4FAF9CD998CE1C00380206B89D@eusrcmw720.eamcs.ericsson.se> References: <4DCBC973AF0D6E4FAF9CD998CE1C00380206B89D@eusrcmw720. eamcs.ericsson.se> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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: , Errors-To: techspec-bounces@ietf.org Two (separable) comments/issues and an aside... --On Wednesday, 22 February, 2006 17:18 -0600 "Stephen Hayes (TX/EUS)" wrote: > Early permanent ID allocation is not something currently done > in the IETF. Although there is already a potential > requirement to do this, implementing it will imply yet another > new potential requirement on the technical publisher. > > o Potential Req-INDEX-7 - When an permanent ID is allocated > early, the technical publisher must provide a disclaimer and > pointer in the index to resolve searches on that permanent ID. > The post approval version of the draft must be stored until > the document is published since it could expire before > publication. > > The text of the disclaimer that comes up could be something > like: > > "RFC xxxx is currently in publication. A preliminary version > of this specification is available at . >... The relevance of the Identifier, how it is assigned, etc., is a current NEWTRK work item, embedded significantly in the "ISD" work and somewhat so in the "SRD" work. Both would provide alternate models to needing more disclaimers that, based on historical experience, would probably be generally ignored. Until and unless NEWTRK is terminated and a plausible disposition made of its outstanding tasks, it seems inappropriate to me for this non-chartered effort to reach conclusions in this area other than, possibly, to make recommendations to NEWTRK. > It is also recommended that the technical publisher retains > control of the allocation of permanent identifiers. This is > especially true when multiple organizations (IESG, IAB, IRTF) > share a single identifier sequence. One way that this might > work is for the IESG to request "publication" or "publication > with early allocation" Please separate this into a separate issue. To the extent to which we are going to maintain multiple sets of numbers, some of which apply to subsets of the others, the standards-track reference ID (currently STD, but its assignment only to Full Standards is another NEWTRK issue) and other reference IDs should arguably be controlled directly by some IASA-associated entity or contractor that is different from the technical publisher. I understand this effort to be defining a "technical publisher" role. If that role is to be one of a publisher, rather than having broader standards-management functions, then we had better be _very_ careful about what the IDs are and who assigns them. And, again, who assigns the identifier is a very different issue from when that identifier is assigned. john _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Thu Feb 23 10:18:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCIES-0003cp-Mz; Thu, 23 Feb 2006 10:18:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCIER-0003c8-8Y for techspec@ietf.org; Thu, 23 Feb 2006 10:18:15 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCIEO-0006iu-3V for techspec@ietf.org; Thu, 23 Feb 2006 10:18:15 -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 k1NFPDWd016327; Thu, 23 Feb 2006 09:25:14 -0600 Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72) id <1FXKJWBN>; Thu, 23 Feb 2006 09:18:11 -0600 Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C00380206B9F5@eusrcmw720.eamcs.ericsson.se> From: "Stephen Hayes (TX/EUS)" To: Paul Hoffman , techspec@ietf.org Subject: RE: [Techspec] New requirement for early permanent ID allocation Date: Thu, 23 Feb 2006 09:18:03 -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: ea4ac80f790299f943f0a53be7e1a21a 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: , Errors-To: techspec-bounces@ietf.org > > At 5:18 PM -0600 2/22/06, Stephen Hayes (TX/EUS) wrote: > >Early permanent ID allocation is not something currently done in the > >IETF. Although there is already a potential requirement to do this, > >implementing it will imply yet another new potential requirement on > >the technical publisher. > > Given the complexity you describe, and the rareness of the need, > might it not be better to change the requirement to "quick > highest-priority publication"? The permanent identifier comes with > that for free, of course. As long as this only comes up a few times a > year (and I think that is more than has been seen to date), the IESG > could tell the technical publisher to stick a particular document at > the top of the editing queue. I'm not sure this is a rare need. Perhaps somebody can provide statistics on how often the expedited handling is requested. Buch each time it is granted it is unfair to the other documents waiting in the queue. Ideally, I would like to see early allocation of identifiers be the norm as opposed to the exception. This relieves some of the pressure in case a publication backlog develops. > > The outside organizations that "need" the identifier will get it more > slowly than "just make one up", but they would get the full document. > Further, there would be no confusion about what the contents that the > identifier point to. Given that the definitive reference for the RFC (I am assuming that a RFC number will continue to be the reference) is determined by the index, I am unsure of what confusion will arise. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Thu Feb 23 11:02:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCIvg-0000Mu-7T; Thu, 23 Feb 2006 11:02:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCIvf-0000Jp-75 for techspec@ietf.org; Thu, 23 Feb 2006 11:02:55 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCIve-00039w-Tq for techspec@ietf.org; Thu, 23 Feb 2006 11:02:55 -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 k1NG9sBM025136; Thu, 23 Feb 2006 10:09:56 -0600 Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72) id <1FXKJW0Y>; Thu, 23 Feb 2006 10:02:52 -0600 Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C00380206BA53@eusrcmw720.eamcs.ericsson.se> From: "Stephen Hayes (TX/EUS)" To: Allison Mankin , Paul Hoffman Subject: RE: [Techspec] New requirement for early permanent ID allocation Date: Thu, 23 Feb 2006 10:02:44 -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: 769a46790fb42fbb0b0cc700c82f7081 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: , Errors-To: techspec-bounces@ietf.org Sorry, I missed this mail in the thread so ignore my previous request for statistics. >From discussions within the organizations Allison cited (3GPP, 3GPP2, OMA), there is a building reluctance to take work into IETF because of a feeling that it will take too long even when the id is very simple. In many cases there is little problem getting technical agreement and stability, but the publication delay is long. We can't really ask IETF to expedite every one of our dependency documents and most of them are normative references which are needed to meet our deadlines. Regards, Stephen > -----Original Message----- > From: Allison Mankin [mailto:mankin@psg.com] > Sent: Wednesday, February 22, 2006 10:47 PM > To: Paul Hoffman > Cc: Stephen Hayes (TX/EUS); techspec@ietf.org > Subject: Re: [Techspec] New requirement for early permanent ID > allocation > > > Paul, > > > Given the complexity you describe, and the rareness of the need, > > might it not be better to change the requirement to "quick > > highest-priority publication"? The permanent identifier comes with > > that for free, of course. As long as this only comes up a > few times a > > year (and I think that is more than has been seen to date) > > It's more than a few times a year. There were 14 documents processed > for Expedited Publication in December through February (so far) - > The total RFCs published in this time (my count, may not be perfect) > was about 130, so the Expedited documents were about 10%. > > Expedited documents entail significant extra effort by the RFC Editor > and the authors, AD, and WG Chair shepherds, as well as affecting > the queue. > > Want more? > > Some SDOs which use our work a lot, 3GPP, OMA, 3GPP2, have sites with > lists of the drafts and when these drafts need to be citable because > the SDO's work gets finished. IETF folks and folks from the SDO > hold discussions to adjust the expectations in both directions, but > these lists have over 50 documents and dates. > > "Quick highest priority publication" is what we're doing now, but > it's pretty painful. > > Allison > > > _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Thu Feb 23 13:14:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCKzI-0004RE-75; Thu, 23 Feb 2006 13:14:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCKzH-0004R6-6e for techspec@ietf.org; Thu, 23 Feb 2006 13:14:47 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCKzF-0007Vi-Sm for techspec@ietf.org; Thu, 23 Feb 2006 13:14:47 -0500 Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k1NIEhJ9050957; Thu, 23 Feb 2006 11:14:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 23 Feb 2006 10:14:41 -0800 To: Allison Mankin From: Paul Hoffman Subject: Re: [Techspec] New requirement for early permanent ID allocation Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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: , Errors-To: techspec-bounces@ietf.org At 8:46 PM -0800 2/22/06, Allison Mankin wrote: >The total RFCs published in this time (my count, may not be perfect) >was about 130, so the Expedited documents were about 10%. Wow. And yuck. >"Quick highest priority publication" is what we're doing now, but >it's pretty painful. That's unfortunate. OK, so back to early permanent ID allocation with a lot of rules about what the identifier means and how the publisher should handle it. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Thu Feb 23 13:48:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCLW1-0001pk-LR; Thu, 23 Feb 2006 13:48:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCLW0-0001pc-W5 for techspec@ietf.org; Thu, 23 Feb 2006 13:48:36 -0500 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCLVz-0008Nz-ND for techspec@ietf.org; Thu, 23 Feb 2006 13:48:36 -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 k1NImXaM005303; Thu, 23 Feb 2006 12:48:34 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 23 Feb 2006 19:48:33 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550967B44D@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Paul Hoffman , Allison Mankin Subject: RE: [Techspec] New requirement for early permanent ID allocation Date: Thu, 23 Feb 2006 19:48:32 +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: a7d6aff76b15f3f56fcb94490e1052e4 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: , Errors-To: techspec-bounces@ietf.org Let me (repeat) state that my opinion is that we SHOULD be able to achieve RFC-publication within 2 months (or less) after IESG approval. And if we can achieve that, then I maintain that early stable references is farr less of a problem (if at all). Just my personal opinion of course. I would rather work on trying to get to a fast-publication-after-approval than thinking of stop-ga[p measures to deal with too-slow-publication. Bert > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] > Sent: Thursday, February 23, 2006 19:15 > To: Allison Mankin > Cc: techspec@ietf.org > Subject: Re: [Techspec] New requirement for early permanent ID > allocation > > > At 8:46 PM -0800 2/22/06, Allison Mankin wrote: > >The total RFCs published in this time (my count, may not be perfect) > >was about 130, so the Expedited documents were about 10%. > > Wow. And yuck. > > >"Quick highest priority publication" is what we're doing now, but > >it's pretty painful. > > That's unfortunate. OK, so back to early permanent ID allocation with > a lot of rules about what the identifier means and how the publisher > should handle it. > > --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 Thu Feb 23 14:09:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCLpz-00053L-C3; Thu, 23 Feb 2006 14:09:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCLpg-0004ke-TO for techspec@ietf.org; Thu, 23 Feb 2006 14:08:56 -0500 Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCLfw-0000A6-OK for techspec@ietf.org; Thu, 23 Feb 2006 13:58:54 -0500 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k1NIwnHa018299; Thu, 23 Feb 2006 20:58:49 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k1NIwm77018294; Thu, 23 Feb 2006 20:58:49 +0200 Date: Thu, 23 Feb 2006 20:58:48 +0200 (EET) From: Pekka Savola To: "Wijnen, Bert (Bert)" Subject: RE: [Techspec] New requirement for early permanent ID allocation In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550967B44D@nl0006exch001u.nl.lucent.com> Message-ID: References: <7D5D48D2CAA3D84C813F5B154F43B1550967B44D@nl0006exch001u.nl.lucent.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88/1298/Wed Feb 22 22:50:12 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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: , Errors-To: techspec-bounces@ietf.org On Thu, 23 Feb 2006, Wijnen, Bert (Bert) wrote: > Let me (repeat) state that my opinion is that we SHOULD be able > to achieve RFC-publication within 2 months (or less) after > IESG approval. And if we can achieve that, then I maintain > that early stable references is farr less of a problem (if at all). > > Just my personal opinion of course. > > I would rather work on trying to get to a fast-publication-after-approval > than thinking of stop-ga[p measures to deal with too-slow-publication. FWIW, I agree completely. If you add fast-tracking to this, we should already have enough tools to allow fast document publication in general, and even faster when required. -- 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 Fri Feb 24 01:03:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCW3E-0002bz-DE; Fri, 24 Feb 2006 01:03:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCW3C-0002bo-Rl for techspec@ietf.org; Fri, 24 Feb 2006 01:03:34 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCW3C-0006Dc-DB for techspec@ietf.org; Fri, 24 Feb 2006 01:03:34 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1FCW3B-0003xS-5B; Fri, 24 Feb 2006 01:03:33 -0500 Date: Fri, 24 Feb 2006 01:03:32 -0500 From: John C Klensin To: "Stephen Hayes (TX/EUS)" , techspec@ietf.org Subject: Re: [Techspec] New requirement for early permanent ID allocation Message-ID: X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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: , Errors-To: techspec-bounces@ietf.org On 23 February, 2006 10:04 -0500, I wrote (text deleted from the earlier note marked with "[...]")... ------- Earlier note ---------- Two (separable) comments/issues and an aside... --On Wednesday, 22 February, 2006 17:18 -0600 "Stephen Hayes (TX/EUS)" wrote: > Early permanent ID allocation is not something currently done > in the IETF. Although there is already a potential > requirement to do this, implementing it will imply yet another > new potential requirement on the technical publisher. > > o Potential Req-INDEX-7 - When an permanent ID is allocated > early, the technical publisher must provide a disclaimer and > pointer in the index to resolve searches on that permanent ID. > The post approval version of the draft must be stored until > the document is published since it could expire before > publication. [...] The relevance of the Identifier, how it is assigned, etc., is a current NEWTRK work item, embedded significantly in the "ISD" work and somewhat so in the "SRD" work. Both would provide alternate models to needing more disclaimers that, based on historical experience, would probably be generally ignored. Until and unless NEWTRK is terminated and a plausible disposition made of its outstanding tasks, it seems inappropriate to me for this non-chartered effort to reach conclusions in this area other than, possibly, to make recommendations to NEWTRK. [...] > It is also recommended that the technical publisher retains > control of the allocation of permanent identifiers. This is > especially true when multiple organizations (IESG, IAB, IRTF) > share a single identifier sequence. One way that this might > work is for the IESG to request "publication" or "publication > with early allocation" Please separate this into a separate issue. To the extent to which we are going to maintain multiple sets of numbers, some of which apply to subsets of the others, the standards-track reference ID (currently STD, but its assignment only to Full Standards is another NEWTRK issue) and other reference IDs should arguably be controlled directly by some IASA-associated entity or contractor that is different from the technical publisher. I understand this effort to be defining a "technical publisher" role. If that role is to be one of a publisher, rather than having broader standards-management functions, then we had better be _very_ careful about what the IDs are and who assigns them. And, again, who assigns the identifier is a very different issue from when that identifier is assigned. [...] --- End of earlier note ---- In the interest of stimulating discussion where it belongs, I have just queued an I-D titled "Identifying Standards Track Documents", draft-ietf-newtrk-docid-00.txt, that addresses these issues and provides for assignment of stable identifiers for standards-track documents not later than the Protocol Action for Proposed Standard. Because this is a simple issue and a simple proposal, the I-D violates what most consider to be my usual practice: exclusive of front and back matter, it is significantly under four pages long. I have written the proposal up as a change, not a process experiment. It occurs to me that, were a different Standards Identifier prefix chosen, it could be structured as a process experiment if people wanted to do that. I'll leave that for discussion in NEWTRK or elsewhere (and this comment will be more clear after one reads the draft). john _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Fri Feb 24 03:38:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCYTK-00014Y-Nd; Fri, 24 Feb 2006 03:38:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCYTJ-00013J-VN for techspec@ietf.org; Fri, 24 Feb 2006 03:38:41 -0500 Received: from smtp.onebb.com ([202.180.161.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCYTH-0002Iw-JU for techspec@ietf.org; Fri, 24 Feb 2006 03:38:41 -0500 Received: from rpk-sip.onebb.com (064-033.onebb.com [202.69.64.33]) by smtp.onebb.com (8.12.11/8.12.11) with ESMTP id k1O8cXZf016616 for ; Fri, 24 Feb 2006 16:38:34 +0800 Received: from [202.131.37.193] (helo=s73602) by rpk-sip.onebb.com with esmtp (Exim 3.34 #1) id 1FCYTE-0007cG-00 for techspec@ietf.org; Fri, 24 Feb 2006 16:38:36 +0800 Message-ID: <103c01c6391d$78ed99f0$0500a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: <4DCBC973AF0D6E4FAF9CD998CE1C00380206B89D@eusrcmw720.eamcs.ericsson.se> <8D4E53DE040CB457E29FAE5E@p3.JCK.COM> Subject: Re: [Techspec] New requirement for early permanent ID allocation Date: Fri, 24 Feb 2006 16:36:56 +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.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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: , Errors-To: techspec-bounces@ietf.org From: "John C Klensin" >> It is also recommended that the technical publisher retains >> control of the allocation of permanent identifiers. This is >> especially true when multiple organizations (IESG, IAB, IRTF) >> share a single identifier sequence. One way that this might >> work is for the IESG to request "publication" or "publication >> with early allocation" > > Please separate this into a separate issue. To the extent to > which we are going to maintain multiple sets of numbers, some of > which apply to subsets of the others, the standards-track > reference ID (currently STD, but its assignment only to Full > Standards is another NEWTRK issue) and other reference IDs > should arguably be controlled directly by some IASA-associated > entity or contractor that is different from the technical > publisher. I understand this effort to be defining a "technical > publisher" role. If that role is to be one of a publisher, > rather than having broader standards-management functions, then > we had better be _very_ careful about what the IDs are and who > assigns them. I agree with John here. I'm not sure I understand the case for continuing current practice, at a minimum. > And, again, who assigns the identifier is a very different issue > from when that identifier is assigned. Ack. _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Fri Feb 24 15:13:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCjK5-00048Z-ED; Fri, 24 Feb 2006 15:13:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCjK4-00044H-3E for techspec@ietf.org; Fri, 24 Feb 2006 15:13:52 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCjK2-0007fu-PG for techspec@ietf.org; Fri, 24 Feb 2006 15:13:52 -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 k1OKKrRl007525; Fri, 24 Feb 2006 14:20:53 -0600 Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72) id <1FXKKJZD>; Fri, 24 Feb 2006 14:13:47 -0600 Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C003802120D30@eusrcmw720.eamcs.ericsson.se> From: "Stephen Hayes (TX/EUS)" To: Spencer Dawkins , techspec@ietf.org Subject: RE: [Techspec] New requirement for early permanent ID allocation Date: Fri, 24 Feb 2006 14:13:40 -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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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: , Errors-To: techspec-bounces@ietf.org ok, I understand the desire to partition the work. pub-req will be agnostic with respect to: - What a stable permanent identifier is and how many classes of identifiers there are - Who owns and who assigns the stable permanent identifiers Godspeed to the newtrk work on this. Stephen > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] > Sent: Friday, February 24, 2006 2:37 AM > To: techspec@ietf.org > Subject: Re: [Techspec] New requirement for early permanent ID > allocation > > > From: "John C Klensin" > > > >> It is also recommended that the technical publisher retains > >> control of the allocation of permanent identifiers. This is > >> especially true when multiple organizations (IESG, IAB, IRTF) > >> share a single identifier sequence. One way that this might > >> work is for the IESG to request "publication" or "publication > >> with early allocation" > > > > Please separate this into a separate issue. To the extent to > > which we are going to maintain multiple sets of numbers, some of > > which apply to subsets of the others, the standards-track > > reference ID (currently STD, but its assignment only to Full > > Standards is another NEWTRK issue) and other reference IDs > > should arguably be controlled directly by some IASA-associated > > entity or contractor that is different from the technical > > publisher. I understand this effort to be defining a "technical > > publisher" role. If that role is to be one of a publisher, > > rather than having broader standards-management functions, then > > we had better be _very_ careful about what the IDs are and who > > assigns them. > > I agree with John here. I'm not sure I understand the case > for continuing > current practice, at a minimum. > > > And, again, who assigns the identifier is a very different issue > > from when that identifier is assigned. > > Ack. > > > > _______________________________________________ > 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