> On Aug 10, 2015, at 3:06 PM, Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote: > > On 11/08/2015 05:34, Roy T. Fielding wrote: >>> On Aug 10, 2015, at 10:23 AM, Paul Hoffman <paul.hoffman@xxxxxxxx> wrote: >>> >>> On 10 Aug 2015, at 10:13, The IESG wrote: >>> >>>> The IESG has received a request from an individual participant to make >>>> the following status changes: >>>> >>>> - RFC1984 from Informational to Best Current Practice >>>> (IAB and IESG Statement on Cryptographic Technology and the Internet) >>>> >>>> The supporting document for this request can be found here: >>>> >>>> https://datatracker.ietf.org/doc/status-change-rfc1984-to-best-current-practice/ >>> >>> Yes, please. What was discussed in 1996 really is a best practice today, and it has certainly been made the current practice. >>> >>> --Paul Hoffman >> >> Umm, the document is specifically worded as a position statement from the >> IAB and IESG. There is no "current practice" described by it. Rather, it is an >> argument against key escrow and limited key sizes; a sort of anti-pattern for >> an old practice. >> >> I'd rather it be left as an informational document, as it was approved, > > When RFC 1984 was published, the way BCP was defined by RFC 1818 made it impossible > to classify it as BCP. RFC 2026 expanded the definition of BCP considerably > and specifically mentioned "the results of community deliberations" and > "common guidelines for policies" and is explicit that a BCP can be a vehicle > for IAB and IESG statements subjected to community consensus. So we are a > few years late, but this action seems well within the rules. That doesn't change the content of the text, which is not expressing a BCP in any shape or form. It is an opinion piece, which is fine as Informational. The document does not describe common guidelines for policies, nor does it summarize the results of community deliberations. It states an opinion of the IAB and IESG at that time regarding two very bad suggestions for key management. The right opinion, IMO, but still just an opinion of a dozen or so individuals. Changing the document status serves no useful purpose. At best, it provides a bad example of how to write other BCPs. If you can't generate enough energy to re-edit the document as a consensus specification, then it surely isn't important enough to serve as a bad example of back-door standardization. Why is it that security-related statements by the IESG need to avoid being subject to the same process as all our other specifications? ....Roy