Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 Revision 1
RFC 4758

Note: This ballot was opened for revision 02 and is now closed.

(Russ Housley) Yes

(Jari Arkko) No Objection

(Ross Callon) No Objection

(Brian Carpenter) No Objection

Comment (2006-07-06 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Points from Gen-ART review by Eric Gray that could
usefully be clarified:

In section 3.7.1 - you say:

"The XML format for CT-KIP messages have been designed to be
 extensible.  However, it is possible that the use of extensions will
 harm interoperability and therefore any use of extensions should be
 carefully considered."

Can we say anything about what "harm interoperability" or "carefully 
considered" means?  What are the risks?  How can they be avoided?
Is there a reference you can point to that talks about the issues?


In section 3.8.6 (CT-KIP server's second PDU), on pages 27 and 28,
I am having trouble matching message fields (shown on page 27) with
descriptions (given on pages 27 and 28).



In section 5.2.1, the last sentence would be better worded as:

"Sections 5.2.2 through 5.2.7 analyze these attack scenarios."


In section 6 (IANA Considerations), you say:

"None at this point; the MIME type is already registered."

The document mentions several MIME types.  I assume you meant:
"application/vnd.otps.ct-kip+xml" in this case (as opposed to
- for instance - "image/jpeg" or "image/gif").

I would change the section to read either -

"None at this point; the MIME type (section 4.2.2) is already


"IANA has no action with respect to this document."

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

(Ted Hardie) (was Discuss) No Objection

(Cullen Jennings) No Objection

(Dan Romascanu) No Objection

Comment (2006-07-05 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
idnits says that reference [11] is not used. Looks like it's right.

(Mark Townsley) No Objection

Magnus Westerlund (was Discuss) No Objection