Skip to main content

IANA Rules for MIKEY (Multimedia Internet KEYing)
draft-arkko-mikey-iana-01

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>
Subject: Protocol Action: 'IANA Rules for MIKEY (Multimedia Internet KEYing)' to Proposed Standard (draft-arkko-mikey-iana-01.txt)

The IESG has approved the following document:
- 'IANA Rules for MIKEY (Multimedia Internet KEYing)'
  (draft-arkko-mikey-iana-01.txt) as a Proposed Standard

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Sean Turner.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-arkko-mikey-iana/


Ballot Text

Technical Summary

  This document clarifies and relaxes the IANA rules for Multimedia
  Internet KEYing (MIKEY). The document changes, for majority of the
  namespaces, the requirement of "IETF Review" into "IETF Review or IESG
  Approval". For some namespaces, the requirement is changed to
 "Specification Required".

Working Group Summary

  Document was presented in the MSEC WG at IETF 80, but consensus was that
  it is best to handle it as an AD-sponsored document.

Document Quality

  This document does not specify a new protocol. 

Personnel

   Ari Keränen (ari.keranen@ericsson.com) is the document shepherd.
   Sean Turner (turners@ieca.com) is the responsible AD.

RFC Editor Note

Please make the following change in Section 1:

OLD:

   Moreover, for some registries a stable specification
   would be a sufficient requirement and hence this is reflected in the
   updated IANA rules.  For instance, for some registries an RFC via the
   Independent Stream at the RFC Editor is sufficient, and does not
   force an IETF evaluation of a particular new extension for which
   there is no general demand.

NEW:

   Moreover, for some registries a stable specification
   would be a sufficient requirement and hence this is reflected in the
   updated IANA rules.  For instance, for some registries an RFC via the
   Independent Stream at the RFC Editor is sufficient, and does not
   force an IETF evaluation of a particular new extension for which
   there is no general demand.  Nevertheless, if there is doubt whether
   IETF review would be needed for a new allocation, that is still
   encouraged instead of using the IESG approval path.




RFC Editor Note