IANA Rules for MIKEY (Multimedia Internet KEYing)
RFC 6309

Document Type RFC - Proposed Standard (August 2011; No errata)
Obsoletes RFC 4909
Was draft-arkko-mikey-iana (individual in sec area)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 6309 (Proposed Standard)
Telechat date
Responsible AD spt
IESG note Ari Keranen (ari.keranen@ericsson.com) is the document shepherd
Send notices to jari.arkko@piuha.net, ari.keranen@ericsson.com, john.mattsson@ericsson.com, draft-arkko-mikey-iana@ietf.org
Internet Engineering Task Force (IETF)                          J. Arkko
Request for Comments: 6309                                    A. Keranen
Obsoletes: 4909                                              J. Mattsson
Updates: 3830, 4563, 5410, 6043                                 Ericsson
Category: Standards Track                                    August 2011
ISSN: 2070-1721

           IANA Rules for MIKEY (Multimedia Internet KEYing)

Abstract

   This document clarifies and relaxes the IANA rules for Multimedia
   Internet KEYing (MIKEY).  This document updates RFCs 3830, 4563,
   5410, and 6043; it obsoletes RFC 4909.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6309.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Arkko, et al.                Standards Track                    [Page 1]
RFC 6309                    MIKEY IANA Rules                 August 2011

1.  Introduction

   This document relaxes the IANA rules for Multimedia Internet KEYing
   (MIKEY) [RFC3830].  The IANA rules defined in [RFC3830], [RFC4563],
   [RFC4909], and [RFC5410] are affected.  In addition, the rules
   specified in [RFC6043] are re-specified here.

   Most of the values in MIKEY namespaces are divided into two ranges:
   "IETF Review" (or "IETF Consensus" as it was previously called) and
   "Reserved for Private Use" [RFC5226].  This document changes, for
   majority of the namespaces, the requirement of "IETF Review" to "IETF
   Review or IESG Approval" [RFC5226].  For some namespaces, the
   requirement is changed to "Specification Required" [RFC5226].

   The rationale for this update is that there can be situations where
   it makes sense to grant an allocation under special circumstances or
   that time has shown that the current requirement is unnecessarily
   strict for some of the namespaces.  By changing the current IANA
   rules to also allow for "IESG Approval" [RFC5226], it becomes
   possible for the Internet Engineering Steering Group (IESG) to
   consider an allocation request, even if it does not fulfill the
   default rule.  For instance, an experimental protocol extension could
   perhaps deserve a new payload type as long as a sufficient number of
   types still remains, and the MIKEY community is happy with such an
   allocation.  Moreover, for some registries, a stable specification
   would be a sufficient requirement, and this is thus reflected in the
   updated IANA rules.  For instance, an RFC via the Independent Stream
   at the RFC Editor is sufficient for some registries and does not
   force an IETF evaluation of a particular new extension for which
   there is no general demand.  Nevertheless, "IETF Review" is still
   encouraged (instead of using the "IESG Approval" path) if there is
   doubt about whether or not it is needed for a new allocation.

   The rest of this document is structured as follows.  Section 2
   defines the new IANA rules.  Section 3 discusses the security
   implications of this document.  Sections 4, 5, 6, and 7 explain the
   changes to [RFC3830], [RFC4563], [RFC4909], [RFC5410], and [RFC6043].

2.  IANA Considerations

   IANA updated the registries related to MIKEY as specified below.  All
   other MIKEY IANA registries remain unchanged.

   New values for the version field ([RFC3830], Section 6.1) and the C
   envelope key cache indicator ([RFC3830], Section 6.3) field can be
   allocated via "IETF Review".

Arkko, et al.                Standards Track                    [Page 2]
RFC 6309                    MIKEY IANA Rules                 August 2011
Show full document text