Re: [saag] Fwd: Last Call: Recognising RFC1984 as a BCP

[Michael StJohns <[e-mail]>]

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