From techspec-bounces@ietf.org Mon Apr 10 18:20:20 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FT4k7-0003eL-R4; Mon, 10 Apr 2006 18:20:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FT4k6-0003eG-KX
	for techspec@ietf.org; Mon, 10 Apr 2006 18:20:18 -0400
Received: from imr1.ericy.com ([198.24.6.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT4k6-000841-98
	for techspec@ietf.org; Mon, 10 Apr 2006 18:20:18 -0400
Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se
	[138.85.133.38])
	by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id k3AMKHwl006102
	for <techspec@ietf.org>; Mon, 10 Apr 2006 17:20:17 -0500
Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72)
	id <GDPV2SKV>; Mon, 10 Apr 2006 17:20:17 -0500
Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C0038027C35DE@eusrcmw720.eamcs.ericsson.se>
From: "Stephen Hayes (TX/EUS)" <stephen.hayes@ericsson.com>
To: techspec@ietf.org
Date: Mon, 10 Apr 2006 17:20:07 -0500
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: 3e15cc4fdc61d7bce84032741d11c8e5
Subject: [Techspec] mankin-pub-req-06 available
X-BeenThere: techspec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org

draft-mankin-pub-req-06 is available http://www.ietf.org/internet-drafts/draft-mankin-pub-req-06.txt.  The changes were based upon the meeting comments and agreements as well as a few items received before the meeting and offline comments.  Feedback appreciated. Given that the timeline calls for last call starting April 15, rapid response is requested.

Stephen

1. In Figure 1: Stages of a Working Group Document, add IANA to the post approval column (but also keep it in the pre-approval column).

2. Section 3.7 Post Approval, Pre-Publication Technical Corrections.  Replaced "This should ideally be a rare occurrence, but as publication times increase, the number of minor technical improvements increases." with "This should ideally be a rare occurrence." since the last part could be read to imply an expected trend towards longer publication times.

3. Removed the reference and references to rfc2223bis.  Specifically:

Removed from section 2: "To allow progress on developing the process requirements, this document assumes the policies for document format, etc. as are currently defined in [1]."

Modified sections 3.1 and to say "This review should strive to maintain consistency in appearance with previously published documents." instead of referencing 2223bis.

4. Also removed the reference and references to proto-wgchair-doc-shepherding since it doesn't look like this will be referencable in time.

5. Modified Req-POSTCORR-2 to indicate that approved technical changes could come from the appropriate party (usually the shepherd, but sometimes the IESG).

6. In requirement	Req-PUBHELP-1 Added the following sentence at the end: "The technical publisher should follow IETF guidance in specifying documentation guidelines."  This is to make it clear that although it is the publisher who may prepare training materials, the IETF is the authority on those guidelines. 

7. Added new requirement:
Req-PUBHELP-3 - The IETF technical publisher shall provide a contact e-mail address and correspond as required to progress the publication work.  The publisher should address queries from both inside and outside of the IETF community.

8. Fuzzed the performance metrics section.  Now reworded to:

Req-TIMEFRAMES-1 - The consensus of the IETF community is that an average publication time of under a month is desirable.  It is understood that in some cases there will be delays outside of the publisher's control. The actual performance targets and metrics are expected to be determined as part of the contract negotiation process.

Req-TIMEFRAMES-2 - The consensus of the IETF community is that the time required for a pre-publication review should be under 10 days.  It is understood that in some cases there will be delays outside of the publisher's control. The actual performance targets and metrics are expected to be determined as part of the contract negotiation process.

Also removed the note about actual numbers determined in the contract since it was superfluous.

9. Add a steady state metric for throughput.  Added a new requirement:

Req-THROUGHPUT-3 - Although minor variations are expected, there should be no long term growth trend in the length of the publication queue.

Also added some text to Req-Stats-2 tying in the need to present historical trending data.

10. Removed the requirements associated with early permanent ID allocation.  

11. Removed the requirement associated with accepting input in xml2rfc.

12. Change the requirement for how the publisher deals with excessive or too late changes:
Req-POSTCORR-3 - The publisher should alert the IESG (or IAB or IRSG) when it feels that a requested change is unreasonable.  Further processing of the draft should be suspended pending a response by the IESG (or IAB or IRSG) on how to proceed.

13. Added a new requirement to purge a document from the index:
Req-INDEX-7 - The IETF can indicate to the publisher that it should purge a document from the index.  This should remove all traces of the document.

14. Added a note at the end of section 2.1 clarifying that a submission may actually consist of multiple source documents.
 
"Note that in some cases a single submission may actually consist of multiple source documents (supporting files, code, etc.)."

15. Removed all the Current and Potential prefixes for the requirements.

16. Correction of some typos, grammar, etc.


_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec



From techspec-bounces@ietf.org Mon Apr 10 18:39:48 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FT52y-00023C-8q; Mon, 10 Apr 2006 18:39:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FT52x-0001zX-Bt
	for techspec@ietf.org; Mon, 10 Apr 2006 18:39:47 -0400
Received: from imr1.ericy.com ([198.24.6.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT52w-000088-1k
	for techspec@ietf.org; Mon, 10 Apr 2006 18:39:47 -0400
Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se
	[138.85.133.38])
	by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id k3AMdjRH008165
	for <techspec@ietf.org>; Mon, 10 Apr 2006 17:39:45 -0500
Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72)
	id <GDPV2SWD>; Mon, 10 Apr 2006 17:39:45 -0500
Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C0038027C3620@eusrcmw720.eamcs.ericsson.se>
From: "Stephen Hayes (TX/EUS)" <stephen.hayes@ericsson.com>
To: techspec@ietf.org
Date: Mon, 10 Apr 2006 17:39:40 -0500
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: 79899194edc4f33a41f49410777972f8
Subject: [Techspec] IETF steering of publisher 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\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org

There is an error in mankin-pub-req-06.  Requirement: 

o Req-POSTEDIT-5 - At the direction of the IESG or (IRSG or IAB), the publisher should publish a document with minimal editing. 

was left in by accident.  It should not be there.  However it was an attempt to capture a requirement originating from  http://www.ietf.org/internet-drafts/draft-eronen-rfc-selective-experiment-00.txt.

The goals of this draft probably can be formulated in different ways.  

	1/ requirement to publish (chunks of) text verbatim,
	   because they have been adequately reviewed and arrived
	   at by some careful negotiation.

	2/ requirement to adjust the level of editorial scrutiny
	   applied by the RFC Editor

The question is:  Do we want to capture the requirement for editorial steering at all and if so what formulation of the requirement is better.

Stephen Hayes



_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec



From techspec-bounces@ietf.org Tue Apr 11 03:00:09 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FTCrA-000446-L2; Tue, 11 Apr 2006 03:00:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FTCr8-000441-QZ
	for techspec@ietf.org; Tue, 11 Apr 2006 03:00:06 -0400
Received: from mtagate4.uk.ibm.com ([195.212.29.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTCr8-0003Qq-Dr
	for techspec@ietf.org; Tue, 11 Apr 2006 03:00:06 -0400
Received: from d06nrmr1407.portsmouth.uk.ibm.com
	(d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185])
	by mtagate4.uk.ibm.com (8.13.6/8.13.6) with ESMTP id k3B705rB233684
	for <techspec@ietf.org>; Tue, 11 Apr 2006 07:00:05 GMT
Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com
	[9.149.37.212])
	by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id
	k3B70fmH203476
	for <techspec@ietf.org>; Tue, 11 Apr 2006 08:00:41 +0100
Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1])
	by d06av01.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id
	k3B704pk014238
	for <techspec@ietf.org>; Tue, 11 Apr 2006 08:00:04 +0100
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id
	k3B7046S014225; Tue, 11 Apr 2006 08:00:04 +0100
Received: from zurich.ibm.com (sig-9-146-217-42.de.ibm.com [9.146.217.42])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA78462;
	Tue, 11 Apr 2006 09:00:02 +0200
Message-ID: <443B53F2.8050903@zurich.ibm.com>
Date: Tue, 11 Apr 2006 09:00:02 +0200
From: Brian E Carpenter <brc@zurich.ibm.com>
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)" <stephen.hayes@ericsson.com>
Subject: Re: [Techspec] IETF steering of publisher editing
References: <4DCBC973AF0D6E4FAF9CD998CE1C0038027C3620@eusrcmw720.eamcs.ericsson.se>
In-Reply-To: <4DCBC973AF0D6E4FAF9CD998CE1C0038027C3620@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: 2409bba43e9c8d580670fda8b695204a
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\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org

Stephen Hayes (TX/EUS) wrote:
> There is an error in mankin-pub-req-06.  Requirement: 
> 
> o Req-POSTEDIT-5 - At the direction of the IESG or (IRSG or IAB), the publisher should publish a document with minimal editing. 
> 
> was left in by accident.  It should not be there.  However it was an attempt to capture a requirement originating from  http://www.ietf.org/internet-drafts/draft-eronen-rfc-selective-experiment-00.txt.
> 
> The goals of this draft probably can be formulated in different ways.  
> 
> 	1/ requirement to publish (chunks of) text verbatim,
> 	   because they have been adequately reviewed and arrived
> 	   at by some careful negotiation.
> 
> 	2/ requirement to adjust the level of editorial scrutiny
> 	   applied by the RFC Editor
> 
> The question is:  Do we want to capture the requirement for editorial steering at all and if so what formulation of the requirement is better.

Personal opinion: Yes. I would suggest something like:

When the approving body (IESG, IRSG or IAB) indicates satisfaction with the stylistic quality
of a draft, the publisher should limit editing to non-stylistic aspects.

When the approving body indicates that given text must be published verbatim, the
publisher shall do so.

     Brian

_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec



From techspec-bounces@ietf.org Tue Apr 11 03:55:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FTDiU-0000ro-0A; Tue, 11 Apr 2006 03:55:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FTDiS-0000pm-QP
	for techspec@ietf.org; Tue, 11 Apr 2006 03:55:12 -0400
Received: from av7-2-sn3.vrr.skanova.net ([81.228.9.182])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTDiR-0005HA-CK
	for techspec@ietf.org; Tue, 11 Apr 2006 03:55:12 -0400
Received: by av7-2-sn3.vrr.skanova.net (Postfix, from userid 502)
	id 1F49A383B2; Tue, 11 Apr 2006 09:34:12 +0200 (CEST)
Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net
	[81.228.9.102]) by av7-2-sn3.vrr.skanova.net (Postfix) with ESMTP
	id CEDCC383AA; Tue, 11 Apr 2006 09:34:11 +0200 (CEST)
Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com
	[81.232.110.214])
	by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id D6F7E37E4E;
	Tue, 11 Apr 2006 09:55:09 +0200 (CEST)
Received: from localhost ([127.0.0.1])
	by shiraz.levkowetz.com with esmtp (Exim 4.60)
	(envelope-from <henrik@levkowetz.com>)
	id 1FTDiO-0001Xu-Cn; Tue, 11 Apr 2006 09:55:08 +0200
Message-ID: <443B60DB.40101@levkowetz.com>
Date: Tue, 11 Apr 2006 09:55:07 +0200
From: Henrik Levkowetz <henrik@levkowetz.com>
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: techspec@ietf.org
Subject: Re: [Techspec] IETF steering of publisher editing
References: <4DCBC973AF0D6E4FAF9CD998CE1C0038027C3620@eusrcmw720.eamcs.ericsson.se>
In-Reply-To: <4DCBC973AF0D6E4FAF9CD998CE1C0038027C3620@eusrcmw720.eamcs.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Scanned: No (on shiraz.levkowetz.com);
	SAEximRunCond expanded to false
X-Spam-Score: 0.1 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
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\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org

Hi,

on 2006-04-11 00:39 Stephen Hayes (TX/EUS) said the following:
> There is an error in mankin-pub-req-06.  Requirement: 
> 
> o Req-POSTEDIT-5 - At the direction of the IESG or (IRSG or IAB), the
> publisher should publish a document with minimal editing.
> 
> was left in by accident. It should not be there. However it was an
> attempt to capture a requirement originating from
> http://www.ietf.org/internet-drafts/draft-eronen-rfc-selective-experiment-00.txt.
> 
> The goals of this draft probably can be formulated in different ways.  
> 
> 	1/ requirement to publish (chunks of) text verbatim,
> 	   because they have been adequately reviewed and arrived
> 	   at by some careful negotiation.
> 
> 	2/ requirement to adjust the level of editorial scrutiny
> 	   applied by the RFC Editor
> 
> The question is:  Do we want to capture the requirement for editorial
> steering at all and if so what formulation of the requirement is
> better.

I'd like to note that in order to be sure that we can actually run
experiments such as the one proposed by draft-eronen-rfc-selective-...
(or similar ones) the contract with the publisher has to provide
for the possibility of giving specific directions regarding the editing
level of individual documents, something like the text captured in 
Req-POSTEDIT-5 above.

If the contract doesn't provide for this, we won't even be able to run
such experiments to find out if they make sense or not.


	Henrik





_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec



From techspec-bounces@ietf.org Tue Apr 11 12:36:53 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FTLrE-0001OY-F6; Tue, 11 Apr 2006 12:36:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FTLrD-0001OO-DM
	for techspec@ietf.org; Tue, 11 Apr 2006 12:36:47 -0400
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTLrC-0000Y7-2H
	for techspec@ietf.org; Tue, 11 Apr 2006 12:36:47 -0400
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k3BGZdX15854;
	Tue, 11 Apr 2006 09:35:39 -0700 (PDT)
From: Bob Braden <braden@ISI.EDU>
Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id JAA01408;
	Tue, 11 Apr 2006 09:35:39 -0700 (PDT)
Date: Tue, 11 Apr 2006 09:35:39 -0700 (PDT)
Message-Id: <200604111635.JAA01408@gra.isi.edu>
To: stephen.hayes@ericsson.com, brc@zurich.ibm.com
Subject: Re: [Techspec] IETF steering of publisher editing
X-Sun-Charset: US-ASCII
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: braden@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
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\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org


Brian,

There is something I just don't get.  Why do you personally wish to
deliberately shun a publication process that is (1) working very well
for nearly everyone, and (2) producing better quality standards
documents than would be possible without this process?  Why
do you want poor quality documents?

Bob Braden, speaking for himself.



_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec



From techspec-bounces@ietf.org Tue Apr 11 14:01:02 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FTNAi-0001iK-1x; Tue, 11 Apr 2006 14:01:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FTNAg-0001i9-Oe
	for techspec@ietf.org; Tue, 11 Apr 2006 14:00:58 -0400
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTNAf-0003Yf-D2
	for techspec@ietf.org; Tue, 11 Apr 2006 14:00:58 -0400
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k3BHwOX12769;
	Tue, 11 Apr 2006 10:58:24 -0700 (PDT)
From: Bob Braden <braden@ISI.EDU>
Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id KAA01446;
	Tue, 11 Apr 2006 10:58:24 -0700 (PDT)
Date: Tue, 11 Apr 2006 10:58:24 -0700 (PDT)
Message-Id: <200604111758.KAA01446@gra.isi.edu>
To: techspec@ietf.org, henrik@levkowetz.com
Subject: Re: [Techspec] IETF steering of publisher editing
X-Sun-Charset: US-ASCII
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: braden@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed
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\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org


  *> > http://www.ietf.org/internet-drafts/draft-eronen-rfc-selective-ex

That document is largely based on fallacies about the publication of
RFCs.  Not that this seems to matter.

