Yes. On Aug 13, 2013, at 12:31 PM, Jari Arkko <[email protected]> wrote:
> Meral: thank you very much for your review. Joe: are the comments going to be > addressed in a new version? > > Jari > > On Aug 10, 2013, at 7:23 AM, Meral Shirazipour > <[email protected]> wrote: > >> Hi Joe, >> Thank you for the answer. Fine with me, if the document shepherd or AD >> approve, I would still suggest adding a comment in the abstract or intro >> mentioning that RFC4851 text is reused. >> >> Best, >> Meral >> >> From: Joseph Salowey (jsalowey) [mailto:[email protected]] >> Sent: Friday, August 09, 2013 15:55 >> To: Meral Shirazipour >> Cc: [email protected]; [email protected] >> Subject: Re: Gen-ART Last Call review of draft-ietf-emu-eap-tunnel-method-07 >> >> Hi Meral, >> >> Thanks for your review, comments inline below. >> >> Cheers, >> >> Joe >> On Jul 30, 2013, at 2:47 PM, Meral Shirazipour >> <[email protected]> wrote: >> >> >> I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ >> athttp://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). >> >> >> >> [Joe] RFC 4851 is informational and making normative reference to it would >> be a downref. We felt it would be better to include the complete text in >> the standards track document and remove any normative dependency on the >> information document. >> >> >> >> 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" >> >> >> [Joe] OK >> >> >> >> >> Best Regards, >> Meral >> --- >> Meral Shirazipour >> Ericsson >> Research >> www.ericsson.com >> >> _______________________________________________ >> Gen-art mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/gen-art > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
