The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY)
draft-ietf-msec-newtype-keyid-05

[Ballot discuss]
Section 3 of this specification makes it clear that this specification
fundamentally changes the role of MIKEY.  This specification turns
MIKEY into a rekey protocol not just a registration protocol.  In
addition, this specification supports in-band encryption parameters,
which again is a significant change.

So, I'd expect  that somewhere the semantics of these new uses of MIKEY are defined.  The closest I find is  the following paragraph:

    The MBMS use of the Key ID Type sub-payloads is as follows.  Since
    each MTK is protected by a particular MSK, there is a need to
    indicate which MSK is used.  This is done by including the MSK
    identity as well as the MTK identity in the Extension payload with
    MTK delivery messages.  The MSK itself is of course not included in
    the message, only its identity.


I'm concerned that this text is not sufficient for interoperable
implementations of this specification.  I'd prefer for the text to
clearly describe how this extension changes the MIKEY messages and to
change their semantics.  Alternatively, if there are two interoperable
implementations my concern could be addressed by an RFC 2026-style
implementation report which the IESG can request.  I'd also listen to
an explanation of why this text is sufficient although I will be skeptical.

[Ballot comment]
Minor typo in the IANA Consideration section:

"Please add the following to the IANA registry at
http://www.iana.org/assignments/mikey-payloads (To be removed by
after IANA processing)."

I assume they mean to say "to be removed by the RFC Editor after..."

[Ballot comment]
Minor typo in the IANA Consideration ssection:

"Please add the following to the IANA registry at
http://www.iana.org/assignments/mikey-payloads (To be removed by
after IANA processing)."

I assume they mean to say "to be removed by the RFC Editor after..."

3GPP2 is looking at this document.  If any changes are made as a result of this coordination, then IETF Last Call will be repeated to ensure that no issues were introduced.  If no changes are made, then the document is ready to be put on the IESG telechat agenda.  A response from 3GPP2 is expected by the end of August.

Late IANA Last Call Comments:
Upon approval of this document the IANA will register a new
MIKEY General Extension Payload Type (requested value 3) which will be placed in the last registry found at the following:
http://www.iana.org/assignments/mikey-payloads

The IANA Considerations section also describes the following:

The name spaces for the following fields in the General Extensions
  payload (from Sections 3 and 4) are requested to be managed by IANA:

  * Key ID Type (Table 2).

  * New value for CS ID map type (Table 3).

We understand these to be 2 new sub registries for the IANA to maintain.
Should these be placed at the same location as the General Extensions?
The IANA Considerations section needs to be updated to explain what the registration rules and what the value ranges are for these 2 new registries.