Bob Braden

_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec



From techspec-bounces@ietf.org Tue Apr 11 15:00:18 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FTO65-0001ft-V9; Tue, 11 Apr 2006 15:00:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FTO64-0001fl-FP
	for techspec@ietf.org; Tue, 11 Apr 2006 15:00:16 -0400
Received: from imr1.ericy.com ([198.24.6.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTO63-0005e4-6N
	for techspec@ietf.org; Tue, 11 Apr 2006 15:00:16 -0400
Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se
	[138.85.133.38])
	by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id k3BJ0Bnk013684;
	Tue, 11 Apr 2006 14:00:12 -0500
Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72)
	id <GDPV276T>; Tue, 11 Apr 2006 14:00:11 -0500
Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C0038027C414E@eusrcmw720.eamcs.ericsson.se>
From: "Stephen Hayes (TX/EUS)" <stephen.hayes@ericsson.com>
To: Bob Braden <braden@ISI.EDU>, brc@zurich.ibm.com
Subject: RE: [Techspec] IETF steering of publisher editing
Date: Tue, 11 Apr 2006 14:00:02 -0500
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: b19722fc8d3865b147c75ae2495625f2
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\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org

I don't think anyone is trying to destroy the publication process.  The idea is to try to speed up the process.  This is one idea.

During the session at IETF#65, two principles came across (at least two me).
1. We shouldn't use requirements as a vehicle to micro-manage the publication process
2. We should keep the processes simple.  Do we need additional process flows if we can get the overall average queue duration down to 4 weeks?

I think that if documents are in good shape and fairly simple, the publisher should be able to get them out the queue rapidly.  We have no FIFO requirement in processing.  So if the performance metric chosen is reasonable (say an average value), then it is in the publisher's interest to get easy documents out quickly.  I'm not sure we need an additional requirement to drive this behaviour.  To me it is micromanagement.

Specifying blocks of text as protected is a different story.  If experts have spent two months carefully crafting a paragraph, I would not like to see it inadvertently disturbed, even if the grammar is bad.  I don't see a problem saying that the IETF can flag parts of the text as "leave alone".  My understanding is that this is something the IESG does now.

Stephen Hayes

> -----Original Message-----
> From: Bob Braden [mailto:braden@ISI.EDU]
> Sent: Tuesday, April 11, 2006 11:36 AM
> To: Stephen Hayes (TX/EUS); brc@zurich.ibm.com
> Cc: techspec@ietf.org
> Subject: Re: [Techspec] IETF steering of publisher editing
> 
> 
> 
> Brian,
> 
> There is something I just don't get.  Why do you personally wish to
> deliberately shun a publication process that is (1) working very well
> for nearly everyone, and (2) producing better quality standards
> documents than would be possible without this process?  Why
> do you want poor quality documents?
> 
> Bob Braden, speaking for himself.
> 
> 
> 

_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec



From techspec-bounces@ietf.org Tue Apr 11 15:56:59 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FTOyu-0006Fh-ME; Tue, 11 Apr 2006 15:56:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FTOyu-0006FN-1N
	for techspec@ietf.org; Tue, 11 Apr 2006 15:56:56 -0400
Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTOyr-0008H7-PW
	for techspec@ietf.org; Tue, 11 Apr 2006 15:56:56 -0400
Received: from [64.100.227.114] ([::ffff:64.100.227.114])
	(AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA)
	by zeke.ecotroph.net with esmtp; Tue, 11 Apr 2006 15:50:41 -0400
	id 0158812E.443C0892.0000443B
Message-ID: <443C08C7.4080906@thinkingcat.com>
Date: Tue, 11 Apr 2006 15:51:35 -0400
From: Leslie Daigle <leslie@thinkingcat.com>
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: "Stephen Hayes (TX/EUS)" <stephen.hayes@ericsson.com>
Subject: Re: [Techspec] IETF steering of publisher editing
References: <4DCBC973AF0D6E4FAF9CD998CE1C0038027C3620@eusrcmw720.eamcs.ericsson.se>
In-Reply-To: <4DCBC973AF0D6E4FAF9CD998CE1C0038027C3620@eusrcmw720.eamcs.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
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\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org


In my personal opinion:

Stephen Hayes (TX/EUS) wrote:
> There is an error in mankin-pub-req-06.  Requirement: 
> 
> o Req-POSTEDIT-5 - At the direction of the IESG or (IRSG or IAB), the
> publisher should publish a document with minimal editing.

This should, indeed, be deleted.

And,

> The goals of this draft probably can be formulated in different ways.  
> 
> 	1/ requirement to publish (chunks of) text verbatim,
> 	   because they have been adequately reviewed and arrived
> 	   at by some careful negotiation.

Could be handled by:

"In specific instances, where some or all of document text is the result
  of a careful negotiation of contributions (within or between working
  groups, reviewers, etc), the IESG will require that the publisher
  publish the text verbatim.   It is the expectation of the IETF
  community that this will not be done often."

Whereas:

> 
> 	2/ requirement to adjust the level of editorial scrutiny
> 	   applied by the RFC Editor
> 

This is largely addressed in Req-POSTEDIT-1 through -4 (copied below for
convenience).  There is some possibility that there should be clarity
about how the style is specified or whether it should be
overridden by a different set of guidelines for a specific document.


But the notion of "minimal editing" is not actionable -- either there
is a strong reason why the text should be included verbatim (see
above), or we need to manage to the existing requirements.


WRT getting in the way of the type of experiment proposed in
draft-eronen-rfc-selective-experiment-00.txt -- I'm sympathetic,
to the extent we believe the IETF community *wants* to be
able to engage in such experiments (I'll observe it's a personal
-00 submission).   But, much of the motivation of that experiment
should be undone if we do the TechSpec job properly.

Leslie.


[From the -06 document:]
>   o  Req-POSTEDIT-1 - The IETF technical publisher should review the 
>       document for grammar, spelling, formatting, adherence to 
>       boilerplate, document structure, proper use of keywords, etc. The 
>       review should strive to maintain consistency in appearance with 
>       previously published documents.  
> 
>    o  Req-POSTEDIT-2 - All changes made to post-approval documents 
>       should be tracked and the changes must be signed off on by the 
>       appropriate technical representatives as defined in the IETF 
>       processes. 
> 
>    o  Req-POSTEDIT-3 - The IETF Technical editor should refrain from 
>       stylistic changes that introduce a substantial review load but 
>       only provides incremental increase in the clarity of the 
>       specification.  Specific guidelines on the types of changes 
>       allowed may be further specified, but ultimately restraint in 
>       editing must be imposed by the IETF technical publisher.  Changes 
>       for stylistic consistency should be done only when there are major 
>       problems with the quality of the document. 
> 
>    o  Req-POSTEDIT-4 - The IETF Technical editor should refrain from 
>       changes to improve readability that may change technical and 
>       consensus wording.  Specific guidelines on the types of changes 
>       allowed may be further specified, but ultimately restraint in 
>       editing must be imposed by the IETF technical publisher. 


_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec



From techspec-bounces@ietf.org Tue Apr 11 16:23:34 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FTPOg-0001mY-6D; Tue, 11 Apr 2006 16:23:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FTPOf-0001kn-0w
	for techspec@ietf.org; Tue, 11 Apr 2006 16:23:33 -0400
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTPOe-0001Ua-8G
	for techspec@ietf.org; Tue, 11 Apr 2006 16:23:33 -0400
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5F357554; 
	Tue, 11 Apr 2006 21:56:17 +0200 (CEST)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 11 Apr 2006 21:56:17 +0200
Received: from [147.214.237.61] ([147.214.237.61]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 11 Apr 2006 21:56:16 +0200
Message-ID: <443C09E0.2080509@levkowetz.com>
Date: Tue, 11 Apr 2006 21:56:16 +0200
From: Henrik Levkowetz <henrik@levkowetz.com>
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: Bob Braden <braden@ISI.EDU>
Subject: Re: [Techspec] IETF steering of publisher editing
References: <200604111758.KAA01446@gra.isi.edu>
In-Reply-To: <200604111758.KAA01446@gra.isi.edu>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Apr 2006 19:56:16.0865 (UTC)
	FILETIME=[FE90AD10:01C65DA1]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
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\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org

Hi Bob,

On 2006-04-11 19:58 Bob Braden said the following:
>   *> > http://www.ietf.org/internet-drafts/draft-eronen-rfc-selective-ex
> 
> That document is largely based on fallacies about the publication of
> RFCs.  Not that this seems to matter.


First, this document has not been offered for discussion on this list, and
it is only indirectly relevant to the current discussion.  I expect it to
be discussed in detail only at such a time when the prerequisites for
experiments like this are in place.

However, if you want to comment on the content of this document, I think it
would be more productive if you were to point out incorrect facts and suggest
alternative changes than to offer such generalisations as "That document is
largely based on fallacies ...".

Of course, there are darn few productive ways to respond to generalisations
about what a document is based on.

Let me just say that this document is an attempt at proposing one of several
possible ways of alleviating a situation which has frustrated a lot of people
for a bit too long.  The authors don't assume that the result is guaranteed
good.  But in the face of a frustrating situation we found it better to offer
concrete specific proposals for change than to offer only generalisations
about how bad things are.

We expect the document to be discussed on its merits at the proper time and
in the proper venue.  Even in the case that it is found to make sense to run such
an experiment, it might still turn out that the outcome of the experiment is
unsatisfactory.  That is a valid outcome - but discarding a document without
actually inspecting its content and discussing its merits specifically is
not, in my book, a valid one.



	Henrik


_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec



From techspec-bounces@ietf.org Tue Apr 11 17:50:48 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FTQl6-0004UP-Cf; Tue, 11 Apr 2006 17:50:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FTQl5-0004Th-KN
	for techspec@ietf.org; Tue, 11 Apr 2006 17:50:47 -0400
Received: from imr1.ericy.com ([198.24.6.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTQl3-0005ER-Ax
	for techspec@ietf.org; Tue, 11 Apr 2006 17:50:47 -0400
Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se
	[138.85.133.38])
	by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id k3BLoeH2004283;
	Tue, 11 Apr 2006 16:50:40 -0500
Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72)
	id <GDPVJAGS>; Tue, 11 Apr 2006 16:50:40 -0500
Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C0038027F53EA@eusrcmw720.eamcs.ericsson.se>
From: "Stephen Hayes (TX/EUS)" <stephen.hayes@ericsson.com>
To: Leslie Daigle <leslie@thinkingcat.com>
Subject: RE: [Techspec] IETF steering of publisher editing
Date: Tue, 11 Apr 2006 16:50:28 -0500
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: 7655788c23eb79e336f5f8ba8bce7906
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\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org

Leslie wrote:
> "In specific instances, where some or all of document text is 
> the result
>   of a careful negotiation of contributions (within or between working
>   groups, reviewers, etc), the IESG will require that the publisher
>   publish the text verbatim.   It is the expectation of the IETF
>   community that this will not be done often."
> 

I think this text captures a capability that the IETF needs and should replace the current text in Req-POSTEDIT-5. It is probably necessary to generalize "the IESG" to include the IAB and IRSG.

> WRT getting in the way of the type of experiment proposed in
> draft-eronen-rfc-selective-experiment-00.txt -- I'm sympathetic,
> to the extent we believe the IETF community *wants* to be
> able to engage in such experiments (I'll observe it's a personal
> -00 submission).   But, much of the motivation of that experiment
> should be undone if we do the TechSpec job properly.

If I understand Henrik correctly, the goal is to not close the door on doing a process experiment like this.  In the future there may be other experiments that we come up with.  It's not possible to figure out what sorts of requirements we might need in the future to accomodate some not yet thought of experiment.  If the desire is just to allow experiments, I think it is more appropriate to add a new requirement to section: 3.20 (Process and Document Evolution).  I think this is already covered, but if we want to make it explict, we should add a new requirement along the lines of:

Req-PROCESSCHG-2 - The IETF technical publisher should participate in and support process experiments involving the technical publication process.

Stephen

_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec



From techspec-bounces@ietf.org Tue Apr 11 20:44:18 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FTTT0-0008CY-1X; Tue, 11 Apr 2006 20:44:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FTTSz-0008CT-Ca
	for techspec@ietf.org; Tue, 11 Apr 2006 20:44:17 -0400
Received: from av9-2-sn3.vrr.skanova.net ([81.228.9.186])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTTSx-0004oK-VQ
	for techspec@ietf.org; Tue, 11 Apr 2006 20:44:17 -0400
Received: by av9-2-sn3.vrr.skanova.net (Postfix, from userid 502)
	id 28F8338063; Wed, 12 Apr 2006 02:44:15 +0200 (CEST)
Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net
	[81.228.9.101]) by av9-2-sn3.vrr.skanova.net (Postfix) with ESMTP
	id 151F337E81; Wed, 12 Apr 2006 02:44:15 +0200 (CEST)
Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com
	[81.232.110.214])
	by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 6BE4237E42;
	Wed, 12 Apr 2006 02:44:14 +0200 (CEST)
Received: from localhost ([127.0.0.1])
	by shiraz.levkowetz.com with esmtp (Exim 4.60)
	(envelope-from <henrik@levkowetz.com>)
	id 1FTTSs-0005uv-4M; Wed, 12 Apr 2006 02:44:10 +0200
Message-ID: <443C4D5A.8020206@levkowetz.com>
Date: Wed, 12 Apr 2006 02:44:10 +0200
From: Henrik Levkowetz <henrik@levkowetz.com>
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: "Stephen Hayes (TX/EUS)" <stephen.hayes@ericsson.com>
Subject: Re: [Techspec] IETF steering of publisher editing
References: <4DCBC973AF0D6E4FAF9CD998CE1C0038027F53EA@eusrcmw720.eamcs.ericsson.se>
In-Reply-To: <4DCBC973AF0D6E4FAF9CD998CE1C0038027F53EA@eusrcmw720.eamcs.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Scanned: No (on shiraz.levkowetz.com);
	SAEximRunCond expanded to false
X-Spam-Score: 0.1 (/)
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\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org

Hi,

on 2006-04-11 23:50 Stephen Hayes (TX/EUS) said the following:
> Leslie wrote:
...
>> WRT getting in the way of the type of experiment proposed in
>> draft-eronen-rfc-selective-experiment-00.txt -- I'm sympathetic,
>> to the extent we believe the IETF community *wants* to be
>> able to engage in such experiments (I'll observe it's a personal
>> -00 submission).   But, much of the motivation of that experiment
>> should be undone if we do the TechSpec job properly.

The TechSpec job is one prerequisite for eliminating the need for the
draft-eronen-... experiment, right, but not the only one.  Inadequate
funding may also be a cause of future problems with increasing
publication queue size and delay, as may other problems with the
process.  But as Stephen points out,

> If I understand Henrik correctly, the goal is to not close the door
> on doing a process experiment like this.

Right.

> In the future there may be
> other experiments that we come up with. It's not possible to figure
> out what sorts of requirements we might need in the future to
> accomodate some not yet thought of experiment. If the desire is just
> to allow experiments, I think it is more appropriate to add a new
> requirement to section: 3.20 (Process and Document Evolution). I
> think this is already covered, but if we want to make it explict, we
> should add a new requirement along the lines of:
> 
> Req-PROCESSCHG-2 - The IETF technical publisher should participate in
> and support process experiments involving the technical publication
> process.

