Skip to main content

Diameter Attribute-Value Pairs for Cryptographic Key Transport
draft-ietf-dime-local-keytran-14

Yes

(Dan Romascanu)
(Jari Arkko)

No Objection

(Adrian Farrel)
(David Harrington)
(Gonzalo Camarillo)
(Pete Resnick)
(Peter Saint-Andre)
(Robert Sparks)
(Ron Bonica)
(Stewart Bryant)
(Wesley Eddy)

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

Dan Romascanu Former IESG member
Yes
Yes () Unknown

                            
Jari Arkko Former IESG member
Yes
Yes () Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection () Unknown

                            
David Harrington Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection () Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection () Unknown

                            
Peter Saint-Andre Former IESG member
No Objection
No Objection () Unknown

                            
Robert Sparks Former IESG member
No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (2011-07-11) Unknown
  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.)
Sean Turner Former IESG member
(was Discuss) No Objection
No Objection (2011-07-13) Unknown
I fully support Stephen's discuss positions.
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2011-08-16) Unknown
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
thought. 

(2) Which of the Key-Type(s) are implementers of this expected
to support?
Stewart Bryant Former IESG member
No Objection
No Objection () Unknown

                            
Wesley Eddy Former IESG member
No Objection
No Objection () Unknown