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

Ben Campbell <ben@nostrum.com> Fri, 31 January 2014 22:57 UTC

From: Ben Campbell <ben@nostrum.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 31 Jan 2014 16:57:06 -0600
Message-Id: <8C9EE7F2-AA3D-482A-B469-4A147D143954@nostrum.com>
To: draft-ietf-radext-ieee802ext.all@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: "gen-art@ietf.org Team (gen-art@ietf.org)" <gen-art@ietf.org>
Subject: [Gen-art] Gen-ART LC Review of draft-ietf-radext-ieee802ext-10
Precedence: list

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] Gen-ART LC Review of draft-ietf-radext-… Ben Campbell
Re: [Gen-art] Gen-ART LC Review of draft-ietf-rad… Benoit Claise
Re: [Gen-art] Gen-ART LC Review of draft-ietf-rad… Jari Arkko
Re: [Gen-art] Gen-ART LC Review of draft-ietf-rad… Jouni Korhonen
Re: [Gen-art] Gen-ART LC Review of draft-ietf-rad… Bernard Aboba
Re: [Gen-art] Gen-ART LC Review of draft-ietf-rad… Ben Campbell
Re: [Gen-art] Gen-ART LC Review of draft-ietf-rad… Jari Arkko