--On Thursday, August 13, 2015 11:26 -0400 Michael StJohns <mstjohns@xxxxxxxxxxx> 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 > > >