Document Action: IAB and IESG Statement on Cryptographic Technology and the Internet to Best Current Practice

The IESG <iesg-secretary@ietf.org> Mon, 21 September 2015 21:06 UTC

Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ietf-announce@ietfa.amsl.com
Delivered-To: ietf-announce@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CAE21A904F for <ietf-announce@ietfa.amsl.com>; Mon, 21 Sep 2015 14:06:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTWCjeLJXwXt; Mon, 21 Sep 2015 14:06:22 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 068831A903A; Mon, 21 Sep 2015 14:06:22 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Document Action: IAB and IESG Statement on Cryptographic Technology and the Internet to Best Current Practice
X-Test-IDTracker: no
X-IETF-IDTracker: 6.4.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150921210622.24061.35825.idtracker@ietfa.amsl.com>
Date: Mon, 21 Sep 2015 14:06:22 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf-announce/FXpz3-UELhF7S5kBxXvTrRDXSgs>
Cc: RFC Editor <rfc-editor@rfc-editor.org>
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: ietf@ietf.org
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-announce/>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Sep 2015 21:06:25 -0000

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.