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 <b...@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_ab...@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.nos...@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.ar...@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 <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 > > _______________________________________________ > 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
