Diameter Attribute-Value Pairs for Cryptographic Key Transport
RFC 6734

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

(Jari Arkko) Yes

(Dan Romascanu) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2011-08-16)
No email
send info
I've cleared points 1 & 2 since the RSA key type is now gone (a pity, 
but I understand why, and hope it comes back in another form soon);
my 2nd point was me getting it wrong, (other specifications use 
this and handle MTI rather than this one),

--- original discuss text below ---

(1) I'm not sure that the Key-Type AVP is well enough specified.  At least
for the RSA-KEM variant, I would have expected to see a set of CMS options
(e.g. are certs to be included or not) would be needed in order to get
interop. (I was offine doing the review and am not familiar enough with 
the other options to know if the same issue arises.) Have there been any 
implementations of these, and if so, what did they put in the key values? 
I also don't get why the RFCs defining the details for Key-Type AVPs
are informative and not normative. If this document defines a protocol
that will result in interop, then they need to be normative I'd have

(2) Which of the Key-Type(s) are implementers of this expected
to support?

(David Harrington) (was Discuss) No Objection

(Russ Housley) No Objection

Comment (2011-07-11 for -)
No email
send info
  The Gen-ART Review by Joel Halpern on 2-Jun-2011 asks a reasonable
  question.  I would like to see it answered.

  The document carefully and reasonably does not define the contents of
  the keying material AVP.  This reviewer presumes that those closer to
  the activity will know where the contents have been or will be
  defined.  Are they already defined, or will they be defined in future
  documents?  If they are already defined, would it make sense to state
  that, and identify the location?  (My confusion is that it would seem
  difficult for existing RFCs to define the format of a TLV that did not
  exist.  But that may be a failure of my understanding.)

(Pete Resnick) No Objection

(Peter Saint-Andre) No Objection

(Robert Sparks) No Objection

(Sean Turner) (was Discuss) No Objection

Comment (2011-07-13)
No email
send info
I fully support Stephen's discuss positions.