Good point.  This is good, as it speaks to the issue of doing
experiments, instead of having a requirement geared towards one
characteristic of one particular experiment.


	Henrik

_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec



From techspec-bounces@ietf.org Wed Apr 12 10:16:12 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FTg8i-00011v-TG; Wed, 12 Apr 2006 10:16:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FTg8h-00011q-G3
	for techspec@ietf.org; Wed, 12 Apr 2006 10:16:11 -0400
Received: from smtp121.iad.emailsrvr.com ([207.97.245.121]
	helo=smtp131.iad.emailsrvr.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTg8g-0007Dh-98
	for techspec@ietf.org; Wed, 12 Apr 2006 10:16:11 -0400
Received: from [192.168.2.5] (69-170-29-227.chvlva.adelphia.net
	[69.170.29.227]) (Authenticated sender: rpelletier@isoc.org)
	by relay2.r2.iad.emailsrvr.com (SMTP Server) with ESMTP id AB2C044EB03
	for <techspec@ietf.org>; Wed, 12 Apr 2006 10:16:08 -0400 (EDT)
Message-ID: <443D0C10.9010703@isoc.org>
Date: Wed, 12 Apr 2006 10:17:52 -0400
From: Ray Pelletier <rpelletier@isoc.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: techspec@ietf.org
X-Virus-Scanned: OK
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Subject: [Techspec] s3.4 Validation of References
X-BeenThere: techspec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0489233147=="
Errors-To: techspec-bounces@ietf.org

This is a multi-part message in MIME format.
--===============0489233147==
Content-Type: multipart/alternative;
	boundary="------------010209080804000005050807"

This is a multi-part message in MIME format.
--------------010209080804000005050807
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Comment on draft-mankin-techspec-pubreq-06
3.4. Validation of references

   Discussion: The RFC Editor may put a document on hold waiting for 
the  availability of other IETF documents.  Incorrect references are 
handled like any other fault detected in the editorial review.

When the document is put on hold can have significant processing 
impacts.  For example, if the document is placed on hold upon receipt by 
the publisher and sits there for months awaiting trailing docs, the 
editor will experience difficulties engaging authors during editing and 
at AUTH48/AUTHLC.  Whereas, the editor will more often have a responsive 
and document knowledgeable author if engaged within days and weeks of 
receipt by the editor.

Recommend language change as
  s/document on hold/ document awaiting publication announcement on hold

Ray Pelletier
IAD

--------------010209080804000005050807
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Comment on <span
 style="font-size: 12pt; font-family: &quot;Times New Roman&quot;;">draft-mankin-techspec-pubreq-06</span><br>
3.4. Validation of references <br>
<br>
&nbsp;&nbsp; Discussion: The RFC Editor may put a document on hold waiting for
the&nbsp; availability of other IETF documents.&nbsp; Incorrect references are
handled like any other fault detected in the editorial review. <br>
<br>
When the document is put on hold can have significant processing
impacts.&nbsp; For example, if the document is placed on hold upon receipt
by the publisher and sits there for months awaiting trailing docs, the
editor will experience difficulties engaging authors during editing and
at AUTH48/AUTHLC.&nbsp; Whereas, the editor will more often have a
responsive and document knowledgeable author if engaged within days and
weeks of receipt by the editor.<br>
<br>
Recommend language change as<br>
&nbsp; s/document on hold/ document awaiting publication announcement on hold<br>
<br>
Ray Pelletier<br>
IAD<br>
</body>
</html>

--------------010209080804000005050807--


--===============0489233147==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec

--===============0489233147==--




From techspec-bounces@ietf.org Wed Apr 12 11:00:15 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FTgpL-000441-2N; Wed, 12 Apr 2006 11:00:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FTgpJ-00042Y-9H
	for techspec@ietf.org; Wed, 12 Apr 2006 11:00:13 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTgQ2-0007oT-SS
	for techspec@ietf.org; Wed, 12 Apr 2006 10:34:06 -0400
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FTgOG-0003Mw-7J
	for techspec@ietf.org; Wed, 12 Apr 2006 10:32:17 -0400
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1FTgOF-000INl-GV; Wed, 12 Apr 2006 10:32:15 -0400
Date: Wed, 12 Apr 2006 10:32:14 -0400
From: John C Klensin <john-ietf@jck.com>
To: Ray Pelletier <rpelletier@isoc.org>, techspec@ietf.org
Subject: Re: [Techspec] s3.4 Validation of References
Message-ID: <DB0A8C5717AD3B9E0EAC9AB3@p3.JCK.COM>
In-Reply-To: <443D0C10.9010703@isoc.org>
References: <443D0C10.9010703@isoc.org>
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: -2.1 (--)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
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\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org



--On Wednesday, 12 April, 2006 10:17 -0400 Ray Pelletier
<rpelletier@isoc.org> wrote:

> Comment on draft-mankin-techspec-pubreq-06
> 3.4. Validation of references
> 
>    Discussion: The RFC Editor may put a document on hold
> waiting for the  availability of other IETF documents.
> Incorrect references are handled like any other fault detected
> in the editorial review.
> 
> When the document is put on hold can have significant
> processing impacts.  For example, if the document is placed on
> hold upon receipt by the publisher and sits there for months
> awaiting trailing docs, the editor will experience
> difficulties engaging authors during editing and at
> AUTH48/AUTHLC.  Whereas, the editor will more often have a
> responsive and document knowledgeable author if engaged within
> days and weeks of receipt by the editor.
> 
> Recommend language change as
>   s/document on hold/ document awaiting publication
> announcement on hold

Ray,

While I see your point, this basically would imply two AUTH48/
AUTHLC cycles.  Not only does the author need to make a check on
the _final_ document, with the problematic references resolved,
but it is not unusual for other references and material to
change during a long window and need to be corrected.  For
example, if the targets of other references are updated or
rendered obsolete, the author, not the publisher/editor needs to
make the final decision as to whether those references are
appropriately updated. 

It is worth remembering that the AUTH48 review was introduced
because authors and the IESG discovered that errors were being
introduced late in the editing process and wanted to shift
responsibility for catching and correcting those errors to the
authors, rather than blaming the RFC Editor after it was too
late to correct them.

In addition, if the dangling reference points to an I-D ("work
in progress"), someone will need to take the final
responsibility for determining that the citation is still valid
or whether it needs additional qualification in the text.
Arguably, if that situation is likely to arise, the document
should be held by the IESG and never passed to the technical
publisher, but neither this document nor existing procedures
require that.   

The thrust of much of this document appears to be to de-skill
the "technical publisher" role.  Whether that is a good idea or
not, one of its consequences is that it is not possible to place
as much reliance on the publisher to just get things right, know
about substantive validity of references, etc., as we have in
the past.  That shifts the burdens to the IESG and the authors,
and we had therefore best not try to shortcut the final review
process.

So I don't think this change would accomplish much of anything
valuable.

 regards,
     john


_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec



From techspec-bounces@ietf.org Wed Apr 12 14:42:05 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FTkI0-0001Qe-K0; Wed, 12 Apr 2006 14:42:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FTkHz-0001QZ-Tw
	for techspec@ietf.org; Wed, 12 Apr 2006 14:42:03 -0400
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTkHy-00008P-Ji
	for techspec@ietf.org; Wed, 12 Apr 2006 14:42:03 -0400
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k3CIf0X02922;
	Wed, 12 Apr 2006 11:41:00 -0700 (PDT)
From: Bob Braden <braden@ISI.EDU>
Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id LAA01933;
	Wed, 12 Apr 2006 11:41:00 -0700 (PDT)
Date: Wed, 12 Apr 2006 11:41:00 -0700 (PDT)
Message-Id: <200604121841.LAA01933@gra.isi.edu>
To: techspec@ietf.org, rpelletier@isoc.org
Subject: Re: [Techspec] s3.4 Validation of References
X-Sun-Charset: US-ASCII
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: braden@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: falk@ISI.EDU, jkrey@ISI.EDU, braden@ISI.EDU
X-BeenThere: techspec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org



Ray,

I realize you have suggested this before, but unfortunately it is a bad
idea.  When document A is held up by a normative reference to B, A and
B must be published together.  It is not at all unusual for some
inconsistency between A and B to show up at the very last minute.
Therefore, it is unreasonable and undesirable to say that A must be
fully ready to publish before B is done.

Furthermore, it seems to be forcing a particular resource allocation on
the pub service with no gain, but rather a loss of flexibility and
therefore efficiency.  If you accept that the pub service has the same
goal that the IAD/IASA/IETF has -- publishing documents as quickly and
efficiently as possible -- then imposing arbitrary scheduling rules
like this cannot be a useful thing to do.

Bob Braden

_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec



From techspec-bounces@ietf.org Thu Apr 13 12:56:53 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FU57j-0005jG-Ed; Thu, 13 Apr 2006 12:56:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FU57i-0005jA-5o
	for techspec@ietf.org; Thu, 13 Apr 2006 12:56:50 -0400
Received: from imr1.ericy.com ([198.24.6.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU57e-000393-TV
	for techspec@ietf.org; Thu, 13 Apr 2006 12:56:48 -0400
Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se
	[138.85.133.38])
	by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id k3DGukvp022867
	for <techspec@ietf.org>; Thu, 13 Apr 2006 11:56:46 -0500
Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72)
	id <GDPVJRMB>; Thu, 13 Apr 2006 11:56:46 -0500
Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C003802822E65@eusrcmw720.eamcs.ericsson.se>
From: "Stephen Hayes (TX/EUS)" <stephen.hayes@ericsson.com>
To: techspec@ietf.org
Date: Thu, 13 Apr 2006 11:56:38 -0500
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] Final call before -07 version of mankin-pub-req
X-BeenThere: techspec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org

To meet the April 15 deadline, I plan to produce mankin-pub-req-07 at the end of today.

The changes collected so far are:

1. Replace Req-POSTEDIT-5 with 

Req-POSTEDIT-5 In specific instances, where some or all of document text is the result of a careful negotiation of contributions (within or between working groups, reviewers, etc), the IESG or IAB or IRSG will require that the publisher
publish that text verbatim.   It is the expectation of the IETF community that this will not be done often.

2. Add a new requirement to section 3.20:

Req-PROCESSCHG-2 - The IETF technical publisher should participate in and support process experiments involving the technical publication process.

Anything else?

Stephen Hayes


_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec



From techspec-bounces@ietf.org Thu Apr 13 13:13:39 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FU5Nz-0006IC-1o; Thu, 13 Apr 2006 13:13:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FU5Nx-0006I7-DY
	for techspec@ietf.org; Thu, 13 Apr 2006 13:13:37 -0400
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU5Nw-0003hd-V7
	for techspec@ietf.org; Thu, 13 Apr 2006 13:13:37 -0400
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1FU5Nw-000KYU-88; Thu, 13 Apr 2006 13:13:36 -0400
Date: Thu, 13 Apr 2006 13:13:35 -0400
From: John C Klensin <john-ietf@jck.com>
To: "Stephen Hayes (TX/EUS)" <stephen.hayes@ericsson.com>, techspec@ietf.org
Subject: Re: [Techspec] Final call before -07 version of
 mankin-pub-req
Message-ID: <E19FDF2C5E9FFFC651EC2C1D@p3.JCK.COM>
In-Reply-To: <4DCBC973AF0D6E4FAF9CD998CE1C003802822E65@eusrcmw720.eamcs.ericsson.se>
References: <4DCBC973AF0D6E4FAF9CD998CE1C003802822E65@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: b280b4db656c3ca28dd62e5e0b03daa8
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\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org



--On Thursday, 13 April, 2006 11:56 -0500 "Stephen Hayes
(TX/EUS)" <stephen.hayes@ericsson.com> wrote:

> To meet the April 15 deadline, I plan to produce
> mankin-pub-req-07 at the end of today.
> 
> The changes collected so far are:
> 
> 1. Replace Req-POSTEDIT-5 with 
> 
> Req-POSTEDIT-5 In specific instances, where some or all of
> document text is the result of a careful negotiation of
> contributions (within or between working groups, reviewers,
> etc), the IESG or IAB or IRSG will require that the publisher
> publish that text verbatim.   It is the expectation of the
> IETF community that this will not be done often.
> 
> 2. Add a new requirement to section 3.20:
> 
> Req-PROCESSCHG-2 - The IETF technical publisher should
> participate in and support process experiments involving the
> technical publication process.
> 
> Anything else?

Stephen, 

While I think these changes, and some related text, reflect the
consensus of discussion on this list, I'd like to raise a flag
about another point of view... and the possibility that IETF
consensus might possibly lie elsewhere.

Over the years, both before and after the creation of the IETF,
the RFC Editor process has provided an important check on
document quality, at least editorial quality and sometimes
technical quality.   The more we move toward "whatever the IESG
wants, the IESG gets", the more we do two other things:

	* we eliminate that check and reduce the need for a
	publisher function that is capable of applying it.
	
	* we make the IESG the final repository of editorial
	skill and judgment. 

Clearly, there are people in the community who believe that the
first of these would be A Good Thing.  Personally, I think it is
an attempt to solve a set of problems with the bathwater by
discarding both the baby and most of the plumbing in the house.

As to the second, many of us have seen IESG nit-picking over
editorial matters as one of the major roadblocks to rapidly
progressing documents.  Early editing experiments are useful in
addressing some of the issues there, as are IESG efforts to pin
down the justifications for "discuss" positions.    But giving
the IESG the authority to say "publish this as is" pushes the
editorial job back on them, at least for whatever documents
someone can argue are Really Important.  It is not clear to me
that we want to head in that direction without stronger
safeguards than "expectation ... that this will not be done
often".  I'd be much more comfortable with the idea if two
additional things went with it:

(i) The proposal that a document will be fast-tracked in this
way must appear as part of the Last Call announcement so that
the community can comment on the necessity of doing that and on
the editorial readiness for publication "as is" as well as on
the technical substance of the document.  I would hope that we
can trust the IESG to either bounce the document or drop the
fast-track plan if there is significant negative feedback on
expedited publication as-is, rather than trying to rewrite the
document themselves.

(ii) The decision to fast-track a document in this way must be
appealable by any impacted party in the community including, if
the document is judged unsatisfactory under our presumably-high
publication quality, by the technical publisher themselves.

  regards,
      john


_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec



From techspec-bounces@ietf.org Thu Apr 13 13:36:36 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FU5k9-0003H1-Jr; Thu, 13 Apr 2006 13:36:33 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FU5k7-0002YV-QD
	for techspec@ietf.org; Thu, 13 Apr 2006 13:36:31 -0400
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU5Wf-00040q-NM
	for techspec@ietf.org; Thu, 13 Apr 2006 13:22:38 -0400
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k3DHL1X26094;
	Thu, 13 Apr 2006 10:21:01 -0700 (PDT)
From: Bob Braden <braden@ISI.EDU>
Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id KAA02432;
	Thu, 13 Apr 2006 10:20:59 -0700 (PDT)
Date: Thu, 13 Apr 2006 10:20:59 -0700 (PDT)
Message-Id: <200604131720.KAA02432@gra.isi.edu>
To: techspec@ietf.org, stephen.hayes@ericsson.com
Subject: Re: [Techspec] Final call before -07 version of mankin-pub-req
X-Sun-Charset: US-ASCII
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: braden@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Cc: braden@ISI.EDU
X-BeenThere: techspec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org



  *> 
  *> 1. Replace Req-POSTEDIT-5 with 
  *> 
  *> Req-POSTEDIT-5 In specific instances, where some or all of document
  *> text is the result of a careful negotiation of contributions (within or
  *> between working groups, reviewers, etc), the IESG or IAB or IRSG will
  *> require that the publisher publish that text verbatim.   It is the
  *> expectation of the IETF community that this will not be done often.
  *> 

Let's explore this.

Suppose that the contribution in question:

(1) contains a spelling error.

(2) contains typographic content, e.g., capitalization or punctuation,
	which is inconsistent with the same usage in the rest of the
	document.

(3) contains typographic content, e.g., capitalization or punctuation,
	which is inconsistent with the established usage in th
	document series.

(4) contains a blatant grammatical error, e.g., it is not a sentence.

(5) contains language which unbiased observers would say was ambiguous
	in meaning.

Are you saying that in NONE of these cases do you want the text changed?
Are you saying that having carefully negotiated deficient text, you want
to protect it, no matter what? 

I might suggest that such careful negotiation concerns the MEANING and
CONTENT, not editorial nits.

The last point is the most interesting...  are you saying that you want
a WG to be able to negotiate and preserve language that is DELIBERATELY
ambiguous, to make everyone happy?  If so, I claim that IETF standards
process is seruously broken, and not in the publication process.


  *> 2. Add a new requirement to section 3.20:
  *> 
  *> Req-PROCESSCHG-2 - The IETF technical publisher should participate in and support process experiments involving the technical publication process.
  *> 

It appears to me that this provision is likely to lead to attempts to
micro-manage the contractor who fills the IETF technical publisher
function after this year.

If you want cooperation with the IETF technical publisher, you are
going to need to bring them into the discussion at an early stage and
get their agreement on the foundation of the proposal.  I have seen a
lot of really bad ideas go by in the past year.  If they were imposed
on the technical publisher, you would not have a very happy
relationship

I think you will need a more formal, less "bottom up" process than the
current process experiment procedure.  For example, such experiments
may affect contractual agreements between the ISOC and the technical
publisher, so representatives of all concerned parties will need to be
involved.

Bob Braden

  *> 
  *> Stephen Hayes
  *> 
  *> 
  *> _______________________________________________
  *> 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 Apr 13 13:55:49 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FU62n-0003fq-56; Thu, 13 Apr 2006 13:55:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FU62m-0003fl-DW
	for techspec@ietf.org; Thu, 13 Apr 2006 13:55:48 -0400
Received: from zeke.ecotroph.net ([69.31.8.124])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU62m-0005FN-4Z
	for techspec@ietf.org; Thu, 13 Apr 2006 13:55:48 -0400
Received: from [64.100.227.124] ([::ffff:64.100.227.124])
	(AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA)
	by zeke.ecotroph.net with esmtp; Thu, 13 Apr 2006 13:54:46 -0400
	id 015880D3.443E9066.00003076
Message-ID: <443E909D.3010501@thinkingcat.com>
Date: Thu, 13 Apr 2006 13:55:41 -0400
From: Leslie Daigle <leslie@thinkingcat.com>
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: Bob Braden <braden@ISI.EDU>
Subject: Re: [Techspec] Final call before -07 version of mankin-pub-req
References: <200604131720.KAA02432@gra.isi.edu>
In-Reply-To: <200604131720.KAA02432@gra.isi.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f
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\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org


The "verbatim" text is intended to address situations where
there are specific sets of words achieved by negotiation,
and perhaps used elsewhre (e.g., something that effectively
becomes boilerplate for certain situations).  This *has*
happened when there are particular phrasings necessary
to get agreement between, say, an IETF WG and a working
party in some other organization.

In that light:  yes, verbatim.

If there were spelling errors, editorial concerns, text perceived as
unclear -- I imagine that, in an ongoing collegial environment,
the document publisher could *flag* those as issues to the
originators who could then *elect* to make changes, but the
important feature is that the default outcome is no change.


That's the reason (IMO) for which it has to be used very
sparingly.

Any text that could make that clearer would be appreciated!


Leslie.

Bob Braden wrote:
>   *> 
>   *> 1. Replace Req-POSTEDIT-5 with 
>   *> 
>   *> Req-POSTEDIT-5 In specific instances, where some or all of document
>   *> text is the result of a careful negotiation of contributions (within or
>   *> between working groups, reviewers, etc), the IESG or IAB or IRSG will
>   *> require that the publisher publish that text verbatim.   It is the
>   *> expectation of the IETF community that this will not be done often.
>   *> 
> 
> Let's explore this.
> 
> Suppose that the contribution in question:
> 
> (1) contains a spelling error.
> 
> (2) contains typographic content, e.g., capitalization or punctuation,
> 	which is inconsistent with the same usage in the rest of the
> 	document.
> 
> (3) contains typographic content, e.g., capitalization or punctuation,
> 	which is inconsistent with the established usage in th
> 	document series.
> 
> (4) contains a blatant grammatical error, e.g., it is not a sentence.
> 
> (5) contains language which unbiased observers would say was ambiguous
> 	in meaning.
> 
> Are you saying that in NONE of these cases do you want the text changed?
> Are you saying that having carefully negotiated deficient text, you want
> to protect it, no matter what? 
> 
> I might suggest that such careful negotiation concerns the MEANING and
> CONTENT, not editorial nits.
> 
> The last point is the most interesting...  are you saying that you want
> a WG to be able to negotiate and preserve language that is DELIBERATELY
> ambiguous, to make everyone happy?  If so, I claim that IETF standards
> process is seruously broken, and not in the publication process.
> 
> 
>   *> 2. Add a new requirement to section 3.20:
>   *> 
>   *> Req-PROCESSCHG-2 - The IETF technical publisher should participate in and support process experiments involving the technical publication process.
>   *> 
> 
> It appears to me that this provision is likely to lead to attempts to
> micro-manage the contractor who fills the IETF technical publisher
> function after this year.
> 
> If you want cooperation with the IETF technical publisher, you are
> going to need to bring them into the discussion at an early stage and
> get their agreement on the foundation of the proposal.  I have seen a
> lot of really bad ideas go by in the past year.  If they were imposed
> on the technical publisher, you would not have a very happy
> relationship
> 
> I think you will need a more formal, less "bottom up" process than the
> current process experiment procedure.  For example, such experiments
> may affect contractual agreements between the ISOC and the technical
> publisher, so representatives of all concerned parties will need to be
> involved.
> 
> Bob Braden
> 
>   *> 
>   *> Stephen Hayes
>   *> 
>   *> 
>   *> _______________________________________________
>   *> Techspec mailing list
>   *> Techspec@ietf.org
>   *> https://www1.ietf.org/mailman/listinfo/techspec
>   *> 
> 
> _______________________________________________
> Techspec mailing list
> Techspec@ietf.org
> https://www1.ietf.org/mailman/listinfo/techspec
> 

_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec



From techspec-bounces@ietf.org Thu Apr 13 17:40:24 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FU9Xz-0007jB-KU; Thu, 13 Apr 2006 17:40:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FU9Xy-0007eF-FR
	for techspec@ietf.org; Thu, 13 Apr 2006 17:40:14 -0400
Received: from imr1.ericy.com ([198.24.6.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU9Xy-0004ng-5H
	for techspec@ietf.org; Thu, 13 Apr 2006 17:40:14 -0400
Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se
	[138.85.133.38])
	by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id k3DLeAeV019210;
	Thu, 13 Apr 2006 16:40:13 -0500
Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72)
	id <GDPVJ45A>; Thu, 13 Apr 2006 16:40:10 -0500
Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C00380282331F@eusrcmw720.eamcs.ericsson.se>
From: "Stephen Hayes (TX/EUS)" <stephen.hayes@ericsson.com>
To: John C Klensin <john-ietf@jck.com>, techspec@ietf.org
Subject: RE: [Techspec] Final call before -07 version of mankin-pub-req
Date: Thu, 13 Apr 2006 16:40:06 -0500
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: 4b800b1eab964a31702fa68f1ff0e955
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\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org

John Klensin wrote:
> While I think these changes, and some related text, reflect the
> consensus of discussion on this list, I'd like to raise a flag
> about another point of view... and the possibility that IETF
> consensus might possibly lie elsewhere.
> 
> Over the years, both before and after the creation of the IETF,
> the RFC Editor process has provided an important check on
> document quality, at least editorial quality and sometimes
> technical quality.   The more we move toward "whatever the IESG
> wants, the IESG gets", the more we do two other things:
> 
> 	* we eliminate that check and reduce the need for a
> 	publisher function that is capable of applying it.
> 	
> 	* we make the IESG the final repository of editorial
> 	skill and judgment. 
> 
> Clearly, there are people in the community who believe that the
> first of these would be A Good Thing.  Personally, I think it is
> an attempt to solve a set of problems with the bathwater by
> discarding both the baby and most of the plumbing in the house.

The dumbing down of the editor role is somewhat implied when you open up the process for outside bids.  You can't assume another editor will have the same knowledge as the RFC editor or trust that they will make the right judgements.  So I view this requirements document as a low level result of a high level decision.  In any case, the result should eventually lead to improved performance.

> 
> As to the second, many of us have seen IESG nit-picking over
> editorial matters as one of the major roadblocks to rapidly
> progressing documents.  Early editing experiments are useful in
> addressing some of the issues there, as are IESG efforts to pin
> down the justifications for "discuss" positions.    But giving
> the IESG the authority to say "publish this as is" pushes the
> editorial job back on them, at least for whatever documents
> someone can argue are Really Important.  It is not clear to me
> that we want to head in that direction without stronger
> safeguards than "expectation ... that this will not be done
> often".  I'd be much more comfortable with the idea if two
> additional things went with it:
> 
> (i) The proposal that a document will be fast-tracked in this
> way must appear as part of the Last Call announcement so that
> the community can comment on the necessity of doing that and on
> the editorial readiness for publication "as is" as well as on
> the technical substance of the document.  I would hope that we
> can trust the IESG to either bounce the document or drop the
> fast-track plan if there is significant negative feedback on
> expedited publication as-is, rather than trying to rewrite the
> document themselves.
> 
> (ii) The decision to fast-track a document in this way must be
> appealable by any impacted party in the community including, if
> the document is judged unsatisfactory under our presumably-high
> publication quality, by the technical publisher themselves.
> 
The current requirement on publishing verbatim gives IESG (or IAB or IRSG) absolute power over the publisher.  As you point out this is a dangerous thing.  I think this capability is needed in the case of conflicts, but checks and balances are needed to prevent it from becoming a common path to get documents out quickly.  Your comment reminded me that I had also forgotten to delete the 2nd bullet in section 5

   o  Post Approval Editorial Cleanup: IETF must define under what 
      conditions the publisher should be instructed to bypass post 
      approval editing. 

I propose to alter this to:

   o  Post Approval Editorial Cleanup: IETF must define under what 
      conditions the publisher should be instructed to bypass post 
      approval editing of sections of text.  Appropriate checks should be established to ensure this an exceptional case.

>   regards,
>       john
> 
> 

_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec



From techspec-bounces@ietf.org Thu Apr 13 18:30:08 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FUAKG-0003VK-Pn; Thu, 13 Apr 2006 18:30:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FUAKF-0003VE-Im
	for techspec@ietf.org; Thu, 13 Apr 2006 18:30:07 -0400
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUAKE-0006nG-O6
	for techspec@ietf.org; Thu, 13 Apr 2006 18:30:07 -0400
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1FUAK8-000Kzp-Qw; Thu, 13 Apr 2006 18:30:01 -0400
Date: Thu, 13 Apr 2006 18:29:59 -0400
From: John C Klensin <john-ietf@jck.com>
To: "Stephen Hayes (TX/EUS)" <stephen.hayes@ericsson.com>, techspec@ietf.org
Subject: RE: [Techspec] Final call before -07 version of
 mankin-pub-req
Message-ID: <A9FC4A18BC918CBEC2630577@p3.JCK.COM>
In-Reply-To: <4DCBC973AF0D6E4FAF9CD998CE1C00380282331F@eusrcmw720.eamcs.ericsson.se>
References: <4DCBC973AF0D6E4FAF9CD998CE1C00380282331F@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: 0ff9c467ad7f19c2a6d058acd7faaec8
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\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org



--On Thursday, 13 April, 2006 16:40 -0500 "Stephen Hayes
(TX/EUS)" <stephen.hayes@ericsson.com> wrote:

> John Klensin wrote:
>> While I think these changes, and some related text, reflect
>> the consensus of discussion on this list, I'd like to raise a
>> flag about another point of view... and the possibility that
>> IETF consensus might possibly lie elsewhere.
>> 
>> Over the years, both before and after the creation of the
>> IETF, the RFC Editor process has provided an important check
>> on document quality, at least editorial quality and sometimes
>> technical quality.   The more we move toward "whatever the
>> IESG wants, the IESG gets", the more we do two other things:
>> 
>> 	* we eliminate that check and reduce the need for a
>> 	publisher function that is capable of applying it.
>> 	
>> 	* we make the IESG the final repository of editorial
>> 	skill and judgment. 
>> 
>> Clearly, there are people in the community who believe that
>> the first of these would be A Good Thing.  Personally, I
>> think it is an attempt to solve a set of problems with the
>> bathwater by discarding both the baby and most of the
>> plumbing in the house.
> 
> The dumbing down of the editor role is somewhat implied when
> you open up the process for outside bids.  You can't assume
> another editor will have the same knowledge as the RFC editor
> or trust that they will make the right judgements.  So I view
> this requirements document as a low level result of a high
> level decision.  In any case, the result should eventually
> lead to improved performance.

Stephen, I don't think either of those conclusions follows.
There are almost certainly people in the wider community who
believe that they have the level of knowledge and understanding
needed to do exactly the job the RFC Editor does today.  Whether
they are correct or not is, fortunately, one of those things the
bidding process might sort out.   What such a requirement does
is to effectively prevent "Joe's Pizza, Used Car Parts, Web
Design, and Copy-Editing Company" from submitting a credible
bid.  That "high level decision" -- the questions of whether we
want bids from Joe, or only from some entities significantly
further up the skill/ knowledge chain (and, if so, how far up)
-- may be ones for which the answers were assumed when TechSpec
was created.  But, as far as I know, those answers have never
been specifically articulated and written down, much less
discussed in the broader community.

In that context, TechSpec could be viewed as an effort to figure
out what the technical publisher role would look like given some
fairly low, but not specifically identified, skill level.  No
opportunity has been identified for similar exercises at other
skill levels or under other assumptions.

As to whether this will result in "improved performance"
depends, of course, in how one defines and measures those terms.
If the only criterion to be applied is time to publish a
document after IESG approval, then it is obvious how to get
"improved performance": automate the process of turning I-D
structure and boilerplate into RFC-like structure and
boilerplate and let someone bid a collection of tools and a
low-level operator for the technical publisher role.  But I
don't think that is what any of us want.

Personally,  I want to see the best performance possible
consistent with quality that is no worse than what we have
today.  That balance is, inevitably, somewhat subjective.  And
I'm not sure that the current document helps very much in
finding that optimal balance.

>> As to the second, many of us have seen IESG nit-picking over
>> editorial matters as one of the major roadblocks to rapidly
>> progressing documents.  Early editing experiments are useful
>> in addressing some of the issues there, as are IESG efforts
>> to pin down the justifications for "discuss" positions.
>> But giving the IESG the authority to say "publish this as is"
>> pushes the editorial job back on them, at least for whatever
>> documents someone can argue are Really Important.  It is not
>> clear to me that we want to head in that direction without
>> stronger safeguards than "expectation ... that this will not
>> be done often".  I'd be much more comfortable with the idea
>> if two additional things went with it:
>> 
>> (i) The proposal that a document will be fast-tracked in this
>> way must appear as part of the Last Call announcement so that
>> the community can comment on the necessity of doing that and
>> on the editorial readiness for publication "as is" as well as
>> on the technical substance of the document.  I would hope
>> that we can trust the IESG to either bounce the document or
>> drop the fast-track plan if there is significant negative
>> feedback on expedited publication as-is, rather than trying
>> to rewrite the document themselves.
>> 
>> (ii) The decision to fast-track a document in this way must be
>> appealable by any impacted party in the community including,
>> if the document is judged unsatisfactory under our
>> presumably-high publication quality, by the technical
>> publisher themselves.
>> 
> The current requirement on publishing verbatim gives IESG (or
> IAB or IRSG) absolute power over the publisher.  As you point
> out this is a dangerous thing.  I think this capability is
> needed in the case of conflicts, but checks and balances are
> needed to prevent it from becoming a common path to get
> documents out quickly.  Your comment reminded me that I had
> also forgotten to delete the 2nd bullet in section 5
> 
>    o  Post Approval Editorial Cleanup: IETF must define under
> what        conditions the publisher should be instructed to
> bypass post        approval editing. 
> 
> I propose to alter this to:
> 
>    o  Post Approval Editorial Cleanup: IETF must define under
> what        conditions the publisher should be instructed to
> bypass post        approval editing of sections of text.
> Appropriate checks should be established to ensure this an
> exceptional case.

Temporarily putting myself into the role of someone who might be
interested in bidding on this, who understood the job that has
been done by the RFC Editor for the last 35 years, and, more
important, understood the quality of some of the documents that
emerge from the IESG, if I saw "appropriate checks should be
established...", I would be deterred from bidding.  It would be
ok if the process post-mankin-pub-req but before an RFP was
issued defined those checks, but I point out that there is not
much time and that serious checks are IETF process issues, not
IASA administrative procedures.  We don't have a history of
being able to make and ratify IETF process changes quickly.
That is why I'd prefer to avoid the handwaving implicit in
"should be established" and make sure that these decisions are
subject to the usual appeals procedures: that, at least,
provides a minimum level of safety.

    john



_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec



From techspec-bounces@ietf.org Mon Apr 17 09:26:07 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FVTjy-0004Q5-TV; Mon, 17 Apr 2006 09:26:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FUWb8-0004rA-HZ
	for techspec@ietf.org; Fri, 14 Apr 2006 18:17:02 -0400
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUWb8-0002bO-22
	for techspec@ietf.org; Fri, 14 Apr 2006 18:17:02 -0400
Received: from adma.isi.edu (adma.isi.edu [128.9.160.239])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with SMTP id k3EMGdM26147;
	Fri, 14 Apr 2006 15:16:39 -0700 (PDT)
Message-Id: <200604142216.k3EMGdM26147@boreas.isi.edu>
Date: Fri, 14 Apr 2006 15:16:39 -0700 (PDT)
From: Sandy Ginoza <ginoza@ISI.EDU>
To: techspec@ietf.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: G1nfUkC6WwbHzRODzGoTFg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.7 SunOS 5.9 sun4u sparc 
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: ginoza@boreas.isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f
X-Mailman-Approved-At: Mon, 17 Apr 2006 09:26:06 -0400
Cc: ginoza@ISI.EDU
Subject: [Techspec] draft-mankin-pub-req-05.txt
X-BeenThere: techspec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Sandy Ginoza <ginoza@ISI.EDU>
List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org

All,

I read through the tech spec document <draft-mankin-pub-req-05.txt> and
have the comments below.  While these are based on my experiences
working for the RFC Editor, the comments below are my personal comments
and do not represent the views of RFC Editor function.

Thanks,

Sandy Ginoza

-----------------------------------------------------------------

- Section 3 states

   Based upon this information we derive requirements on the IETF
   technical editor:

  6. Assignment of parameter values

This seems like incorrect phraseology (unless the functions are to be
combined), as the publisher would insert the assigned values, not
assign the values themselves.


- Section 3.1 states

  In many cases the technical publisher may provide a review or
  editing service to improve document quality prior to the approval of
  a document.  This review process would normally address issues such
  as grammar, spelling, formatting, adhrence to boilerplate, document 
  structure, proper use of keywords (RFC 2119), etc.

Prior to document approval, the document has different boilerplate
info.  The technical publisher is to check the boilerplate info of the
ID?  Are these functions to be combined?



- Section 3.1 states

  Discussion: Pre-approval review is not part of the normal process
  flow with the IETF but this concept has been explored with promising
  results in the early copy editing experiment.

I think the results of the experiment are inconclusive.  Thus far, only
one of six documents involved in this experiment has made it into the
RFC Editor queue.  It did not enter the queue until just recently
(maybe the week or two prior to IETF).  Alice has not yet reviewed the
diffs (as it has not made it to the front of the queue), so we do not
know whether the pre-editing has helped.


- Section 3.3 states

  The ambition level for cleanup can vary from:

  o Corrections to errors only,

  ...

  o Rewriting of all documents to the dictates of a style manual

We attempt only to correct errors, and we try to ensure that all
documents adhere to some form of grammar guide.  We try to make changes
that improve clarity and make the document more consistent within
itself, as well as across a document set.


- Section 3.3 states

  At times in the past year, stylistic editing has resulted in 40-100
  substantive changes in many documents.  These changes must then be
  vetted by all the authors followed by subsequent rounds of author
  acceptance and re-vetting.

I'm not sure what is considered a substantive change here, but
sometimes 40-100 substantive changes in one document may be necessary.
I believe this to be a very unusual case, and I am not sure if this
takes into account instances for which, although we did not change the
text correctly, the authors came back with a more clearly worded
alternate?

Also, an average size RFC is roughly 30 pages.  Assuming a middle
ground between the 40-100 changes gets us to an average of 70 changes
per document, which means an average of 2.33 changes per page.  This is
not a high rate of change considering the amount of work some of these
documents require.

Furthermore, there are often a large number of changes requested by the
authors themselves, many of which require AD review and approval.  Does
this 40-100 number differentiate the RFC Editor induced and the
author/wg chair/ad induced changes?


- Section 3.3 state
	
  o Potential Req-POSTEDIT-4 - The IETF Technical editor should
    refrain from making changes to improve readability that may change
    technical and consensus wording.

Do not make changes to improve readability??
We often find errors in documents after any number of revisions and
after the documents have been approved that require author/editor
clarification, e.g., cut and paste errors, missing text.


- Section 3.7 states

  o Potential Req-POSTCORR-3 - The IETF technical publisher should
    have the discretion to reject post-approval corrections as too
    late in the process and propose that it be handled as errata.

Errata maintenance will turn into an even bigger headache.  Why not
just make the correction instead of going through the process of
approving and posting an errata?


- Section 3.15 discusses the maintenance of errata... 

Who verifies this errata?


- Section 3.16 states

  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.  

Again, this sounds as though the RFC Editor and ID functions will be
combined.  Or, does this just require that the technical publisher
request that the ID repository not expire a draft?


- Section 3.18 states

  Discussion: The RFC Editor does not maintain a document or database
  of terms or acronyms.

This statement is untrue.  However, our main goal is to be consistent
within a single document and across a set of documents.  If an author
has used terminology inconsistently, we will update the text with our
preferred usage.  If the author has already used the terminology
consistenly, we will leave the terms unaltered (unless they go against
some pre-specified usage, e.g., IPSEC would be changed to IPsec
regardless of whether the author used IPSEC consistently throughout the
document).



- Section 4 states

  Here are some metrics that could apply to the IETF technical
  publisher.

  ...

  3. Non author changes generated during publication

  4. Author changes generated during publication

This does not take into account changes requested by those other than
the editor and author.  For example, ADs and WG chairs.


- Section 4.1 states

  o Potential Req-TIMEFRMAES-1 - The IETF technical publisher should
    have a goal of an average publication time of no more than 4 weeks
    and at least 90% of all documents should be published within 8
    weeks. 

Does this time frame refer only to those documents that have been
through the early copy edit phase or all documents in general?


- Section 4.1 states

  o Potential Req-TIMEFRAMES-2 - For those documents for which early
    allocation of an identifier is request, The IETF technical
    publisher should have a goal of an average allocation time of no
    more than 1 week and at least 90% of early allocation documents
    should have a stable identifier allocated within 2 weeks of
    approval.  ...

  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 10 days and at least 90% of all 
    documents should be reviewed within 15 days.  ...

I guess since it says average, it's okay, but this does not take into
consideration document size and other variables associated with
document delay, such as the sudden influx of documents from the IESG
secretariat. 


- Section 4.3 states

  o Potential Req-EDITCHGSTATS-1 - The IETF technical publisher should
    provide monthly statistics on the types of editorial corrections
    being found during review as well as the percent of corrections
    which are rejected by the authors.

This will require even more time spent on each document, as it will
require stopping to make tally marks each time we mark a correction,
or going through the document a second time to count and tally the
marks inserted.  It will also require a third review of the document
to tally the changes accepted/rejected by the authors.  For a process
that is supposedly already too time consuming, this will make the
process even more lengthy.  It will also require formal definitions of
the varying types of errors that can be found, as often times, a
correction cannot be classified as purely
grammatical/editorial/technical. 


- Section 5 states

  o Exception Handling: If publication timelines can be reduced
    sufficiently or permanent identifiers allocated early, then
    expedited handling may no longer be needed.

According to section 3.13, exception handling refers to the reasons a
document can be withdrawn or put on hold.  The above seems to be
refering to early allocation requests.



_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec



From techspec-bounces@ietf.org Mon Apr 17 10:31:23 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FVUl2-0003uZ-Ns; Mon, 17 Apr 2006 10:31:16 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FVUl1-0003p2-Kl
	for techspec@ietf.org; Mon, 17 Apr 2006 10:31:15 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVUl1-00019y-8c
	for techspec@ietf.org; Mon, 17 Apr 2006 10:31:15 -0400
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 k3HEVDqi020282
	for <techspec@ietf.org>; Mon, 17 Apr 2006 07:31:14 -0700 (MST)
	(envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p06230919c069557afefb@[10.20.30.249]>
In-Reply-To: <200604142216.k3EMGdM26147@boreas.isi.edu>
References: <200604142216.k3EMGdM26147@boreas.isi.edu>
Date: Mon, 17 Apr 2006 07:31:15 -0700
To: techspec@ietf.org
From: Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Early copyediting experiment (was: Re: [Techspec]
	draft-mankin-pub-req-05.txt)
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org

At 3:16 PM -0700 4/14/06, Sandy Ginoza wrote:
>I think the results of the experiment are inconclusive.  Thus far, only
>one of six documents involved in this experiment has made it into the
>RFC Editor queue.

That document was in the WG I co-chair, so I feel comfortable speaking for it.

>It did not enter the queue until just recently
>(maybe the week or two prior to IETF).

The document went into the RFC Editor queue six weeks ago.

>Alice has not yet reviewed the
>diffs (as it has not made it to the front of the queue), so we do not
>know whether the pre-editing has helped.

As we reported to Bert back in November, the experiment from the WG 
side went smoothly and quickly. As Jari Arkko said at the time:

At 4:41 PM +0200 11/2/05, Jari Arkko wrote:
>The change was really minor. Language in the document
>was fairly good already.
>
>Well, there were some dozens of changes as I recall, but
>none of them appeared to impact readibility in significant
>degree.

In other words, the early review step didn't impede us and hopefully 
helped the overall process.

--Paul Hoffman, Director
--VPN Consortium

_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec



From techspec-bounces@ietf.org Mon Apr 17 10:38:22 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FVUru-0007CT-4f; Mon, 17 Apr 2006 10:38:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FVUrs-0007CO-9T
	for techspec@ietf.org; Mon, 17 Apr 2006 10:38:20 -0400
Received: from balder-227.proper.com ([192.245.12.227])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVUrr-0001UJ-Vj
	for techspec@ietf.org; Mon, 17 Apr 2006 10:38:20 -0400
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 k3HEcIjK020512
	for <techspec@ietf.org>; Mon, 17 Apr 2006 07:38:19 -0700 (MST)
	(envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p0623091ac069580e999d@[10.20.30.249]>
In-Reply-To: <200604142216.k3EMGdM26147@boreas.isi.edu>
References: <200604142216.k3EMGdM26147@boreas.isi.edu>
Date: Mon, 17 Apr 2006 07:38:19 -0700
To: techspec@ietf.org
From: Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Tallying (Was: Re: [Techspec] draft-mankin-pub-req-05.txt)
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
X-BeenThere: techspec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org

At 3:16 PM -0700 4/14/06, Sandy Ginoza wrote:
>- Section 4.3 states
>
>   o Potential Req-EDITCHGSTATS-1 - The IETF technical publisher should
>     provide monthly statistics on the types of editorial corrections
>     being found during review as well as the percent of corrections
>     which are rejected by the authors.
>
>This will require even more time spent on each document, as it will
>require stopping to make tally marks each time we mark a correction,
>or going through the document a second time to count and tally the
>marks inserted.

Not really. First, statistics could be collected on a representative 
sample of documents during the month, not every document. Second, the 
person tallying does not need to be the person correcting, and 
therefor there is no requirement of "stopping to make tally marks". 
Such tallying could be done by the management, not the workers, for 
example.

--Paul Hoffman, Director
--VPN Consortium

_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec



From techspec-bounces@ietf.org Tue Apr 18 06:14:23 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FVnDw-0001Qr-Ca; Tue, 18 Apr 2006 06:14:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FVnDv-0001Qm-AS
	for techspec@ietf.org; Tue, 18 Apr 2006 06:14:19 -0400
Received: from p130.piuha.net ([193.234.218.130])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVnDt-0004PN-R7
	for techspec@ietf.org; Tue, 18 Apr 2006 06:14:19 -0400
Received: from p130.piuha.net (localhost [127.0.0.1])
	by p130.piuha.net (Postfix) with ESMTP id 9EAE4898BC;
	Tue, 18 Apr 2006 13:14:16 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130])
	by p130.piuha.net (Postfix) with ESMTP id 64E00898BA;
	Tue, 18 Apr 2006 13:14:16 +0300 (EEST)
Message-ID: <4444BBF8.8080705@piuha.net>
Date: Tue, 18 Apr 2006 13:14:16 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: techspec@ietf.org, "Stephen Hayes (TX/EUS)" <stephen.hayes@ericsson.com>
Subject: Re: [Techspec] IETF steering of publisher editing
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
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\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org

> In the future there may be
> other experiments that we come up with. It's not possible to figure
> out what sorts of requirements we might need in the future to
> accomodate some not yet thought of experiment. If the desire is just
> to allow experiments, I think it is more appropriate to add a new
> requirement to section: 3.20 (Process and Document Evolution). I
> think this is already covered, but if we want to make it explict, we
> should add a new requirement along the lines of:
> 
> Req-PROCESSCHG-2 - The IETF technical publisher should participate in
> and support process experiments involving the technical publication
> process.

I think this is much better than the initial requirement, as
it no longer focuses on specific needs of a single experiment.

But I think the issue we are discussing goes beyond experiments.
The question is IETF's ability to affect what the publisher
does. There are several aspects in this. One is the ability to
run experiments, even those that go against currently approved
requirements. Another is the ability of the IETF to change
the requirements. Your text above captures the former. The
latter is captured elsewhere in the document:

> The IETF 
> technical publisher must be part of the discussions of these policies 
> and be prepared to implement and facilitate policy changes as they 
> are determined by IETF consensus. 
...
> Req-PROCESSCHG-1 - The IETF technical publisher should participate 
> in the discussions of changes to author guidelines and publication 
> process changes. 

Both are essential, I think. (Of course, they may result
in additional negotiation over, for instance, new tasks
required to be taken on by the publisher.)

These requirements allow us to cover, for instance, changes
to handling normative references as in draft-klensin,
"service level differentiation" as proposed in draft-eronen,
adoption of new input formats to the publisher, new technology
that allows automation of some steps in a way that the
publisher no longer needs to perform a particula
task, etc.

Is this all that is needed? In draft-klensin/eronen,
for instance, the -2 requirement would allow running
the experiments. If the experiments are successful,
the -1 requirement would allow a permanent change.

--Jari



_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec



From techspec-bounces@ietf.org Wed Apr 19 08:04:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FWBPp-0003hC-Hv; Wed, 19 Apr 2006 08:04:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FWBPo-0003h7-Sd
	for techspec@ietf.org; Wed, 19 Apr 2006 08:04:12 -0400
Received: from mtagate1.de.ibm.com ([195.212.29.150])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWBPo-00071e-Dq
	for techspec@ietf.org; Wed, 19 Apr 2006 08:04:12 -0400
Received: from d12nrmr1607.megacenter.de.ibm.com
	(d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate1.de.ibm.com (8.13.6/8.13.6) with ESMTP id k3JC4Bsc028516
	for <techspec@ietf.org>; Wed, 19 Apr 2006 12:04:11 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/VER6.8) with ESMTP id
	k3JC5BIO082938
	for <techspec@ietf.org>; Wed, 19 Apr 2006 14:05:11 +0200
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
	k3JC4BF3018122
	for <techspec@ietf.org>; Wed, 19 Apr 2006 14:04:11 +0200
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
	k3JC4AEM018108; Wed, 19 Apr 2006 14:04:10 +0200
Received: from zurich.ibm.com (sig-9-145-255-62.de.ibm.com [9.145.255.62])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA74694;
	Wed, 19 Apr 2006 14:04:09 +0200
Message-ID: <44462739.2040604@zurich.ibm.com>
Date: Wed, 19 Apr 2006 14:04:09 +0200
From: Brian E Carpenter <brc@zurich.ibm.com>
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: Paul Hoffman <paul.hoffman@vpnc.org>
References: <200604142216.k3EMGdM26147@boreas.isi.edu>
	<p06230919c069557afefb@[10.20.30.249]>
In-Reply-To: <p06230919c069557afefb@[10.20.30.249]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: techspec@ietf.org
Subject: [Techspec] Re: Early copyediting experiment
X-BeenThere: techspec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org

Paul Hoffman wrote:
> At 3:16 PM -0700 4/14/06, Sandy Ginoza wrote:
> 
>> I think the results of the experiment are inconclusive.  Thus far, only
>> one of six documents involved in this experiment has made it into the
>> RFC Editor queue.

I think it would be more accurate to say "the results aren't 
known yet." The fact is that the natural timescale for measuring
results is many months.
> 
> 
> That document was in the WG I co-chair, so I feel comfortable speaking 
> for it.
> 
>> It did not enter the queue until just recently
>> (maybe the week or two prior to IETF).
> 
> 
> The document went into the RFC Editor queue six weeks ago.
> 
>> Alice has not yet reviewed the
>> diffs (as it has not made it to the front of the queue), so we do not
>> know whether the pre-editing has helped.
> 
> 
> As we reported to Bert back in November, the experiment from the WG side 
> went smoothly and quickly. As Jari Arkko said at the time:
> 
> At 4:41 PM +0200 11/2/05, Jari Arkko wrote:
> 
>> The change was really minor. Language in the document
>> was fairly good already.
>>
>> Well, there were some dozens of changes as I recall, but
>> none of them appeared to impact readibility in significant
>> degree.
> 
> 
> In other words, the early review step didn't impede us and hopefully 
> helped the overall process.

There's a question here which, I suggest, is actually out of
scope for techspec: should we push the onus of document
quality assurance back to the WGs? I suggest that discussing
that here and now would be a bit of a distraction.

     Brian

_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec



From techspec-bounces@ietf.org Wed Apr 19 08:16:22 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FWBbZ-0005ME-Hv; Wed, 19 Apr 2006 08:16:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FWBbY-0005M9-Tm
	for techspec@ietf.org; Wed, 19 Apr 2006 08:16:20 -0400
Received: from mtagate4.uk.ibm.com ([195.212.29.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWBbW-0007qX-H8
	for techspec@ietf.org; Wed, 19 Apr 2006 08:16:20 -0400
Received: from d06nrmr1407.portsmouth.uk.ibm.com
	(d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185])
	by mtagate4.uk.ibm.com (8.13.6/8.13.6) with ESMTP id k3JCGHfO144426
	for <techspec@ietf.org>; Wed, 19 Apr 2006 12:16:17 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/VER6.8) with ESMTP id
	k3JCGw4M218666
	for <techspec@ietf.org>; Wed, 19 Apr 2006 13:16:58 +0100
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
	k3JCGHxd015074
	for <techspec@ietf.org>; Wed, 19 Apr 2006 13:16:17 +0100
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
	k3JCGHWR015065; Wed, 19 Apr 2006 13:16:17 +0100
Received: from zurich.ibm.com (sig-9-145-255-62.de.ibm.com [9.145.255.62])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA56316;
	Wed, 19 Apr 2006 14:16:16 +0200
Message-ID: <44462A0C.2080409@zurich.ibm.com>
Date: Wed, 19 Apr 2006 14:16:12 +0200
From: Brian E Carpenter <brc@zurich.ibm.com>
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: Sandy Ginoza <ginoza@ISI.EDU>
Subject: Terminology [Re: [Techspec] draft-mankin-pub-req-05.txt]
References: <200604142216.k3EMGdM26147@boreas.isi.edu>
In-Reply-To: <200604142216.k3EMGdM26147@boreas.isi.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: techspec@ietf.org
X-BeenThere: techspec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org

Sandy,

Sandy Ginoza wrote:
...
> - Section 3.18 states
> 
>   Discussion: The RFC Editor does not maintain a document or database
>   of terms or acronyms.
> 
> This statement is untrue.

That's interesting. Where can authors find the glossary?

    Brian

> However, our main goal is to be consistent
> within a single document and across a set of documents.  If an author
> has used terminology inconsistently, we will update the text with our
> preferred usage.  If the author has already used the terminology
> consistenly, we will leave the terms unaltered (unless they go against
> some pre-specified usage, e.g., IPSEC would be changed to IPsec
> regardless of whether the author used IPSEC consistently throughout the
> document).


_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec



From techspec-bounces@ietf.org Wed Apr 19 08:30:50 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FWBpa-0001Go-2Q; Wed, 19 Apr 2006 08:30:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FWBpY-0001Gj-UX
	for techspec@ietf.org; Wed, 19 Apr 2006 08:30:48 -0400
Received: from mtagate4.de.ibm.com ([195.212.29.153])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWBpY-0000LG-HP
	for techspec@ietf.org; Wed, 19 Apr 2006 08:30:48 -0400
Received: from d12nrmr1607.megacenter.de.ibm.com
	(d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate4.de.ibm.com (8.13.6/8.13.6) with ESMTP id k3JCUlOV025266
	for <techspec@ietf.org>; Wed, 19 Apr 2006 12:30:47 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/VER6.8) with ESMTP id
	k3JCVlIO080384
	for <techspec@ietf.org>; Wed, 19 Apr 2006 14:31:47 +0200
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
	k3JCUldP025386
	for <techspec@ietf.org>; Wed, 19 Apr 2006 14:30:47 +0200
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
	k3JCUkHM025379; Wed, 19 Apr 2006 14:30:46 +0200
Received: from zurich.ibm.com (sig-9-145-255-62.de.ibm.com [9.145.255.62])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA65910;
	Wed, 19 Apr 2006 14:30:46 +0200
Message-ID: <44462D75.7080506@zurich.ibm.com>
Date: Wed, 19 Apr 2006 14:30:45 +0200
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Bob Braden <braden@ISI.EDU>
Subject: Re: [Techspec] IETF steering of publisher editing
References: <200604111635.JAA01408@gra.isi.edu>
In-Reply-To: <200604111635.JAA01408@gra.isi.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
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\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org

Bob,

Bob Braden wrote:
> Brian,
> 
> There is something I just don't get.  Why do you personally wish to
> deliberately shun a publication process that is (1) working very well
> for nearly everyone, and (2) producing better quality standards
> documents than would be possible without this process?  Why
> do you want poor quality documents?
> 
> Bob Braden, speaking for himself.

I'm in catch-up mode and most of what I would have said on this
has been said by others; let me comment that I think the balance
is about right in draft-mankin-pub-req-07.txt.

I do want to make it clear that I have never advocated and will
never advocate publishing poor quality documents. I simply
believe that some documents are good enough as they stand, or
may be deliberately and intentionally written in a casual style,
and that this is a flag that it is reasonable for the approving
body to set.

    Brian, speaking for himself
           (as usual, unless I say otherwise)

_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec



From techspec-bounces@ietf.org Wed Apr 19 08:38:28 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FWBwy-0002kO-MC; Wed, 19 Apr 2006 08:38:28 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FWBwy-0002kJ-6G
	for techspec@ietf.org; Wed, 19 Apr 2006 08:38:28 -0400
Received: from mtagate4.de.ibm.com ([195.212.29.153])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWBwx-0000fa-PI
	for techspec@ietf.org; Wed, 19 Apr 2006 08:38:28 -0400
Received: from d12nrmr1607.megacenter.de.ibm.com
	(d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate4.de.ibm.com (8.13.6/8.13.6) with ESMTP id k3JCcQVc063660
	for <techspec@ietf.org>; Wed, 19 Apr 2006 12:38:26 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/VER6.8) with ESMTP id
	k3JCdQIO083136
	for <techspec@ietf.org>; Wed, 19 Apr 2006 14:39:26 +0200
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
	k3JCcQba002989
	for <techspec@ietf.org>; Wed, 19 Apr 2006 14:38:26 +0200
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
	k3JCcPO6002974; Wed, 19 Apr 2006 14:38:25 +0200
Received: from zurich.ibm.com (sig-9-145-255-62.de.ibm.com [9.145.255.62])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA60128;
	Wed, 19 Apr 2006 14:38:24 +0200
Message-ID: <44462F3A.4020709@zurich.ibm.com>
Date: Wed, 19 Apr 2006 14:38:18 +0200
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Bob Braden <braden@ISI.EDU>
Subject: Re: [Techspec] s3.4 Validation of References
References: <200604121841.LAA01933@gra.isi.edu>
In-Reply-To: <200604121841.LAA01933@gra.isi.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: falk@ISI.EDU, techspec@ietf.org, jkrey@ISI.EDU
X-BeenThere: techspec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org


Bob Braden wrote:
> Ray,
> 
> I realize you have suggested this before, but unfortunately it is a bad
> idea.  When document A is held up by a normative reference to B, A and
> B must be published together.  It is not at all unusual for some
> inconsistency between A and B to show up at the very last minute.
> Therefore, it is unreasonable and undesirable to say that A must be
> fully ready to publish before B is done.
> 
> Furthermore, it seems to be forcing a particular resource allocation on
> the pub service with no gain, but rather a loss of flexibility and
> therefore efficiency.  If you accept that the pub service has the same
> goal that the IAD/IASA/IETF has -- publishing documents as quickly and
> efficiently as possible -- then imposing arbitrary scheduling rules
> like this cannot be a useful thing to do.

I suspect we may be over-designing a bit here, but I'd observe
that holding documents for missing references at the entry to
the queue (which I believe is current practice) may not be ideal
either - although it may be a perfectly sensible pragmatic
choice when the workload is high. So while validation of
references is a requirement, I'm not sure we should
write down *when* it has to be done. When I buy a Model T Ford,
I don't specify where in the production line the wheels
have to be attached.

     Brian

_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec



From techspec-bounces@ietf.org Wed Apr 19 08:50:27 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FWC8Z-0005JI-A8; Wed, 19 Apr 2006 08:50:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FWC8X-0005JD-Rg
	for techspec@ietf.org; Wed, 19 Apr 2006 08:50:25 -0400
Received: from mtagate4.uk.ibm.com ([195.212.29.137])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWC8X-0001BG-FF
	for techspec@ietf.org; Wed, 19 Apr 2006 08:50:25 -0400
Received: from d06nrmr1407.portsmouth.uk.ibm.com
	(d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185])
	by mtagate4.uk.ibm.com (8.13.6/8.13.6) with ESMTP id k3JCoMbl118270
	for <techspec@ietf.org>; Wed, 19 Apr 2006 12:50:23 GMT
Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com
	[9.149.37.212])
	by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id
	k3JCp14M207224
	for <techspec@ietf.org>; Wed, 19 Apr 2006 13:51:03 +0100
Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1])
	by d06av01.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id
	k3JCoJFU014306
	for <techspec@ietf.org>; Wed, 19 Apr 2006 13:50:19 +0100
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232])
	by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id
	k3JCoJXQ014275; Wed, 19 Apr 2006 13:50:19 +0100
