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-rfc5617-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.
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.
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).
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.
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.
So: Yes, we could publish an RFC that basically has the content that
status-change-adsp-rfc5617-to-historic now has, and that new RFC could
obsolete RFC 5617. Personally, I don't see why that's necessary or
even useful. We have a *new* tool for this, and we should use it.
That said, the IESG, not I alone, will decide, and will take all the
input y'all have given -- thanks for that input.
Barry