At 12:49 PM 11/30/2004, Sam Hartman wrote:
>>>>> "Michael" == Michael StJohns <mstjohns(_at_)mindspring(_dot_)com> 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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf