Recognising RFC1984 as a BCP
status-change-rfc1984-to-best-current-practice-01

The following approval message was sent
From: The IESG
To: IETF-Announce
Cc: RFC Editor , stephen.farrell@cs.tcd.ie, rjsparks@nostrum.com
Subject: Document Action: IAB and IESG Statement on Cryptographic Technology and the Internet to Best Current Practice

The IESG has approved changing the status of the following document:
- IAB and IESG Statement on Cryptographic Technology and the Internet
  (rfc1984) to Best Current Practice

This document action is documented at:
https://datatracker.ietf.org/doc/status-change-rfc1984-to-best-current-practice/

A URL of the affected document is:
https://datatracker.ietf.org/doc/rfc1984/

Status Change Details:


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


Personnel

  Stephen Farrell is the responsible Area Director.

[Ballot comment]
Having balloted Yes, I note that the question on this ballot is "is this the right thing to do?".

There has been more than a little process wonking in the community discussion on this status change. Stephen has done a fairly heroic job in responding to that discussion. I happen to think that our current process really doesn't help us in this case (see: lawyering about whether we're allowed to move an Informational RFC produced by the IAB and IESG to BCP without issuing a new RFC, for starters).

There are moments when I wish we were doing a new document that says "the IESG has been treating RFC 1984 as if it were an IETF-stream BCP for a very long time. RFC 1984 doesn't look like a BCP that we would publish in 2015, and it wasn't produced the way we would produce a BCP in 2015, but that hasn't prevented anyone from treating it as if it had been produced and evaluated as a BCP, had that option been possible twenty years ago, so, we're going for it", and publishing THAT as a BCP.

But the question on this ballot isn't whether we would approve RFC 1984 unchanged as a new RFC, it's whether recognizing twenty years of reality is the right thing to do. So. I'm a Yes.

[Ballot comment]
For the record I believe that the IETF experience of the interceding twenty years since the original publication reinforces the necessity of this statement.

[Ballot comment]
Consensus was clear at the SAAG meeting for this change IMO.  The mailing list discussions were very helpful to sort through options and opinions.

[Ballot comment]

As this is on a telechat, and I'm the responsible AD, you know
that I think there is rough consensus for this. But the in-place
part is a bit rough, so to help you figure out what you think,
Robert Sparks nicely summarised the IETF last call for this [1]
to which Dave Crocker responded [2] calling out that it was
more than just one or two folks with issues. (That said, there
were a lot of people at the saag meeting who supported doing
just this so to the extent that numbers matter, the ietf@ietf.org
mailing list traffic is not the full picture as we know.)

[1] https://www.ietf.org/mail-archive/web/ietf/current/msg94632.html
[2] https://www.ietf.org/mail-archive/web/ietf/current/msg94635.html

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call: Recognising RFC1984 as a BCP


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/

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-09-07. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The affected document can be obtained via
https://datatracker.ietf.org/doc/rfc1984/

IESG discussion of this request can be tracked via
https://datatracker.ietf.org/doc/status-change-rfc1984-to-best-current-practice/ballot/