From techspec-bounces@ietf.org Wed Mar 01 03:37:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEMpg-0001AL-OS; Wed, 01 Mar 2006 03:37:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEMpg-0001AG-29 for techspec@ietf.org; Wed, 01 Mar 2006 03:37:16 -0500 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEMpe-0003NE-KP for techspec@ietf.org; Wed, 01 Mar 2006 03:37:16 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id k218b8Qk082872 for ; Wed, 1 Mar 2006 08:37:08 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k218bO7S227838 for ; Wed, 1 Mar 2006 09:37:24 +0100 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k218b8Wr030871 for ; Wed, 1 Mar 2006 09:37:08 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k218b7Kc030854; Wed, 1 Mar 2006 09:37:07 +0100 Received: from zurich.ibm.com (sig-9-146-216-66.de.ibm.com [9.146.216.66]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA66102; Wed, 1 Mar 2006 09:37:06 +0100 Message-ID: <44055D2F.7080203@zurich.ibm.com> Date: Wed, 01 Mar 2006 09:37:03 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Pekka Savola Subject: Re: [Techspec] New requirement for early permanent ID allocation References: <7D5D48D2CAA3D84C813F5B154F43B1550967B44D@nl0006exch001u.nl.lucent.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Paul Hoffman , techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org Pekka Savola wrote: > On Thu, 23 Feb 2006, Wijnen, Bert (Bert) wrote: > >> Let me (repeat) state that my opinion is that we SHOULD be able >> to achieve RFC-publication within 2 months (or less) after >> IESG approval. And if we can achieve that, then I maintain >> that early stable references is farr less of a problem (if at all). >> >> Just my personal opinion of course. >> >> I would rather work on trying to get to a fast-publication-after-approval >> than thinking of stop-ga[p measures to deal with too-slow-publication. > > > FWIW, I agree completely. If you add fast-tracking to this, we should > already have enough tools to allow fast document publication in general, > and even faster when required. That is all true. But I don't believe that the permanent identifier issue is a big deal. In fact, I bet you that today the RFC number is internally assigned pretty much as soon as a draft gets in the publication queue. The question is when it gets published, and that is something we can choose quite independently of everything else. I think it's important that the IETF states a requirement that this publication occurs when we need it to occur. Brian _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Mar 01 03:40:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEMtC-0006Xm-R2; Wed, 01 Mar 2006 03:40:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEMtC-0006Vc-6G for techspec@ietf.org; Wed, 01 Mar 2006 03:40:54 -0500 Received: from mtagate1.uk.ibm.com ([195.212.29.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEMtA-0003R7-LH for techspec@ietf.org; Wed, 01 Mar 2006 03:40:54 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k218epnk149070 for ; Wed, 1 Mar 2006 08:40:51 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k218f33n200652 for ; Wed, 1 Mar 2006 08:41:03 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id k218ephi028205 for ; Wed, 1 Mar 2006 08:40:51 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id k218eo5W028188; Wed, 1 Mar 2006 08:40:50 GMT Received: from zurich.ibm.com (sig-9-146-216-66.de.ibm.com [9.146.216.66]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA66214; Wed, 1 Mar 2006 09:40:49 +0100 Message-ID: <44055E13.6070006@zurich.ibm.com> Date: Wed, 01 Mar 2006 09:40:51 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: John C Klensin Subject: Re: [Techspec] New requirement for early permanent ID allocation References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org I think we're at risk of confusing two identifiers: RFC 9999 and STD 999. As I've just said on the newtrk list, I think John is on the right track for STD 999 type identifiers. But I took this requirement to refer to RFC 9999 type identifiers. As Humpty Dumpty would explain better than me, they're different. Bria John C Klensin wrote: > On 23 February, 2006 10:04 -0500, I wrote (text deleted from > the earlier note marked with "[...]")... > > ------- Earlier note ---------- > > Two (separable) comments/issues and an aside... > > --On Wednesday, 22 February, 2006 17:18 -0600 "Stephen Hayes > (TX/EUS)" wrote: > > >>Early permanent ID allocation is not something currently done >>in the IETF. Although there is already a potential >>requirement to do this, implementing it will imply yet another >>new potential requirement on the technical publisher. >> >>o Potential Req-INDEX-7 - When an permanent ID is allocated >>early, the technical publisher must provide a disclaimer and >>pointer in the index to resolve searches on that permanent ID. >>The post approval version of the draft must be stored until >>the document is published since it could expire before >>publication. > > > [...] > > The relevance of the Identifier, how it is assigned, etc., is a > current NEWTRK work item, embedded significantly in the "ISD" > work and somewhat so in the "SRD" work. Both would provide > alternate models to needing more disclaimers that, based on > historical experience, would probably be generally ignored. > Until and unless NEWTRK is terminated and a plausible > disposition made of its outstanding tasks, it seems > inappropriate to me for this non-chartered effort to reach > conclusions in this area other than, possibly, to make > recommendations to NEWTRK. > > [...] > > >>It is also recommended that the technical publisher retains >>control of the allocation of permanent identifiers. This is >>especially true when multiple organizations (IESG, IAB, IRTF) >>share a single identifier sequence. One way that this might >>work is for the IESG to request "publication" or "publication >>with early allocation" > > > Please separate this into a separate issue. To the extent to > which we are going to maintain multiple sets of numbers, some of > which apply to subsets of the others, the standards-track > reference ID (currently STD, but its assignment only to Full > Standards is another NEWTRK issue) and other reference IDs > should arguably be controlled directly by some IASA-associated > entity or contractor that is different from the technical > publisher. I understand this effort to be defining a "technical > publisher" role. If that role is to be one of a publisher, > rather than having broader standards-management functions, then > we had better be _very_ careful about what the IDs are and who > assigns them. > > And, again, who assigns the identifier is a very different issue > from when that identifier is assigned. > > [...] > > --- End of earlier note ---- > > In the interest of stimulating discussion where it belongs, I > have just queued an I-D titled "Identifying Standards Track > Documents", > draft-ietf-newtrk-docid-00.txt, that addresses these issues and > provides for assignment of stable identifiers for > standards-track documents not later than the Protocol Action for > Proposed Standard. Because this is a simple issue and a simple > proposal, the I-D violates what most consider to be my usual > practice: exclusive of front and back matter, it is > significantly under four pages long. > > I have written the proposal up as a change, not a process > experiment. It occurs to me that, were a different Standards > Identifier prefix chosen, it could be structured as a process > experiment if people wanted to do that. I'll leave that for > discussion in NEWTRK or elsewhere (and this comment will be more > clear after one reads the draft). > > john > > > _______________________________________________ > Techspec mailing list > Techspec@ietf.org > https://www1.ietf.org/mailman/listinfo/techspec > _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Mar 01 08:34:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FERTi-00047J-V4; Wed, 01 Mar 2006 08:34:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FERTh-00045n-N1 for techspec@ietf.org; Wed, 01 Mar 2006 08:34:53 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FERTh-0005nH-8c for techspec@ietf.org; Wed, 01 Mar 2006 08:34:53 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1FERTa-000H40-8l; Wed, 01 Mar 2006 08:34:46 -0500 Date: Wed, 01 Mar 2006 08:34:45 -0500 From: John C Klensin To: Brian E Carpenter Subject: Re: [Techspec] New requirement for early permanent ID allocation Message-ID: <271FA60BC49B6582BE7D1246@p3.JCK.COM> In-Reply-To: <44055E13.6070006@zurich.ibm.com> References: <44055E13.6070006@zurich.ibm.com> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org --On Wednesday, 01 March, 2006 09:40 +0100 Brian E Carpenter wrote: > I think we're at risk of confusing two identifiers: > RFC 9999 and STD 999. > > As I've just said on the newtrk list, I think John is on the > right track for STD 999 type identifiers. But I took this > requirement to refer to RFC 9999 type identifiers. As Humpty > Dumpty would explain better than me, they're different. I have made a leap here, which I clearly should have been more explicit about. My apologies. Explanation: I'm trying to look at Techspec through a "figure out what the problem is and then how to solve it" perspective rather that a "how to tune what we are doing now" one. We've been repeatedly encouraged to do that. So I read the description of this issue/ requirement, saw what "permanent IDs", especially early ones, were for, and got "these are identifiers of the _standards_, not identifiers of the documents". Now, if one wants to identify the standards, then the right target is, IMO, offspring-of-STD and not a serial document number (which the RFC 9999 numbers ultimately are). And it appears to me that we need those stable standards-reference numbers (or standardized acronyms, or whatever we use -- another newtrk topic) regardless of what we do about the multi-step standards model, i.e., * If we keep the present system, we need to get stable standards-references assigned at Proposed (or earlier) because few things go to Internet Standard and those that do take a long time. * If we drop the number of maturity levels to two or one, we will still need a way to assign stable standards-reference numbers because of publication lag (even if it is short) and because we revise standards. * And, if we develop a way to fast-track Internet Standards on the basis of market acceptance, there is still a significant lag time while that market acceptance and experience develops and we therefore still need standards-reference numbers early on. For the purposes of any of those references, especially by other groups, assignment of serial document numbers is (or should be) largely irrelevant. The fact that we have been using them as standards-identifiers and are talking about assigning them early is, to me, more a sign that our standards-identifier system --i.e., the STD numbers-- is broken and needs to be fixed, not that we need to devise a new system for serial document numbers. john _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Mar 01 09:16:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FES7e-0003he-4K; Wed, 01 Mar 2006 09:16:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FES7c-0003hV-O8 for techspec@ietf.org; Wed, 01 Mar 2006 09:16:08 -0500 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FES7c-0007Jv-9c for techspec@ietf.org; Wed, 01 Mar 2006 09:16:08 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id k21EG7Qk205982 for ; Wed, 1 Mar 2006 14:16:07 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 k21EGN7S205292 for ; Wed, 1 Mar 2006 15:16:23 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k21EG6PD023662 for ; Wed, 1 Mar 2006 15:16:07 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k21EG6Ku023642; Wed, 1 Mar 2006 15:16:06 +0100 Received: from zurich.ibm.com (sig-9-145-249-23.de.ibm.com [9.145.249.23]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA42042; Wed, 1 Mar 2006 15:16:05 +0100 Message-ID: <4405ACA5.3060706@zurich.ibm.com> Date: Wed, 01 Mar 2006 15:16:05 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: "Stephen Hayes (TX/EUS)" Subject: Re: [Techspec] Summary of pub-req scope discussions and proposals References: <4DCBC973AF0D6E4FAF9CD998CE1C00380206B898@eusrcmw720.eamcs.ericsson.se> In-Reply-To: <4DCBC973AF0D6E4FAF9CD998CE1C00380206B898@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: 7aafa0432175920a4b3e118e16c5cb64 Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org Stephen Hayes (TX/EUS) wrote: > The issue being discussed is whether the mankin-pub-req draft ... > It is recommended that: > 1. The scope of pub-req be clarified > to indicate that it applies to documents within the IETF > family including IETF documents processed by the IESG, IAB > documents processed by the IETF, and IRTF documents processed > by the IRTF (other wording happily accepted). IAB documents are generally reviewed by the community but they don't go through formal IESG review (unless they are BCPs); the IAB self-approves them. So I think you should simply say "IAB documents,..." I think for IRTF documents it would be more appropriate to say "IRTF documents processed by the IRSG." Brian > > 2. Ensure that these organizations which use the technical > publisher service have the opportunity to review > mankin-pub-req so that it represents the consensus of the > IETF family. > > 3. Modify section 5 to indicate that processes for working > with and feeding documents into the technical publisher needs > to be developed in the respective organizations, however > indicate that this will be documented in companion documents > which can be generated by the respective organizations. > > 4. Processes for arbitrating between competing resource > requests by organizations within the IETF family needs to be > dealt with, but mankin-pub-req does not seem like an > appropriate place for documenting the priorities. So this > would not be covered in mankin-pub-req. > > Regards, Stephen > > > > > > > > _______________________________________________ Techspec > mailing list Techspec@ietf.org > https://www1.ietf.org/mailman/listinfo/techspec > _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Mar 01 13:24:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEVzl-0002Gh-PN; Wed, 01 Mar 2006 13:24:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEVzk-0002Dv-Fe for techspec@ietf.org; Wed, 01 Mar 2006 13:24:16 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEVzh-0001GX-4U for techspec@ietf.org; Wed, 01 Mar 2006 13:24:16 -0500 Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k21IO9UA083039 for ; Wed, 1 Mar 2006 11:24:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <271FA60BC49B6582BE7D1246@p3.JCK.COM> References: <44055E13.6070006@zurich.ibm.com> <271FA60BC49B6582BE7D1246@p3.JCK.COM> Date: Wed, 1 Mar 2006 10:24:09 -0800 To: techspec@ietf.org From: Paul Hoffman Subject: Re: [Techspec] New requirement for early permanent ID allocation Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org At 8:34 AM -0500 3/1/06, John C Klensin wrote: >So I read the >description of this issue/ requirement, saw what "permanent >IDs", especially early ones, were for, and got "these are >identifiers of the _standards_, not identifiers of the >documents". Another way to say this is that we are required to have a naming system for documents, and are required to have a naming system for standards. Documents that are not standards will have a name only in the first, while documents that are standards will have a name in both. From the Techspec perspective, there is not a requirement for how the naming system for standards is organized, nor when the names in the naming system for standards are allocated. IESGers: do the external bodies who want permanent identifiers need all of the identifiers that will be associated with the document (the document naming system *and* the standards naming system), or just a document identifier? --Paul Hoffman, Director --VPN Consortium _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Mar 01 14:30:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEX1o-0008Rg-QR; Wed, 01 Mar 2006 14:30:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEX1n-0008R5-Bd for techspec@ietf.org; Wed, 01 Mar 2006 14:30:27 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEX1n-0004Av-03 for techspec@ietf.org; Wed, 01 Mar 2006 14:30:27 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1FEX1m-000Hcj-9W; Wed, 01 Mar 2006 14:30:26 -0500 Date: Wed, 01 Mar 2006 14:30:25 -0500 From: John C Klensin To: Paul Hoffman , techspec@ietf.org Subject: Re: [Techspec] New requirement for early permanent ID allocation Message-ID: <304B22A3CA4C23D05C232FE6@p3.JCK.COM> In-Reply-To: References: <44055E13.6070006@zurich.ibm.com> <271FA60BC49B6582BE7D1246@p3.JCK.COM> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org --On Wednesday, 01 March, 2006 10:24 -0800 Paul Hoffman wrote: > At 8:34 AM -0500 3/1/06, John C Klensin wrote: >> So I read the >> description of this issue/ requirement, saw what "permanent >> IDs", especially early ones, were for, and got "these are >> identifiers of the _standards_, not identifiers of the >> documents". > > Another way to say this is that we are required to have a > naming system for documents, and are required to have a naming > system for standards. Documents that are not standards will > have a name only in the first, while documents that are > standards will have a name in both. That description makes me vaguely uncomfortable for some reason, but I don't find anything in it with which I disagree. > From the Techspec perspective, there is not a requirement for > how the naming system for standards is organized, nor when the > names in the naming system for standards are allocated. Agreed. That is why I suggested in an earlier note that this was a Newtrk issue. > IESGers: do the external bodies who want permanent identifiers > need all of the identifiers that will be associated with the > document (the document naming system *and* the standards > naming system), or just a document identifier? Having been in the liaison loop to one or two of them, here is where I think we get hung up. What we have effectively told them is that there is no standards-identifier until very late in the process (years or never) and, consequently, if they need something to reference for standards they have under development, it is the document identifier. In the current system, that would be the case even if 2026 were being followed scrupulously and every Proposed Standard that we were not going to discard was published at Internet Standard within 10 to 11 months. The result is that they are asking for document identifiers. I suggest that is profoundly broken and that the solution is not earlier assignment, or other juggling, of document identifiers. john _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Mar 01 14:40:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEXBJ-0003Rw-2G; Wed, 01 Mar 2006 14:40:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEXBH-0003Q7-KA for techspec@ietf.org; Wed, 01 Mar 2006 14:40:15 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEXBD-0004pw-8D for techspec@ietf.org; Wed, 01 Mar 2006 14:40:15 -0500 Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id k21JlU1N020794; Wed, 1 Mar 2006 13:47:30 -0600 Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72) id ; Wed, 1 Mar 2006 13:40:10 -0600 Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C0038021C982F@eusrcmw720.eamcs.ericsson.se> From: "Stephen Hayes (TX/EUS)" To: Paul Hoffman , techspec@ietf.org Subject: RE: [Techspec] New requirement for early permanent ID allocation Date: Wed, 1 Mar 2006 13:40:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org I think we are in agreement, but I want to make sure. Stephen Hayes > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] > Sent: Wednesday, March 01, 2006 12:24 PM > To: techspec@ietf.org > Subject: Re: [Techspec] New requirement for early permanent ID > allocation > > > At 8:34 AM -0500 3/1/06, John C Klensin wrote: > >So I read the > >description of this issue/ requirement, saw what "permanent > >IDs", especially early ones, were for, and got "these are > >identifiers of the _standards_, not identifiers of the > >documents". > > Another way to say this is that we are required to have a naming > system for documents, and are required to have a naming system for > standards. Documents that are not standards will have a name only in > the first, while documents that are standards will have a name in > both. > pub-req is intended to address identifiers for documents that pass through the IETF publication process. I guess even given John's taxonomy of standards, there are some which will fall outside of the categories listed. Whatever identifers are agreed upon, they will be publicly visible. This means that the technical publisher (who I assume maintains the index) will need to provide lookup based upon those identifiers. > From the Techspec perspective, there is not a requirement > for how the > naming system for standards is organized, nor when the names in the > naming system for standards are allocated. Agree. In pub-req we have tried not to make too many assumptions: - It does not assume the documents are standards - It does not preclude multiple identifiers being associated with a published document. - It does not make any assumptions on the format of the identifier(s) - It does not assume that the IETF publication process has exclusive ownership of an identifier series other than the uniqueness requirement (read: independent submissions) > > IESGers: do the external bodies who want permanent identifiers need > all of the identifiers that will be associated with the document (the > document naming system *and* the standards naming system), or just a > document identifier? > Not an IESGer, but 99% of the references I have seen are to RFC numbers. I don't think external bodies care particularly what the identifier is as long as it is permanent and stable. I know this is true for 3GPP. Many of the references may be to non-standards track documents. Also note that when the term "stable" is used in relation to "permanent and stable identifiers" this is referring to being able to the stability of the document reference, not to the stability or maturity of the protocol or standard itself. If the IESG wants to "encourage" external bodies to preferentially cite one class of identifiers over another, that is an issue outside of techpub. As long as an identifier is externally visible, the publisher must be able to resolve it in the index. > --Paul Hoffman, Director > --VPN Consortium > > _______________________________________________ > Techspec mailing list > Techspec@ietf.org > https://www1.ietf.org/mailman/listinfo/techspec > _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Mar 01 22:34:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEeab-0003yq-WE; Wed, 01 Mar 2006 22:34:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEeaa-0003yJ-Eo for techspec@ietf.org; Wed, 01 Mar 2006 22:34:52 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEeaZ-0007bW-5S for techspec@ietf.org; Wed, 01 Mar 2006 22:34:52 -0500 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 k223YoUK024883; Wed, 1 Mar 2006 21:34:50 -0600 Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72) id ; Wed, 1 Mar 2006 21:34:50 -0600 Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C0038021C99E9@eusrcmw720.eamcs.ericsson.se> From: "Stephen Hayes (TX/EUS)" To: Brian E Carpenter Subject: RE: [Techspec] Summary of pub-req scope discussions and proposals Date: Wed, 1 Mar 2006 21:34:46 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org > > > 1. The scope of pub-req be clarified > > to indicate that it applies to documents within the IETF > > family including IETF documents processed by the IESG, IAB > > documents processed by the IETF, and IRTF documents processed > > by the IRTF (other wording happily accepted). > > IAB documents are generally reviewed by the community but > they don't go through formal IESG review (unless they > are BCPs); the IAB self-approves them. So I think you should > simply say "IAB documents,..." > > I think for IRTF documents it would be more appropriate to > say "IRTF documents processed by the IRSG." > I am happy to use the proposed wording. Stephen _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Mar 01 22:38:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEee8-0003VF-AE; Wed, 01 Mar 2006 22:38:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEee7-0003Rz-2I for techspec@ietf.org; Wed, 01 Mar 2006 22:38:31 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEee6-0007mc-Pi for techspec@ietf.org; Wed, 01 Mar 2006 22:38:31 -0500 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 k223cUP9025125 for ; Wed, 1 Mar 2006 21:38:30 -0600 Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72) id ; Wed, 1 Mar 2006 21:38:30 -0600 Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C0038021C99EC@eusrcmw720.eamcs.ericsson.se> From: "Stephen Hayes (TX/EUS)" To: techspec@ietf.org Date: Wed, 1 Mar 2006 21:38:25 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Techspec] Issue poll for 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org My intention is to produce a new draft of pub-req on Friday (March 3rd) preceeding the publication deadline (I am leaving for China on the 4th so can't wait until the very last minute). I will incorporate the various improvements and corrections discussed on the list so far. As far as I can tell the only controversial issue we have left is whether or not to have early permanent id allocation. Please let me know any other concerns by Friday morning so I can include them in the next version. Thanks, Stephen _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Thu Mar 02 05:54:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FElRa-00058F-I2; Thu, 02 Mar 2006 05:54:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FElRZ-00058A-6x for techspec@ietf.org; Thu, 02 Mar 2006 05:54:01 -0500 Received: from mtagate4.uk.ibm.com ([195.212.29.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FElRX-0000Xs-Nh for techspec@ietf.org; Thu, 02 Mar 2006 05:54:01 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k22Arvl6037228 for ; Thu, 2 Mar 2006 10:53:57 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 k22As9Vw218368 for ; Thu, 2 Mar 2006 10:54:09 GMT Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id k22Arvww024888 for ; Thu, 2 Mar 2006 10:53:57 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id k22Arufi024867; Thu, 2 Mar 2006 10:53:56 GMT Received: from zurich.ibm.com (sig-9-145-249-16.de.ibm.com [9.145.249.16]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA63230; Thu, 2 Mar 2006 11:53:55 +0100 Message-ID: <4406CEC5.1080208@zurich.ibm.com> Date: Thu, 02 Mar 2006 11:53:57 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: John C Klensin Subject: Re: [Techspec] New requirement for early permanent ID allocation References: <44055E13.6070006@zurich.ibm.com> <271FA60BC49B6582BE7D1246@p3.JCK.COM> <304B22A3CA4C23D05C232FE6@p3.JCK.COM> In-Reply-To: <304B22A3CA4C23D05C232FE6@p3.JCK.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Paul Hoffman , techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org John C Klensin wrote: > > --On Wednesday, 01 March, 2006 10:24 -0800 Paul Hoffman > wrote: ... >>IESGers: do the external bodies who want permanent identifiers >>need all of the identifiers that will be associated with the >>document (the document naming system *and* the standards >>naming system), or just a document identifier? > > > Having been in the liaison loop to one or two of them, here is > where I think we get hung up. What we have effectively told > them is that there is no standards-identifier until very late in > the process (years or never) and, consequently, if they need > something to reference for standards they have under > development, it is the document identifier. In the current > system, that would be the case even if 2026 were being followed > scrupulously and every Proposed Standard that we were not going > to discard was published at Internet Standard within 10 to 11 > months. The result is that they are asking for document > identifiers. I suggest that is profoundly broken and that the > solution is not earlier assignment, or other juggling, of > document identifiers. As Stephen wrote, what they *use* is the RFC number. I think that's because we've trained them that RFCs never change, so they are excellent stable references (much better than some things we refer to very loosely sometimes, such as "ASN.1" or "Unicode", whatever they may be.) What they may well want is STD-999.ps, but we haven't ever offered them that. (This terminology refers to draft-ietf-newtrk-docid). Brian _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Thu Mar 02 17:01:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEvqy-0006oi-Dk; Thu, 02 Mar 2006 17:00:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEvqw-0006o6-Sq for techspec@ietf.org; Thu, 02 Mar 2006 17:00:54 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEvqw-0007Lt-H1 for techspec@ietf.org; Thu, 02 Mar 2006 17:00:54 -0500 Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k22M0r1H012253 for ; Thu, 2 Mar 2006 15:00:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 2 Mar 2006 14:00:50 -0800 To: techspec@ietf.org From: Internet-Drafts@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.2 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [Techspec] I-D ACTION:draft-irtf-rfcs-00.txt X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IRTF Research Group RFCs Author(s) : A. Falk Filename : draft-irtf-rfcs-00.txt Pages : 11 Date : 2006-3-2 This document describes a process for research groups in the Internet Research Task Force to publish RFCs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-irtf-rfcs-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-irtf-rfcs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-irtf-rfcs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. [The following attachment must be fetched by mail. Command-click the URL below and send the resulting message to get the attachment.] [The following attachment must be fetched by ftp. Command-click the URL below to ask your ftp client to fetch it.] _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Fri Mar 03 01:20:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF3eB-0000jf-9f; Fri, 03 Mar 2006 01:20:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF3eA-0000j4-5w for techspec@ietf.org; Fri, 03 Mar 2006 01:20:14 -0500 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF3e6-00063P-TF for techspec@ietf.org; Fri, 03 Mar 2006 01:20:14 -0500 Received: from [10.71.1.40] ([::ffff:203.221.61.236]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Fri, 03 Mar 2006 01:19:04 -0500 id 01588196.4407DFDA.00007F46 Message-ID: <4407DFFA.3020601@thinkingcat.com> Date: Fri, 03 Mar 2006 01:19:38 -0500 From: Leslie Daigle User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: techspec@ietf.org Subject: Re: [Techspec] I-D ACTION:draft-irtf-rfcs-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org Well, this is curious... While I heartily encourage everyone on this list to read the document and provide comments, I have no notion of why we got this from the Internet-Drafts administrator (practically speaking -- i.e., who told them to send it here). Substantively speaking -- I think it's at best peripherally related to the current scope of discussion. Leslie. Internet-Drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : IRTF Research Group RFCs > Author(s) : A. Falk > Filename : draft-irtf-rfcs-00.txt > Pages : 11 > Date : 2006-3-2 > > This document describes a process for research groups in the Internet > Research Task Force to publish RFCs. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-irtf-rfcs-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-irtf-rfcs-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-irtf-rfcs-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > [The following attachment must be fetched by mail. Command-click the URL > below and send the resulting message to get the attachment.] > > > [The following attachment must be fetched by ftp. Command-click the URL > below to ask your ftp client to fetch it.] > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > > _______________________________________________ > Techspec mailing list > Techspec@ietf.org > https://www1.ietf.org/mailman/listinfo/techspec > _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Fri Mar 03 05:52:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF7tU-0007Cf-Ra; Fri, 03 Mar 2006 05:52:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF7tT-0007Ca-Iv for techspec@ietf.org; Fri, 03 Mar 2006 05:52:19 -0500 Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF7tT-0007B9-2g for techspec@ietf.org; Fri, 03 Mar 2006 05:52:19 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k23AqITJ090644 for ; Fri, 3 Mar 2006 10:52:18 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k23AqURg131200 for ; Fri, 3 Mar 2006 10:52:30 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id k23AqHvk028410 for ; Fri, 3 Mar 2006 10:52:17 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id k23AqHjo028403; Fri, 3 Mar 2006 10:52:17 GMT Received: from zurich.ibm.com (sig-9-145-132-49.de.ibm.com [9.145.132.49]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA63030; Fri, 3 Mar 2006 11:52:13 +0100 Message-ID: <44081FD4.2090100@zurich.ibm.com> Date: Fri, 03 Mar 2006 11:52:04 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: John C Klensin Subject: Re: [Techspec] New requirement for early permanent ID allocation References: <44055E13.6070006@zurich.ibm.com> <271FA60BC49B6582BE7D1246@p3.JCK.COM> In-Reply-To: <271FA60BC49B6582BE7D1246@p3.JCK.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org John, I find myself in complete agreement with you. In the techspec context, I think the basic requirement remains that the publisher follows IETF instructions on how to assign identifiers, and assigns them as early in the processing of a document as the IETF requests. And we should note for clarity that identifiers may come in multiple types, exactly as you say. I think that for defining contractual requirements on the publisher, that is sufficient. Brian John C Klensin wrote: > > --On Wednesday, 01 March, 2006 09:40 +0100 Brian E Carpenter > wrote: > > >>I think we're at risk of confusing two identifiers: >>RFC 9999 and STD 999. >> >>As I've just said on the newtrk list, I think John is on the >>right track for STD 999 type identifiers. But I took this >>requirement to refer to RFC 9999 type identifiers. As Humpty >>Dumpty would explain better than me, they're different. > > > I have made a leap here, which I clearly should have been more > explicit about. My apologies. > > Explanation: I'm trying to look at Techspec through a "figure > out what the problem is and then how to solve it" perspective > rather that a "how to tune what we are doing now" one. We've > been repeatedly encouraged to do that. So I read the > description of this issue/ requirement, saw what "permanent > IDs", especially early ones, were for, and got "these are > identifiers of the _standards_, not identifiers of the > documents". > > Now, if one wants to identify the standards, then the right > target is, IMO, offspring-of-STD and not a serial document > number (which the RFC 9999 numbers ultimately are). And it > appears to me that we need those stable standards-reference > numbers (or standardized acronyms, or whatever we use -- another > newtrk topic) regardless of what we do about the multi-step > standards model, i.e., > > * If we keep the present system, we need to get stable > standards-references assigned at Proposed (or earlier) > because few things go to Internet Standard and those > that do take a long time. > > * If we drop the number of maturity levels to two or > one, we will still need a way to assign stable > standards-reference numbers because of publication lag > (even if it is short) and because we revise standards. > > * And, if we develop a way to fast-track Internet > Standards on the basis of market acceptance, there is > still a significant lag time while that market > acceptance and experience develops and we therefore > still need standards-reference numbers early on. > > For the purposes of any of those references, especially by other > groups, assignment of serial document numbers is (or should be) > largely irrelevant. The fact that we have been using them as > standards-identifiers and are talking about assigning them early > is, to me, more a sign that our standards-identifier system > --i.e., the STD numbers-- is broken and needs to be fixed, not > that we need to devise a new system for serial document numbers. > > john > _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Fri Mar 03 10:12:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFBx3-0007po-Lj; Fri, 03 Mar 2006 10:12:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFBx2-0007p4-7P for techspec@ietf.org; Fri, 03 Mar 2006 10:12:16 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFBx0-0000Jd-Tz for techspec@ietf.org; Fri, 03 Mar 2006 10:12:16 -0500 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 k23FCC2i002287; Fri, 3 Mar 2006 09:12:12 -0600 Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72) id ; Fri, 3 Mar 2006 09:12:12 -0600 Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C0038021C9F2C@eusrcmw720.eamcs.ericsson.se> From: "Stephen Hayes (TX/EUS)" To: Brian E Carpenter , John C Klensin Subject: RE: [Techspec] New requirement for early permanent ID allocation Date: Fri, 3 Mar 2006 09:12:07 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org > Brian Carpenter wrote > > In the techspec context, I think the basic requirement > remains that the publisher follows IETF instructions on > how to assign identifiers, and assigns them as early > in the processing of a document as the IETF requests. pub-req does not currently preclude the publisher from having their own identifier. Suppose the IETF comes up with several bright shiny new types of identifiers. The publisher continues to also allocate their identifier (lets call it RFCxxxx for sake of argument). External bodies may be slow to adopt the new identifiers. So a possible requirement is that the publisher only uses identifiers as instructed by the IETF and not also allocate them to a publisher defined series. > > And we should note for clarity that identifiers may come > in multiple types, exactly as you say. > > I think that for defining contractual requirements on > the publisher, that is sufficient. > > _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Fri Mar 03 10:47:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFCUf-0005Ld-DY; Fri, 03 Mar 2006 10:47:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFCUd-0005LY-PP for techspec@ietf.org; Fri, 03 Mar 2006 10:46:59 -0500 Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFCUd-0001dg-BS for techspec@ietf.org; Fri, 03 Mar 2006 10:46:59 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k23FkwTJ097878 for ; Fri, 3 Mar 2006 15:46:58 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 k23FlBf1192260 for ; Fri, 3 Mar 2006 15:47:11 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id k23Fkv1k025829 for ; Fri, 3 Mar 2006 15:46:57 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id k23FkvMt025824; Fri, 3 Mar 2006 15:46:57 GMT Received: from zurich.ibm.com (sig-9-145-132-49.de.ibm.com [9.145.132.49]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA60620; Fri, 3 Mar 2006 16:46:56 +0100 Message-ID: <440864EE.30801@zurich.ibm.com> Date: Fri, 03 Mar 2006 16:46:54 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: "Stephen Hayes (TX/EUS)" Subject: Re: [Techspec] New requirement for early permanent ID allocation References: <4DCBC973AF0D6E4FAF9CD998CE1C0038021C9F2C@eusrcmw720.eamcs.ericsson.se> In-Reply-To: <4DCBC973AF0D6E4FAF9CD998CE1C0038021C9F2C@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: a7d6aff76b15f3f56fcb94490e1052e4 Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org Stephen Hayes (TX/EUS) wrote: >> Brian Carpenter wrote >> >> In the techspec context, I think the basic requirement >> remains that the publisher follows IETF instructions on how >> to assign identifiers, and assigns them as early in the >> processing of a document as the IETF requests. > > > pub-req does not currently preclude the publisher from having > their own identifier. Suppose the IETF comes up with several > bright shiny new types of identifiers. The publisher > continues to also allocate their identifier (lets call it > RFCxxxx for sake of argument). External bodies may be slow > to adopt the new identifiers. I'm not sure we're in agreement. Let's assume that we switch contractors every two years. We can't have even the serial numbers (RFCxxxx for sake of argument) changing or resetting whenever we change contractor. So I think the IETF has to govern all types of identifier, including the basic document serial number. > So a possible requirement is that the publisher only uses > identifiers as instructed by the IETF and not also allocate > them to a publisher defined series. Yes. But I didn't get that from your previous paragraph. Brian > > >> And we should note for clarity that identifiers may come in >> multiple types, exactly as you say. >> >> I think that for defining contractual requirements on the >> publisher, that is sufficient. >> >> > > _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Fri Mar 03 11:39:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFDJH-0001f5-Nh; Fri, 03 Mar 2006 11:39:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFDJG-0001f0-EZ for techspec@ietf.org; Fri, 03 Mar 2006 11:39:18 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFDJF-0004EK-4v for techspec@ietf.org; Fri, 03 Mar 2006 11:39:18 -0500 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 k23GdGhs016942; Fri, 3 Mar 2006 10:39:16 -0600 Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72) id ; Fri, 3 Mar 2006 10:39:16 -0600 Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C0038021C9FDF@eusrcmw720.eamcs.ericsson.se> From: "Stephen Hayes (TX/EUS)" To: Brian E Carpenter Subject: RE: [Techspec] New requirement for early permanent ID allocation Date: Fri, 3 Mar 2006 10:39:10 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org > -----Original Message----- > From: Brian E Carpenter [mailto:brc@zurich.ibm.com] > I'm not sure we're in agreement. Let's assume that we switch > contractors every two years. We can't have even the serial > numbers (RFCxxxx for sake of argument) changing or resetting > whenever we change contractor. So I think the IETF has to > govern all types of identifier, including the basic document > serial number. > > > So a possible requirement is that the publisher only uses > > identifiers as instructed by the IETF and not also allocate > > them to a publisher defined series. > > Yes. But I didn't get that from your previous paragraph. I listed this as a possible requirement due to the implications. It means that there is no longer an overarching serial identifier like the current RFC series. A serial identifier allocated by the IETF is insufficient since independent submissions do not go through the the IETF. A serial identifier allocated by the publisher is insufficient since the IETF can request it not be allocated one of those identifiers. Stephen _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Fri Mar 03 17:21:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFIed-0006JP-IL; Fri, 03 Mar 2006 17:21:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFIeb-00067G-Ui for techspec@ietf.org; Fri, 03 Mar 2006 17:21:41 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFHyv-0005i2-AK for techspec@ietf.org; Fri, 03 Mar 2006 16:38:37 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FFHnk-0005XQ-9v for techspec@ietf.org; Fri, 03 Mar 2006 16:27:09 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1FFHnd-000MaX-Ck; Fri, 03 Mar 2006 16:26:57 -0500 Date: Fri, 03 Mar 2006 16:26:56 -0500 From: John C Klensin To: "Stephen Hayes (TX/EUS)" , Brian E Carpenter Subject: RE: [Techspec] New requirement for early permanent ID allocation Message-ID: <7B260F7A07BA063EB4554EA5@p3.JCK.COM> In-Reply-To: <4DCBC973AF0D6E4FAF9CD998CE1C0038021C9FDF@eusrcmw720.eamcs.ericsson.se> References: <4DCBC973AF0D6E4FAF9CD998CE1C0038021C9FDF@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: -2.2 (--) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org --On Friday, 03 March, 2006 10:39 -0600 "Stephen Hayes (TX/EUS)" wrote: > > >> -----Original Message----- >> From: Brian E Carpenter [mailto:brc@zurich.ibm.com] >> I'm not sure we're in agreement. Let's assume that we switch >> contractors every two years. We can't have even the serial >> numbers (RFCxxxx for sake of argument) changing or resetting >> whenever we change contractor. So I think the IETF has to >> govern all types of identifier, including the basic document >> serial number. >> >> > So a possible requirement is that the publisher only uses >> > identifiers as instructed by the IETF and not also allocate >> > them to a publisher defined series. >> >> Yes. But I didn't get that from your previous paragraph. > > I listed this as a possible requirement due to the > implications. It means that there is no longer an overarching > serial identifier like the current RFC series. A serial > identifier allocated by the IETF is insufficient since > independent submissions do not go through the the IETF. A > serial identifier allocated by the publisher is insufficient > since the IETF can request it not be allocated one of those > identifiers. And the solution, of course, is two identifiers, which is what we have been doing for years, albeit badly for standards-track documents (for reasons that are clearly out of TechSpec scope). If there is a techspec requirement, I think it is that, if there is a serial document identifier (and, IMO, dropping it would be a terrible idea), the numbering system "belong" sufficiently to the IETF that, if there is a change in publisher, the new one can continue the numbers where the old one left off. This does _not_ require IETF management of the number space, consolidation of document numbers with standards-identifiers (numbers or otherwise), or any number of other too-complex possibilities. john > > Stephen _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Mon Mar 06 21:27:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGRvU-0003hW-I5; Mon, 06 Mar 2006 21:27:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGRvS-0003cJ-Lc for techspec@ietf.org; Mon, 06 Mar 2006 21:27:50 -0500 Received: from [198.144.201.116] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGRvR-00044r-Uj for techspec@ietf.org; Mon, 06 Mar 2006 21:27:50 -0500 Received: from networkresonance.com (delta.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id D5513B811 for ; Mon, 6 Mar 2006 18:27:48 -0800 (PST) To: techspec@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 18) Date: Mon, 06 Mar 2006 18:27:48 -0800 From: Eric Rescorla Message-Id: <20060307022748.D5513B811@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: [Techspec] Review of draft-mankin-pub-req-04 X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org Overall, this document seems pretty sound. I've got one meta-issue and a bunch of smaller issues. The meta issue is the labelling of the requirements. You have "current" and "potential" but I think it would be good to distinguish three cases: 1. Requirements that you believer are commonly accepted. 2. Requirements that you believe we currently have but that not everyone agrees with. 3. Requirements that you're proposing we may or may not need sometime in the future. It's not clear to me whether "Current" embodies both (1) and (2) or... Figure 1 could use a little clarification, since the actual IANA parameter assignnment is done after approval, no? S 3.3: Can you define "substantive" changes please. Do you mean "significant" or "ones that affect the actual meaning of the documents"? I don't understand the difference between Req-POSTEDIT-3 and Req-POSTEDIT-4. S 3.7: 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. I'm not sure I agree with this. Fundamentally, that seems like the kind of discretion that should rest with the IESG. The publisher can of course say "this will require reflowing the document" or "this will delay the document X weeks" but up until the moment of publication I'm not sure why IESG shouldn't be able to direct changes. S 3.9: o Current Req-DOCCONVERT-1 - The IETF technical publisher should accept as input ascii text files and publish documents as ascii text files, postscript files, and pdf files. I think this needs some clarity. It's one thing to publish the documents in PDF file that looks exactly like the ASCII, as RFC-Ed does now. But that's not really what most people would expect when they wanted it done in PDF or PS. S 3.12: approving organization to request expedites publication of a This should read "expedited", no. S 4: I'm not sure I agree that this kind of metric granularity is appropriate in this document. I would prefer it set general policy and leave the IAD/IASA to formulate specific metrics in the technical publisher contract as appropriate. S 7. There is a tussle between the sought-for improvements in readability and the specific language that has often been negotiated carefully for the security content of IETF documents. As with other text, I'm not sure I would use the word "tussle" here. There's a tension, true, but a tussle involves divergent interests, which isn't quite what's going on here. _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Tue Mar 07 12:57:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGgR7-00017z-TQ; Tue, 07 Mar 2006 12:57:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGgR7-00015v-2k for techspec@ietf.org; Tue, 07 Mar 2006 12:57:29 -0500 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGgR6-0004Sa-Qo for techspec@ietf.org; Tue, 07 Mar 2006 12:57:29 -0500 Received: from [192.168.0.101] ([::ffff:64.102.254.33]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Tue, 07 Mar 2006 12:56:40 -0500 id 01588119.440DC958.00006EB4 Message-ID: <440DC980.9090903@thinkingcat.com> Date: Tue, 07 Mar 2006 12:57:20 -0500 From: Leslie Daigle User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_zeke.ecotroph.net-28340-1141754201-0001-2" To: techspec@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Subject: [Techspec] [Fwd: I-D ACTION:draft-mankin-pub-req-05.txt] X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-28340-1141754201-0001-2 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI -- new version is published. Thanks, Leslie. -------- Original Message -------- Subject: I-D ACTION:draft-mankin-pub-req-05.txt Date: Tue, 07 Mar 2006 02:50:02 -0500 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for IETF Technical Publication Service Author(s) : A. Mankin, S. Hayes Filename : draft-mankin-pub-req-05.txt Pages : 24 Date : 2006-3-6 The work of the IETF is to discuss, develop, and disseminate technical specifications to support the Internet's operation. Technical publication is the process by which that output is disseminated to the community at large. As such, it is important to understand the requirements on the publication process. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mankin-pub-req-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mankin-pub-req-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mankin-pub-req-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --=_zeke.ecotroph.net-28340-1141754201-0001-2 Content-Type: message/external-body; x-mac-type=0; x-mac-creator=0; name="draft-mankin-pub-req-05.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-mankin-pub-req-05.txt" Content-Type: text/plain Content-ID: <2006-3-6204326.I-D@ietf.org> --=_zeke.ecotroph.net-28340-1141754201-0001-2 Content-Type: text/plain; x-mac-type=0; x-mac-creator=0; name="file:///tmp/nsmail-1.asc"; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///tmp/nsmail-1.asc" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --=_zeke.ecotroph.net-28340-1141754201-0001-2 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 --=_zeke.ecotroph.net-28340-1141754201-0001-2-- From techspec-bounces@ietf.org Tue Mar 07 17:37:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGkoT-0005OC-Me; Tue, 07 Mar 2006 17:37:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGkoS-0005Mf-Mw for techspec@ietf.org; Tue, 07 Mar 2006 17:37:52 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGkoS-0007AB-AM for techspec@ietf.org; Tue, 07 Mar 2006 17:37:52 -0500 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 k27Mbp2J017113; Tue, 7 Mar 2006 16:37:51 -0600 Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72) id ; Tue, 7 Mar 2006 16:37:48 -0600 Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C0038022673C9@eusrcmw720.eamcs.ericsson.se> From: "Stephen Hayes (TX/EUS)" To: Eric Rescorla , techspec@ietf.org Subject: RE: [Techspec] Review of draft-mankin-pub-req-04 Date: Tue, 7 Mar 2006 16:37:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org My response to Eric's comments inline. Stephen > > Overall, this document seems pretty sound. I've got one meta-issue > and a bunch of smaller issues. The meta issue is the labelling > of the requirements. You have "current" and "potential" but I > think it would be good to distinguish three cases: > > 1. Requirements that you believer are commonly accepted. > 2. Requirements that you believe we currently have but that > not everyone agrees with. > 3. Requirements that you're proposing we may or may not need > sometime in the future. > > It's not clear to me whether "Current" embodies both (1) and (2) > or... > My idea was to eventually drop the "current" and "potential" designation. We ultimately only want to have just requirements. The designation of current and potential was just to help people understand the requirements in terms of what we are currently doing and what is newly proposed. I think once we have decided which ones to keep we will just have requirements. If it is a requirement which we intend to phase in or which we plan to phase out, then that is something we should probably indicate in the text since we need to specify the conditions for phasing in or phasing out the requirement. > > Figure 1 could use a little clarification, since the actual > IANA parameter assignnment is done after approval, no? > Your concern seems logical. Any objections to moving the IANA into the post approval part of the diagram? > > S 3.3: > Can you define "substantive" changes please. Do you mean "significant" > or "ones that affect the actual meaning of the documents"? > Rather than trying to pin down the boundary of substantive, can we could probably just remove the word "substantive" from the sentence. The logic remains the same. Allison, do the statistics need to change if we remove "substantive"? > I don't understand the difference between Req-POSTEDIT-3 and > Req-POSTEDIT-4. > I agree they are close. They are intended to control two different aspects of editorial behaviour by the publisher. POSTEDIT-3 is targeted for stylistic changes such as formatting, numbering, etc. to achieve consistency with other published documents. POSTEDIT-4 is intended to control behavious associated with improving the text so it reads better or has better grammar (and thus risk destroying consensus wording). People had different views on how much to suppress each of these behaviours so they are captured in two separate requirements. The boundary between them is pretty vague but I am not sure it does any harm to have two separate requirements so the wording can be tweaked independently. > > S 3.7: > > 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. > > I'm not sure I agree with this. Fundamentally, that seems like the > kind of discretion that should rest with the IESG. The publisher > can of course say "this will require reflowing the document" or > "this will delay the document X weeks" but up until the moment > of publication I'm not sure why IESG shouldn't be able to direct > changes. > Ultimately, the publisher should be at the command of the IESG. But this is analogous to the 11th hour appeal. If the document is ready to be published, there will be a process in the publisher to put it in the index and announce its availability. At what point can the IESG say "Stop"? Maybe it's like the movies and stopping the process is ok as long as they can rush in, throw themselves across the room, and stop the publisher from hitting the "Enter" key. > > S 3.9: > > o Current Req-DOCCONVERT-1 - The IETF technical publisher should > accept as input ascii text files and publish documents as ascii > text files, postscript files, and pdf files. > > I think this needs some clarity. It's one thing to publish > the documents > in PDF file that looks exactly like the ASCII, as RFC-Ed does now. But > that's not really what most people would expect when they wanted it > done in PDF or PS. True, this was just to capture the current practice. The wording can be clarified to indicate that. If we want them to do more, then we should probably add a new potential requirement. I really didn't want techspec to become mired in the "what formats should be allowed" discussion so I didn't add any new requirement here except for xmltorfc (DOCCONVERT-2). > > > S 3.12: > > approving organization to request expedites publication of a > > This should read "expedited", no. Correct > > > > S 4: > I'm not sure I agree that this kind of metric granularity is > appropriate in this document. I would prefer it set general > policy and leave the IAD/IASA to formulate specific metrics > in the technical publisher contract as appropriate. > See the improved wording in version 05. > > S 7. > > There is a tussle between the sought-for improvements in > readability > and the specific language that has often been negotiated carefully > for the security content of IETF documents. As with other text, > > I'm not sure I would use the word "tussle" here. There's a tension, > true, but a tussle involves divergent interests, which isn't quite > what's going on here. I am happy to change it to "tension". > _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Tue Mar 07 18:36:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGljM-0007Ly-Ir; Tue, 07 Mar 2006 18:36:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGljK-0007Fn-Mq for techspec@ietf.org; Tue, 07 Mar 2006 18:36:38 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGljK-0002KG-BT for techspec@ietf.org; Tue, 07 Mar 2006 18:36:38 -0500 Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k27NaYlJ006305 for ; Tue, 7 Mar 2006 16:36:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4DCBC973AF0D6E4FAF9CD998CE1C0038022673C9@eusrcmw720.eamcs.ericsson.se> References: <4DCBC973AF0D6E4FAF9CD998CE1C0038022673C9@eusrcmw720.eamcs.ericsson.se> Date: Tue, 7 Mar 2006 15:36:17 -0800 To: techspec@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Techspec] Cutoff for post-approval corrections X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org At 4:37 PM -0600 3/7/06, Stephen Hayes (TX/EUS) wrote: >My response to Eric's comments inline. > > S 3.7: >> > > 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. >> >> I'm not sure I agree with this. Fundamentally, that seems like the >> kind of discretion that should rest with the IESG. The publisher >> can of course say "this will require reflowing the document" or >> "this will delay the document X weeks" but up until the moment >> of publication I'm not sure why IESG shouldn't be able to direct >> changes. >> >Ultimately, the publisher should be at the command of the IESG. I think that might be "pentultimately"; ultimately, isn't the publishers at the command of IASA? >But this is analogous to the 11th hour appeal. If the document is >ready to be published, there will be a process in the publisher to >put it in the index and announce its availability. At what point >can the IESG say "Stop"? Maybe it's like the movies and stopping >the process is ok as long as they can rush in, throw themselves >across the room, and stop the publisher from hitting the "Enter" key. Fully agree. But, in the movie scenario, if the publisher sees the IESG collectively throw themselves across the room (well worth the price of admission alone!), the publisher would take its finger off the button. The wording of Req-POSTCORR-3 doesn't reflect that. A more accurate wording might be: o Potential Req-POSTCORR-3 - The IETF technical publisher should have the discretion to publish the document as soon as all the parties that must approve the final document have done so. This allows the IESG can dramatically leap in at any point before publication. Further, if the IESG wants the discretion to make changes in the document, it might make itself one of the parties that must approve the final document, most likely through one or more Area Directors. That is already the case now for any WG document and (possibly) any individual submission that has a sponsoring AD. The IESG and IASA can figure out exactly what the rules should be here. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Tue Mar 07 21:08:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGo5n-0003z5-Qf; Tue, 07 Mar 2006 21:07:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGo5n-0003yz-0n for techspec@ietf.org; Tue, 07 Mar 2006 21:07:59 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGo5m-0008H3-Mn for techspec@ietf.org; Tue, 07 Mar 2006 21:07:58 -0500 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 k2827vsf009068; Tue, 7 Mar 2006 20:07:58 -0600 Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72) id ; Tue, 7 Mar 2006 20:07:57 -0600 Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C003802267434@eusrcmw720.eamcs.ericsson.se> From: "Stephen Hayes (TX/EUS)" To: Paul Hoffman , techspec@ietf.org Subject: RE: [Techspec] Cutoff for post-approval corrections Date: Tue, 7 Mar 2006 20:07:40 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] > Sent: Tuesday, March 07, 2006 5:36 PM > To: techspec@ietf.org > Subject: [Techspec] Cutoff for post-approval corrections > > > At 4:37 PM -0600 3/7/06, Stephen Hayes (TX/EUS) wrote: > >My response to Eric's comments inline. > > > S 3.7: > >> > > > 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. > >> > >> I'm not sure I agree with this. Fundamentally, that seems like the > >> kind of discretion that should rest with the IESG. The publisher > >> can of course say "this will require reflowing the document" or > >> "this will delay the document X weeks" but up until the moment > >> of publication I'm not sure why IESG shouldn't be able to direct > >> changes. > >> > >Ultimately, the publisher should be at the command of the IESG. > > I think that might be "pentultimately"; ultimately, isn't the > publishers at the command of IASA? > > >But this is analogous to the 11th hour appeal. If the document is > >ready to be published, there will be a process in the publisher to > >put it in the index and announce its availability. At what point > >can the IESG say "Stop"? Maybe it's like the movies and stopping > >the process is ok as long as they can rush in, throw themselves > >across the room, and stop the publisher from hitting the "Enter" key. > > Fully agree. But, in the movie scenario, if the publisher sees the > IESG collectively throw themselves across the room (well worth the > price of admission alone!), the publisher would take its finger off > the button. The wording of Req-POSTCORR-3 doesn't reflect that. A > more accurate wording might be: > > o Potential Req-POSTCORR-3 - The IETF technical publisher should > have the discretion to publish the document as soon as all > the parties that must approve the final document have done so. > > This allows the IESG can dramatically leap in at any point before > publication. Further, if the IESG wants the discretion to make > changes in the document, it might make itself one of the parties that > must approve the final document, most likely through one or more Area > Directors. That is already the case now for any WG document and > (possibly) any individual submission that has a sponsoring AD. The > IESG and IASA can figure out exactly what the rules should be here. If this is the case, I'm not sure we need to keep this requirement at all. I think the requirement captured in the reworded version is somewhat implied. The original idea was whether or not to give the technical publisher the ability to say "sorry, too late". If we don't want to give them that authority then we should just remove this potential requirement all together. > > --Paul Hoffman, Director > --VPN Consortium > > _______________________________________________ > Techspec mailing list > Techspec@ietf.org > https://www1.ietf.org/mailman/listinfo/techspec > _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Mar 08 10:07:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH0G7-0004Kt-AI; Wed, 08 Mar 2006 10:07:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH0G6-0004Iy-7s for techspec@ietf.org; Wed, 08 Mar 2006 10:07:26 -0500 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH0G5-0004eX-N2 for techspec@ietf.org; Wed, 08 Mar 2006 10:07:26 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id k28F7OHm198084 for ; Wed, 8 Mar 2006 15:07:24 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k28F7kkA210962 for ; Wed, 8 Mar 2006 16:07:46 +0100 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k28F7NX5016474 for ; Wed, 8 Mar 2006 16:07:24 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k28F7N5K016460; Wed, 8 Mar 2006 16:07:23 +0100 Received: from zurich.ibm.com (sig-9-145-248-2.de.ibm.com [9.145.248.2]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA55390; Wed, 8 Mar 2006 16:07:21 +0100 Message-ID: <440EF328.3040601@zurich.ibm.com> Date: Wed, 08 Mar 2006 16:07:20 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: "Stephen Hayes (TX/EUS)" Subject: Re: [Techspec] Cutoff for post-approval corrections References: <4DCBC973AF0D6E4FAF9CD998CE1C003802267434@eusrcmw720.eamcs.ericsson.se> In-Reply-To: <4DCBC973AF0D6E4FAF9CD998CE1C003802267434@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: cd26b070c2577ac175cd3a6d878c6248 Cc: Paul Hoffman , techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org Stephen Hayes (TX/EUS) wrote: > >>-----Original Message----- >>From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] >>Sent: Tuesday, March 07, 2006 5:36 PM >>To: techspec@ietf.org >>Subject: [Techspec] Cutoff for post-approval corrections >> >> >>At 4:37 PM -0600 3/7/06, Stephen Hayes (TX/EUS) wrote: >> >>>My response to Eric's comments inline. >>> > S 3.7: >>> >>> > 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. >> >>>> I'm not sure I agree with this. Fundamentally, that seems like the >>>> kind of discretion that should rest with the IESG. The publisher >>>> can of course say "this will require reflowing the document" or >>>> "this will delay the document X weeks" but up until the moment >>>> of publication I'm not sure why IESG shouldn't be able to direct >>>> changes. >>>> >>> >>>Ultimately, the publisher should be at the command of the IESG. >> >>I think that might be "pentultimately"; ultimately, isn't the >>publishers at the command of IASA? >> >> >>>But this is analogous to the 11th hour appeal. If the document is >>>ready to be published, there will be a process in the publisher to >>>put it in the index and announce its availability. At what point >>>can the IESG say "Stop"? Maybe it's like the movies and stopping >>>the process is ok as long as they can rush in, throw themselves >>>across the room, and stop the publisher from hitting the "Enter" key. >> >>Fully agree. But, in the movie scenario, if the publisher sees the >>IESG collectively throw themselves across the room (well worth the >>price of admission alone!), the publisher would take its finger off >>the button. The wording of Req-POSTCORR-3 doesn't reflect that. A >>more accurate wording might be: >> >> o Potential Req-POSTCORR-3 - The IETF technical publisher should >> have the discretion to publish the document as soon as all >> the parties that must approve the final document have done so. >> >>This allows the IESG can dramatically leap in at any point before >>publication. Further, if the IESG wants the discretion to make >>changes in the document, it might make itself one of the parties that >>must approve the final document, most likely through one or more Area >>Directors. That is already the case now for any WG document and >>(possibly) any individual submission that has a sponsoring AD. The >>IESG and IASA can figure out exactly what the rules should be here. > > > If this is the case, I'm not sure we need to keep this requirement at all. I think the requirement captured in the reworded version is somewhat implied. The original idea was whether or not to give the technical publisher the ability to say "sorry, too late". If we don't want to give them that authority then we should just remove this potential requirement all together. > Basically we need to be sure we keep the equivalent of AUTH48 where the authors and AD have a final look; but if they ask for excessive changes at that stage, which *does* happen, the publisher needs to be able to say no. On the other hand we need the publisher to stop if someone on the technical side finds a major problem at the last moment. Whether that makes two requirements or one, I leave to Stephen. Brian _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Mar 08 11:36:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH1e8-0007A2-S2; Wed, 08 Mar 2006 11:36:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH1e6-00079H-UH for techspec@ietf.org; Wed, 08 Mar 2006 11:36:18 -0500 Received: from rwcrmhc12.comcast.net ([204.127.192.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH1e3-0007h9-Lq for techspec@ietf.org; Wed, 08 Mar 2006 11:36:18 -0500 Received: from s73602 (unknown[65.104.224.98]) by comcast.net (rwcrmhc12) with SMTP id <20060308163614m1200lr4iae>; Wed, 8 Mar 2006 16:36:14 +0000 Message-ID: <2dcd01c642ce$1a1863a0$0500a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: <4DCBC973AF0D6E4FAF9CD998CE1C003802267434@eusrcmw720.eamcs.ericsson.se> <440EF328.3040601@zurich.ibm.com> Subject: Re: [Techspec] Cutoff for post-approval corrections Date: Wed, 8 Mar 2006 10:33:55 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org I'm not sure whether I lack understanding or lack clue on this... > Basically we need to be sure we keep the equivalent of AUTH48 > where the authors and AD have a final look; but if they ask ... with Brian so far, why would this be wrong ... > for excessive changes at that stage, which *does* happen, > the publisher needs to be able to say no. ... and get lost here. I'm fine with the AD saying "that change is excessive for AUTH48" to authors, but having the technical publisher tell the AD(s, or the IESG), "that change is excessive for AUTH48" seems like a stretch. Maybe I have the wrong understanding of "excessive". Is "excessive" simply a quantitative issue ("we can't possibly do that terminology change so quickly"), or is technical judgement involved ("adding IDN support is too big for AUTH48, and needs to be discussed within the working group")? > On the other hand we > need the publisher to stop if someone on the technical side > finds a major problem at the last moment. Whether that makes > two requirements or one, I leave to Stephen. > > Brian Thanks, Spencer _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Mar 08 15:17:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH55z-0001K3-Cs; Wed, 08 Mar 2006 15:17:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH55y-0001HE-2G for techspec@ietf.org; Wed, 08 Mar 2006 15:17:18 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH55w-00075E-Og for techspec@ietf.org; Wed, 08 Mar 2006 15:17:18 -0500 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 k28KHFg1008360; Wed, 8 Mar 2006 14:17:15 -0600 Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72) id ; Wed, 8 Mar 2006 14:17:15 -0600 Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C0038022676E7@eusrcmw720.eamcs.ericsson.se> From: "Stephen Hayes (TX/EUS)" To: Brian E Carpenter Subject: RE: [Techspec] Cutoff for post-approval corrections Date: Wed, 8 Mar 2006 14:17:11 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Paul Hoffman , techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org Brian Carpenter Wrote > > Basically we need to be sure we keep the equivalent of AUTH48 > where the authors and AD have a final look; but if they ask > for excessive changes at that stage, which *does* happen, > the publisher needs to be able to say no. On the other hand we > need the publisher to stop if someone on the technical side > finds a major problem at the last moment. Whether that makes > two requirements or one, I leave to Stephen. > We already have the stop publication requirement in section 3.13. I'm not really sure whether there is a big disagreement between Brian and Eric on whether the publisher can refuse last minute changes. The potential responses of "no (too late or too big)" and "yes, but it has to go to the bottom of the queue again" amount to about the same thing in terms of what the publisher can actually enforce. > > _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Mar 08 17:10:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH6rV-0005JS-Vh; Wed, 08 Mar 2006 17:10:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH6rV-0005Hq-2W for techspec@ietf.org; Wed, 08 Mar 2006 17:10:29 -0500 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 1FH68d-0007Sk-5f for techspec@ietf.org; Wed, 08 Mar 2006 16:24:07 -0500 Received: from rwcrmhc13.comcast.net ([204.127.192.83]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FH64a-0006SL-SQ for techspec@ietf.org; Wed, 08 Mar 2006 16:19:58 -0500 Received: from s73602 (unknown[65.104.224.98]) by comcast.net (rwcrmhc13) with SMTP id <20060308211955m13000lnete>; Wed, 8 Mar 2006 21:19:55 +0000 Message-ID: <30b601c642f5$ba454380$0500a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: <200603082107.k28L718K032203@rotala.raleigh.ibm.com> Subject: Re: [Techspec] Cutoff for post-approval corrections Date: Wed, 8 Mar 2006 15:17:37 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org Hi, Thomas, I may not be making myself clear enough here... From: "Thomas Narten" >> > for excessive changes at that stage, which *does* happen, >> > the publisher needs to be able to say no. > >> ... and get lost here. I'm fine with the AD saying "that change is >> excessive for AUTH48" to authors, but having the technical publisher >> tell the AD(s, or the IESG), "that change is excessive for AUTH48" >> seems like a stretch. > > excessive: you know it when you see it. Like when an l2tp document > asked for 278 editorial changes during AUTH48. (No, I'm not making > this up!) Fully ACK on "excessive". My concern was about the technical publisher being the one who "knows it when you see it" - Stephen's point that saying "no" and saying "this is going to take a while" are probably very similar regarding what happens next seems helpful here. I'm OK with the technical publisher saying, "if you want us to make 278 changes, this is going to the bottom of the queue", or even, "please go away and come back when you have a document that looks like text you actually want to publish", but not saying, "no, we need to publish the document without making the changes, because the number of AUTH48 changes are excessive". And that's why I'm lost. Spencer _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Thu Mar 09 08:05:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHKpU-00018E-Dx; Thu, 09 Mar 2006 08:05:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHKpS-000189-QD for techspec@ietf.org; Thu, 09 Mar 2006 08:05:18 -0500 Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHKpR-0000ra-Bs for techspec@ietf.org; Thu, 09 Mar 2006 08:05:18 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k29D5GTJ033262 for ; Thu, 9 Mar 2006 13:05:16 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k29D5WGu220628 for ; Thu, 9 Mar 2006 13:05:32 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id k29D5FjG008161 for ; Thu, 9 Mar 2006 13:05:15 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id k29D5FRq008153; Thu, 9 Mar 2006 13:05:15 GMT Received: from zurich.ibm.com (sig-9-146-223-150.de.ibm.com [9.146.223.150]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA35466; Thu, 9 Mar 2006 14:05:14 +0100 Message-ID: <44102809.7060000@zurich.ibm.com> Date: Thu, 09 Mar 2006 14:05:13 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Spencer Dawkins Subject: Re: [Techspec] Cutoff for post-approval corrections References: <200603082107.k28L718K032203@rotala.raleigh.ibm.com> <30b601c642f5$ba454380$0500a8c0@china.huawei.com> In-Reply-To: <30b601c642f5$ba454380$0500a8c0@china.huawei.com> 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 X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org Spencer Dawkins wrote: > Hi, Thomas, > > I may not be making myself clear enough here... > > From: "Thomas Narten" > > >>> > for excessive changes at that stage, which *does* happen, >>> > the publisher needs to be able to say no. >> >> >>> ... and get lost here. I'm fine with the AD saying "that change is >>> excessive for AUTH48" to authors, but having the technical publisher >>> tell the AD(s, or the IESG), "that change is excessive for AUTH48" >>> seems like a stretch. >> >> >> excessive: you know it when you see it. Like when an l2tp document >> asked for 278 editorial changes during AUTH48. (No, I'm not making >> this up!) > > > Fully ACK on "excessive". My concern was about the technical publisher > being the one who "knows it when you see it" - Stephen's point that > saying "no" and saying "this is going to take a while" are probably very > similar regarding what happens next seems helpful here. > > I'm OK with the technical publisher saying, "if you want us to make 278 > changes, this is going to the bottom of the queue", or even, "please go > away and come back when you have a document that looks like text you > actually want to publish", but not saying, "no, we need to publish the > document without making the changes, because the number of AUTH48 > changes are excessive". > > And that's why I'm lost. It's always going to be a judgement call, but I really don't see that the publisher needs an AD's backup to Just Say No when a document that has been approved by our consensus process and formally approved by the IESG comes back with hundreds of changes. The authors simply don't have the right to do that - it's a process violation. Since it's a judgement call, it's appealable, so it can come back to the AD anyway as an appeal. Brian _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Thu Mar 09 08:12:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHKvG-00075A-Cg; Thu, 09 Mar 2006 08:11:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHKvE-0006zy-IY for techspec@ietf.org; Thu, 09 Mar 2006 08:11:16 -0500 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHKvD-00014s-BD for techspec@ietf.org; Thu, 09 Mar 2006 08:11:16 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k29DBEr3015690 for ; Thu, 9 Mar 2006 08:11:14 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k29DBE8D135758 for ; Thu, 9 Mar 2006 08:11:14 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k29DBEr4006177 for ; Thu, 9 Mar 2006 08:11:14 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-76-144-179.mts.ibm.com [9.76.144.179]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k29DBDSa006152; Thu, 9 Mar 2006 08:11:14 -0500 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id k29DBD4Z019700; Thu, 9 Mar 2006 08:11:13 -0500 Message-Id: <200603091311.k29DBD4Z019700@cichlid.raleigh.ibm.com> To: "Spencer Dawkins" Subject: Re: [Techspec] Cutoff for post-approval corrections In-Reply-To: Message from "Spencer Dawkins" of "Wed, 08 Mar 2006 15:17:37 CST." <30b601c642f5$ba454380$0500a8c0@china.huawei.com> Date: Thu, 09 Mar 2006 08:11:13 -0500 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org > Fully ACK on "excessive". My concern was about the technical publisher being > the one who "knows it when you see it" - Stephen's point that saying "no" > and saying "this is going to take a while" are probably very similar > regarding what happens next seems helpful here. OK. I think the end-of-the day requirement here is publisher can say "that's an awful lot of changes, it will cost you in terms of priority/delay/etc., do you really want us to do that?", with the ADs/IESG having the final say if it comes to that. In practice, I would expect the above would lead to a discussion in which it is decided how to balance the needs (i.e., just publish w/o changes vs., yep they are important enough they need to get done.), since the discussion will inevitably balance a number of issues that only the IETF can properly weigh. Thomas _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Thu Mar 09 08:48:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHLVe-00072E-Uk; Thu, 09 Mar 2006 08:48:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHLVd-000724-Nm for techspec@ietf.org; Thu, 09 Mar 2006 08:48:53 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHLVc-0002Gr-5l for techspec@ietf.org; Thu, 09 Mar 2006 08:48:53 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1FHLVY-000CNE-8v; Thu, 09 Mar 2006 08:48:48 -0500 Date: Thu, 09 Mar 2006 08:48:47 -0500 From: John C Klensin To: Brian E Carpenter , Spencer Dawkins Subject: Re: [Techspec] Cutoff for post-approval corrections Message-ID: In-Reply-To: <44102809.7060000@zurich.ibm.com> References: <200603082107.k28L718K032203@rotala.raleigh.ibm.com> <30b601c642f5$ba454380$0500a8c0@china.huawei.com> <44102809.7060000@zurich.ibm.com> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org --On Thursday, 09 March, 2006 14:05 +0100 Brian E Carpenter wrote: >> I'm OK with the technical publisher saying, "if you want us >> to make 278 changes, this is going to the bottom of the >> queue", or even, "please go away and come back when you have >> a document that looks like text you actually want to >> publish", but not saying, "no, we need to publish the >> document without making the changes, because the number of >> AUTH48 changes are excessive". >> >> And that's why I'm lost. > > It's always going to be a judgement call, but I really don't > see that > the publisher needs an AD's backup to Just Say No when a > document that > has been approved by our consensus process and formally > approved by > the IESG comes back with hundreds of changes. The authors > simply don't > have the right to do that - it's a process violation. > > Since it's a judgement call, it's appealable, so it can come > back to > the AD anyway as an appeal. Brian, I think this is exactly right, but I would add "or any substantive ones" to the "hundred of changes" in your comment. Unless we select a technical publisher who can, on an average day, usually tell a substantive change from an editorial one, we are going to be in serious trouble for other reasons. If the editor detects such changes in an author's reply, the document should be bounced and the author told that such changes require AD signoff (at least). john _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Fri Mar 10 08:47:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHhxa-0007EE-Py; Fri, 10 Mar 2006 08:47:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHhxZ-0007Dn-69 for techspec@ietf.org; Fri, 10 Mar 2006 08:47:13 -0500 Received: from mtagate2.uk.ibm.com ([195.212.29.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHhxY-00070H-Nw for techspec@ietf.org; Fri, 10 Mar 2006 08:47:13 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k2ADlBm9128374 for ; Fri, 10 Mar 2006 13:47:11 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2ADlRoZ191988 for ; Fri, 10 Mar 2006 13:47:27 GMT Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id k2ADlAaf018129 for ; Fri, 10 Mar 2006 13:47:10 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id k2ADl9gX018117; Fri, 10 Mar 2006 13:47:10 GMT Received: from zurich.ibm.com (sig-9-145-253-68.de.ibm.com [9.145.253.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA73336; Fri, 10 Mar 2006 14:47:04 +0100 Message-ID: <4411834F.8090002@zurich.ibm.com> Date: Fri, 10 Mar 2006 14:46:55 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: John C Klensin Subject: Re: [Techspec] Cutoff for post-approval corrections References: <200603082107.k28L718K032203@rotala.raleigh.ibm.com> <30b601c642f5$ba454380$0500a8c0@china.huawei.com> <44102809.7060000@zurich.ibm.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org John C Klensin wrote: > > --On Thursday, 09 March, 2006 14:05 +0100 Brian E Carpenter > wrote: > > >>>I'm OK with the technical publisher saying, "if you want us >>>to make 278 changes, this is going to the bottom of the >>>queue", or even, "please go away and come back when you have >>>a document that looks like text you actually want to >>>publish", but not saying, "no, we need to publish the >>>document without making the changes, because the number of >>>AUTH48 changes are excessive". >>> >>>And that's why I'm lost. >> >>It's always going to be a judgement call, but I really don't >>see that >>the publisher needs an AD's backup to Just Say No when a >>document that >>has been approved by our consensus process and formally >>approved by >>the IESG comes back with hundreds of changes. The authors >>simply don't >>have the right to do that - it's a process violation. >> >>Since it's a judgement call, it's appealable, so it can come >>back to >>the AD anyway as an appeal. > > > > Brian, I think this is exactly right, but I would add "or any > substantive ones" to the "hundred of changes" in your comment. > > Unless we select a technical publisher who can, on an average > day, usually tell a substantive change from an editorial one, we > are going to be in serious trouble for other reasons. If the > editor detects such changes in an author's reply, the document > should be bounced and the author told that such changes require > AD signoff (at least). Agreed. Brian _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Tue Mar 14 19:20:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJJkP-0000y4-Sv; Tue, 14 Mar 2006 19:20:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJJkO-0000xz-P9 for techspec@ietf.org; Tue, 14 Mar 2006 19:20:16 -0500 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJJkN-0003S1-JS for techspec@ietf.org; Tue, 14 Mar 2006 19:20:16 -0500 Received: from [171.71.5.127] ([::ffff:171.71.5.127]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Tue, 14 Mar 2006 19:19:24 -0500 id 015880F9.44175D8C.00006A9D Message-ID: <44175DB9.30209@thinkingcat.com> Date: Tue, 14 Mar 2006 19:20:09 -0500 From: Leslie Daigle User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Stephen Hayes (TX/EUS)" Subject: Re: [Techspec] Review of draft-mankin-pub-req-04 References: <4DCBC973AF0D6E4FAF9CD998CE1C0038022673C9@eusrcmw720.eamcs.ericsson.se> In-Reply-To: <4DCBC973AF0D6E4FAF9CD998CE1C0038022673C9@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: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org (Catching up) Stephen Hayes (TX/EUS) wrote: >>Figure 1 could use a little clarification, since the actual >>IANA parameter assignnment is done after approval, no? >> > > Your concern seems logical. Any objections to moving the IANA into > the post approval part of the diagram? Actually, I don't think that's the right choice. There is IANA review of the text *before* approval. It is an explicit step of the review, and can cause text to change in the document; the document is not approved until IANA nods that the text is clear enough to instruct them. The work of the IANA *after* approval is almost immaterial to this process -- or, at most, it involves filling in values that are not known until IANA actions are completed. So -- at most, note IANA on both sides of the approval line, but certainly we need to retain the pre-approval instance. Leslie. _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Mar 15 07:31:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJVAB-0007Au-Uq; Wed, 15 Mar 2006 07:31:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJVAA-0007AU-6j for techspec@ietf.org; Wed, 15 Mar 2006 07:31:38 -0500 Received: from mtagate4.uk.ibm.com ([195.212.29.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJVA8-0007XW-Pk for techspec@ietf.org; Wed, 15 Mar 2006 07:31:38 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k2FCVal6275598 for ; Wed, 15 Mar 2006 12:31:36 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2FCVuOd199836 for ; Wed, 15 Mar 2006 12:31:56 GMT Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id k2FCVZaH032304 for ; Wed, 15 Mar 2006 12:31:35 GMT Received: from mail-gw3.hursley.ibm.com (mail-gw3.hursley.ibm.com [9.20.131.251]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id k2FCVZF0032301; Wed, 15 Mar 2006 12:31:35 GMT Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw3.hursley.ibm.com with esmtp (Exim 4.50) id 1FJVA7-0004cT-39; Wed, 15 Mar 2006 12:31:35 +0000 Received: from zurich.ibm.com (sig-9-145-254-246.de.ibm.com [9.145.254.246]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with SMTP id k2FCVZV173148; Wed, 15 Mar 2006 12:31:35 GMT Message-ID: <44180926.2010603@zurich.ibm.com> Date: Wed, 15 Mar 2006 13:31:34 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Leslie Daigle Subject: Re: [Techspec] Review of draft-mankin-pub-req-04 References: <4DCBC973AF0D6E4FAF9CD998CE1C0038022673C9@eusrcmw720.eamcs.ericsson.se> <44175DB9.30209@thinkingcat.com> In-Reply-To: <44175DB9.30209@thinkingcat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org Leslie Daigle wrote: > > (Catching up) > > Stephen Hayes (TX/EUS) wrote: > >>> Figure 1 could use a little clarification, since the actual >>> IANA parameter assignnment is done after approval, no? >>> >> >> Your concern seems logical. Any objections to moving the IANA into >> the post approval part of the diagram? > > > > Actually, I don't think that's the right choice. There is > IANA review of the text *before* approval. It is an explicit > step of the review, and can cause text to change in the document; > the document is not approved until IANA nods that the text > is clear enough to instruct them. > > The work of the IANA *after* approval is almost immaterial to > this process -- or, at most, it involves filling in values that > are not known until IANA actions are completed. > > So -- at most, note IANA on both sides of the approval line, > but certainly we need to retain the pre-approval instance. Exactly. I can't be bothered to count but I would say probably 20% of drafts need some clarification or explanation for IANA during IESG evaluation. It's not unusual for a problem noticed by IANA being sufficiently serious that an AD places a DISCUSS on behalf of IANA. Typically, the pre-approval review by IANA is to figure out if the instructions to IANA in the document are unambiguous, complete and actionable. The post-approval stage is different: actually creating a new registry if needed, and assigning values to the TBDs in the draft. Brian _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Tue Mar 21 17:01:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLoum-0001lY-PF; Tue, 21 Mar 2006 17:01:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLoul-0001ki-CY for Techspec@ietf.org; Tue, 21 Mar 2006 17:01:19 -0500 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 1FLoIJ-0003TT-E3 for Techspec@ietf.org; Tue, 21 Mar 2006 16:21:35 -0500 Received: from zproxy.gmail.com ([64.233.162.192]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FLo4v-00043e-0l for Techspec@ietf.org; Tue, 21 Mar 2006 16:07:45 -0500 Received: by zproxy.gmail.com with SMTP id x3so1520221nzd for ; Tue, 21 Mar 2006 13:07:44 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:content-type:content-transfer-encoding; b=kT5eFUOcGdH6DffY3l+cKu5g2GrGh4V3maIfObPNnXjvh90Tk+ktBgmnm3mIdbOyMLClrMAN8VO7YZSz7h3B7JVZdop/77ZX9PdPlQFVz/gDPrVwOMMIjJIUOQVY9FboZdh2RUgwzLEtdBZKatkI+/3hvH1qfe1PN72rpQVeMZ8= Received: by 10.36.158.1 with SMTP id g1mr114680nze; Tue, 21 Mar 2006 13:07:43 -0800 (PST) Received: from ?130.129.130.223? ( [130.129.130.223]) by mx.gmail.com with ESMTP id 14sm220313nzp.2006.03.21.13.07.43; Tue, 21 Mar 2006 13:07:43 -0800 (PST) Message-ID: <44206BB4.1020000@googlemail.com> Date: Tue, 21 Mar 2006 15:10:12 -0600 From: Elwyn Davies User-Agent: Thunderbird 1.5 (Windows/20051201) 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.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Subject: [Techspec] Comments on draft-mankin-pub-req-05.txt X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org Some comments on draft-mankin-pub-req-05.txt: s3.7, second para: > > Discussion: IETF allows minor technical corrects during the > > publication process. This should ideally be a rare occurrence, but > > as publication times increase, the number of minor technical > improvements increases. > (editoral aside: s/corrects/corrections/) The phrase 'but as publication times increase' reads like a criticism of throughput , and whilst we may have a problem with this, the issue here is 'in the abstract'. I suggest s/but as publication times increase.. increases/but should time from initial approval to final publication increase, the number of minor technical improvements that might be incorporated is likely to increase correspondingly./ - Certainly we need to keep this time down: the s4.1 proposal seems reasonable and should limit the opportunity for thinking of cunning new tweaks to sneak in under the wire. s3.7: > > Current Req-POSTCORR-2 - The IETF technical publisher should only > > allow post approval technical changes which have been approved by > > the IESG. > > 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. > This requires a certain level of technical savvy and judgment in the technical editors to ensure that they can tell the difference between editorial and technical so as they don't have the wool pulled over their eyes by authors. This is a significant requirement for any organisation that might bid for this work. s3.7, last para: the implication is that there might be multiple source documents - what these are is not really discussed until 3.9: it might be good to either put 3.9 before 3.7 or move the discussion of what constitutes source documents to at or before this point. s3.9, Discussion: I was under the impression that at present the RFC Editor would accept postscript and pdf as well as ascii but does the RFC Editor actually do conversions? In the recent past (last few hundred RFCs) anything other than txt is rare (about 3 pdfs I could find). In general terms the RFC Editor needs more than ascii input to create pdf or postscript output and this certainly doesn't happen by default. s3.16, Potential Req-INDEX-5: Also need to archive any necessary tools and know what version of tools was used to create corresponding output. s3.17: Should be an additional requirement to give access to archived source to (?appropriately authorized) people for the purposes of making derived works (like new versions) or getting MIB sources etc. This may result in an extra item in s5. s3.19: I think that we should explicitly require that the editorial style guide is published. s4.1, Potential Req-TIMEFRAMES-2: 'Documents held up due to references or...': I don't see why this should be a cause for delay of early allocation of an identifier. '...or due to a protocol action should be excluded from this statistic.': I am not sure which action this might refer to. I think this whole sentence is probably a cut and paste error. s4.1/s4.2: The metrics in these two sections define the overall scale of the operation which the IETF is requiring/expecting the technical publisher to perform. I think we could usefully add an extra section indicating how we would task the technical publisher (and hence how the IETf would be charged). Depending on whether we are looking for a Time and Materials contract (the IETF sends documents, the contractor agrees to process them according an SLA based on s4.1 and charges per unit processed) or we agree a Fixed Price contract based on a throughput per unit time as measured in s4.2, and any additional documents have to wait (or are done on a special basis - expedited handling again!). s6: Potential Req-DOCCONVERT-2 in s3.9 would require additional work in the IETF to complete and maintain xml2rfc if it is adopted. Editorial: s3.5, last para (Current Req-FORMALVAL-1): s/xml/XML/ _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Tue Mar 21 22:28:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLu1A-0007uK-RZ; Tue, 21 Mar 2006 22:28:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLu19-0007uF-G1 for Techspec@ietf.org; Tue, 21 Mar 2006 22:28:15 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLu19-0001Gw-22 for Techspec@ietf.org; Tue, 21 Mar 2006 22:28:15 -0500 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 k2M3SD9b024226; Tue, 21 Mar 2006 21:28:13 -0600 Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72) id ; Tue, 21 Mar 2006 21:28:13 -0600 Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C0038024964C1@eusrcmw720.eamcs.ericsson.se> From: "Stephen Hayes (TX/EUS)" To: Elwyn Davies , Techspec@ietf.org Date: Tue, 21 Mar 2006 21:28:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: Subject: [Techspec] RE: Comments on draft-mankin-pub-req-05.txt X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org Thanks for taking the time to review the draft. See my responses below: Stephen > -----Original Message----- > From: Elwyn Davies [mailto:elwynd@googlemail.com] > Sent: Tuesday, March 21, 2006 3:10 PM > To: Techspec@ietf.org > Cc: mankin@psg.com; Stephen Hayes (TX/EUS) > Subject: Comments on draft-mankin-pub-req-05.txt > > > Some comments on draft-mankin-pub-req-05.txt: > > s3.7, second para: > > > > Discussion: IETF allows minor technical corrects during the > > > > publication process. This should ideally be a rare > occurrence, but > > > > as publication times increase, the number of minor technical > > improvements increases. > > > (editoral aside: s/corrects/corrections/) > The phrase 'but as publication times increase' reads like a > criticism of > throughput , and whilst we may have a problem with this, the > issue here > is 'in the abstract'. I suggest s/but as publication times > increase.. > increases/but should time from initial approval to final publication > increase, the number of minor technical improvements that might be > incorporated is likely to increase correspondingly./ - > Certainly we need > to keep this time down: the s4.1 proposal seems reasonable and should > limit the opportunity for thinking of cunning new tweaks to sneak in > under the wire. This certainly wasn't intended to imply a need for longer publication times. I will reword this requirement (although I may not use exactly the suggested words) > > s3.7: > > > > Current Req-POSTCORR-2 - The IETF technical publisher should only > > > > allow post approval technical changes which have been > approved by > > > > the IESG. > > > > > 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. > > > This requires a certain level of technical savvy and judgment in the > technical editors to ensure that they can tell the difference between > editorial and technical so as they don't have the wool pulled > over their > eyes by authors. This is a significant requirement for any > organisation > that might bid for this work. This is an open issue I will raise at the techspec BOF. > > s3.7, last para: the implication is that there might be > multiple source > documents - what these are is not really discussed until 3.9: > it might > be good to either put 3.9 before 3.7 or move the discussion of what > constitutes source documents to at or before this point. We are somewhat vague in the draft about what the source documents are because it's probably not possible to cover all cases. I fear that having a discussion of multiple source documents in the early sections will just detract from the main point of the earlier requirements. If the auxilary source documents are code or formal languages, the technical publisher might be able to validate them but I wouldn't expect the technical publisher to edit them. So in my view, the primary requirement for dealing with multiple source documents doesn't really come until section 3.16 (Potential Req-INDEX-5). However, I can add some early text to indicate that the possiblity of multiple source documents does exist. > > s3.9, Discussion: I was under the impression that at present the RFC > Editor would accept postscript and pdf as well as ascii but > does the RFC > Editor actually do conversions? In the recent past (last few hundred > RFCs) anything other than txt is rare (about 3 pdfs I could > find). In > general terms the RFC Editor needs more than ascii input to > create pdf > or postscript output and this certainly doesn't happen by default. > The only conversion referred to here is creating a postscript and pdf output of an ascii document. No additional conversion is implied. > s3.16, Potential Req-INDEX-5: Also need to archive any > necessary tools > and know what version of tools was used to create > corresponding output. Is this really needed? We are not actually developing products. If both source files and output are archived, isn't it sufficient to indicate that one of them is normative? > > s3.17: Should be an additional requirement to give access to archived > source to (?appropriately authorized) people for the purposes > of making > derived works (like new versions) or getting MIB sources etc. > This may > result in an extra item in s5. I had assumed that all source documents were accessible. Is there a reason to restrict access to a subset of the files? > > s3.19: I think that we should explicitly require that the editorial > style guide is published. I thought the IETF was trying to stay away from an explicit style guide. I had not explicitly assumed that a style guide exists in the requirements. In my experience having a published style guide starts you down the road to fairly bureaucratic processing of documents and only really starts becoming useful when you shift away from ascii or xml generated drafts. > > s4.1, Potential Req-TIMEFRAMES-2: 'Documents held up due to > references > or...': I don't see why this should be a cause for delay of early > allocation of an identifier. '...or due to a > protocol action should be excluded from this > statistic.': I am not > sure which action this might refer to. I think this whole > sentence is > probably a cut and paste error. This sentence isn't a cut and paste error. It was taken out and then added back in. The reason it was put back was that if there is an expected delay in publication (due to dangling references or other reasons) then you don't want to allocate the id early. While a reference delay doesn't prevent you from supplying an early permanent ID, you can't ensure that the final published document will be available in a timely manner. > > s4.1/s4.2: The metrics in these two sections define the > overall scale of > the operation which the IETF is requiring/expecting the technical > publisher to perform. I think we could usefully add an extra section > indicating how we would task the technical publisher (and > hence how the > IETf would be charged). Depending on whether we are looking > for a Time > and Materials contract (the IETF sends documents, the > contractor agrees > to process them according an SLA based on s4.1 and charges per unit > processed) or we agree a Fixed Price contract based on a > throughput per > unit time as measured in s4.2, and any additional documents > have to wait > (or are done on a special basis - expedited handling again!). Although I agree that the contact conditions could effect the quality of service provided, it seems to me to be out of scope of this document. The actual contract conditions will be determined by the contract negotiations. > > s6: Potential Req-DOCCONVERT-2 in s3.9 would require > additional work in > the IETF to complete and maintain xml2rfc if it is adopted. > Yes. Given the usage of xml2rfc, isn't this the defacto case now? > Editorial: > s3.5, last para (Current Req-FORMALVAL-1): s/xml/XML/ ok, Thanks > > > _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Mar 22 10:58:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5ik-0000vt-7c; Wed, 22 Mar 2006 10:58:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5ij-0000sC-7y for Techspec@ietf.org; Wed, 22 Mar 2006 10:58:01 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM5ih-0004lP-TK for Techspec@ietf.org; Wed, 22 Mar 2006 10:58:01 -0500 Received: from [198.18.100.117] (DHCP-Wireless-134-198.ietf65.org [130.129.134.198]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2MFvtW3037005; Wed, 22 Mar 2006 08:57:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4DCBC973AF0D6E4FAF9CD998CE1C0038024964C1@eusrcmw720.eamcs.ericsson.se> References: <4DCBC973AF0D6E4FAF9CD998CE1C0038024964C1@eusrcmw720.eamcs.ericsson.se> Date: Wed, 22 Mar 2006 09:55:51 -0600 To: "Stephen Hayes (TX/EUS)" , Elwyn Davies , Techspec@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [Techspec] Style guides X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org At 9:28 PM -0600 3/21/06, Stephen Hayes (TX/EUS) wrote: > > From: Elwyn Davies [mailto:elwynd@googlemail.com] > > >> s3.19: I think that we should explicitly require that the editorial >> style guide is published. > >I thought the IETF was trying to stay away from an explicit style guide. That would be a Bad Thing. Having a style guide helps reduce the number of edits that a conscientious author will face in Auth48. It is very disconcerting to have, for example, to have the title of your RFC-to-be changed just before it is published based on style considerations that you didn't know about. >I had not explicitly assumed that a style guide exists in the >requirements. In my experience having a published style guide >starts you down the road to fairly bureaucratic processing of >documents and only really starts becoming useful when you shift away >from ascii or xml generated drafts. Going down that road is not a requirement. Many of us who have written books for multiple publishers have seen a range of how bureaucratic the copyediting and formatting of documents based on house style guides. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Mar 22 11:05:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5q5-0006IR-Bu; Wed, 22 Mar 2006 11:05:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5q4-0006H5-9b for Techspec@ietf.org; Wed, 22 Mar 2006 11:05:36 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM5q3-0005Bz-23 for Techspec@ietf.org; Wed, 22 Mar 2006 11:05:36 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FM5q1-0009di-JO; Wed, 22 Mar 2006 16:05:33 +0000 To: "Stephen Hayes (TX/EUS)" Date: Wed, 22 Mar 2006 08:05:33 -0800 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Techspec@ietf.org Subject: [Techspec] Re: Comments on draft-mankin-pub-req-05.txt X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org Message-Id: I too want to thank Elwyn for the detailed somments. > > 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. > This is an open issue I will raise at the techspec BOF. I see as the not the IETF technical publisher's discretion. I would see this as the IETF's policy determination and an Area Director determining. The technical publisher could propose errata but the document shepherd and the final greenlighter of the document (currently the AD) should be the ones who exercise the technical discretion. They should strongly respect the technical publisher's motivation in pushing back post-approval corrections, but not give up their technical accountability. My view. Allison _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Mar 22 12:24:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM74t-0004Zl-OO; Wed, 22 Mar 2006 12:24:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM74r-0004Zd-L4 for Techspec@ietf.org; Wed, 22 Mar 2006 12:24:57 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM74q-0000Xq-Bx for Techspec@ietf.org; Wed, 22 Mar 2006 12:24:57 -0500 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 k2MHOt2P012929; Wed, 22 Mar 2006 11:24:55 -0600 Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72) id ; Wed, 22 Mar 2006 11:24:55 -0600 Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C003802496721@eusrcmw720.eamcs.ericsson.se> From: "Stephen Hayes (TX/EUS)" To: Allison Mankin Date: Wed, 22 Mar 2006 11:24:48 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Techspec@ietf.org Subject: [Techspec] RE: Comments on draft-mankin-pub-req-05.txt X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org Allison Mankin wrote: > > > 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. > > > This is an open issue I will raise at the techspec BOF. > > I see as the not the IETF technical publisher's discretion. > > I would see this as the IETF's policy determination and an Area > Director determining. The technical publisher could propose > errata but the document shepherd and the final greenlighter > of the document (currently the AD) should be the ones who > exercise the technical discretion. They should strongly > respect the technical publisher's motivation in pushing > back post-approval corrections, but not give up their technical > accountability. My view. > > Allison > I agree. The IETF should have final say. The question is how to engineer the process so that the technical publisher's objection and the IETF decision to proceed anyway (or take it back and process) is documented and the decision doesn't fall through the cracks. If the publisher highlights a problem, then the publication of the document should be put on hold. Until the IETF decides what to do with the publisher's objection it is premature to publish the document either with or without the offending changes. The IETF can decide to tell the publisher to: 1. Publish without the changes 2. Publish with all or some subset of the changes 3. Take the document out of the queue to allow rework in IETF. So having the technical publisher reject the offending changes (which is what I had proposed earlier) is insufficient because it implies that publication goes ahead without the offending changes. Having the technical publisher just highlight the concerns to the IETF and proceed with including them and publishing is also inappropriate. So what we need is a state in the publication process where the publication is on hold awaiting feedback from the IETF. This hold shouldn't count against the publisher's performance statistics. My revised opinion (after further thought) Stephen Stephen _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Mar 22 17:07:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMBUX-00036s-D7; Wed, 22 Mar 2006 17:07:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMBUW-00035X-AQ for Techspec@ietf.org; Wed, 22 Mar 2006 17:07:44 -0500 Received: from zproxy.gmail.com ([64.233.162.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMBUV-0004xH-S1 for Techspec@ietf.org; Wed, 22 Mar 2006 17:07:44 -0500 Received: by zproxy.gmail.com with SMTP id x3so219573nzd for ; Wed, 22 Mar 2006 14:07:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=tva8HuDiDTXSlj7QHG0zA+zKBQYQv65Emn2/HYY0niPKa3io8L3W+P1mCJYvMUyRCWrjAwR1xaTkt9nobSuimFFGnAEXc+hEqAQ3Y1OXcLg5T3kifgEs3DwoAokY6vm3O18WKBCrBN7MFfFZ4NLzCeeC+0xd3gqWRBDvG8n8TAA= Received: by 10.36.146.20 with SMTP id t20mr1632390nzd; Wed, 22 Mar 2006 14:07:43 -0800 (PST) Received: from ?130.129.130.223? ( [130.129.130.223]) by mx.gmail.com with ESMTP id 38sm203354nzk.2006.03.22.14.07.34; Wed, 22 Mar 2006 14:07:38 -0800 (PST) Message-ID: <4421CB3C.2090701@googlemail.com> Date: Wed, 22 Mar 2006 16:10:04 -0600 From: Elwyn Davies User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Stephen Hayes (TX/EUS)" References: <4DCBC973AF0D6E4FAF9CD998CE1C0038024964C1@eusrcmw720.eamcs.ericsson.se> In-Reply-To: <4DCBC973AF0D6E4FAF9CD998CE1C0038024964C1@eusrcmw720.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: Techspec@ietf.org Subject: [Techspec] Re: Comments on draft-mankin-pub-req-05.txt X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org Stephen Hayes (TX/EUS) wrote: > Thanks for taking the time to review the draft. See my responses below: > > Stephen > > :-) This mostly seems ok.. responses inline. /elwyn >> -----Original Message----- >> From: Elwyn Davies [mailto:elwynd@googlemail.com] >> Sent: Tuesday, March 21, 2006 3:10 PM >> To: Techspec@ietf.org >> Cc: mankin@psg.com; Stephen Hayes (TX/EUS) >> Subject: Comments on draft-mankin-pub-req-05.txt >> >> >> Some comments on draft-mankin-pub-req-05.txt: >> >> s3.7, second para: >> >>> Discussion: IETF allows minor technical corrects during the >>> >>> publication process. This should ideally be a rare >>> >> occurrence, but >> >>> as publication times increase, the number of minor technical >>> improvements increases. >>> >>> >> (editoral aside: s/corrects/corrections/) >> The phrase 'but as publication times increase' reads like a >> criticism of >> throughput , and whilst we may have a problem with this, the >> issue here >> is 'in the abstract'. I suggest s/but as publication times >> increase.. >> increases/but should time from initial approval to final publication >> increase, the number of minor technical improvements that might be >> incorporated is likely to increase correspondingly./ - >> Certainly we need >> to keep this time down: the s4.1 proposal seems reasonable and should >> limit the opportunity for thinking of cunning new tweaks to sneak in >> under the wire. >> > > This certainly wasn't intended to imply a need for longer publication times. I will reword this requirement (although I may not use exactly the suggested words) > > Fine. >> s3.7: >> >>> Current Req-POSTCORR-2 - The IETF technical publisher should only >>> >>> allow post approval technical changes which have been >>> >> approved by >> >>> the IESG. >>> >>> >>> 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. >>> >>> >> This requires a certain level of technical savvy and judgment in the >> technical editors to ensure that they can tell the difference between >> editorial and technical so as they don't have the wool pulled >> over their >> eyes by authors. This is a significant requirement for any >> organisation >> that might bid for this work. >> > > This is an open issue I will raise at the techspec BOF. > > this has its own thread.... >> s3.7, last para: the implication is that there might be >> multiple source >> documents - what these are is not really discussed until 3.9: >> it might >> be good to either put 3.9 before 3.7 or move the discussion of what >> constitutes source documents to at or before this point. >> > > We are somewhat vague in the draft about what the source documents are because it's probably not possible to cover all cases. I fear that having a discussion of multiple source documents in the early sections will just detract from the main point of the earlier requirements. If the auxilary source documents are code or formal languages, the technical publisher might be able to validate them but I wouldn't expect the technical publisher to edit them. So in my view, the primary requirement for dealing with multiple source documents doesn't really come until section 3.16 (Potential Req-INDEX-5). However, I can add some early text to indicate that the possiblity of multiple source documents does exist. > > That would probably be fne. >> s3.9, Discussion: I was under the impression that at present the RFC >> Editor would accept postscript and pdf as well as ascii but >> does the RFC >> Editor actually do conversions? In the recent past (last few hundred >> RFCs) anything other than txt is rare (about 3 pdfs I could >> find). In >> general terms the RFC Editor needs more than ascii input to >> create pdf >> or postscript output and this certainly doesn't happen by default. >> >> > The only conversion referred to here is creating a postscript and pdf output of an ascii document. No additional conversion is implied. > > Just that as far as I know it is not currently done! >> s3.16, Potential Req-INDEX-5: Also need to archive any >> necessary tools >> and know what version of tools was used to create >> corresponding output. >> > > Is this really needed? We are not actually developing products. If both source files and output are archived, isn't it sufficient to indicate that one of them is normative? > This has been discussed elsewhere. The problem is that if we use xml2rfc, we need to be sure that it is strictly backwards compatible and produces the same output for the old output forever.. otherwise the output is not reproducible. This has some effect on exactly what your 'index'/archive has to maintain - if you can't guarantee to reproduce output then the output MUST be stored securely as well as the source. At the moment,as I understand it, the RFC Editor keeps the nroff as the main archive.. but that may not be the real state of play. > >> s3.17: Should be an additional requirement to give access to archived >> source to (?appropriately authorized) people for the purposes >> of making >> derived works (like new versions) or getting MIB sources etc. >> This may >> result in an extra item in s5. >> > > I had assumed that all source documents were accessible. Is there a reason to restrict access to a subset of the files? > > At the moment the nroff source is not immediately available on line AFAICS. >> s3.19: I think that we should explicitly require that the editorial >> style guide is published. >> > > I thought the IETF was trying to stay away from an explicit style guide. I had not explicitly assumed that a style guide exists in the requirements. In my experience having a published style guide starts you down the road to fairly bureaucratic processing of documents and only really starts becoming useful when you shift away from ascii or xml generated drafts. See separate thread. > > >> s4.1, Potential Req-TIMEFRAMES-2: 'Documents held up due to >> references >> or...': I don't see why this should be a cause for delay of early >> allocation of an identifier. '...or due to a >> protocol action should be excluded from this >> statistic.': I am not >> sure which action this might refer to. I think this whole >> sentence is >> probably a cut and paste error. >> > > This sentence isn't a cut and paste error. It was taken out and then added back in. The reason it was put back was that if there is an expected delay in publication (due to dangling references or other reasons) then you don't want to allocate the id early. While a reference delay doesn't prevent you from supplying an early permanent ID, you can't ensure that the final published document will be available in a timely manner. > OK. I hadn't been following in detail. > >> s4.1/s4.2: The metrics in these two sections define the >> overall scale of >> the operation which the IETF is requiring/expecting the technical >> publisher to perform. I think we could usefully add an extra section >> indicating how we would task the technical publisher (and >> hence how the >> IETf would be charged). Depending on whether we are looking >> for a Time >> and Materials contract (the IETF sends documents, the >> contractor agrees >> to process them according an SLA based on s4.1 and charges per unit >> processed) or we agree a Fixed Price contract based on a >> throughput per >> unit time as measured in s4.2, and any additional documents >> have to wait >> (or are done on a special basis - expedited handling again!). >> > > Although I agree that the contact conditions could effect the quality of service provided, it seems to me to be out of scope of this document. The actual contract conditions will be determined by the contract negotiations. > We'll take this elsewhere! >> s6: Potential Req-DOCCONVERT-2 in s3.9 would require >> additional work in >> the IETF to complete and maintain xml2rfc if it is adopted. >> >> > Yes. Given the usage of xml2rfc, isn't this the defacto case now? > > xml2rfc is still experimental... it would have to be a bit more 'official' if it becomes the archive format. >> Editorial: >> s3.5, last para (Current Req-FORMALVAL-1): s/xml/XML/ >> > > ok, Thanks > >> >> > > _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Thu Mar 23 01:04:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMIvs-0001qN-O4; Thu, 23 Mar 2006 01:04:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMIvs-0001qF-AL for techspec@ietf.org; Thu, 23 Mar 2006 01:04:28 -0500 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMIvr-0000Pm-3y for techspec@ietf.org; Thu, 23 Mar 2006 01:04:28 -0500 Received: from [204.96.114.155] ([::ffff:12.5.186.26]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Thu, 23 Mar 2006 01:03:32 -0500 id 01584387.44223A35.00007DF9 Message-ID: <44223A66.8020004@thinkingcat.com> Date: Thu, 23 Mar 2006 01:04:22 -0500 From: Leslie Daigle User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: techspec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Techspec] (jabber) scribe for tomorrow's meeting? X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org Howdy, Might I have a volunteer or 2 to do jabber/scribing at tomorrow morning's TechSpec BoF? (9am-11:30am). It'll save me terrorizing the room with the Pointing Finger of Random Volunteerization ;-) Thanks, Leslie. _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Mon Mar 27 23:19:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO5fb-0003N2-R9; Mon, 27 Mar 2006 23:19:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO5fa-0003MA-RC for techspec@ietf.org; Mon, 27 Mar 2006 23:19:02 -0500 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO5fa-0005gs-DP for techspec@ietf.org; Mon, 27 Mar 2006 23:19:02 -0500 Received: from [192.168.0.101] ([::ffff:64.102.254.33]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Mon, 27 Mar 2006 23:18:06 -0500 id 015880E5.4428B8FE.00002EE7 Message-ID: <4428B92D.7070907@thinkingcat.com> Date: Mon, 27 Mar 2006 23:18:53 -0500 From: Leslie Daigle User-Agent: Thunderbird 1.5 (Macintosh/20051201) 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.1 (/) X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094 Subject: [Techspec] DRAFT Techspec minutes X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: techspec-bounces@ietf.org Here are DRAFT techspec minutes, courtesy Paul Hoffman -- thanks, Paul! I've fixed a couple of typos, added a word or two, and fixed the formatting... or broken it. The original version didn't fit in 72chars, so the format got lost. I hope I have adequately recreated it. At any rate -- I have posted these as provisional minutes, but fixes still welcome. Leslie. Techspec minutes Taken by Paul Hoffman March 23, 2006 9:00 AM Dallas TX See the slides; these notes go along with them Leslie Daigle So, what is this? Ongoing effort Review of requirements of IETF technical specification requirements Draft is in -05 version, with an active mailing list Intention is to produce a community-reviewed document One piece of a larger puzzle She has posted a timeline for next steps We should be timely so the IAOC can put out their request for interest The times are theoretical but hopefully reasonable Brian Carpenter asked if this would be an IAB or GenArea document Leslie said "probably GenArea" Quick review of what this area is not Status of draft-mankin-pub-req-05.txt Steven Hayes presented for he and Allison Mankin What the document covers Questions on the mailing list about this Covers IETF and IRTF but not independent submissions Doesn't cover what they do leading up to submission, only what the publisher does Document was extensively restructured Long list of publisher tasks, collected from lots of SDOs Some of the requirements are controversial Scott Bradner mentioned that there is also an interface to the public (reading and responding to email) There are performance metrics for how well a publisher is doing Post-approval timeframes Throughput Number of changes generated during publication Author changes that need to be incorporated Allison Mankin mentioned that not having backlogs is a throughput measurement might be useful Eric Rescorla said this is typical IETF micromanagement Why should we tell them which numbers need to be published Wants verbal targets "publish in a timely fashion, don't have a long queue, and turn out reasonable documents" Leslie asked are these the right metrics, or the right kind of metrics Aaron Falk said it is hard to make commitments like this without knowing what the load will be Thomas Narten echoed what Eric said How much of this is high-level BCPish stuff and how much Is administrative stuff Brian said this could be considered informative, not normative Agreed with Eric, should not be coded into an RFC Other SDO have general targets that are reevaluated on an annual basis The metrics should be guidance to the people creating the contract Leslie summarized that the document needs to be clearer that some of these metrics are informative, but some will be normative The community might want to address specifics of what they want There may be some dependencies on some numbers Thomas said he wanted more fuzzy words like "most documents should be published in about a month" Would prefer that the document said "for example" more The contract might use different words than what is in this document Ray Pelletier (IAD) says that we are looking for a steady-flow state This document has gross processing times and net processing times Asks what happens when the input rate goes up? Are we willing to pay more when the time gets longer? Allison said that for some number of documents per year, these are the expected timeframes, but if the number goes up, the timeframes will change These are reasonable numbers that are not micromanagement that are based on gut feelings from people who have to deal with this work Leslie summaries that these number should be in RFP, but a small number will be specific for our work needs Eric says that the things we care about are not the same as the metrics we collect Metrics are a proxy for what we really want If we offer more load, the rates go up because we are having a greater backlog Suggested that maybe use per dollar used per document given to the publisher We should specify which axes we think is important, and the publisher should create reports on those axes John Klensin wants this document to have a 5-10 year lifespan It should have principles and guidelines Stick to the long-term goals Understand that you can't divorce these from the costs Aaron points out that the process is full of exceptions All the parties might have issues that take time to resolve themselves Within each stage, the document can get bogged down The publisher is not the only party who causes delay Expectation have to be set appropriately Only one participant (the publisher) is under contract Leslie wants text Express crisply the invariable metrics, components Frame the overall process with specific text Allison says that there will be some number of documents which have problems that are not under the control of the publisher, but the IETF wants most documents to meet these numbers Leslie isn't sure if this document is the right place to get this nailed down Lucy Lynch wants to deal with the RFP needs to be sensitive to the irregularity of the input to the publisher Brian says this is a standard service contract with expected stochastic inputs We need further documentation on specific services we want from the technical publisher Open issues Style guide Proposal: publish 2223bis instead Aaron said that publishing the style guide as an RFC is a bad idea; have it be a living document in a stable location John said that our style guide is "look at recent RFCs and do things like that" They are lots of pages of small type Brian points to Harald's ipod draft We currently have a problem with not having a stable link Eric said that the most interesting question is should the publisher enforce the style guide, and if so, how Two lists: suggestions for clarity, what will be enforced Ray said the first question will be "what style guide will you want us to use?" Leslie reminds us to focus on what is invariable and what will change over time Who should decide which things are enforced? John said that recent tendency is greater non-technical editing This affects budgets of time for writers and budget for the publisher How much latitude to make stylistic changes? Paul Hoffman said that the style guide will allow authors to reduce the number of diffs in final review Leslie suggested that the RFC Editor needs to say what they are using and how much they are using it, but we don't need to tell them what to use Format Is xml2rfc allowed as input Yaakov Stein asks whether this will completely block drafts that will have PDF Elwyn Davies this has knock-on effect back to the style guide because tools induce some style Stewart Bryant wants to be sure that the contract does not require that we stay in the current format for the duration of the contract Taken off the table by Leslie Can publisher refuse "late changes" Some people felt that the publisher shouldn't be able to make that call Proposal: alert the IESG when it feels that the request is unreasonable; suspend until hearing how to proceed Early allocation of stable identifiers Proposal: have ID allocation as a safety valve, replace the expedited handling process Aaron points out that the ID might be allocated before the appeals timer is out Brian says that that is something we have to do anyway since we expect some RFCs to be out in under two months Leslie says that once something has been approved, you can point to the actual text with an identifier Different from either an ID or RFC state Captures the text that was approved We tie semantics to the name because you know that Internet Drafts are variable and RFCs are permanent Eric is not convinced there is a not a need to exist because it is fiction that you can't point to a particular draft Leslie says it is about our official rules A lot of other organizations will not reference I-Ds, they will copy the whole draft into an annex We're talking about early allocations of RFC numbers Allison suggested the publisher would create a pointer to the place where the document will be published Pointed out that drafts in the RFC Editor queue have expiration dates, confusing users about their status Leslie: we have three states; to what extent do we want to identify the intermediate state? John points out that NewTrack is dealing with additional states and identifiers Scott says that we may be dealing with effects of the long queue, but we're trying to shorten the queue We should not do this Leslie does a straw poll: should we drop the requirement for early permanent identifiers from the document It was a 60/40 split Refined question: how many people would be satisfied in some other venue if we drop it here? Brian points out there is a problem because we get expedited requests with greater frequency Proposed leaving it in but never using it Leslie pushes back on an existing rule that "is never used", takes the issue off the table until there is more clarity Documentation of changes to IETF process Additional drafts might be needed if there are process gaps (such as allocated of early identifiers) Brian pointed out that these are mostly operational Allison says that there needs to be IETF procedural documents that are not part of the RFP Not appropriate to expand the current document Leslie says we just don't worry about them here Remove "potential" and "current" requirements prefix in the document Agreement in the room Aaron has two further open issues RFC Editor has index of what documents update or obsolete other documents Usually/often that is in the document action, but not always Wants the IETF to formalize this and pass it to the publisher Scott asks if the this really the publisher's job vs. the IETF's job? It might not be the right concept Difference between maintaining and publishing such a table John points out that NewTrack has active proposals about this Brian points out that we have to contract this out It might be the technical publisher, or someone else John points out that we have multiple indexes that we have folded together Should the document publisher be allowed to unpublish a document Scott points out that we must be able to take down for some legal reasons People agreed to change "unpublish" to something like "rescind" Paul said that all publishers should be able to do this We don't need to be talking about this Allison disagrees and says we should be listing them Steve says that the requirement is to be able to update status and metadata of the document What more is left to do? Leslie reiterates the schedule No one had issues with the current dates Everyone silently agreed to bring all issues to the mailing list in a timely fashion _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec