Re: [Gen-art] Gen-ART LC Review of draft-ietf-radext-ieee802ext-10

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 <bclaise@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