Disclaimer: This note has nothing to do with either ADSP or any
other variation or component of DKIM. If any part of it appears
otherwise, I apologize for the unintended confusion.
--On Wednesday, November 20, 2013 18:10 -0500 Barry Leiba
<barryleiba(_at_)computer(_dot_)org> wrote:
it would seem to me to be a dereliction of duty to not
publish a document that says why such a change
is made -
...
https://datatracker.ietf.org/doc/status-change-adsp-rfc561
7-to-historic/
Just to make this all very clear:
When we had no obvious "metadata", we would publish an RFC
that said that a previous RFC is now Historic, and we hoped
that people would see both and know what the situation was.
Then we established metadata that goes with an RFC, and the
RFC's status and the "obsoletes" and "updates" chains are part
of the metadata. No need to hope any more: Anyone who looks
at the datatracker or tools versions of the RFCs will see that
metadata, so (1) we can now rely on having the "Historic"
status be clear, and (2) the RFC that updates or obsoletes the
old one is now called out clearly.
Then we set up special documents by which we process status
changes. The cited one above is one of them. Those special
documents are also tied to the original document's metadata.
Moving to a very high level, it seems to me that what is wrong
with the above is that, while adding metadata and making it more
accessible are useful at best and harmless at worst, it seems to
me that you are making a leap from "the metadata are available
if you know where to look" (or use the right tools) to
"therefore it is reasonable to change the procedures by which
standards-affecting decisions are documented and to introduce
those procedures via a specific case". It also seems to me
that this process involves doing that without any real
discussion of the procedural change independent of that case.
If we push all other issues aside, it is that change, without a
clear discussion or statement of what is being done, that is
troubling, not the particular action or documentation of one
particular case. Suggestion below.
So here's the thing:
1. If RFC 9999 were to "obsolete" RFC 5617 and declare it
Historic, someone looking at the datatracker page for RFC 5617
would see (1) that it's Historic and (2) that RFC 9999
obsoletes it. They would, therefore, know to look at RFC 9999
to understand what happened.
I note they they would also get that much information by looking
at the ASCII-text RFC Index. I also note that we have not
obsoleted that index, nor have we included datatracker links in
it, nor attached a giant disclaimer to it that anyone interested
in what the published status information means needs to go to
the datatracker.
2. But if we just process this status change as currently
proposed, someone looking at the datatracker page for RFC 5617
would see (1) that it's Historic and (2) that
status-change-adsp-rfc5617-to-historic made that status
change. They would, therefore, know to look at
status-change-adsp-rfc5617-to-historic to understand what
happened (and there's a convenient, clickable link).
As long as they look at the datatracker. It is worth noting,
now that
draft-resnick-retire-std1 has been approved, that STD 1 used to
be a place where what we now describe as metadata was supplied,
including requirement levels and some explanations of choices.
A glance through some of the earlier versions of STD 1, e.g.,
RFC 1360, are particularly illuminating in that regard. I note
that draft-resnick-retire-std1-01 doesn't say "you need to look
at the datatracker in order to find the status of a
specification". Instead, it refers the reader to
http://www.rfc-editor.org/rfcxx00.html. If one finds a protocol
there and uses the RFC references in it to retrieve the
document, none of the metadata other than maturity level will be
found (not even "updates") information.
That suggests to me that, if we are going to expect people to go
to the datatracker (or equivalent) in all cases, we have some
act-cleaning-up to do.
If you want another example, look at RFC 6376:
https://datatracker.ietf.org/doc/rfc6376/
...and see how the status change document that made it Internet
Standard is clearly linked at the top of the page. See how
that document contains the explanation for the action.
Curiously, I think that example supports my point. RFC 6410
explicitly provided for promotion of specifications to Internet
Standard without publication of a formal, archival, discussion
of why it was being done. It also defines (partially by
reference) the criteria that one can assume if something is
designated as an Internet Standard. It was posted as an I-D,
underwent significant community discussion about the procedural
change, and was formally adopted as reflecting community [rough
at least] consensus.
We do have examples of publishing tombstone documents for
specifications that are moved to Historic because they are not
implemented or not in use. Perhaps RFC 4450 is the best example
of that simply because it covers a large group of RFCs. It
seems to me that deprecating a specification that is claimed to
be implemented, in some use, and found to be undesirable should
require a higher and more formal degree of documentation. It
also appears to me that the difference between those two sets of
cases invalidates any argument that there is only one use of
Historic.
Neither 6410 nor, AFAIK, anything anything published since RFC
2926, addresses moving of a document to Historic, nor does it
provide the precise definition of Historic that (as Bob Braden
pointed out) we've never had, nor does it provide an alternate
mechanism for saying "use Not Recommended" other than publishing
an Applicability Statement.
As we change our tools, we need to understand that the ways we
used to handle certain things are no longer necessary, because
the improved tools have made things better. This is one of
those situations.
Obviously I, and perhaps some others, see "no longer necessary"
and "one of those situations" as more controversial than you do.
I may be alone in this, but I see formalizing information in the
datatracker as having the same level of archival and reference
permanence as a rather big step with some interesting
side-effects [1]. But it seems to me that, if you want to make
the change you apparently believe is obvious because the tools
have changed, then let's have that discussion and see if the
community reaches that conclusion... just as we did with what
became RFC 6410.
best,
john
[1] As an example, if another protocol came along that was
intended to replace one that had been move to Historic using
datatracker entries alone, would (and should) the RFC Editor
allow normative references to those datatracker entries? Are we
sure that the relevant URLs are stable enough and will stay that
way?