Last Call: RFC 5011 (Automated Updates of DNS Security (DNSSEC) Trust Anchors) to Internet Standard

IESG Secretary <iesg-secretary@ietf.org> Fri, 05 October 2012 14:48 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: IESG Secretary <iesg-secretary@ietf.org>
To: IETF Announcement List <ietf-announce@ietf.org>
Subject: Last Call: RFC 5011 (Automated Updates of DNS Security (DNSSEC) Trust Anchors) to Internet Standard
Message-ID: <20121005144802.1972.16798.idtracker@ietfa.amsl.com>
Date: Fri, 05 Oct 2012 07:48:02 -0700
Cc: dnsext@ietf.org
Precedence: list

The IESG has received a request from the author to consider the
following document:
 
'Automated Updates of DNS Security (DNSSEC) Trust Anchors,' RFC 5011

as an Internet Standard.

RFC 6410 specifies 4 criteria for reclassifying a document as Internet
Standard:

   (1) There are at least two independent interoperating implementations
       with widespread deployment and successful operational experience.

1. RFC 5011 support is built in to BIND, the most widely deployed DNS
   server/resolver as of version 9.7. 
2. RFC 5011 support is built in to MS Active
   Directory. http://technet.microsoft.com/en-us/library/jj200224.aspx 

There appears to be sufficient support in zone signing tools for the
REVOKE bit. 

RFC5011 is specified as the root key rollover protocol.  Other zones
appear have adopted this astheir mechanism for updating their trust
anchors.

RFC5011 is a hybrid of operational practices (by the zone owner to
signal key changes) and implementations (by the zone owner to sign new
keys and revocations, and by the client to automatically update the
trust store).

There appear to be more than two implementations on the client side.  

There is anecdotal evidence that successful operational key rollovers
have been made with this protocol.

   (2) There are no errata against the specification that would cause a
       new implementation to fail to interoperate with deployed ones.

There are no outstanding errata for RFC 5011.

   (3) There are no unused features in the specification that greatly
       increase implementation complexity.

There are no such unused features in RFC 5011.

   (4) If the technology required to implement the specification
       requires patented or otherwise controlled technology, then the
       set of implementations must demonstrate at least two independent,
       separate and successful uses of the licensing process.

The IPR claims against RFC 5011 are non-specific and do not appear to
have affected the implementation of the protocol.

Note that RFC 5011 does include normative references to RFC 3755, RFC
4033, RFC 4034 and RFC 4035 that will become down-refs if RFC 5011 is
reclassified as "Internet Standard."  These down-refs do not preclude
reclassification of RFC 5011 under the criteria of RFC 6410.
 
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 2012-11-02. 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 file can be obtained via 
http://www.ietf.org/rfc/rfc5011.txt 
 
IESG discussion can be tracked via 
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=5011&rfc_flag=1

Last Call: RFC 5011 (Automated Updates of DNS Sec… IESG Secretary