Skip to main content

Recognising RFC1984 as a BCP

Document Status change Recognising RFC1984 as a BCP
Last updated 2015-10-14
Moves to BCP RFC1984
State Approved - announcement sent
IESG Telechat date (None)
Responsible AD Stephen Farrell
Send notices to

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.