I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-abfab-eapapplicability-03 Reviewer: David L. Black Review Date: June 17, 2003 IETF LC End Date: June 17, 2003 Summary: This draft is on the right track but has open issues, described in the review. This draft updates the applicability statement for EAP to include usage for application layer access via EAP over GSSAPI. Additional security requirements are introduced for environments in which EAP is used for that purpose. I found one open issue, which is minor, and may be editorial Major issues: None Minor issues: One The next to last paragraph on p.3 begins with this sentence: For these reasons, channel binding MUST be implemented by peers, EAP servers and AAA servers in environments where EAP authentication is used to access application layer services. It appear that this "MUST" requirement applies to all uses of EAP, including network access authentication, not just application layer access authentication. If so, that's not immediately obvious from the text, and an additional sentence should be added to make this clearer. If not, the above sentence needs to exclude network access authentication from that requirement. Nits/editorial comments: The same paragraph (p.3) continues with: In addition, channel binding MUST default to being required by peers for non-network authentication. If the EAP server is aware that authentication is for something other than a network service, it too MUST default to requiring channel binding. What is meant by "non-network authentication" and "other than a network service"? If those mean "other than for network access authentication" as the term "network access authentication" is used in section 1 and RFC 3748, that meaning should be clarified. idnits 2.12.17 generated this comment: -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) idnits appears to be confused ;-). The -00 version of this draft is from 2012, and this draft does not contain sufficient material from RFC 3748 that would raise that concern, so this comment should be ok to ignore. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA  01748 +1 (508) 293-7953             FAX: +1 (508) 293-7786 david.black at emc.com        Mobile: +1 (978) 394-7754 ----------------------------------------------------