Last Call Review of draft-ietf-emu-eap-tunnel-method-07
review-ietf-emu-eap-tunnel-method-07-genart-lc-shirazipour-2013-07-31-00

Request Review of draft-ietf-emu-eap-tunnel-method
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-07-30
Requested 2013-07-18
Authors Hao Zhou, Nancy Cam-Winget, Joseph Salowey, Steve Hanna
Draft last updated 2013-07-31
Completed reviews Genart Last Call review of -07 by Meral Shirazipour (diff)
Secdir Last Call review of -07 by Chris Lonvick (diff)
Assignment Reviewer Meral Shirazipour 
State Completed
Review review-ietf-emu-eap-tunnel-method-07-genart-lc-shirazipour-2013-07-31
Reviewed rev. 07 (document currently at 10)
Review result Almost Ready
Review completed: 2013-07-31

Review
review-ietf-emu-eap-tunnel-method-07-genart-lc-shirazipour-2013-07-31






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-emu-eap-tunnel-method-07




Reviewer: Meral Shirazipour




Review Date: 2013-07-30




IETF LC End Date: 2013-07-30




IESG Telechat date: NA




 




 




Summary:




This draft is almost ready to be published as Standards Track RFC but I have some comments.




 




 




Nits/editorial comments:




Many sections of the document are a direct copy paste of RFC4851(EAP-FAST) with a minor change: "EAP-FAST"->"TEAP".





Since RFC4851 is mentioned as being well adopted, is there a reason why it has not been used as reference point and then only mention the diffs in more detail? (for the sections concerned).





Appendix B is useful, but the above suggestion could have made the document a lot shorter and easier to understand by people already familiar with EAP-FAST.




Unless this draft is to replace RFC4851? In which case the abstract should mention this.







e.g.




[Page 20], Section 3.7 Fragmentation, is a copy of RFC4851's Section 3.7 with "EAP-FAST"->"TEAP".




Why not use RFC4851's Fragmentation proposal as a reference point and just mention what is different (e.g. nothing but the EAP-Type in this case).




 




 




Nits:




[Page 6], Section 1.2, reference [RFC5077] appears twice.




[Page 21], section 3.8, paragraph 2, "which the the peer"--typo-->remove extra "the"




[Page 24], Section 3.8.4, paragraph 2, "succ;essfully"--typo-->"successfully"




[Page 56], line 3, "Note: Peer's are"---->"Peers"




[Page 73], Section 7.6, "is remoted"--typo-->"is remote"




 




 




Best Regards,




Meral




---




Meral Shirazipour




Ericsson




Research




www.ericsson.com