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

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 <jari.arkko@piuha.net> 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 <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
> 