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