Hi Roni, Sorry I missed your first message, thank you for resending it. Comments in line below: Cheers, Joe On Nov 27, 2010, at 11:34 PM, Roni Even wrote: > Hi, > I sent the following review on October 25th but did not see and response. > > Roni Even > > > > 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-eaptunnel-req-08 > Reviewer: Roni Even > Review Date:2010–10–25 > IETF LC End Date: 2010–11–10 > IESG Telechat date:2010-12-2 > > Summary: This draft is almost ready for publication as an Informational RFC. > > Major issues: > > Minor issues: > 1. In section 2 why not reference RFC 2119 or at least copy the definition from RFC 2119 for the capitalized term. > [Joe] We followed the convention used in RFC 5209 (NEA protocol requirements), because this document is defining requirements rather than the protocol itself. > 2. In section 3.9 when you say “if this technique is used”, by this do you mean certificate –less or the flow defined in the previous sentence. > [Joe] "if this technique is used" refers to certificatel-less authentication using the inner EAP method for client authentication without server authentication. Perhaps the following sentence would be clearer: "If an inner EAP method is used for client authentication without full server validation the inner method MUST provide resistance to dictionary attack and a cryptographic binding between the inner method and the tunnel method MUST be established. ..." Does this help? > 3. In section 4.6.3 the first paragraph defines the requirements for Cryptographic Binding. It looks to me like the rest of the section talks about a specific use case, so why is it in the requirements section and not in section 3. > [Joe] The majority of section 4.6.3 discusses a possible mechanism to achieve cryptographic binding. While it is not specifically a requirement I think it supports the requirement defined in the first paragraph. I do not think it belongs in the use case section. > > > > Nits/editorial comments: > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf