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

Thanks, I have placed a no-obj position on the ballot. I agree with Ben that additional explanation might be useful.

Jari

On Mar 27, 2014, at 6:18 AM, Ben Campbell <ben@nostrum.com> wrote:

> I'm satisfied with the responses. I think it would not hurt to add some of the explanations from the various emails into the draft, but that's by no means a show stopper.
> 
> Thanks!
> 
> Ben.
> 
> On Mar 26, 2014, at 7:17 AM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
> 
>> In 802.1X-2010, the EAP Key Name is  actually needed to calculate the session keys. So if it is unavailable, the NAS won't be able to decrypt traffic. Therefore treating the Accept as a Reject is probably the only viable option.
>> 
>>> On Mar 26, 2014, at 5:42 AM, "Jouni Korhonen" <jouni.nospam@gmail.com> wrote:
>>> 
>>> 
>>> 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
>>> 
>> 
>> _______________________________________________
>> 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