From techspec-bounces@ietf.org Thu Oct 06 10:18:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENWa9-0008W1-5U; Thu, 06 Oct 2005 10:18:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENWa8-0008Uh-3r for techspec@megatron.ietf.org; Thu, 06 Oct 2005 10:18:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06496 for ; Thu, 6 Oct 2005 10:18:45 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENWjD-0001gv-G1 for techspec@ietf.org; Thu, 06 Oct 2005 10:28:12 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j96EIau9008556 for ; Thu, 6 Oct 2005 09:18:36 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 6 Oct 2005 16:18:35 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155083CEBFB@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: techspec@ietf.org Date: Thu, 6 Oct 2005 16:18:25 +0200 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: 8ac499381112328dd60aea5b1ff596ea Subject: [Techspec] test - pls ignore X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org Mmm... I got a bounce (you are now un-subscribed) and then a welcome message. Wonder if I am still subscribed. So therefore I am sending this test, that you can ignore. Bert _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Fri Oct 21 12:33:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESzpo-00035x-TL; Fri, 21 Oct 2005 12:33:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESzbM-00024O-5i for techspec@megatron.ietf.org; Fri, 21 Oct 2005 12:18:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16577 for ; Fri, 21 Oct 2005 12:18:28 -0400 (EDT) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESznW-0004L3-4r for techspec@ietf.org; Fri, 21 Oct 2005 12:31:15 -0400 Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id j9LGITY1014052 for ; Fri, 21 Oct 2005 11:18:29 -0500 Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72) id ; Fri, 21 Oct 2005 11:18:29 -0500 Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C0038F775BF@eusrcmw720.eamcs.ericsson.se> From: "Stephen Hayes (TX/EUS)" To: techspec@ietf.org Date: Fri, 21 Oct 2005 11:18:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-Mailman-Approved-At: Fri, 21 Oct 2005 12:33:36 -0400 Subject: [Techspec] Comments on techspec from a user perspective X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org I had a look at mankin-pub-req and I applaud the initiative. From the perspective of a SDO using IETF specs, the the RFC publication process has always been a bit of a black hole. Most other areas of IETF have shown increased transparency, but not the publication process. The draft seems well written but I did have a few comments on the stable permanent identifier at approval experiment: 1. This is something that is really needed by external SDOs. Most SDOs have a very onerous errata process for making an update to insert a RFC reference. The inability to get this 4 digit number in a timely manner leads to undesirable behaviour such as copying the text into annexes. 2. If you have early allocation of a stable permanent identifier, do you still need fast tracking? It seems like Fast Tracking was a method to meet external timelines when you didn't have a way of getting an early RFC number. In general external SDOs just need a reference and an assurance that it will pop out in a reasonable time. 3. As soon as a permanent identifier is allocated, the RFC editor should provide a pointer in the RFC database to the pre-publication version (again with appropriate disclaimers), so that the references can be resolved. 4. Is it really necessary to wait for the two month appeal process to assign a stable permanent identifier? It would seem that the necessary disclaimers could be added to the RFC-TO-BE so that it was clear that references to it carry a risk. 5. Will IETF itself use the stable references? For example, if a draft is in the RFC editor queue waiting for dependencies, can it be published as soon as those dependencies have stable references or will it need to wait for the references to be actually published. Not waiting for actual publication will speed things up, but raises the risk of major ripple effects if a RFC-TO-BE ever has to be withdrawn. IMHO, The RFC editor itself shouldn't publish a RFC until all required references are also published. Thus when you finally get the RFC, you can be sure that it is solid. Regards, Stephen Hayes _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Fri Oct 21 14:45:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET1t5-0005sH-Lq; Fri, 21 Oct 2005 14:45:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET1t3-0005rx-DK for techspec@megatron.ietf.org; Fri, 21 Oct 2005 14:45:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25032 for ; Fri, 21 Oct 2005 14:44:54 -0400 (EDT) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET25D-0001TC-DH for techspec@ietf.org; Fri, 21 Oct 2005 14:57:42 -0400 Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id j9LIislN022243 for ; Fri, 21 Oct 2005 13:44:54 -0500 Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72) id ; Fri, 21 Oct 2005 13:44:53 -0500 Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C0038F775D9@eusrcmw720.eamcs.ericsson.se> From: "Stephen Hayes (TX/EUS)" To: techspec@ietf.org Date: Fri, 21 Oct 2005 13:44:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Subject: [Techspec] Comments on techspec from a user perspective 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: , Content-Type: multipart/mixed; boundary="===============0268079636==" Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0268079636== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D66F.82C91430" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5D66F.82C91430 Content-Type: text/plain; charset="iso-8859-1" I had a look at mankin-pub-req and I applaud the initiative. From the perspective of a SDO using IETF specs, the the RFC publication process has always been a bit of a black hole. Most other areas of IETF have shown increased transparency, but not the publication process. The draft seems well written but I did have a few comments on the stable permanent identifier at approval experiment: 1. This is something that is really needed by external SDOs. Most SDOs have a very onerous errata process for making an update to insert a RFC reference. The inability to get this 4 digit number in a timely manner leads to undesirable behaviour such as copying the text into annexes. 2. If you have early allocation of a stable permanent identifier, do you still need fast tracking? It seems like Fast Tracking was a method to meet external timelines when you didn't have a way of getting an early RFC number. In general SDOs just need a reference and an assurance that it will pop out in a reasonable time. 3. As soon as a permanent identifier is allocated, the RFC editor should provide a pointer in the RFC database to the pre-publication version (again with appropriate disclaimers), so that the references can be resolved. 4. Is it really necessary to wait for the two month appeal process to assign a stable permanent identifier? It would seem that the necessary disclaimers could be added to the RFC-TO-BE so that it was clear that references to it carry a risk. 5. Will IETF itself use the stable references? For example, if a draft is in the RFC editor queue waiting for dependencies, can it be published as soon as those dependencies have stable references or will it need to wait for the references to be actually published. Not waiting for actual publication will speed things up, but raises the risk of major ripple effects if a RFC-TO-BE ever has to be withdrawn. IMHO, The RFC editor itself shouldn't publish a RFC until all required references are also published. Thus when you finally get the RFC, you can be sure that it is solid. Regards, Stephen Hayes ------_=_NextPart_001_01C5D66F.82C91430 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments on techspec from a user perspective

I had a look at mankin-pub-req = and I applaud the initiative.  From the perspective of a SDO using = IETF specs, the the RFC publication process has always been a bit of a = black hole. Most other areas of IETF have shown increased transparency, = but not the publication process. 

The draft seems well written but = I did have a few comments on the stable permanent identifier at = approval experiment:

1. This is something that is = really needed by external SDOs.  Most SDOs have a very onerous = errata process for making an update to insert a RFC reference.  = The inability to get this 4 digit number in a timely manner leads to = undesirable behaviour such as copying the text into annexes.

2. If you have early allocation = of a stable permanent identifier, do you still need fast = tracking?  It seems like Fast Tracking was a method to meet = external timelines when you didn't have a way of getting an early RFC = number. In general SDOs just need a reference and an assurance that it = will pop out in a reasonable time.

3. As soon as a permanent = identifier is allocated, the RFC editor should provide a pointer in the = RFC database to the pre-publication version (again with appropriate = disclaimers), so that the references can be resolved.

4. Is it really necessary to = wait for the two month appeal process to assign a stable permanent = identifier?  It would seem that the necessary disclaimers could be = added to the RFC-TO-BE so that it was clear that references to it carry = a risk.

