On Aug 10, 2015, at 3:06 PM, Brian E Carpenter
<brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com> wrote:
On 11/08/2015 05:34, Roy T. Fielding wrote:
On Aug 10, 2015, at 10:23 AM, Paul Hoffman
<paul(_dot_)hoffman(_at_)vpnc(_dot_)org> 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