MIKEY-SAKKE: Sakai-Kasahara Key Encryption in Multimedia Internet KEYing (MIKEY)
draft-groves-mikey-sakke-03

[Ballot comment]
Thank you for removing the text on legal intercept. I still believe there has not been an appropriate level of review of the implications of the forking and retargeting text. But given the current formulation, I've been convinced to abstain.

[Ballot comment]
I am not sure that I would necessarily describe "support for lawful
interception" as a "desirable feature".

---

Would be nice to run idnits and tidy the document up.

[Ballot discuss]
No issue with this document, but a couple of matters of process to be sorted out, I think.

---

Figure 1 uses some form of syntax that isn't defined in this document.
Please insert a reference to the document that defines the syntax.

---

Section 3.2

There is an example phone number +441234567890
This doesn't look like a "standard" example phone number to me.

[Ballot comment]
It is the job of the *AD* to check conformance to idnits for AD-sponsored documents...

INTRODUCTION, paragraph 10:
> Copyright Notice

Boilerplate is outdated for a -00 doc that was submitted Jun 2010.


INTRODUCTION, paragraph 15:
> Table of Contents

The document seems to lack an IANA Considerations section.

[Ballot comment]
Abstract: this document mentions this key exchange method is used in the IMS. It may be good to repeat the statement in the Introduction adding a reference to an IMS-reated 3GPP spec.

TGK is not expanded in the text.

[Ballot discuss]
1) (This is mostly a question for the sponsoring AD for telechat discussion, but anyone is welcome to reply). Is this intended to be an IETF consensus document? What boilerplate are you targeting?

2) This document is registering a mikey mode. Does it need to mention Lawful Intercept (see RFC2804)? Is it necessary for it to discuss forking, retargeting, and deferred delivery as part of registering the mode? These things need to be discussed somewhere, but is this the right document?

[Ballot comment]
Please consider the editorial comments  from the Gen-ART Review by
  Avshalom Houri on 19-JAN-2011.  You can found the review at:

    http://www.softarmor.com/rai/temp-gen-art/
    draft-groves-mikey-sakke-00-houri.txt

[Ballot discuss]
#1) Needs an IANA section.  Basically, it needs to point to Section 4 to say you're registering X # of new items for MIKEY.

#2) Section 3.2 indicates that:

  Further Identifier
  schemes MAY be defined for communities that require different key
  longevity.

Is there some type of registry needed for the different identifiers? I.e., would somebody that wanted to do bi-weekly updates need new registry entries in Section 4?  For example should it be SAKKE - Monthly so when people decide to do it biweekly it'd be SAKKE- Bi Weekly?

[Ballot discuss]
This has not been sent to the author yet.

#1) Needs an IANA section.  Basically, it needs to point to Section 4 to say you're registering X # of new items for MIKEY.

#2) Section 3.2 indicates that:

  Further Identifier
  schemes MAY be defined for communities that require different key
  longevity.

Is there some type of registry needed for the different identifiers? I.e., would somebody that wanted to do bi-weekly updates need new registry entries in Section 4?  For example should it be SAKKE - Monthly so when people decide to do it biweekly it'd be SAKKE- Bi Weekly?

[Ballot discuss]
This has not been sent to the author yet.

#1) Needs an IANA section.

#2) Section 3.2 indicates that:

  Further Identifier
  schemes MAY be defined for communities that require different key
  longevity.

Is there some type of registry needed for the different identifiers? I.e., would somebody that wanted to do bi-weekly updates need new registry entries in Section 4?  For example should it be SAKKE - Monthly so when people decide to do it biweekly it'd be SAKKE- Bi Weekly?

[Ballot comment]
#1) Abstract:

The acronym IDPKC doesn't match the capitalized letters in
its expansion.  Suggestion: s/Identifier-based Public Key
Cryptography/Identifier-Based Public Key Cryptography/

Please expand IMS.

#2) Is it Identifier-Based Encryption or Identity-Based Encryption?  RFC 5091
indicates it's the latter.

#3) Any reason this can't reference FIPS 180-3?

#4) In section 1, paragraph 2, s/legislation/legislations/.

#5) In the title of section 2, s/Mode;/Mode:/.

#6) In section 2.1, paragraph 1, the acronym "TGK" is not expanded on first use.

[Ballot comment]
#1) Abstract: Please expand IMS.

#2) Is it Identifier-Based Encryption or Identity-Based Encryption?  RFC 5091
indicates it's the latter.

#) Any reason this can't reference FIPS 180-3?

n the Abstract, the acronym IDPKC doesn't match the capitalized letters in
its expansion.  Suggestion: s/Identifier-based Public Key
Cryptography/Identifier-Based Public Key Cryptography/

In section 1, paragraph 2, s/legislation/legislations/.

Why is the word "identifier" (and variants) persistently capitalized?  It
doesn't appear to be being used as a proper noun.

In the title of section 2, s/Mode;/Mode:/.

In section 2.1, paragraph 1, the acronym "TGK" is not expanded on first use.

There is no IANA Considerations section, FULL STOP.

IANA has a question about this document.

IANA notes that this document does not contain a standard IANA
Considerations section. After examining the draft, IANA sees several
values in the document that are marked TBD. Are these values that IANA
is supposed to assign or register? If so, in which registry should these
values be registered?

Further, IANA understands that SAKKE -- a protocol that is the subject
of another draft being considered for publication -- requires each
application to define the set of public parameters to be used by
implementations. Appendix A provides those public parameters for MIKEY.
Should those parameters be registered by IANA or is their publication in
an approved document sufficient?

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

To: IETF-Announce 
From: The IESG
Reply-to: ietf@ietf.org
Subject: Last Call: draft-groves-mikey-sakke (MIKEY-SAKKE: Sakai-Kasahara Key Exchange in Multimedia Internet KEYing (MIKEY)) to Informational RFC

The IESG has received a request from an individual submitter to consider
the following document:

- 'MIKEY-SAKKE: Sakai-Kasahara Key Exchange in Multimedia Internet KEYing
  (MIKEY) '
    as an Informational RFC

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 2011-01-18. 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/internet-drafts/draft-groves-mikey-sakke-00.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=20161&rfc_flag=0