A final follow-up on this:
A couple of people raised the issue of whether the new "status-change"
documents are sufficient as archival documentation, and where the
process for handling them is defined. I brought the concern to the
IESG, and we discussed it on our last informal telechat.
When we publish an RFC to document a status change, that RFC is not
connected to the original RFC (the one whose status is changed),
unless we use the "updates" or "obsoletes" metadata for that. We
often do not, and the result is that someone looking at the original
RFC will have no pointer at all to the documenting RFC.
With the new tools and the status-change documents, there is metadata
going in both directions, directly connecting the RFC with the
explanatory document -- and, consequently, with the IESG ballot on the
action, and any comments and history therein. Those pointers are
clearly available in the datatracker view of the RFC and in the view
on the RFC Editor's web site (any gaps there are scheduled to be
updated soon). Further, status-change documents are fully searchable
in the datatracker, through the "Advanced" search. There's an extra
benefit to the ability to specifically search only the status-change
documents.
On process: Status-change documents are treated as any other documents
handled by the IESG. Someone writes up a proposal, the proposal is
discussed, the document is sent out for last call, last-call comments
are considered and addressed, and the IESG ballots. The document is
approved (or not) on a formal telechat, and the result is in the
telechat minutes, with the ballot and history recorded in the
datatracker.
It's the strong consensus of the IESG that:
1. The benefits of the new tools and the status-change documents are clear.
2. When the explanation of a status change is relatively simple, there
is no need to have an RFC in addition to the status-change document.
As they are permanently recorded and indexed in the datatracker, the
status-change documents certainly serve as archival documentation.
3. There is no question on process. RFC 2026 describes how documents
are processed in the IETF, and these documents are processed
accordingly. There is no need to document anything specific about
status-change documents.
Barry, for the IESG