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
