>>>>> "Michael" == Michael StJohns <mstjohns@xxxxxxxxxxxxxx> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf