--On Thursday, March 03, 2011 10:41 -0500 "Joel M. Halpern"
<jmh@xxxxxxxxxxxxxxx> wrote:
> No, I do not agree with you.
> Our current definition for historic, and our current choices
> for when to move things, have worked sufficiently well.
> I have not seen any evidence that there is a problem that
> needs solving.
> I have also not seen any evidence that the changes you propose
> to the definitions would help anything.
>
> Yes, there are problems with our current definitions.
> Those problems serve to keep us from declaring something
> historic when we shouldn't.
>...
I pretty much agree with Joel (and others), but suggest that
there is another, better, solution to this problem (or at least
the version of it I understand).
Ultimately, whether under 2026 or your proposal, there are
ultimately two reasons for making something historic (this is
different from your Section 2 list; more about that below):
(i) No one is using the protocol and no one cares any
more about it.
(ii) The protocol contains elements or defects that, in
retrospect, make it dangerous.
With the exceptions that are already covered by the existing
"Obsoleted by" category, the first is, as Joel points out, hard
to identify and get agreement about. As other have suggested,
"no one cares" means "no one cares", i.e., that putting
significant energy into trying to identify and classify those
documents is probably not a good use of community resources.
Reaching formal agreement about the second effectively requires
publication of an RFC that describes the problem, at which point
"Obsoletes" can be used and there is no reason to develop new
procedures.
For the few cases that are actually worth it, we do have the
ability to approve and publish documents that identify a
protocol as "not recommended". We don't use stand-alone
Applicability Statements very often any more, especially for
that purpose, but, if a particular protocol deserved the effort,
it would be lots easier --and lots less wear and tear on the
community in review and the RFC Editor in publication-- to write
an I-D that said "the protocol described in RFC NNNN has turned
out to be a bad idea because... Its use is Not Recommended."
than to republish or "historicize" as you suggest.
Trying to turn Historic even more into an ambiguous synonym for
"old", "unused", "uninteresting", or "bad" just does not strike
me as a good idea, especially with the possibility of
applicability statements that are orthogonal to maturity level
classification on the books.
FWIW, your "republication as historic" approach is not feasible
for documents more than a few years old. The rules about
information to be included in RFCs, how that information is
structured, IPR statements, etc., have evolved over the years.
Permitting republication of an old RFC in facsimile would often
break those rules. Figuring out the mechanisms for getting
around that would cost far more in resources than the community
is, I believe, willing to invest. If I thought that another
iteration would improve this proposal enough to make it
acceptable, I'd recommend that your Section 3.1 should be
required to address republication of new documents with
identical technical content with old ones in the light of those
rules. But I don't think that is the case.
On a note of sadness rather than as a sales pitch, the community
has discussed several ways of dealing with what I think it the
underlying problem you are trying to address -- getting readers
of RFCs the most up to date information possible about those
documents and the status of the protocols they describe. At
least some of them would have worked better than this, with less
load on the community. For whatever reasons, none of them have
achieved sufficient consensus to move forward. Against that
background, I can't imagine what would cause us to adopt a
weaker proposal that required more work.
regards,
john
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf