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