Received: from zurich.ibm.com (sig-9-145-255-62.de.ibm.com [9.145.255.62])
	by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA43048;
	Wed, 19 Apr 2006 14:50:17 +0200
Message-ID: <44463209.7070903@zurich.ibm.com>
Date: Wed, 19 Apr 2006 14:50:17 +0200
From: Brian E Carpenter <brc@zurich.ibm.com>
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 <john-ietf@jck.com>
Subject: Re: [Techspec] Final call before -07 version of mankin-pub-req
References: <4DCBC973AF0D6E4FAF9CD998CE1C003802822E65@eusrcmw720.	eamcs.ericsson.se>
	<E19FDF2C5E9FFFC651EC2C1D@p3.JCK.COM>
In-Reply-To: <E19FDF2C5E9FFFC651EC2C1D@p3.JCK.COM>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
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\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org

John C Klensin wrote:
...
> often".  I'd be much more comfortable with the idea if two
> additional things went with it:
> 
> (i) The proposal that a document will be fast-tracked in this
> way must appear as part of the Last Call announcement so that
> the community can comment on the necessity of doing that and on
> the editorial readiness for publication "as is" as well as on
> the technical substance of the document.  I would hope that we
> can trust the IESG to either bounce the document or drop the
> fast-track plan if there is significant negative feedback on
> expedited publication as-is, rather than trying to rewrite the
> document themselves.

