Skip to main content

The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method
RFC 5106

Yes

(Jari Arkko)

No Objection

(Cullen Jennings)
(Dan Romascanu)
(David Ward)
(Lisa Dusseault)
(Magnus Westerlund)
(Mark Townsley)
(Ron Bonica)
(Ross Callon)
(Tim Polk)

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

Jari Arkko Former IESG member
(was Discuss, Yes) Yes
Yes () Unknown

                            
Chris Newman Former IESG member
No Objection
No Objection (2007-10-04) Unknown
Were this going standards track, I'd probably abstain due to the 
complexity of this protocol unless there was strong evidence of
interoperability in practice.  I would be concerned about the real
world security of such a complex protocol -- every line of code is
an opportunity for a security vulnerability and every option makes
this more difficult to deploy and use.  I'd also be concerned
about the sub-negotiation problem (first negotiate EAP-IKEv2,
then negotiate EAP-IKEv2 options, but what if another EAP mechanism
was a better fit for the client once the available EAP-IKEv2 options
were seen?).

The abstract shouldn't mention the expert review -- that's not relevant
to a summary of the salient content of the document.  That mention would
be better in the introduction or IANA Considerations section.
Cullen Jennings Former IESG member
No Objection
No Objection () Unknown

                            
Dan Romascanu Former IESG member
No Objection
No Objection () Unknown

                            
David Ward Former IESG member
No Objection
No Objection () Unknown

                            
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Magnus Westerlund Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Mark Townsley Former IESG member
No Objection
No Objection () Unknown

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

                            
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (2007-10-03) Unknown
  Based on the Gen-ART Review by Robert Sparks:

  The 2119 language isn't boilerplate.

  Reference 6 (to RFC 3629) is not used.

  Section 8.8 first sentence should probably start "The Certificate  
  Request payload".

  The IANA considerations should suggest a registry name.

  The last full paragraph on page 32: s/outline in [9]/outlined in [9]/
  Also,  if the polices are stated in this document, pointing to [9]
  seems a little redundant; however, if there's stuff in [9] that is
  missing here, then it is probably not an informative reference.
Tim Polk Former IESG member
No Objection
No Objection () Unknown