On Wed, Nov 20, 2013 at 3:10 PM, Barry Leiba <barryleiba@xxxxxxxxxxxx> wrote:
-MSK
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.
If the IESG decides it wants an RFC, I'll volunteer to do the editing if nobody else wants to do it, unless John (or others) see me as part of some kind of pro-DKIM cabal that's giving him the willies and we'd rather someone else do it. It's almost no work since the text is basically already laid out. Or maybe this would be a good opportunity for a relative neophyte to IETF process to learn how something gets published; I'll happily shepherd.
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.
That's true, but there are other sources of RFCs that don't contain such information, such as http://www.ietf.org/rfc/rfc6376.txt and I think the one at rfc-editor.org. Someone grabbing the RFC from such sources (which could easily be seen as official) would not be aware of the status change or the reason for it.