I think this is a very reasonable requirement. It's
probably out of scope for techspec as such, since it's upstream
of when the draft is actually handed over for editing.

All it needs is one sentence in the Last Call text, and
any comments on that point would need to be considered
just like any other LC comment.
> 
> (ii) The decision to fast-track a document in this way must be
> appealable by any impacted party in the community including, if
> the document is judged unsatisfactory under our presumably-high
> publication quality, by the technical publisher themselves.

This seems to be guaranteed by the existing right of appeal
against IESG approvals, which is open to any individual.

      Brian

_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec



From techspec-bounces@ietf.org Wed Apr 19 15:57:21 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FWInc-0000eS-La; Wed, 19 Apr 2006 15:57:16 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FWInb-0000Ze-Et
	for techspec@ietf.org; Wed, 19 Apr 2006 15:57:15 -0400
Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWInb-0003ww-6u
	for techspec@ietf.org; Wed, 19 Apr 2006 15:57:15 -0400
Received: from [64.100.227.237] ([::ffff:64.100.227.237])
	(AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA)
	by zeke.ecotroph.net with esmtp; Wed, 19 Apr 2006 15:56:05 -0400
	id 0158812B.444695D7.000027AB
Message-ID: <4446960D.4070406@thinkingcat.com>
Date: Wed, 19 Apr 2006 15:57:01 -0400
From: Leslie Daigle <leslie@thinkingcat.com>
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: Brian E Carpenter <brc@zurich.ibm.com>
Subject: Re: [Techspec] Final call before -07 version of mankin-pub-req
References: <4DCBC973AF0D6E4FAF9CD998CE1C003802822E65@eusrcmw720.	eamcs.ericsson.se>	<E19FDF2C5E9FFFC651EC2C1D@p3.JCK.COM>
	<44463209.7070903@zurich.ibm.com>
