Skip to main content

Last Call Review of draft-ietf-emu-eaptunnel-req-
review-ietf-emu-eaptunnel-req-secdir-lc-mundy-2010-12-03-00

Request Review of draft-ietf-emu-eaptunnel-req
Requested revision No specific revision (document currently at 09)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-11-30
Requested 2010-10-24
Authors Hao Zhou , Joseph A. Salowey , Katrin Hoeper , Steve Hanna
I-D last updated 2010-12-03
Completed reviews Secdir Last Call review of -?? by Russ Mundy
Assignment Reviewer Russ Mundy
State Completed
Request Last Call review on draft-ietf-emu-eaptunnel-req by Security Area Directorate Assigned
Completed 2010-12-03
review-ietf-emu-eaptunnel-req-secdir-lc-mundy-2010-12-03-00
I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors. Document editors and WG chairs should treat 
these comments just like any other last call comments.

I need to start my comments by saying that I do not have a background
in the details EAP, tunnels and TLS so I approached the document
review as someone who was a potential designer of a solution that the
document might provide.  The broad problem that I encountered with the
document is that it is unclear how it relates to other EAP, TLS and
other tunnel specifications.  Since there are essentially no
illustrations or text describing the various parts and how they are
related nor was I able to locate any other document providing
architectural descriptions, my conclusion is that the document seems
to be for people that already are very familiar with other
specifications/documents related to the multiple technology pieces
described in the document.  In short, there is not sufficient
architectural context for the document to be widely useful.

- Publication of the current document (without the architectural
  context) might provide some value to the Internet community
  but I would recommend that the IESG sees that more architectural
  context gets put in some document in the near future. Without such
  architectural direction, documents such as this one will not be used
  as expected either because they won't be found or won't be understood.


A couple of more specific comments:

- In section 2., the redifinition of MUST, MUST NOT, SHOULD, SHOULD
  NOT, and MAY for _this_ document does not seem appropriate.  The
  document should use the standard definitions for these terms or find
  different words for the definitions (conventions).

- Section 4.4 has a normative reference to an I-D which expired in May
  of 2009.  This needs to be corrected prior to publications.


Russ Mundy