--On Thursday, August 13, 2015 11:26 -0400 Michael StJohns
<mstjohns(_at_)comcast(_dot_)net> wrote:
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:
The date issue had not occurred to me, but I concur. I suppose
the tracker could be modified to show a "last status change"
field and link for all documents whose status had changed, but
obviously this isn't going to happen before this proposed change
is processed (if it is).
It also raises another variation on my concern about just
documenting these things in the tracker. We've historically
tried to take the notion of RFCs as an archival series quite
seriously. The more often we place critical information about
RFCs and their status (history, metadata, etc.), in separate
databases, the more complex preserving the "archival" condition
becomes. In particular, if we have expectations that the
tracker can be considered an archival source on a par with the
RFCs themselves, it is likely to be necessary to make sure there
is dated backtrace capability (or equivalent) and that we be
sure that the tracker database is managed in a way that
guarantees its accessibility for a really long time (some
approximation to "forever").
I'm not sure how much the community actually cares but, if we
do, it is another reason to be careful about these
reclassifications, how they are documented, and where.
best,
john
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