In-Reply-To: <44463209.7070903@zurich.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
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\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org


Reading these comments prompted me to realize that I don't
agree with John's characterization of the requirement.

I don't believe the intent was that the "verbatim" requirement
was for "fast tracking".

I believe the intent was to be able to make it plain when the
text is the way it is for a reason and should not be messed
with:  as a chunk of a document (most likely) or a whole
document.  This may or may not produce a fast track.

Specific use cases:

	. "boilerplate" that's agreed on in an IETF working
	  group to apply to all instances of derivative
	  works (e.g., IANA registration documents, MIBs
	  etc)

	. text referring to other organizations' work -- which
	  has been carefully phrased and arranged with reps
	  of that other organization to deal with some
	  politically sensitive issue.


So -- if the current req reads like fast-tracking, IMO it
is wrong and needs to be fixed.

Which should blow out the requirement for LC announcement
meddling.

Leslie.



Brian E Carpenter wrote:
> John C Klensin wrote:
> ...
>> often".  I'd be much more comfortable with the idea if two
>> additional things went with it:
>>
>> (i) The proposal that a document will be fast-tracked in this
>> way must appear as part of the Last Call announcement so that
>> the community can comment on the necessity of doing that and on
>> the editorial readiness for publication "as is" as well as on
>> the technical substance of the document.  I would hope that we
>> can trust the IESG to either bounce the document or drop the
>> fast-track plan if there is significant negative feedback on
>> expedited publication as-is, rather than trying to rewrite the
>> document themselves.
> 
> I think this is a very reasonable requirement. It's
> probably out of scope for techspec as such, since it's upstream
> of when the draft is actually handed over for editing.
> 
> All it needs is one sentence in the Last Call text, and
> any comments on that point would need to be considered
> just like any other LC comment.
>>
>> (ii) The decision to fast-track a document in this way must be
>> appealable by any impacted party in the community including, if
>> the document is judged unsatisfactory under our presumably-high
>> publication quality, by the technical publisher themselves.
> 
> This seems to be guaranteed by the existing right of appeal
> against IESG approvals, which is open to any individual.
> 
>      Brian
> 
> _______________________________________________
> Techspec mailing list
> Techspec@ietf.org
> https://www1.ietf.org/mailman/listinfo/techspec
> 

