Another document series?
Folks - I've recently been asked to review a number of works in progress related to restructuring and other similar things. Those documents were liberally splattered with references to various IDs (http://www.ietf.org/internet-drafts/draft-ietf-newtrk-cruft-00.txt, http://www.ietf.org/internet-drafts/draft-ietf-newtrk-repurposing-isd-00.txt, http://www.ietf.org/internet-drafts/draft-wasserman-iasa-bcp-01.txt etc). Its unclear that either the work in progress or the cited drafts will ever be published as RFCs. Its also unclear that this (restructuring etc) will be resolved within the 6 month lifetime of any given ID. Its also unclear that we can afford to either have these expire, or continually resubmit them. And finally, we NEED to have this set of documents as permanent archivable documents to maintain the historical record. It seems to me that neither ID status nor RFC status are appropriate for these documents. The ID series is, by design, ephemeral and generally not citeable. The RFC series is stable and citeable, but the lead time for introducing an RFC is somewhat north of 30 days or more. I hate to open Pandora's box, but what I think we need is a citable, stable document series that has a production lead time similar to that of the IDs. I would probably limit this to the non-technical administrivia we've been recently inundated with. *sigh* Mike ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Another document series?
Michael == Michael StJohns [EMAIL PROTECTED] writes: Michael It seems to me that neither ID status nor RFC status are Michael appropriate for these documents. The ID series is, by Michael design, ephemeral and generally not citeable. The RFC Michael series is stable and citeable, but the lead time for Michael introducing an RFC is somewhat north of 30 days or more. Michael I hate to open Pandora's box, but what I think we need is Michael a citable, stable document series that has a production Michael lead time similar to that of the IDs. I would probably Michael limit this to the non-technical administrivia we've been Michael recently inundated with. Michael *sigh* Please provide some justification. You said that you needed these things but you didn't really say why. I also don't understand how this is any different than work that goes on in a lot of protocol working groups. I'm particularly confused about why we would have documents that we neither want to be long-lived but that we cannot be bothered to resubmit every six months. If we want the document to be long-lived, what is wrong with RFC publication? ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Another document series?
--On tirsdag, november 30, 2004 12:13:41 -0500 Michael StJohns [EMAIL PROTECTED] wrote: Folks - I've recently been asked to review a number of works in progress related to restructuring and other similar things. Those documents were liberally splattered with references to various IDs (http://www.ietf.org/internet-drafts/draft-ietf-newtrk-cruft-00.txt, http://www.ietf.org/internet-drafts/draft-ietf-newtrk-repurposing-isd-00. txt, http://www.ietf.org/internet-drafts/draft-wasserman-iasa-bcp-01.txt etc). Its unclear that either the work in progress or the cited drafts will ever be published as RFCs. The answer is yes-if-successful, yes-if-consensus, yes-with-namechange for those three particular documents. Not much different from the I-Ds of any given working group. Its also unclear that this (restructuring etc) will be resolved within the 6 month lifetime of any given ID. Its also unclear that we can afford to either have these expire, or continually resubmit them. And finally, we NEED to have this set of documents as permanent archivable documents to maintain the historical record. Query: What purpose do you see the historical record as having? I'm serious - visibility to serious historians, historical sunshine law and armoury for lawyers in court cases are very different things to design for. It seems to me that neither ID status nor RFC status are appropriate for these documents. The ID series is, by design, ephemeral and generally not citeable. The RFC series is stable and citeable, but the lead time for introducing an RFC is somewhat north of 30 days or more. Optimist the current queue time (approval to publication) is closer to 4 months for IETF standards track. The effort at speeding up the IESG approval process has had ripple effects :-( (that's why the RFC Editor's 2006 budget shows a hefty increase, btw...) I hate to open Pandora's box, but what I think we need is a citable, stable document series that has a production lead time similar to that of the IDs. I would probably limit this to the non-technical administrivia we've been recently inundated with. Unfortunately, almost the same arguments can be made for anything that has received serious attention in the I-D series. See the NEWTRK discussion about working group snapshot. Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Another document series?
At 12:49 PM 11/30/2004, Sam Hartman wrote: Michael == Michael StJohns [EMAIL PROTECTED] writes: Michael It seems to me that neither ID status nor RFC status are Michael appropriate for these documents. The ID series is, by Michael design, ephemeral and generally not citeable. The RFC Michael series is stable and citeable, but the lead time for Michael introducing an RFC is somewhat north of 30 days or more. Michael I hate to open Pandora's box, but what I think we need is Michael a citable, stable document series that has a production Michael lead time similar to that of the IDs. I would probably Michael limit this to the non-technical administrivia we've been Michael recently inundated with. Michael *sigh* Please provide some justification. You said that you needed these things but you didn't really say why. I tend to disagree with you that I didn't say why, but here's some more: Pick any one of a number of the current documents related to restructuring. Do a topological sort on the publication dependencies. (E.g. stable references for RFCs can't be IDs). Now figure out whether this entire set of IDs will make it to RFC status. Further, figure the amount of bureaucratic cruft that will have to happen to bring this set to RFC status with the concomitant allocation of scarce resources. The various restructuring documents that have been published as IDs tend to have a history that's important. RFCs are published at a single point (the end point) in the life of an ID. In this discussion, and in others, its important to know where we started, where we were along the way and where we ended up. Sometimes that's embodied as a single document history, sometimes as a set of revisions to a document, and sometimes as a series of documents with different names, but parented by the same ideas. The ID series can't track this in the manner it needs to be tracked due to its current ephemeral nature. I also don't understand how this is any different than work that goes on in a lot of protocol working groups. Because in the protocol working groups, its the end product that is most important because that's what gets published as the RFC. The IDs CAN be discarded at the end of the process because they become irrelevant. RFCs are edited to a fare-thee-well - IDs are not. We need something stable like an RFC that doesn't require the resource allocation of an RFC to get published. Finally, the documents in the restructuring set are mostly individual or small group efforts, individual opinion rather than a group consensus of a WG. The changes to those documents over time (e.g. the -01 -02 etc) tend not to be changes in meaning, but refinements of the original thesis. Protocol RFCs reflect group consensus and tend to change somewhat drastically from initial idea to final publication. (Broad generalization which tends to be more true than not - there are exceptions). I'm particularly confused about why we would have documents that we neither want to be long-lived but that we cannot be bothered to resubmit every six months. If we want the document to be long-lived, what is wrong with RFC publication? I want document A to be long lived, but I don't want to wait the 4 months (see Harald's note) to have it see the light of day because the discussions on A have to take place now. That assumes that A can be published direct from creation, which isn't the case in the IETF. Instead A has to be published as an ID first, before it can be published as an RFC. Someone else comes along with document B that cites A. B depends heavily on A. And C and D and E. B becomes very important and makes it to the point where we want to turn it into an RFC, in the mean time authors of A, C, D and E have dropped out of the process through sheer fatigue and decline to push their documents to RFC status. Does B get published as an RFC by removing the cites for A, C, D and E or does some overworked volunteer pick up A, C, D and E to edit them? What happens if the various authors decline permission to take these drafts forward? This isn't as much of a problem in the protocol work side of things, but the web of documents so far on the restructuring is much broader than anything I can remember seeing for any of the work products of any of the WGs. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Another document series?
Mike, As the other co-author to http://www.ietf.org/internet-drafts/draft-ietf-newtrk-cruft-00.txt, [...]Its unclear that either the work in progress or the cited drafts will ever be published as RFCs. Its also unclear that this (restructuring etc) will be resolved within the 6 month lifetime of any given ID. Its also unclear that we can afford to either have these expire, or continually resubmit them. And finally, we NEED to have this set of documents as permanent archivable documents to maintain the historical record. I think the current cruft draft is best suited only as an I-D. We are right now conducting a cruft experiment. It is quite possible -- in fact darn near certain -- that we will need to update that draft based on the experiences of the old-standards mailing list, making the current draft, well, cruft. Depending on the results of the experiment I think the WG could produce either an update to RFC 2026/3667/ or an informational RFC. Why is this not sufficient? What is it you want to capture? Eliot ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
