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

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