_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec



From techspec-bounces@ietf.org Wed Apr 19 16:13:25 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FWJ3F-0004yZ-0F; Wed, 19 Apr 2006 16:13:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FWJ3E-0004yO-Ar
	for techspec@ietf.org; Wed, 19 Apr 2006 16:13:24 -0400
Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWJ3D-0005Qt-S8
	for techspec@ietf.org; Wed, 19 Apr 2006 16:13:24 -0400
Received: from [64.100.227.237] ([::ffff:64.100.227.237])
	(AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA)
	by zeke.ecotroph.net with esmtp; Wed, 19 Apr 2006 16:12:20 -0400
	id 01588110.444699A4.00002B00
Message-ID: <444699DC.4090509@thinkingcat.com>
Date: Wed, 19 Apr 2006 16:13:16 -0400
From: Leslie Daigle <leslie@thinkingcat.com>
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: Sandy Ginoza <ginoza@ISI.EDU>
Subject: Re: [Techspec] draft-mankin-pub-req-05.txt
References: <200604142216.k3EMGdM26147@boreas.isi.edu>
In-Reply-To: <200604142216.k3EMGdM26147@boreas.isi.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b
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\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org


I want to comment on one specific point:

Sandy wrote:
> - Section 3.3 state
> 	
>   o Potential Req-POSTEDIT-4 - The IETF Technical editor should
>     refrain from making changes to improve readability that may change
>     technical and consensus wording.
> 
> Do not make changes to improve readability??
> We often find errors in documents after any number of revisions and
> after the documents have been approved that require author/editor
> clarification, e.g., cut and paste errors, missing text.
> 
> 


The quoted requirement is not something that you can split
and interpret separately as you have done in your comment.

Yes, RFC Editor certainly routinely catches issues of readability,
greater and lesser.  AUTH48 is always (at least, for me :-) )
an exercise in learning how unclearly one writes ;-)   And,
there was a notable instance when the RFC Editor caught the fact
that my document had 2 non-sentences trailing at the end of
a section -- leftovers from previous edits.  I had not caught
that.  The IETF-wide last call had not caught that.  The IESG
review had not caught that.  Oops on all of us :-)

But.

"that may change technical ... wording" is key.  Too often
"clarity" breaks the intended meaning.

A simple sample, from my own experience:

ORIGINAL:
2.2.4  S-NAPTR and Successive Resolution


    As shown in the example NAPTR RR set above, it is possible to have
    multiple possible targets for a single application service+protocol
    pair.  These are to be pursued in order until a server is
    successfully contacted or all possible matching NAPTR records have
    been successively pursued to terminal lookups and servers contacted.
    That is, a client must backtrack and attempt other resolution paths
    in the case of failure.


AUTH-48:
2.2.4.  S-NAPTR and Successive Resolution

    As shown in the example set above, it is possible to have multiple
    possible targets for a single application service+protocol pair.
    These are to be pursued in order until a server is successfully
    contacted or all possible matching NAPTR records have been
    successively pursued to terminal lookups and contacted servers.  That
    is, a client must backtrack and attempt other resolution paths in the
    case of failure.


ISSUE:
The binding of "all" has failed, in rewriting "servers contacted"
to "contacted servers".

NEW:
2.2.4.  S-NAPTR and Successive Resolution

    As shown in the example set above, it is possible to have multiple
    possible targets for a single application service+protocol pair.
    These are to be pursued in order until a server is successfully
    contacted or all possible matching NAPTR records have been
    successively pursued through terminal lookup and server contact. That
    is, a client must backtrack and attempt other resolution paths in the
    case of failure.



Leslie.

Sandy Ginoza wrote:
> All,
> 
> I read through the tech spec document <draft-mankin-pub-req-05.txt> and
> have the comments below.  While these are based on my experiences
> working for the RFC Editor, the comments below are my personal comments
> and do not represent the views of RFC Editor function.
> 
> Thanks,
> 
> Sandy Ginoza
> 
> -----------------------------------------------------------------
> 
> - Section 3 states
> 
>    Based upon this information we derive requirements on the IETF
>    technical editor:
> 
>   6. Assignment of parameter values
> 
> This seems like incorrect phraseology (unless the functions are to be
> combined), as the publisher would insert the assigned values, not
> assign the values themselves.
> 
> 
> - Section 3.1 states
> 
>   In many cases the technical publisher may provide a review or
>   editing service to improve document quality prior to the approval of
>   a document.  This review process would normally address issues such
>   as grammar, spelling, formatting, adhrence to boilerplate, document 
>   structure, proper use of keywords (RFC 2119), etc.
> 
> Prior to document approval, the document has different boilerplate
> info.  The technical publisher is to check the boilerplate info of the
> ID?  Are these functions to be combined?
> 
> 
> 
> - Section 3.1 states
> 
>   Discussion: Pre-approval review is not part of the normal process
>   flow with the IETF but this concept has been explored with promising
>   results in the early copy editing experiment.
> 
> I think the results of the experiment are inconclusive.  Thus far, only
> one of six documents involved in this experiment has made it into the
> RFC Editor queue.  It did not enter the queue until just recently
> (maybe the week or two prior to IETF).  Alice has not yet reviewed the
> diffs (as it has not made it to the front of the queue), so we do not
> know whether the pre-editing has helped.
> 
> 
> - Section 3.3 states
> 
>   The ambition level for cleanup can vary from:
> 
>   o Corrections to errors only,
> 
>   ...
> 
>   o Rewriting of all documents to the dictates of a style manual
> 
> We attempt only to correct errors, and we try to ensure that all
> documents adhere to some form of grammar guide.  We try to make changes
> that improve clarity and make the document more consistent within
> itself, as well as across a document set.
> 
> 
> - Section 3.3 states
> 
>   At times in the past year, stylistic editing has resulted in 40-100
>   substantive changes in many documents.  These changes must then be
>   vetted by all the authors followed by subsequent rounds of author
>   acceptance and re-vetting.
> 
> I'm not sure what is considered a substantive change here, but
> sometimes 40-100 substantive changes in one document may be necessary.
> I believe this to be a very unusual case, and I am not sure if this
> takes into account instances for which, although we did not change the
> text correctly, the authors came back with a more clearly worded
> alternate?
> 
> Also, an average size RFC is roughly 30 pages.  Assuming a middle
> ground between the 40-100 changes gets us to an average of 70 changes
> per document, which means an average of 2.33 changes per page.  This is
> not a high rate of change considering the amount of work some of these
> documents require.
> 
> Furthermore, there are often a large number of changes requested by the
> authors themselves, many of which require AD review and approval.  Does
> this 40-100 number differentiate the RFC Editor induced and the
> author/wg chair/ad induced changes?
> 
> 
> - Section 3.3 state
> 	
>   o Potential Req-POSTEDIT-4 - The IETF Technical editor should
>     refrain from making changes to improve readability that may change
>     technical and consensus wording.
> 
> Do not make changes to improve readability??
> We often find errors in documents after any number of revisions and
> after the documents have been approved that require author/editor
> clarification, e.g., cut and paste errors, missing text.
> 
> 
> - Section 3.7 states
> 
>   o Potential Req-POSTCORR-3 - The IETF technical publisher should
>     have the discretion to reject post-approval corrections as too
>     late in the process and propose that it be handled as errata.
> 
> Errata maintenance will turn into an even bigger headache.  Why not
> just make the correction instead of going through the process of
> approving and posting an errata?
> 
> 
> - Section 3.15 discusses the maintenance of errata... 
> 
> Who verifies this errata?
> 
> 
> - Section 3.16 states
> 
>   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.  
> 
> Again, this sounds as though the RFC Editor and ID functions will be
> combined.  Or, does this just require that the technical publisher
> request that the ID repository not expire a draft?
> 
> 
> - Section 3.18 states
> 
>   Discussion: The RFC Editor does not maintain a document or database
>   of terms or acronyms.
> 
> This statement is untrue.  However, our main goal is to be consistent
> within a single document and across a set of documents.  If an author
> has used terminology inconsistently, we will update the text with our
> preferred usage.  If the author has already used the terminology
> consistenly, we will leave the terms unaltered (unless they go against
> some pre-specified usage, e.g., IPSEC would be changed to IPsec
> regardless of whether the author used IPSEC consistently throughout the
> document).
> 
> 
> 
> - Section 4 states
> 
>   Here are some metrics that could apply to the IETF technical
>   publisher.
> 
>   ...
> 
>   3. Non author changes generated during publication
> 
>   4. Author changes generated during publication
> 
> This does not take into account changes requested by those other than
> the editor and author.  For example, ADs and WG chairs.
> 
> 
> - Section 4.1 states
> 
>   o Potential Req-TIMEFRMAES-1 - The IETF technical publisher should
>     have a goal of an average publication time of no more than 4 weeks
>     and at least 90% of all documents should be published within 8
>     weeks. 
> 
> Does this time frame refer only to those documents that have been
> through the early copy edit phase or all documents in general?
> 
> 
> - Section 4.1 states
> 
>   o Potential Req-TIMEFRAMES-2 - For those documents for which early
>     allocation of an identifier is request, The IETF technical
>     publisher should have a goal of an average allocation time of no
>     more than 1 week and at least 90% of early allocation documents
>     should have a stable identifier allocated within 2 weeks of
>     approval.  ...
> 
>   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 10 days and at least 90% of all 
>     documents should be reviewed within 15 days.  ...
> 
> I guess since it says average, it's okay, but this does not take into
> consideration document size and other variables associated with
> document delay, such as the sudden influx of documents from the IESG
> secretariat. 
> 
> 
> - Section 4.3 states
> 
>   o Potential Req-EDITCHGSTATS-1 - The IETF technical publisher should
>     provide monthly statistics on the types of editorial corrections
>     being found during review as well as the percent of corrections
>     which are rejected by the authors.
> 
> This will require even more time spent on each document, as it will
> require stopping to make tally marks each time we mark a correction,
> or going through the document a second time to count and tally the
> marks inserted.  It will also require a third review of the document
> to tally the changes accepted/rejected by the authors.  For a process
> that is supposedly already too time consuming, this will make the
> process even more lengthy.  It will also require formal definitions of
> the varying types of errors that can be found, as often times, a
> correction cannot be classified as purely
> grammatical/editorial/technical. 
> 
> 
> - Section 5 states
> 
>   o Exception Handling: If publication timelines can be reduced
>     sufficiently or permanent identifiers allocated early, then
>     expedited handling may no longer be needed.
> 
> According to section 3.13, exception handling refers to the reasons a
> document can be withdrawn or put on hold.  The above seems to be
> refering to early allocation requests.
> 
> 
> 
> _______________________________________________
> 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 Apr 19 17:42:00 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FWKQt-0004os-8c; Wed, 19 Apr 2006 17:41:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FWKQs-0004on-3w
	for techspec@ietf.org; Wed, 19 Apr 2006 17:41:54 -0400
