At 05:06 PM 8/12/2015, John C Klensin wrote:
Unlike Roy, Joe, and some others, I don't fundamentally object
to reclassifying 1984 (and object less if the BCP category
sweeps up other documents that are judged similar). Independent
of the principles 1984 expresses, I am uncomfortable with making
a document with its statements and style a BCP, but I'm
pragmatic about that and can live with it if we are clear about
what we are doing and why. I do feel that we should have some
justification that makes sense.
I mostly agree with John as above. But I've got a few housekeeping questions:
1) Unlike the publication of a new RFC and its associated dates, there isn't
any way to permanently associate the change of status date with the RFC. At
some future time (and here I'm talking 10-20 years), will it ever be important
to be able to identify when the change was made (without having to do email
archeology)? Changes to Historic require the submission of an RFC to mark the
change - why wouldn't this change also require such a document. From the IESG
web page:
A major advantage of a status-change document is that it adds traceability:
when the now-Historic RFC is displayed in the datatracker, there is a pointer
directly to the status-change document, making the explanation more readily
accessible. See <http://tools.ietf.org/html/rfc5617>RFC 5617 for an example:
2) According to RFC 2026, BCPs are documents of the IESG, not the IAB and IESG
together. Should that be reflected on any change of status in the document
itself? Or is the language in 2026 incomplete and we should spend a little
time updating things there?
And one minor nit:
RFC1984 seems pretty OK with the idea of passwords as a security mechanism.
While that's only a single aside in the document, reaffirming that passwords
are OK in 2015 seems like a bad idea.
For example,
conventional passwords, credit card numbers, and the like must be
protected by strong encryption, even though some day more
sophisticated techniques may replace them. Encryption can be added
on quite easily; wholesale changes to diverse systems cannot.
"Encryption can be added on quite easily"??
Just thoughts - but I think the tracker question is important to consider prior
to this status change.
Mike