I don't think there is anything that needs to be done for 2.2. It is a normal capability exchange type of mechanism.
The text is IMHO clear: "in situations where the Attribute is required to provision service.." Then the lack of EAP-Key-Name means the service cannot be provisioned and the NAS can safely interpret that as an Access-Reject, when appropriate by the deployment. NAS doesn't include the attribute if it is not needed. And if it does, the current text allows still accepting the service regardless the lack of the attribute in the Access-Accept. - Jouni On Mar 26, 2014, at 8:55 AM, Jari Arkko <[email protected]> wrote: > 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 <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/gen-art > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
