Distribution of EAP-Based Keys for Handover and Re-Authentication
RFC 5749

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

(Jari Arkko) (was Discuss) Yes

(Tim Polk) Yes

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Ralph Droms) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

(Pasi Eronen) (was Discuss) No Objection

(Adrian Farrel) No Objection

Comment (2009-10-20 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
AAA is not an RFC Editor "well-known" abbrevation, and should be 
expanded in the Abstract and on first use in the main text. You 
might also add it to section 2.

(Russ Housley) No Objection

Comment (2009-10-20 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  In the Gen-ART Review by Francis Dupont on 2009-07-30, it was suggested:

    I understand this specification is very abstract about on wire
    entities (for instance there is nothing about encoding, etc) but
    this can become an issue about key labels, i.e., the reader has
    to read the (referenced) RFC 5295 if (s)he wants to know what are
    exactly these key labels (note the term "label" can denote many
    different things). I suggest to be slightly more reader friendly,
    for instance by writing the RFC 5295 establishes a IANA registry
    for "USRK Key Labels" too:
    
    for the specification of key labels -> ... and associated IANA registry.

(Cullen Jennings) No Objection

Alexey Melnikov No Objection

Comment (2009-10-17 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
The following 2 references don't look like Normative references:

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

(Dan Romascanu) No Objection

Comment (2009-10-21 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I noticed that the PROTO write-up includes the following: 

>My only concern is whether the document should be on the Standards track or
>if BCP would be a better classification: the original document was less
>abstract & more RADIUS-specific & so Standards Track made some sense; I'm
>not so sure about this version.  

I actually am quite confortable with this document being approved as PS, because it does define a mechanism that involves interoperability on the wire. It would be good however for the IESG to consider again this issue before approval.

(Robert Sparks) No Objection

Magnus Westerlund No Objection