The issue of mandatory government key escrow was recently discussed on
the saag list. [1] 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
and clearly represent the results of community deliberations as called
for in RFC2026, section 5, [3] which introduces the idea of a BCP.

Based on the the saag list discussion and questions considered at the
saag meeting at IETF93, the security area of the IETF appears 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. 

The closest precedent we have for this status chage is the change of
RFC20 to Internet Standard. [4] That shows that if the text of an RFC
is acceptable, the age of the RFC isn't material in discussing proper
RFC status. 

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
[4] https://datatracker.ietf.org/doc/status-change-rfc20-ascii-format-to-standard/