5. Will IETF itself use the = stable references?  For example, if a draft is in the RFC editor = queue waiting for dependencies, can it be published as soon as those = dependencies have stable references or will it need to wait for the = references to be actually published.  Not waiting for actual = publication will speed things up, but raises the risk of major ripple = effects if a RFC-TO-BE ever has to be withdrawn. 

IMHO, The RFC editor itself = shouldn't publish a RFC until all required references are also = published.  Thus when you finally get the RFC, you can be sure = that it is solid.

Regards,
Stephen Hayes



------_=_NextPart_001_01C5D66F.82C91430-- --===============0268079636== 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 --===============0268079636==-- From techspec-bounces@ietf.org Sun Oct 23 18:42:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EToXd-0001BZ-LF; Sun, 23 Oct 2005 18:42:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EToXc-0001BP-5h for techspec@megatron.ietf.org; Sun, 23 Oct 2005 18:42:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28737 for ; Sun, 23 Oct 2005 18:41:59 -0400 (EDT) Message-Id: <200510232241.SAA28737@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETokE-0001KH-F2 for techspec@ietf.org; Sun, 23 Oct 2005 18:55:15 -0400 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EToXS-0000b4-DR; Sun, 23 Oct 2005 22:42:02 +0000 To: "Stephen Hayes (TX/EUS)" Subject: Re: [Techspec] Comments on techspec from a user perspective Date: Sun, 23 Oct 2005 15:42:02 -0700 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org Thanks Stephen, A bit of uncloaking - Stephen was reading very closely on the way to agreeing to join the document as an author. Having someone in it who's a very substantial user/coordinator of the use of IETF technical specifications seems like a great way to keep it on track. Now to some specific responses to these: > I had a look at mankin-pub-req and I applaud the initiative. From > the perspective of a SDO using IETF specs, the the RFC publication > process has always been a bit of a black hole. Most other areas of > IETF have shown increased transparency, but not the publication > process. > > The draft seems well written but I did have a few comments on the stable > permanent identifier at approval experiment: > > 1. This is something that is really needed by external SDOs. Most SDOs have a > very onerous errata process for making an update to insert a RFC reference. > The inability to get this 4 digit number in a timely manner leads to undesirable > behaviour such as copying the text into annexes. > > 2. If you have early allocation of a stable permanent identifier, do you still > need fast tracking? It seems like Fast Tracking was a method to meet external > timelines when you didn't have a way of getting an early RFC number. In general > external SDOs just need a reference and an assurance that it will pop out in a > reasonable time. I will add a comment about the experiment leading to not needing Fast Tracking. If the experiment were a success the usage would be that the i-d with the permanent-identifier in it would provide both the stable technical content and the bibliographic constructor needed by the SDO. > > 3. As soon as a permanent identifier is allocated, the RFC editor should > provide a pointer in the RFC database to the pre-publication version (again with > appropriate disclaimers), so that the references can be resolved. Note that in this document we're talking mostly about the technical publisher, rather than specifically about the RFC Editor service. But the section is about an experiment that this document proposes, with the RFC Editor, similar to the Early Copy Edit experiment. So I am going to edit the document to ask that in the database of the RFC Editor, the pending document would be this pre-publication draft with its permanent identifier. In at least some cases, this would happen naturally, because the RFC Editor refers to the IETF's internet-draft, which would be this new type of draft. > > 4. Is it really necessary to wait for the two month appeal process to assign a > stable permanent identifier? It would seem that the necessary disclaimers > could be added to the RFC-TO-BE so that it was clear that references to it carry a > risk. Your question is echoed by several others - the two month delay was originally proposed to me in a private chat by another AD but it has been questioned to me privately by others in the IESG. The case of revoked approval is very rare, though this year very oddly it occurred twice, in one case due to an appeal, in another case after an interoperability problem. Both cases are expected to result in re-approval. We should call for explicit consensus on this point for this part of the document as we progress in discussion. > > 5. Will IETF itself use the stable references? For example, if a draft is in > the RFC editor queue waiting for dependencies, can it be published as soon as > those dependencies have stable references or will it need to wait for the > references to be actually published. Not waiting for actual publication will > speed things up, but raises the risk of major ripple effects if a RFC-TO-BE > ever has to be withdrawn. > > IMHO, The RFC editor itself shouldn't publish a RFC until all required > references es are also published. Thus when you finally get the RFC, > you can be sure that it is solid. > Figure 1 distinguishes the technical publisher pretty clearly from the IETF. But the draft probably should do so better. Your point though is that the RFC Editor (to go back to the experiment) would not push out a document which has still in the form of permanent stable identifiers. That's right. So we may still have an IETF request to make of the RFC Editor, to get these documents published when there are clusters of them waiting on the queue for periods of time. As far as withdrawal of documents: the reference issue (the formal part) is the tip of the iceberg. If there's an appeal or other problem, the AD and WG shepherds in technology dependent on that need to be alert to substantive fallout - this is a tiny aspect. _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Tue Oct 25 11:56:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EURA6-0004lm-EO; Tue, 25 Oct 2005 11:56:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EURA5-0004lh-R1 for techspec@megatron.ietf.org; Tue, 25 Oct 2005 11:56:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01404 for ; Tue, 25 Oct 2005 11:56:14 -0400 (EDT) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EURN3-0000Ug-29 for techspec@ietf.org; Tue, 25 Oct 2005 12:09:55 -0400 Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id j9PFu3kp017044 for ; Tue, 25 Oct 2005 10:56:04 -0500 Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72) id ; Tue, 25 Oct 2005 10:56:03 -0500 Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C0038F77767@eusrcmw720.eamcs.ericsson.se> From: "Stephen Hayes (TX/EUS)" To: techspec@ietf.org Subject: RE: [Techspec] Comments on techspec from a user perspective Date: Tue, 25 Oct 2005 10:55:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org I'm not sure my point 5 was clear. One requirement on a technical publisher is that they generally verify the references in a document to be published are valid. The stable reference plan proposed in the experiment should be adequate to satisfy that criteria and will allow SDOs to go ahead with approval and publication of documents with a RFC reference even before a RFC is formally published (provided they are willing to accept a small risk). My question, should the IETF technical publisher also follow this practice with respect to RFC references? This policy would allow documents to be published earlier, however the risk is compounded within IETF as it would be possible to create reference chains where few of the documents actually are RFCs. I single failure in the chain would lead to problems. In analogy, most other SDOs assign their stable references early in the process. They also often approve clumps of documents at a time. References between the documents in the group are quite common. The publisher typically does not publish any of the documents until all the references (within that SDO) have been or are ready to be published. Stephen > > 5. Will IETF itself use the stable references? For > example, if a draft is in > > the RFC editor queue waiting for dependencies, can it be > published as soon as > > those dependencies have stable references or will it need > to wait for the > > references to be actually published. Not waiting for > actual publication will > > speed things up, but raises the risk of major ripple > effects if a RFC-TO-BE > > ever has to be withdrawn. > > > > IMHO, The RFC editor itself shouldn't publish a RFC until > all required > > references es are also published. Thus when you finally > get the RFC, > > you can be sure that it is solid. > > > > Figure 1 distinguishes the technical publisher pretty clearly > from the IETF. But the draft probably should do so better. > > Your point though is that the RFC Editor (to go back to > the experiment) would not push out a document which > has still in the form of permanent stable identifiers. > That's right. So we may still have an IETF request to make > of the RFC Editor, to get these documents published when there > are clusters of them waiting on the queue for periods of time. > > As far as withdrawal of documents: the reference issue (the > formal part) is the tip of the iceberg. If there's an appeal > or other problem, the AD and WG shepherds in technology > dependent on that need to be alert to substantive fallout - > this is a tiny aspect. > > > _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Oct 26 09:13:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUl5f-0006W6-QQ; Wed, 26 Oct 2005 09:13:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUl5d-0006UW-PL for techspec@megatron.ietf.org; Wed, 26 Oct 2005 09:13:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18574 for ; Wed, 26 Oct 2005 09:12:58 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUlIn-00016p-3G for techspec@ietf.org; Wed, 26 Oct 2005 09:26:50 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j9QDCq44001210; Wed, 26 Oct 2005 08:12:55 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 26 Oct 2005 15:12:51 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508650D32@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Stephen Hayes (TX/EUS)" , techspec@ietf.org Subject: RE: [Techspec] Comments on techspec from a user perspective Date: Wed, 26 Oct 2005 15:12:48 +0200 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: 34d35111647d654d033d58d318c0d21a Cc: X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org Speaking as an individual I personally think that our primary requirement is that an approved document gets formally published ASAP. In my view I'd even like to state that we would want it published within a week or two at most. And so then all the "early stable references issues" go away. The discussion about "early stable references" in my view is caused by the fact that we currently have a lag-time of what 4-6 months (or sometimes even more) for approved documents. Only if it turns out that our primary requirement of "get the RFC published within a week or two after approval" cannot be met by any publication-service-provider, only then do I think we should have this discussion. Bert > -----Original Message----- > From: techspec-bounces@ietf.org [mailto:techspec-bounces@ietf.org]On > Behalf Of Stephen Hayes (TX/EUS) > Sent: Tuesday, October 25, 2005 17:56 > To: techspec@ietf.org > Subject: RE: [Techspec] Comments on techspec from a user perspective > > > I'm not sure my point 5 was clear. > > One requirement on a technical publisher is that they > generally verify the references in a document to be published > are valid. The stable reference plan proposed in the > experiment should be adequate to satisfy that criteria and > will allow SDOs to go ahead with approval and publication of > documents with a RFC reference even before a RFC is formally > published (provided they are willing to accept a small risk). > > My question, should the IETF technical publisher also follow > this practice with respect to RFC references? This policy > would allow documents to be published earlier, however the > risk is compounded within IETF as it would be possible to > create reference chains where few of the documents actually > are RFCs. I single failure in the chain would lead to problems. > > In analogy, most other SDOs assign their stable references > early in the process. They also often approve clumps of > documents at a time. References between the documents in the > group are quite common. The publisher typically does not > publish any of the documents until all the references (within > that SDO) have been or are ready to be published. > > Stephen > > > > 5. Will IETF itself use the stable references? For > > example, if a draft is in > > > the RFC editor queue waiting for dependencies, can it be > > published as soon as > > > those dependencies have stable references or will it need > > to wait for the > > > references to be actually published. Not waiting for > > actual publication will > > > speed things up, but raises the risk of major ripple > > effects if a RFC-TO-BE > > > ever has to be withdrawn. > > > > > > IMHO, The RFC editor itself shouldn't publish a RFC until > > all required > > > references es are also published. Thus when you finally > > get the RFC, > > > you can be sure that it is solid. > > > > > > > Figure 1 distinguishes the technical publisher pretty clearly > > from the IETF. But the draft probably should do so better. > > > > Your point though is that the RFC Editor (to go back to > > the experiment) would not push out a document which > > has still in the form of permanent stable identifiers. > > That's right. So we may still have an IETF request to make > > of the RFC Editor, to get these documents published when there > > are clusters of them waiting on the queue for periods of time. > > > > As far as withdrawal of documents: the reference issue (the > > formal part) is the tip of the iceberg. If there's an appeal > > or other problem, the AD and WG shepherds in technology > > dependent on that need to be alert to substantive fallout - > > this is a tiny aspect. > > > > > > > > _______________________________________________ > 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 Oct 26 10:15:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUm4F-0000GH-DL; Wed, 26 Oct 2005 10:15:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUm4E-0000GC-3j for techspec@megatron.ietf.org; Wed, 26 Oct 2005 10:15:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22428 for ; Wed, 26 Oct 2005 10:15:34 -0400 (EDT) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUmHN-0003Bd-VB for techspec@ietf.org; Wed, 26 Oct 2005 10:29:27 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 73CD82596BE; Wed, 26 Oct 2005 16:15:00 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18788-07; Wed, 26 Oct 2005 16:14:56 +0200 (CEST) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3935D2596BD; Wed, 26 Oct 2005 16:14:54 +0200 (CEST) Date: Wed, 26 Oct 2005 07:15:25 -0700 From: Harald Tveit Alvestrand To: "Wijnen, Bert (Bert)" , "Stephen Hayes (TX/EUS)" , techspec@ietf.org Subject: RE: [Techspec] Comments on techspec from a user perspective Message-ID: In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15508650D32@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B15508650D32@nl0006exch001u.nl.luce nt.com> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0522036295==" Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org --===============0522036295== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========304EC0F2FC86AFDD4D0A==========" --==========304EC0F2FC86AFDD4D0A========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable My thought (speaking out of turn because I haven't read the techspec = draft): - We need to have our approved texts referencable and findable - This needs to be true SOON after approval (the urgency varies from=20 document to document) - The ideal way to do this is to have it published in our permanent=20 document series (RFCs) the day after approval. This may be unrealistic. - The current way is to use draft name + knowledge of approval in the 4=20 months until the RFC pops out. That is painful. One note about our current "expedited number" process: The formal request from the IESG to the RFC Editor is for an early number=20 assignment (permanent identifier). The RFC Editor has chosen to accelerate=20 publication of these documents on such a request, because the RFC Editor=20 believes that this lessens the chance of problems that might derail the=20 publication of the doucment. Assigning permanent identifiers is not the heart of the problem. --On 26. oktober 2005 15:12 +0200 "Wijnen, Bert (Bert)"=20 wrote: > Speaking as an individual > > I personally think that our primary requirement is that an approved > document gets formally published ASAP. In my view I'd even like to > state that we would want it published within a week or two at most. > And so then all the "early stable references issues" go away. > > The discussion about "early stable references" in my view is caused > by the fact that we currently have a lag-time of what 4-6 months > (or sometimes even more) for approved documents. > > Only if it turns out that our primary requirement of "get the RFC > published within a week or two after approval" cannot be met by > any publication-service-provider, only then do I think we should > have this discussion. --==========304EC0F2FC86AFDD4D0A========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFDX499OMj+2+WY0F4RApEZAKDY3sE2q0X4swsJUzfcY8xBEFUdiQCfe2XD 3zvB7IKyoBVME2Ma9ojhDJs= =E5Rg -----END PGP SIGNATURE----- --==========304EC0F2FC86AFDD4D0A==========-- --===============0522036295== 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 --===============0522036295==-- From techspec-bounces@ietf.org Wed Oct 26 11:12:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUmwv-0001ck-EO; Wed, 26 Oct 2005 11:12:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUmwu-0001a3-DL for techspec@megatron.ietf.org; Wed, 26 Oct 2005 11:12:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00038 for ; Wed, 26 Oct 2005 11:12:04 -0400 (EDT) Message-Id: <200510261512.LAA00038@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUnA4-0006Ut-Vj for techspec@ietf.org; Wed, 26 Oct 2005 11:25:58 -0400 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EUmwr-000BzJ-C1; Wed, 26 Oct 2005 15:12:17 +0000 To: Harald Tveit Alvestrand , Bert Wijnen Subject: Re: [Techspec] Comments on techspec from a user perspective Date: Wed, 26 Oct 2005 08:12:17 -0700 From: Allison Mankin 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 Reply-To: mankin@psg.com List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org The basic principle in the draft is that the document once approved by the IETF has become a standard and the large community now needs to use it. The technical publishing step adds tremendous value to our specifications, but it is not responsible for the technical standards content and approval, those are done when IETF sends out the announcements, and the users are ready to use them then in some form. In the draft I point out that our final i-ds include the statement that they expire. This signals the users (naturally) that the documents are not stable. But also, like us, and as Stephen stated, our users want to include references, and they can't reference the unstable bibliographic reference, the i-d. It's just like us with normative references. As Bert and you stated, this would be made moot if the technical publication stage completed very quickly. But since the technical publisher has a different functional role than the standards developer (IETF), it has different events that can occur. It is staffed differently. It can have this excellent goal of always gettling the every document out in one month, but then a few documents meet with non-responsive authors, the queue builds up, some staff turns over, other circumstances arise, and if the IETF has hinged providing references on publication, it is not able to do so quickly. Separating the functions - making a parallel flow - seems efficient. The technical publisher can continue to work very hard to maintain high throughput on its production, but meanwhile the IETF can provide its users with access to reference and stable though not perfect versions (pre-publication) of the specifications at the time when they become standards. Allison _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Oct 26 11:55:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUncU-0004NK-E8; Wed, 26 Oct 2005 11:55:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUncT-0004MR-Io for techspec@megatron.ietf.org; Wed, 26 Oct 2005 11:55:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03108 for ; Wed, 26 Oct 2005 11:55:01 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUnpe-00080R-2Y for techspec@ietf.org; Wed, 26 Oct 2005 12:08:55 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j9QFsmb26690; Wed, 26 Oct 2005 18:54:50 +0300 Date: Wed, 26 Oct 2005 18:54:48 +0300 (EEST) From: Pekka Savola To: "Wijnen, Bert (Bert)" In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15508650D32@nl0006exch001u.nl.lucent.com> Message-ID: References: <7D5D48D2CAA3D84C813F5B154F43B15508650D32@nl0006exch001u.nl.lucent.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: techspec@ietf.org Subject: [Techspec] permanent identifier at approval X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org Hi, On Wed, 26 Oct 2005, Wijnen, Bert (Bert) wrote: > Speaking as an individual > > I personally think that our primary requirement is that an approved > document gets formally published ASAP. In my view I'd even like to > state that we would want it published within a week or two at most. > And so then all the "early stable references issues" go away. > > The discussion about "early stable references" in my view is caused > by the fact that we currently have a lag-time of what 4-6 months > (or sometimes even more) for approved documents. > > Only if it turns out that our primary requirement of "get the RFC > published within a week or two after approval" cannot be met by > any publication-service-provider, only then do I think we should > have this discussion. I've stated this point offlist before the mailing list was set up but will do so again (I think I agree with Bert): It doesn't seem that the procedure in section 5.2 ("Stable Permanent Identifier at Approval") buys much compared to the complexity. I feel for the same amount of energy used in the extra steps one could actually just simply publish the document and the whole point would be moot. One tricky thing the doc raises is the two-month appeals timeout after the approval. Does that need to pass before a document should be published? If it does, any "permanent identifier immediately" scheme for faster than 2-month service seems invalid. (Personally, I don't think it should pass; if there is a problem with the approval and the RFC has already been published, the category of the RFC can just be changed later.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Oct 26 12:03:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUnk9-0008Jn-Bk; Wed, 26 Oct 2005 12:03:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUnk7-0008JI-6G for techspec@megatron.ietf.org; Wed, 26 Oct 2005 12:03:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03528 for ; Wed, 26 Oct 2005 12:02:54 -0400 (EDT) Message-Id: <200510261602.MAA03528@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUnxH-0008Dt-Dd for techspec@ietf.org; Wed, 26 Oct 2005 12:16:48 -0400 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EUnjp-000FPi-Fa; Wed, 26 Oct 2005 16:02:53 +0000 To: "Stephen Hayes (TX/EUS)" Subject: Re: [Techspec] SPI: Comments on techspec from a user perspective Date: Wed, 26 Oct 2005 09:02:53 -0700 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org [I've added the label, SPI, for stable permanent identifier, to the subject line - should have that in my previous message too.] Stephen, I may still not quite understand the question, but I think the answer is that to get a stable permanent identifier a document has to have stable permament identifiers for all of its normative references as well. This is complicating but not devastating. First, the document shepherds need to pay attention to the status of documents that are normative, paring them to just the ones that actually do matter and making sure those are making progress (ideally making sure they are complete or nearly complete, because if they're going to change a lot, your technology may be on shifting ground). Bill Fenner developed a tool that creates daily visual maps of the normative dependency webs for every working group. These are easy to find linked from the pages at: tools.ietf.org/wg// Allison _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Oct 26 12:27:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUo7F-0000x9-4M; Wed, 26 Oct 2005 12:27:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUo7D-0000wB-W9 for techspec@megatron.ietf.org; Wed, 26 Oct 2005 12:27:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05712 for ; Wed, 26 Oct 2005 12:26:48 -0400 (EDT) Message-Id: <200510261626.MAA05712@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUoKP-0000q5-5B for techspec@ietf.org; Wed, 26 Oct 2005 12:40:42 -0400 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EUo7A-000GxJ-9R; Wed, 26 Oct 2005 16:27:00 +0000 To: Pekka Savola Subject: Re: [Techspec] permanent identifier at approval Date: Wed, 26 Oct 2005 09:27:00 -0700 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org Pekka, In the new draft, the two month delay for waiting for appeals is reconsidered in general. Probably not as clearly as it should be. I think we could do some form of not delaying for the appeals process, but again, I think we only have control over the IETF's part of the document activity, so in my view, putting out the stable permanent identifier form of the document predictably in a month would be a good way to handle this. For getting the full document out that quickly, this group had best look at all the techspec requirements as a whole. The following from -01 was written from much experience, with many many documents, and many expedited documents, where we had to get everyone in line to do the process fast: Note that this requirement is heavily interdependent with other requirements. It has implications for authors, editors, and protocol parameter assignment personnel: they must be committed to timely action for their followup on any final reviews, changes, and actions needed post-approval. (Small delays add up shockingly if one is looking for a month or two month turn-around; the AD and working group shepherd really have to act as herders on this). Reviewing for final, forever publication is hard to corral people to do right, in my experience. Allison _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Oct 26 12:58:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUobx-0001bD-JC; Wed, 26 Oct 2005 12:58:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUobu-0001aG-2d for techspec@megatron.ietf.org; Wed, 26 Oct 2005 12:58:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07282 for ; Wed, 26 Oct 2005 12:58:29 -0400 (EDT) Message-Id: <200510261658.MAA07282@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUop5-0001jm-Jp for techspec@ietf.org; Wed, 26 Oct 2005 13:12:24 -0400 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EUobq-000IxZ-BV; Wed, 26 Oct 2005 16:58:42 +0000 To: Pekka Savola Subject: Re: [Techspec] permanent identifier at approval Date: Wed, 26 Oct 2005 09:58:42 -0700 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org Pekka, > Only if it turns out that our primary requirement of "get the RFC > published within a week or two after approval" cannot be met by By the way, we have not got agreement among all of us that that is a feasible requirement; it's a metric that could be placed, but we have to agree on the input requirements for the service and on our interactions with the technical publisher (that is the point of my other post). Let's put it on an issues list, but let's look at the list of input requirements: requirements on the technical publications service and requirements that are placed on IETF/publisher interaction. A starting set is in draft-mankin-pub-req-01.txt I mean to run an issues list, but let me check for a good setup. Allison _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Oct 26 15:06:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUqbl-000396-Ok; Wed, 26 Oct 2005 15:06:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUqbk-000387-Qv for techspec@megatron.ietf.org; Wed, 26 Oct 2005 15:06:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15014 for ; Wed, 26 Oct 2005 15:06:29 -0400 (EDT) Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUqov-0005rZ-2e for techspec@ietf.org; Wed, 26 Oct 2005 15:20:24 -0400 Received: from [192.35.165.156] ([::ffff:128.107.248.220]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Wed, 26 Oct 2005 15:05:51 -0400 id 0158806D.435FD38F.000075D7 Message-ID: <435FD38C.30503@thinkingcat.com> Date: Wed, 26 Oct 2005 15:05:48 -0400 From: Leslie Daigle User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: techspec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Subject: [Techspec] Agenda -- update? X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org Howdy, Here is the agenda as currently posted for the TechSpec BoF: > Agenda > ------ > > 1. Overview & Introduction [BoF Chair] > 2. Review and discussion of draft-mankin-pub-req [Allison Mankin] > 3. Discussion of any other requirements > 4. Update from experiment in early copy editing [Bert Wijnen, RFC > Editor] > 5. Determination of where from here for requirements documentation. Here's a proposed tweak of the agenda, based on discussion so far: Agenda ------ 0. Agenda bash [Leslie, all] 1. Overview & Introduction [Leslie] . why are we here . what we are *not* here for . scope of "requirement" 2. Review and discussion of draft-mankin-pub-req-01 [Allison Mankin] 3. Discussion of any other requirements 4. Update from experiment in early copy editing [Bert Wijnen, RFC Editor] 5. Determination of where from here for requirements documentation. Are there any updates we should make before Oct 31? (And we can bash again in the session). By way of reminder: > Out of scope for this BoF > ------------------------- > > 1/ The term "technical specification" is used here purposefully > to refer to the technical output of the IETF -- debate about > whether it is expressed as RFCs or ISDs, what "is" an RFC, etc, is out > of scope. > > 2/ Critique of the existing RFC Editor/publication activity is out of > scope, although illustrations of requirements based on RFC experience > will be acceptable as appropriate to the BoF's constructive focus. > > 3/ Discussion of specific publication formats is out of > scope. A goal of this discussion is to cover the full process of > technical specification publication, from beginning-to- > end specification tracking, to errata. To cover all > of that, and to keep the discussion at the level of requirement > (not implementation), the question of publication formats > needs to be out of scope of this discussion. > > Once there is community agreement on what the basic requirements are, > there will be a separate discussion of how to map this to existing, > modified, or new publication activities -- thereby addressing the > out of scope points above. To the extent that requirements are > determined to be mechanical in nature, next steps will be carried out > under the auspices of the IASA. For other issues identified, further > community discussions, documentation, and IETF process updates will be > undertaken as appropriate. Thanks, Leslie. _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Oct 26 16:45:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUs9G-0001vm-OY; Wed, 26 Oct 2005 16:45:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUs9F-0001r5-7g for techspec@megatron.ietf.org; Wed, 26 Oct 2005 16:45:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13498 for ; Wed, 26 Oct 2005 16:45:09 -0400 (EDT) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUsMS-0000Gl-Js for techspec@ietf.org; Wed, 26 Oct 2005 16:59:05 -0400 Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id j9QKjEYI001775; Wed, 26 Oct 2005 15:45:14 -0500 Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72) id ; Wed, 26 Oct 2005 15:45:14 -0500 Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C0038F7786C@eusrcmw720.eamcs.ericsson.se> From: "Stephen Hayes (TX/EUS)" To: Allison Mankin , Pekka Savola Subject: RE: [Techspec] permanent identifier at approval Date: Wed, 26 Oct 2005 15:45:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 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: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org Publishing specs within two weeks is certainly possible. Within 3GPP, 90% of the specifications are published within 2 weeks of approval, 100% are published within 3 weeks of approval. However to do so requires the necessary allocation of resources. In 3GPP this is essentially the equivalent of having a dedicated full time secretary per WG to track and edit the documents. I don't see this level of resource committment occuring within IETF. In lieu of this, then I think the early allocation of permanent identifiers is a good second choice. Stephen Hayes > -----Original Message----- > From: techspec-bounces@ietf.org [mailto:techspec-bounces@ietf.org]On > Behalf Of Allison Mankin > Sent: Wednesday, October 26, 2005 11:59 AM > To: Pekka Savola > Cc: techspec@ietf.org > Subject: Re: [Techspec] permanent identifier at approval > > > Pekka, > > > Only if it turns out that our primary requirement of "get the RFC > > published within a week or two after approval" cannot be met by > > By the way, we have not got agreement among all of us that that > is a feasible requirement; it's a metric that could be placed, > but we have to agree on the input requirements for the service > and on our interactions with the technical publisher (that is > the point of my other post). > > Let's put it on an issues list, but let's look at the list > of input requirements: requirements on the technical publications > service and requirements that are placed on IETF/publisher > interaction. > > A starting set is in draft-mankin-pub-req-01.txt > > I mean to run an issues list, but let me check for a good setup. > > Allison > > _______________________________________________ > 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 Oct 26 20:09:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUvKs-0006D3-1i; Wed, 26 Oct 2005 20:09:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUvK1-0004kY-P9 for techspec@megatron.ietf.org; Wed, 26 Oct 2005 20:08:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06045 for ; Wed, 26 Oct 2005 20:08:26 -0400 (EDT) Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUvXB-0006FU-Bu for techspec@ietf.org; Wed, 26 Oct 2005 20:22:24 -0400 Received: from [192.35.165.156] ([::ffff:128.107.248.220]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Wed, 26 Oct 2005 20:08:25 -0400 id 0158806D.43601A79.00003114 Message-ID: <43601A76.4030803@thinkingcat.com> Date: Wed, 26 Oct 2005 20:08:22 -0400 From: Leslie Daigle User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: techspec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Subject: [Techspec] publication times & stable identifiers X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org First, I observe that the -01 draft doesn't seem to be in the I-D repository yet. For our discussion purposes this week, I'll observe that Allison has made a copy available at: http://psg.com/~mankin/draft-mankin-pub-req-01.txt From a discussion point of view, I would like us to keep a the clean separation between discussion of: 1/ Requirement on time from approval to publication Current text: Req-5 Published document at a predictable time after approval Discussion on list: Bert: 1-2 weeks Stephen: doable in 2 weeks, 3 max, at 3GPP *with* dedicated WG secretaries to pursue the document I'd like to hear what we think is the *requirement* for the *IETF* in terms of publication times -- is it as it stands now in the text? Or is there a specific timeframe in which it is required (for purposes of implementation, interaction with other SDOs, etc). I'd like to explicitly leave aside the discussion of "how fast do we think we can really do it" for the moment. 2/ Point at which *a* stable reference is available Current text: Req-4 Stable permanent reference one or two months after approval Discussion on list: We need it sooner than that. So, the question is how soon do we need a stable reference after approval -- IRRESPECTIVE of whether the document is published at that time. We can come back to determining whether this collapses into "permanent identifier is the published identifier because we publish fast enough" *after* we discuss them independently. Leslie. _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Oct 26 21:07:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUwF5-0005BU-9X; Wed, 26 Oct 2005 21:07:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUwF4-00056u-1a for techspec@megatron.ietf.org; Wed, 26 Oct 2005 21:07:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12314 for ; Wed, 26 Oct 2005 21:07:26 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUwSK-0001JK-Ih for techspec@ietf.org; Wed, 26 Oct 2005 21:21:25 -0400 Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9R17URd038967; Wed, 26 Oct 2005 18:07:34 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <43601A76.4030803@thinkingcat.com> References: <43601A76.4030803@thinkingcat.com> Date: Wed, 26 Oct 2005 18:07:04 -0700 To: Leslie Daigle , techspec@ietf.org From: Paul Hoffman Subject: Re: [Techspec] publication times & stable identifiers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org At 8:08 PM -0400 10/26/05, Leslie Daigle wrote: >1/ Requirement on time from approval to publication > >Current text: > > Req-5 Published document at a predictable time after approval > >Discussion on list: > > Bert: 1-2 weeks > Stephen: doable in 2 weeks, 3 max, at 3GPP *with* dedicated > WG secretaries to pursue the document > >I'd like to hear what we think is the *requirement* for the *IETF* >in terms of publication times -- is it as it stands now in >the text? Or is there a specific timeframe in which it is >required (for purposes of implementation, interaction with other >SDOs, etc). I'd like to explicitly leave aside the discussion of >"how fast do we think we can really do it" for the moment. It is a requirement for the IETF that a document always be in a predictable state. Current practice has shown us where that goes wrong. Because the time between approval and publication is almost always long (that is, more than three months), "things change" after approval. a) Small editorial problems are found and are promised to be fixed in AUTH48. b) Serious technical errors are found. c) Implementers start implementing the "standard" even if there are values in the Internet Draft that are known to be changing in the RFC. (a) is not a problem for predictability, unless authors forget some of the items (which happens, of course). (b) is a real problem. There is often pressure to fix non-editorial problems in AUTH48 because the alternative is to pull back the draft, ask the IESG to rescind the approval, prepare another rev of the draft, (possibly) go through IETF last call again, and go through IESG approval again. (c) is also a real problem. It causes jockeying among implementers to choose which of the two values they should ship. It causes many implementers to delay shipping, which means that the protocol gets less use than it might. Given the requirement that an approved document be in a predictable state, I would agree with Bert and Stephen on the 1-2 weeks. That is a short enough period where no one would expect absolute stability, and if it is a predictable length, implementers will just wait until publication. Beyond two weeks, the problems in (c) start to loom. >2/ Point at which *a* stable reference is available > >Current text: > > Req-4 Stable permanent reference one or two months after > approval > >Discussion on list: > > We need it sooner than that. > > >So, the question is how soon do we need a stable reference after >approval -- IRRESPECTIVE of whether the document is published >at that time. This is impossible to state in general, particularly because different outside body have different "needs". Some of them are gated to a calendar, and if the IESG approves a standard at one time, the outside body might need the stable reference the next week, but if the IESG approved the standard two weeks later, the same body might not need the stable reference for another three months. It really depends on the particular path the particular body's own documents is taking. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Wed Oct 26 21:33:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUweH-0006ml-59; Wed, 26 Oct 2005 21:33:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUweG-0006md-6i for techspec@megatron.ietf.org; Wed, 26 Oct 2005 21:33:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14058 for ; Wed, 26 Oct 2005 21:33:29 -0400 (EDT) Message-Id: <200510270133.VAA14058@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUwrV-0002AQ-9B for techspec@ietf.org; Wed, 26 Oct 2005 21:47:27 -0400 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EUwe6-000200-6m; Thu, 27 Oct 2005 01:33:34 +0000 To: Leslie Daigle Subject: Re: [Techspec] publication times & stable identifiers Date: Wed, 26 Oct 2005 18:33:34 -0700 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org Leslie, all, If people look at Figure 1 to think about what the timeframe from approval to publication means now, note that it needs a correction, because it currently shows IANA review during the Post-WG, Pre-approval, but it accidentally omitted the IANA actions during Post-Approval (by accident). Leslie wrote: 1/ Requirement on time from approval to publication Current text: Req-5 Published document at a predictable time after approval Discussion on list: Bert: 1-2 weeks Stephen: doable in 2 weeks, 3 max, at 3GPP *with* dedicated WG secretaries to pursue the document _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Thu Oct 27 12:29:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVAcq-0002Z4-5y; Thu, 27 Oct 2005 12:29:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVAco-0002VV-Is for techspec@megatron.ietf.org; Thu, 27 Oct 2005 12:29:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11859 for ; Thu, 27 Oct 2005 12:28:53 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVAqC-0002Al-4M for techspec@ietf.org; Thu, 27 Oct 2005 12:43:00 -0400 Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9RGT2JM031996 for ; Thu, 27 Oct 2005 09:29:03 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 27 Oct 2005 09:28:59 -0700 To: techspec@ietf.org From: Internet-Drafts@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.3 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: [Techspec] I-D ACTION:draft-mankin-pub-req-01.txt X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org 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-01.txt Pages : 20 Date : 2005-10-27 The work of the IETF is to discuss, develop and disseminate technical specifiations to support the Internet's operation. As the the IETF progresses, document and review of its requirements for the process and structure of its technical specification publication is increasingly important, in order to ensure continued support for the IETF's work. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mankin-pub-req-01.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-01.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-01.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 Thu Oct 27 14:38:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVCeR-0001Qb-Bb; Thu, 27 Oct 2005 14:38:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVCeP-0001Od-DF for techspec@megatron.ietf.org; Thu, 27 Oct 2005 14:38:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21650 for ; Thu, 27 Oct 2005 14:38:40 -0400 (EDT) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVCro-0006wt-DA for techspec@ietf.org; Thu, 27 Oct 2005 14:52:49 -0400 Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id j9RIcgXE001939; Thu, 27 Oct 2005 13:38:42 -0500 Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72) id ; Thu, 27 Oct 2005 13:38:42 -0500 Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C0038F77905@eusrcmw720.eamcs.ericsson.se> From: "Stephen Hayes (TX/EUS)" To: Leslie Daigle , techspec@ietf.org Subject: RE: [Techspec] publication times & stable identifiers Date: Thu, 27 Oct 2005 13:38:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org Leslie and all, I have a bit of a difficult time separating the requirement on publication time from "how fast do we think we can really do it". Paul's analysis is correct. Within IETF it seems to be an issue of creeping instability as the publication time increases. External SDOs are asynchronous so the complaints increases proportionally to the delay in publication. There are no hard deadlines, it is more an issue of how fast are you willing to pay for and organize for. Note that even though 3GPP can achieve fast publication by relying on support staff, this does not mean IETF can. 3GPP membership is composed of companies and these companies have the resources to respond in a timely manner to questions and editing requests. This may not be possible when the involved parties are volunteer individuals. Regards, Stephen > 1/ Requirement on time from approval to publication > > I'd like to hear what we think is the *requirement* for the *IETF* > in terms of publication times -- is it as it stands now in > the text? Or is there a specific timeframe in which it is > required (for purposes of implementation, interaction with other > SDOs, etc). I'd like to explicitly leave aside the discussion of > "how fast do we think we can really do it" for the moment. > > _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Thu Oct 27 15:09:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVD7a-00052Q-P7; Thu, 27 Oct 2005 15:09:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVD7Y-000521-Q0 for techspec@megatron.ietf.org; Thu, 27 Oct 2005 15:09:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23119 for ; Thu, 27 Oct 2005 15:08:47 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVDKw-0007n2-F2 for techspec@ietf.org; Thu, 27 Oct 2005 15:22:57 -0400 Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9RJ8m4L050946; Thu, 27 Oct 2005 12:08:49 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4DCBC973AF0D6E4FAF9CD998CE1C0038F77905@eusrcmw720.eamcs.ericsson.se> References: <4DCBC973AF0D6E4FAF9CD998CE1C0038F77905@eusrcmw720.eamcs.ericsson.se> Date: Thu, 27 Oct 2005 12:08:45 -0700 To: "Stephen Hayes (TX/EUS)" , Leslie Daigle , techspec@ietf.org From: Paul Hoffman Subject: RE: [Techspec] publication times & stable identifiers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org At 1:38 PM -0500 10/27/05, Stephen Hayes (TX/EUS) wrote: >Note that even though 3GPP can achieve fast publication by relying >on support staff, this does not mean IETF can. 3GPP membership is >composed of companies and these companies have the resources to >respond in a timely manner to questions and editing requests. This >may not be possible when the involved parties are volunteer >individuals. The current RFC Editor is paid under a contract with ISOC; they are not volunteers. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Thu Oct 27 15:37:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVDYx-00067s-UU; Thu, 27 Oct 2005 15:37:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVDYw-00063l-8U for techspec@megatron.ietf.org; Thu, 27 Oct 2005 15:37:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24719 for ; Thu, 27 Oct 2005 15:37:06 -0400 (EDT) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVDmL-0000Aq-N2 for techspec@ietf.org; Thu, 27 Oct 2005 15:51:15 -0400 Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id j9RJbCO7018433; Thu, 27 Oct 2005 14:37:12 -0500 Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72) id ; Thu, 27 Oct 2005 14:37:11 -0500 Message-ID: <4DCBC973AF0D6E4FAF9CD998CE1C0038F7791B@eusrcmw720.eamcs.ericsson.se> From: "Stephen Hayes (TX/EUS)" To: Paul Hoffman , Leslie Daigle , techspec@ietf.org Subject: RE: [Techspec] publication times & stable identifiers Date: Thu, 27 Oct 2005 14:34:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] > Sent: Thursday, October 27, 2005 2:09 PM > To: Stephen Hayes (TX/EUS); Leslie Daigle; techspec@ietf.org > Subject: RE: [Techspec] publication times & stable identifiers > > > At 1:38 PM -0500 10/27/05, Stephen Hayes (TX/EUS) wrote: > >Note that even though 3GPP can achieve fast publication by relying > >on support staff, this does not mean IETF can. 3GPP membership is > >composed of companies and these companies have the resources to > >respond in a timely manner to questions and editing requests. This > >may not be possible when the involved parties are volunteer > >individuals. > > The current RFC Editor is paid under a contract with ISOC; they are > not volunteers. > I wasn't referring to the RFC Editors. I was referring to the authors that need to complete the 48 hours and other parties that must work with the RFC editor to complete the work. In 3GPP, that responsibility to provide timely resolution of issues towards the spec editors is with the supporting companies which are motivated to get the specs published for commercial reasons. This situation seems different from IETF. Regards, Stephen > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Thu Oct 27 15:55:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVDqu-0000Wb-Ce; Thu, 27 Oct 2005 15:55:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVDqs-0000WJ-J0 for techspec@megatron.ietf.org; Thu, 27 Oct 2005 15:55:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26124 for ; Thu, 27 Oct 2005 15:55:38 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVE4H-0000zT-KQ for techspec@ietf.org; Thu, 27 Oct 2005 16:09:47 -0400 Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9RJthBR057503; Thu, 27 Oct 2005 12:55:44 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4DCBC973AF0D6E4FAF9CD998CE1C0038F7791B@eusrcmw720.eamcs.ericsson.se> References: <4DCBC973AF0D6E4FAF9CD998CE1C0038F7791B@eusrcmw720.eamcs.ericsson.se> Date: Thu, 27 Oct 2005 12:55:20 -0700 To: "Stephen Hayes (TX/EUS)" , Leslie Daigle , techspec@ietf.org From: Paul Hoffman Subject: RE: [Techspec] publication times & stable identifiers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org At 2:34 PM -0500 10/27/05, Stephen Hayes (TX/EUS) wrote: >I wasn't referring to the RFC Editors. I was referring to the >authors that need to complete the 48 hours and other parties that >must work with the RFC editor to complete the work. Whoops, sorry, I misunderstood. >In 3GPP, that responsibility to provide timely resolution of issues >towards the spec editors is with the supporting companies which are >motivated to get the specs published for commercial reasons. This >situation seems different from IETF. Right. The IETF (correctly) requires sign-off from a group of volunteers for each document. That is an interesting issue, but I think we would have much faster response to the "RFC Editor has the document ready for publication" state if it came within a few weeks after IESG approval rather than a few months. This might be even more true if the RFC editing process was completely transparent, with a tracker-type mechanism. If the WG knew that their document was ready to be born, but was stuck, a few people would probably try to do out-of-band nudging to get the signers-off attention. Of course, vacations alway happen (well, not often enough), so another method to achieve faster final publishing would be to all/encourage the document authors to designate alternates. This makes much more sense when the publication time is more predictable than currently. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Fri Oct 28 02:05:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVNGH-00024A-7A; Fri, 28 Oct 2005 01:58:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVNGD-00023D-KV for techspec@megatron.ietf.org; Fri, 28 Oct 2005 01:58:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23180 for ; Fri, 28 Oct 2005 01:58:23 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVNFg-00014p-K5 for techspec@ietf.org; Fri, 28 Oct 2005 01:58:10 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j9S5hoV15770; Fri, 28 Oct 2005 08:43:51 +0300 Date: Fri, 28 Oct 2005 08:43:50 +0300 (EEST) From: Pekka Savola To: Paul Hoffman Subject: RE: [Techspec] publication times & stable identifiers In-Reply-To: Message-ID: References: <4DCBC973AF0D6E4FAF9CD998CE1C0038F7791B@eusrcmw720.eamcs.ericsson.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org On Thu, 27 Oct 2005, Paul Hoffman wrote: > Right. The IETF (correctly) requires sign-off from a group of volunteers for > each document. [...] I do not think the AUTH48 period needs to take long. When I was a WG chair, we had a number of non-responsive authors; if they had not signed off the document within a week, I asked the AD to sign off the document on their behalf. This worked just fine. The problem with holidays can likely be mitigated if the RFC-editing process is more predictable, i.e., you can estimate when the document will enter AUTH48 so you can either give guidance to co-authors, WG chair or AD, check the message from vacation, or whatever. My perception has been that when a document lingers for longer than a week in AUTH48 state, it's either because there are copyediting issues which need to be fixed (or other similar issues like an internet-draft used as a reference having been published as RFC since) and the rfc-editor after each step asks all co-authors to sign off the document, or that the authors have gone "missing", when an AD should step in to help. The RFC-editor's processing time (without AUTH48) could be reduced to, say, one month, I think the time in AUTH48 could be significantly reduced as well. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Fri Oct 28 12:57:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVXXa-0000cZ-JI; Fri, 28 Oct 2005 12:57:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVEr0-0000Nu-Ni for techspec@megatron.ietf.org; Thu, 27 Oct 2005 17:00:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17028 for ; Thu, 27 Oct 2005 16:59:50 -0400 (EDT) Received: from 216-43-25-66.ip.mcleodusa.net ([216.43.25.66] helo=episteme-software.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVF4O-0000aq-Mq for techspec@ietf.org; Thu, 27 Oct 2005 17:13:59 -0400 Received: from [216.43.25.67] (127.0.0.1) by episteme-software.com with ESMTP (EIMS X 3.3d14); Thu, 27 Oct 2005 15:59:49 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: <435FD38C.30503@thinkingcat.com> References: <435FD38C.30503@thinkingcat.com> X-Mailer: Eudora [Macintosh version 7.0a12] Date: Thu, 27 Oct 2005 15:59:40 -0500 To: Leslie Daigle From: Pete Resnick Subject: Re: [Techspec] Agenda -- update? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-Mailman-Approved-At: Fri, 28 Oct 2005 12:57:17 -0400 Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org On 10/26/05 at 3:05 PM -0400, Leslie Daigle wrote: >Agenda >------ > >0. Agenda bash [Leslie, all] >1. Overview & Introduction [Leslie] > . why are we here > . what we are *not* here for > . scope of "requirement" >2. Review and discussion of draft-mankin-pub-req-01 [Allison Mankin] >3. Discussion of any other requirements >4. Update from experiment in early copy editing [Bert Wijnen, RFC > Editor] >5. Determination of where from here for requirements documentation. > >Are there any updates we should make before Oct 31? (And we can >bash again in the session). A simple change: I would expect #4 to be report-like and non-controversial. I would expect #2 to in part refer to the results of #4, and #2 to generate discussion about which are good ideas and which are bad. Can we move #4 before #2? pr -- Pete Resnick QUALCOMM Incorporated _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Fri Oct 28 19:53:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVe2O-0001Im-GS; Fri, 28 Oct 2005 19:53:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVe2N-0001IK-KE for techspec@megatron.ietf.org; Fri, 28 Oct 2005 19:53:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27763 for ; Fri, 28 Oct 2005 19:53:14 -0400 (EDT) Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVeG2-000157-48 for techspec@ietf.org; Fri, 28 Oct 2005 20:07:39 -0400 Received: from [192.168.0.101] ([::ffff:64.102.254.33]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Fri, 28 Oct 2005 19:53:14 -0400 id 01588085.4362B9EB.0000245F Message-ID: <4362B9E6.2010505@thinkingcat.com> Date: Fri, 28 Oct 2005 19:53:10 -0400 From: Leslie Daigle User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete Resnick Subject: Re: [Techspec] Agenda -- update? References: <435FD38C.30503@thinkingcat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: techspec@ietf.org X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org ACK -- that looks like a good plan. Leslie. Pete Resnick wrote: > On 10/26/05 at 3:05 PM -0400, Leslie Daigle wrote: > >> Agenda >> ------ >> >> 0. Agenda bash [Leslie, all] >> 1. Overview & Introduction [Leslie] >> . why are we here >> . what we are *not* here for >> . scope of "requirement" >> 2. Review and discussion of draft-mankin-pub-req-01 [Allison Mankin] >> 3. Discussion of any other requirements >> 4. Update from experiment in early copy editing [Bert Wijnen, RFC >> Editor] >> 5. Determination of where from here for requirements documentation. >> >> Are there any updates we should make before Oct 31? (And we can bash >> again in the session). > > > A simple change: I would expect #4 to be report-like and > non-controversial. I would expect #2 to in part refer to the results of > #4, and #2 to generate discussion about which are good ideas and which > are bad. Can we move #4 before #2? > > pr _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Sun Oct 30 14:22:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWIlP-0005aI-R6; Sun, 30 Oct 2005 14:22:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWIlM-0005Yr-Ju for techspec@megatron.ietf.org; Sun, 30 Oct 2005 14:22:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07570 for ; Sun, 30 Oct 2005 14:22:18 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWFpp-0000QR-Jt for techspec@ietf.org; Sun, 30 Oct 2005 11:15:06 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 82BB6258077; Sun, 30 Oct 2005 16:59:45 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14472-03; Sun, 30 Oct 2005 16:59:41 +0100 (CET) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id A183C25806F; Sun, 30 Oct 2005 16:59:41 +0100 (CET) Date: Sun, 30 Oct 2005 17:01:04 +0100 From: Harald Tveit Alvestrand To: Paul Hoffman , techspec@ietf.org Subject: Auth48 again (RE: [Techspec] publication times & stable identifiers) Message-ID: In-Reply-To: References: <4DCBC973AF0D6E4FAF9CD998CE1C0038F7791B@eusrcmw720.eamcs.ericsson .se> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org --On torsdag, oktober 27, 2005 12:55:20 -0700 Paul Hoffman wrote: > Of course, vacations alway happen (well, not often enough), so another > method to achieve faster final publishing would be to all/encourage the > document authors to designate alternates. This makes much more sense when > the publication time is more predictable than currently. I think we have a clear requirement that the IETF (WG, WG chairs, AD or IESG - I don't care too much) should be able to say who has to sign off on the final results on IETF documents. The default should probably be "the people listed on the front page", but I think the IETF needs to be able to change this when it makes sense. Another thing we should have: A visible list of who's signed off and whose signature is still outstanding. When I was AD, I usually did not get copied on people's "yes, this looks OK" messages to the RFC Editor, although I usually got copies of the complaints.... and I had no way to tell who the document was ready for. I think I've said both things before.... Harald _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Sun Oct 30 19:12:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWNHQ-0007l4-Md; Sun, 30 Oct 2005 19:12:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWNHP-0007kJ-On for techspec@megatron.ietf.org; Sun, 30 Oct 2005 19:12:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27014 for ; Sun, 30 Oct 2005 19:11:45 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWNVT-0006sV-Fp for techspec@ietf.org; Sun, 30 Oct 2005 19:26:36 -0500 Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9V0Bt1n044183 for ; Sun, 30 Oct 2005 16:11:56 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4DCBC973AF0D6E4FAF9CD998CE1C0038F7791B@eusrcmw720.eamcs.ericsson .se> Date: Sun, 30 Oct 2005 16:11:55 -0700 To: techspec@ietf.org From: Paul Hoffman Subject: Re: Auth48 again (RE: [Techspec] publication times & stable identifiers) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org At 5:01 PM +0100 10/30/05, Harald Tveit Alvestrand wrote: >I think we have a clear requirement that the IETF (WG, WG chairs, AD >or IESG - I don't care too much) should be able to say who has to >sign off on the final results on IETF documents. >The default should probably be "the people listed on the front >page", but I think the IETF needs to be able to change this when it >makes sense. Fully agree. This is a requirement, not a luxury, for the document publishing to be predictable. It would prevent WG items from being in the RFC Editor queue for years because of rogue authors. >Another thing we should have: A visible list of who's signed off and >whose signature is still outstanding. If we consider it a requirement to have the process be predictable, having every significant step in the publishing process be visible is also a requirement. We pretty much have that now with the Internet Draft part of the process, and the result has been excellent. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec From techspec-bounces@ietf.org Mon Oct 31 10:59:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWc3t-0005NG-EF; Mon, 31 Oct 2005 10:59:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWc3s-0005Mu-5w for techspec@megatron.ietf.org; Mon, 31 Oct 2005 10:59:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15765 for ; Mon, 31 Oct 2005 10:58:43 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWcI4-0001is-2O for techspec@ietf.org; Mon, 31 Oct 2005 11:13:45 -0500 Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9VFwuAZ081806 for ; Mon, 31 Oct 2005 07:58:57 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 31 Oct 2005 07:58:53 -0700 To: techspec@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Techspec] Proposed additional requirement: change history and provenance for RFCs X-BeenThere: techspec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion list for IETF Technical Specifications \(BOF at IETF64\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: techspec-bounces@ietf.org Errors-To: techspec-bounces@ietf.org Greetings again. One thing that many people in the IETF have needed, and have often only found through heavy research, is important metadata for RFCs. Two important types of metadata come to mind: - The change history for an RFC that updates or obsoletes an earlier RFC. Some RFCs are very good about listing this type of information, but many (particularly those that update instead of obsolete) are not. This type of information needs to be available to implementers who are handed a pile of RFCs and told to implement the "current standard". - The provenance information, namely what caused the document to be published as an RFC. For example, if you are looking at an informational RFC, it is nearly impossible to tell whether it was a self-submitted RFC or one that came from a WG action, unless you know exactly which different boilerplate text was used at which time relative to when the RFC was published. Similarly, knowing if an older standards-track RFC was an individual submission or a WG item can help an implementer look for mailing lists where the RFC was discussed. I see that making these both public and easily findable as requirements for our documentation process. Do others agree? --Paul Hoffman, Director --VPN Consortium _______________________________________________ Techspec mailing list Techspec@ietf.org https://www1.ietf.org/mailman/listinfo/techspec