Received: from boreas.isi.edu ([128.9.160.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWKQr-0001Ub-Oj
	for techspec@ietf.org; Wed, 19 Apr 2006 17:41:54 -0400
Received: from gra.isi.edu (gra.isi.edu [128.9.160.133])
	by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k3JLf4C21623;
	Wed, 19 Apr 2006 14:41:04 -0700 (PDT)
From: Bob Braden <braden@ISI.EDU>
Received: (from braden@localhost) by gra.isi.edu (8.9.3/8.8.6) id OAA04241;
	Wed, 19 Apr 2006 14:41:02 -0700 (PDT)
Date: Wed, 19 Apr 2006 14:41:02 -0700 (PDT)
Message-Id: <200604192141.OAA04241@gra.isi.edu>
To: ginoza@ISI.EDU, leslie@thinkingcat.com
Subject: Re: [Techspec] draft-mankin-pub-req-05.txt
X-Sun-Charset: US-ASCII
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: braden@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
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\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org


Leslie,

You wrote:

 *> 
  *> 
  *> The quoted requirement is not something that you can split
  *> and interpret separately as you have done in your comment.
  *> 
  *> Yes, RFC Editor certainly routinely catches issues of readability,
  *> greater and lesser.  AUTH48 is always (at least, for me :-) )
  *> an exercise in learning how unclearly one writes ;-)   And,
  *> there was a notable instance when the RFC Editor caught the fact
  *> that my document had 2 non-sentences trailing at the end of
  *> a section -- leftovers from previous edits.  I had not caught
  *> that.  The IETF-wide last call had not caught that.  The IESG
  *> review had not caught that.  Oops on all of us :-)
  *> 
  *> But.
  *> 
  *> "that may change technical ... wording" is key.  Too often
  *> "clarity" breaks the intended meaning.
  *> 
  *> A simple sample, from my own experience:
  *> 
  *> ORIGINAL:
  *> 2.2.4  S-NAPTR and Successive Resolution
  *> 
  *> 
  *>     As shown in the example NAPTR RR set above, it is possible to have
  *>     multiple possible targets for a single application service+protocol
  *>     pair.  These are to be pursued in order until a server is
  *>     successfully contacted or all possible matching NAPTR records have
  *>     been successively pursued to terminal lookups and servers contacted.
  *>     That is, a client must backtrack and attempt other resolution paths
  *>     in the case of failure.
  *> 
  *> 
  *> AUTH-48:
  *> 2.2.4.  S-NAPTR and Successive Resolution
  *> 
  *>     As shown in the example set above, it is possible to have multiple
  *>     possible targets for a single application service+protocol pair.
  *>     These are to be pursued in order until a server is successfully
  *>     contacted or all possible matching NAPTR records have been
  *>     successively pursued to terminal lookups and contacted servers.  That
  *>     is, a client must backtrack and attempt other resolution paths in the
  *>     case of failure.
  *> 
  *> 
  *> ISSUE:
  *> The binding of "all" has failed, in rewriting "servers contacted"
  *> to "contacted servers".
  *> 
  *> NEW:
  *> 2.2.4.  S-NAPTR and Successive Resolution
  *> 
  *>     As shown in the example set above, it is possible to have multiple
  *>     possible targets for a single application service+protocol pair.
  *>     These are to be pursued in order until a server is successfully
  *>     contacted or all possible matching NAPTR records have been
  *>     successively pursued through terminal lookup and server contact. That
  *>     is, a client must backtrack and attempt other resolution paths in the
  *>     case of failure.
  *> 
  *> 


The original sentence did not make sense (to me), while your final
corrected sentence does make sense.  If we had not made the AUTH48
change, the original nonsensical sentence would have persisted.

I expected you to object to the removal to "NAPTR RR" from the first
sentence; I myself would agree that this removal was erroneous editing.

Bob Braden

_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec



From techspec-bounces@ietf.org Wed Apr 19 18:21:25 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FWL37-0001Fr-G7; Wed, 19 Apr 2006 18:21:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FWL36-0001Fm-RF
	for techspec@ietf.org; Wed, 19 Apr 2006 18:21:24 -0400
Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWL36-00031g-Gx
	for techspec@ietf.org; Wed, 19 Apr 2006 18:21:24 -0400
Received: from [192.168.0.101] ([::ffff:64.102.254.33])
	(AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA)
	by zeke.ecotroph.net with esmtp; Wed, 19 Apr 2006 18:20:20 -0400
	id 01588130.4446B7A4.00003EDD
Message-ID: <4446B7DC.4060800@thinkingcat.com>
Date: Wed, 19 Apr 2006 18:21:16 -0400
From: Leslie Daigle <leslie@thinkingcat.com>
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
MIME-Version: 1.0
To: Bob Braden <braden@ISI.EDU>
Subject: Re: [Techspec] draft-mankin-pub-req-05.txt
References: <200604192141.OAA04241@gra.isi.edu>
In-Reply-To: <200604192141.OAA04241@gra.isi.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610
Cc: ginoza@ISI.EDU, techspec@ietf.org
X-BeenThere: techspec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org



Bob Braden wrote:
 > I expected you to object to the removal to "NAPTR RR" from the first
 > sentence; I myself would agree that this removal was erroneous editing.

Hmmm... I feel an update to this spec coming on ;-)


 > The original sentence did not make sense (to me), while your final
 > corrected sentence does make sense.  If we had not made the AUTH48
 > change, the original nonsensical sentence would have persisted.


But only because I caught it -- or else it would have gone out
saying the wrong thing.

And given the choice between a *possibility* of being misunderstood
or having the document going out stating the wrong thing, albeit
with improved clarity -- well, there is a certain sense in the
community that the 1st option is the winning one.

Note that, for the first case, I, as author of the specification, must
bear responsibility.  The latter appears to happen due to some magical
force that has acted upon the text.


My very personal opinion:

I, as an author, read the AUTH48 diffs diligently.  It doesn't
always happen on all documents though, and the IETF doesn't have a clear
way of dealing with that in producing its specs.  Also, dealing with
these issues at the tail end of the process, in a blackbox,
depersonalized exchange with rfc-editor@rfc-editor.org is *stressful*
to authors.  "I place my changes upon the stone steps and hope they will
be accepted"...?!  Perhaps it's not a lot less stressful on the other
end of the exchange, either.

Note that I *fully* appreciate having issues in my text flagged.
My *personal* preference is to have editing happen earlier in the
process, and more interactively. "Hey, Leslie, I can't understand
what the HECK you're trying to say in this sentence; how about
this?".  Note that  I was not one of the authors/editors
who got to participate in the early editing experiment, but I really
am hopeful for integrating more of that sort of thing into our
overall process.

But, if we can't, the IETF needs to make a decision about
whether it will sacrifice potential clarity for possible error.

Here's another example from that same document/exchange.
Note that I'm not really convinced the final version was a lot
clearer, but it's what the RFC Editor put in the document.  I
kinda was left wondering if I'd won the point or the RFC Editor
gave up arguing with this pesky author.

> AUTH-48:
> 6.3.  Expected Output
> 
>    The expected output of this application is the information necessary
>    for an application service within a given domain to connect to
>    authoritative server(s) (host, port, protocol).
> 
> 
> ORIGINAL:
> 6.3  Expected Output
> 
>    The expected output of this Application is the information necessary
>    to connect to authoritative server(s) (host, port, protocol) for an
>    application service within a given a given domain.
> 
> 
> ISSUES:
> First, the "Application" refers specifically to a DDDS Application, not
> to any random generic application.  Therefore, here (and in the several
> other places you've changed "Application" to "application"), it
> should either revert to "Application", or be changed to "DDDS
> Application".
> 
> More importantly, for this paragraph -- the meaning has been completely
> changed.  The original described [a little-a application] connecting to
> an authoritative server within a domain.  The AUTH-48 describes an
> authoritative server connecting to a server within a domain, which
> is nonsense.  If the rewrite below seems complex & tortuous -- well,
> I don't think it's a language problem, it's just what this stuff is.
> 
> NEW:
> 6.3  Expected Output
> 
>    The expected output of this Application is the information necessary
>    for a client to connect to authoritative server(s) (host, port,
> protocol) for a particular
>    application service within a given domain. 




Leslie.

> Leslie,
> 
> You wrote:
> 
>  *> 
>   *> 
>   *> The quoted requirement is not something that you can split
>   *> and interpret separately as you have done in your comment.
>   *> 
>   *> Yes, RFC Editor certainly routinely catches issues of readability,
>   *> greater and lesser.  AUTH48 is always (at least, for me :-) )
>   *> an exercise in learning how unclearly one writes ;-)   And,
>   *> there was a notable instance when the RFC Editor caught the fact
>   *> that my document had 2 non-sentences trailing at the end of
>   *> a section -- leftovers from previous edits.  I had not caught
>   *> that.  The IETF-wide last call had not caught that.  The IESG
>   *> review had not caught that.  Oops on all of us :-)
>   *> 
>   *> But.
>   *> 
>   *> "that may change technical ... wording" is key.  Too often
>   *> "clarity" breaks the intended meaning.
>   *> 
>   *> A simple sample, from my own experience:
>   *> 
>   *> ORIGINAL:
>   *> 2.2.4  S-NAPTR and Successive Resolution
>   *> 
>   *> 
>   *>     As shown in the example NAPTR RR set above, it is possible to have
>   *>     multiple possible targets for a single application service+protocol
>   *>     pair.  These are to be pursued in order until a server is
>   *>     successfully contacted or all possible matching NAPTR records have
>   *>     been successively pursued to terminal lookups and servers contacted.
>   *>     That is, a client must backtrack and attempt other resolution paths
>   *>     in the case of failure.
>   *> 
>   *> 
>   *> AUTH-48:
>   *> 2.2.4.  S-NAPTR and Successive Resolution
>   *> 
>   *>     As shown in the example set above, it is possible to have multiple
>   *>     possible targets for a single application service+protocol pair.
>   *>     These are to be pursued in order until a server is successfully
>   *>     contacted or all possible matching NAPTR records have been
>   *>     successively pursued to terminal lookups and contacted servers.  That
>   *>     is, a client must backtrack and attempt other resolution paths in the
>   *>     case of failure.
>   *> 
>   *> 
>   *> ISSUE:
>   *> The binding of "all" has failed, in rewriting "servers contacted"
>   *> to "contacted servers".
>   *> 
>   *> NEW:
>   *> 2.2.4.  S-NAPTR and Successive Resolution
>   *> 
>   *>     As shown in the example set above, it is possible to have multiple
>   *>     possible targets for a single application service+protocol pair.
>   *>     These are to be pursued in order until a server is successfully
>   *>     contacted or all possible matching NAPTR records have been
>   *>     successively pursued through terminal lookup and server contact. That
>   *>     is, a client must backtrack and attempt other resolution paths in the
>   *>     case of failure.
>   *> 
>   *> 
> 
> 
> The original sentence did not make sense (to me), while your final
> corrected sentence does make sense.  If we had not made the AUTH48
> change, the original nonsensical sentence would have persisted.
> 
> I expected you to object to the removal to "NAPTR RR" from the first
> sentence; I myself would agree that this removal was erroneous editing.
> 
> Bob Braden
> 

_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec



From techspec-bounces@ietf.org Wed Apr 19 19:17:10 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FWLv2-0008Pr-1A; Wed, 19 Apr 2006 19:17:08 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FWLv0-0008Pm-Kz
	for techspec@ietf.org; Wed, 19 Apr 2006 19:17:06 -0400
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWLv0-0005yl-96
	for techspec@ietf.org; Wed, 19 Apr 2006 19:17:06 -0400
Received: from [127.0.0.1] (helo=p3.JCK.COM)
	by bs.jck.com with esmtp (Exim 4.34)
	id 1FWLup-0009ia-Fr; Wed, 19 Apr 2006 19:16:55 -0400
Date: Wed, 19 Apr 2006 19:16:54 -0400
From: John C Klensin <john-ietf@jck.com>
To: Leslie Daigle <leslie@thinkingcat.com>,
	Brian E Carpenter <brc@zurich.ibm.com>
Subject: Verbatim requirement (was: Re: [Techspec] Final call
	before -07 version of mankin-pub-req)
Message-ID: <183F1F2719D5C094B080D5A6@p3.JCK.COM>
In-Reply-To: <4446960D.4070406@thinkingcat.com>
References: <4DCBC973AF0D6E4FAF9CD998CE1C003802822E65@eusrcmw720.	
	eamcs.ericsson.se>	<E19FDF2C5E9FFFC651EC2C1D@p3.JCK.COM>
	<44463209.7070903@zurich.ibm.com>
	<4446960D.4070406@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: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
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\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org



--On Wednesday, 19 April, 2006 15:57 -0400 Leslie Daigle
<leslie@thinkingcat.com> wrote:

> 
> Reading these comments prompted me to realize that I don't
> agree with John's characterization of the requirement.
> 
> I don't believe the intent was that the "verbatim" requirement
> was for "fast tracking".
> 
> I believe the intent was to be able to make it plain when the
> text is the way it is for a reason and should not be messed
> with:  as a chunk of a document (most likely) or a whole
> document.  This may or may not produce a fast track.

That the suggested requirement can be applied only to a chunk of
a document is also not clear, at least to me, nor is it clear
how the IESG (or whomever) would designate such a thing.

> Specific use cases:
> 
> 	. "boilerplate" that's agreed on in an IETF working
> 	  group to apply to all instances of derivative
> 	  works (e.g., IANA registration documents, MIBs
> 	  etc)
> 
> 	. text referring to other organizations' work -- which
> 	  has been carefully phrased and arranged with reps
> 	  of that other organization to deal with some
> 	  politically sensitive issue.

These two examples seem perfectly sensible, especially since
both imply other, and serious, efforts to get the text exactly
right.  And both generally require approval of that specific
text in the IETF community.  The "LC announcement" requirement
would presumably be applied at that point, with it being made
clear to the IETF community that the text was intended to be
used verbatim.   Of course, we do not generally Last Call
agreements with other organizations, but the level of scrutiny
is typically similar.

> So -- if the current req reads like fast-tracking, IMO it
> is wrong and needs to be fixed.
> 
> Which should blow out the requirement for LC announcement
> meddling.

See above.  I don't think it blows it out (or away), but that it
moves it to a much different point in the process.

      john



_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec



From techspec-bounces@ietf.org Thu Apr 20 07:16:50 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FWX9V-0008VJ-Rx; Thu, 20 Apr 2006 07:16:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FWX9D-0008MP-IV
	for techspec@ietf.org; Thu, 20 Apr 2006 07:16:31 -0400
Received: from zeke.ecotroph.net ([69.31.8.124])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWX9C-0000JI-9W
	for techspec@ietf.org; Thu, 20 Apr 2006 07:16:31 -0400
Received: from [192.168.0.104] ([::ffff:24.54.213.214])
	(AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA)
	by zeke.ecotroph.net with esmtp; Thu, 20 Apr 2006 07:15:26 -0400
	id 01588110.44476D4E.000044A2
Message-ID: <44476DA7.1070501@thinkingcat.com>
Date: Thu, 20 Apr 2006 07:16:55 -0400
From: Leslie Daigle <leslie@thinkingcat.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: techspec@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Subject: [Techspec] Apologies
X-BeenThere: techspec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)"
	<techspec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/techspec>
List-Post: <mailto:techspec@ietf.org>
List-Help: <mailto:techspec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/techspec>,
	<mailto:techspec-request@ietf.org?subject=subscribe>
Errors-To: techspec-bounces@ietf.org


I woke up this morning and realized that I owe the
RFC Editor, and this list, a pretty big apology!

My quoting examples of AUTH48 exchanges that I have
had could perhaps be construed as picking on the RFC Editor
  -- which is not helpful, and something I have
said is quite out of scope.

Of course, I truly did not *intend* them as such; I was
focused on providing concrete examples of how
editing doesn't always work out the way one expects.

But, irrespective of intentions, what came out was wrong.

So -- my sincere apologies to the RFC Editor for
any offense, and to this list for having slipped
out of bounds.

Leslie.

_______________________________________________
Techspec mailing list
Techspec@ietf.org
https://www1.ietf.org/mailman/listinfo/techspec