The issue of mandatory government key escrow was recently discussed on the saag list [1] and has also recently been the topic of much broader discussion in the technical community and beyond. RFC1984 [2] has set out the IETF's position on this topic since 1996, when that RFC was published. The principles described in RFC1984 have held up well in the nearly two decades since. For both symbolic reasons (that the technical position then is the technical position now) and to better ensure that IETF specifications reflect the spirit of RFC1984, a number of participants in the discussion felt it would be advantageous to recognize the substantive content of RFC1984 as a BCP. Based on the the saag list discussion and questions considered at the saag meeting at IETF93, the security area of the IETF appear to have rough consensus to change the status of RFC1984 to BCP in-place, without changes to the text. The possibility of revising the text of RFC1984 was discussed, but rejected because a) the current text is still fine, b) any changes we'd likely make now wouldn't improve it significantly, c) affirming the continuity of the IETF's position is valuable and even d) keeping the RFC number is worthwhile. Thus, though there may be boilerplate issues, and issues with some presentations of meta-data, this in-place status change is overall considered reasonable and beneficial. While this is an exceptional case (given the time lapse involved and the change from informational to BCP), this kind of status-change is allowed for by RFC2026 as the text of RFC1984 does represent a result of community deliberation, as does this status-change itself (should it be finally approved). As the IESG and IAB are listed as authors, the current IESG and IAB were asked if they had any objection to this status change. None has been offered so far though the IESG will of course evaluate the last call for this status change. Current tooling support for status change documents does not have the concept of a document shepherd. However, for this IETF last call, Robert Sparks has agreed to act in this role. [1] https://www.ietf.org/mail-archive/web/saag/current/msg06343.html [2] https://tools.ietf.org/html/rfc1984 [3] https://tools.ietf.org/html/rfc2026#section-5