Thanks for the review. I did not see a response or change regarding 2.1 or 2.2. Does this need to be addressed? Authors?
Jari On Feb 27, 2014, at 9:08 PM, Benoit Claise <bcla...@cisco.com> wrote: > Dear authors, > > Can you please follow up on that one. > > Regards, Benoit >> 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-radext-ieee802ext-10 >> Reviewer: Ben Campbell >> Review Date: 2014-01-31 >> IETF LC End Date: 2014-02-04 >> >> Summary: This draft is almost ready for publication as a standards track >> RFC. I have a small number of minor comments that may be worth considering >> prior to publication. >> >> Major issues: None >> >> Minor issues: >> >> -- 2.1, last paragraph: >> >> Does the last sentence imply Allowed-Called-Station-Id actually should (or >> SHOULD) not be used in non-wireless scenarios? (I note that the >> Network-Id-Name section talks about how 802.1X NID-Names should not be >> included in Called-Station-Id, but rather put in Network-Id-Name. Does that >> apply here as well? >> >> -- 2.2, last paragraph: "Since a NAS will typically only include a >> EAP-Key-Name Attribute in an Access-Request in situations where the >> Attribute is required to provision service, if an EAP-Key-Name Attribute is >> included in an Access-Request but is not present in the Access-Accept, the >> NAS SHOULD treat the Access-Accept as though it were an Access-Reject. " >> >> Is there a backwards compatibility issue? What if a NAS sends the field to a >> server that doesn't implement this draft? Is there an assumption that a NAS >> that supports this draft will only work with a server that also supports it? >> >> Or more to the point, is the "...typically only include...where required..." >> strong enough to require a normative SHOULD? Seems like this would >> discourage the inclusion of EAP-Key-Name in the non-typical case of it _not_ >> being required. Is that the intent? >> >> Nits/editorial comments: >> >> -- section 2.8: >> >> It might be worth expanding "EAPoL" >> >> >> >> . >> > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
