--On Monday, May 14, 2018 04:54 -0400 Barry Leiba
<barryleiba@xxxxxxxxxxxx> wrote:
> Documents are obsoleted by other documents.
> Protocols and technologies become historic by the fact that
> they're not/no longer in use.
> There is a difference between "obsolete" and "historic". It
> makes perfect sense to say that the technologies described in
> RFCs 4405-4407 are historic, as they're no longer in use; the
> fact that if was an experimental technology isn't relevant to
> that. And RFC 6686 did not make that (Sender ID becoming
> historic) happen.
Barry,
I'm glad that distinction is completely clear to you.
Especially given the history or application of those terms, it
is less clear to me and more than one attempt to get the IESG to
clarify it (or initiate a community effort to clarify it) and
get it written down in clear form has been met with silence.
To this specific case...
> It's true that 6686 could have requested that the IESG change
> the status of Sender ID to Historic. It didn't. And this
> situation is exactly what the "status change" document set was
> created for: to perform these sorts of status changes without
> having to publish new RFCs. There's no reason to use errata
> for this sort of thing.
I suggested adding a erratum, not to "do this sort of thing" but
to provide a pointer, more or less attached to 6686 and/or the
original documents, pointing to the status change document.
Why? Because, which the "status change" document set (itself an
interesting assertion) may be intended for the purpose of
reclassifications, I suggest that almost no one who knows about
and looks at the RFC Series is away of that collection, much
less where to find them. Granted, only a slightly larger
fraction of the RFC Series audience knows to look for, and where
to find, errata, but it would at least be a more serious attempt
than marking the documents "Historic" in the index and leaving
people to guess.
Is it really an error? Probably not, even though it is
possible to stretch things a bit and claim that it was an
inadvertent omission from 6686. But, unless we either abandon
this "put a note about a status change somewhere handy like in
the tracker" stuff and publish RFCs or resurrect the part of the
xx00 documents (see RFC 7100) that was essentially a summary of
status changes, it is probably the best answer we have.
> We have what we need to do the right thing, and we're doing
> it. Let's not make it more complicated than it needs to be.
Working on that, but, IMO, "the right thing" includes leaving
clear tracks and pointers to descriptions of actions where
people would reasonable expect to find them.
best,
john
