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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]