[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue 115: WGLC
Dave pointed out many days ago a number of editorial comments...
> Issue 115: WG Last Call Comments
> Submitter name: David Nelson
> Submitter email address: dnelson@enterasys.com Date first
> (1)
>
> Within the confines of RADIUS authentication, authorization,
> and accounting (AAA) environments, there is a general dearth
> of standardized RADIUS attributes to limit user access using
> dynamic VLANs, filters or redirection.
>
> Could we change "a general dearth of" to "a requirement for"?
> It sounds more positive.
[ms] Accepted.
>
> (2)
>
> IEEE 802.1X-2004 [IEEE8021X] provides "network port
> authentication" for IEEE 802 [IEEE802] media, including
> Ethernet [IEEE8023], Token Ring and 802.11 wireless LANs [IEEE80211i].
>
> Remove this sentence as it appears in the second paragraph as well.
[ms] Accepted.
>
> Section 1.1: The following definitions are not used in the draft:
>
> Access Point
> Association
> Station
>
> Requested change:
>
> Please delete them.
[ms] Accepted.
>
> Section 2: Better phrasing.
>
> Requested changes:
>
> (1) The first paragraph is awkwardly worded. Perhaps the
> following would be an improvement.
>
> In this section we provide an elaboration of the requirements
> briefly described in the Introduction.
>
> (2)
> For example, the user maybe on
> a prepaid plan and all the resources have been used up.
>
> Change "maybe" to "may be" and "resources have" to "credit
> balance has".
>
> (3)
> For example, the ability to block and
> redirect traffic is required for TCP users, cell phone users,
> WiFi users.
>
> Change "TCP users" to "IP users".
>
> (4) Change:
>
> As pointed out by [NASREQ] the use Filter-Id is not roaming
> friendly and it is recommended that instead one should use NAS-
> Filter-Rule(TBD) AVP. For this reason, this document introduces
> NAS-Filter-Rule(TBD) to RADIUS.
>
> To:
>
> As pointed out by [NASREQ] the use Filter-Id is not roaming
> friendly and it is recommended that instead one should adapt
> the Diameter NAS-Filter-Rule AVP as a RADIUS
> NAS-Filter-Rule(TBD) attribute.
[ms] Given the result of I114, section 2 may be eliminated entirely.
> Section 2.1: This section seems out of place.
>
> 2.1 Capability Advertisement
>
> RADIUS does not currently define a method by which a NAS can
> advertise its capabilities and in many instances, it would be
> desirable for the home network to know what capabilities are
> supported by the NAS to ensure proper operational behavior.
> The attributes defined in this document are intended to be
> used to enforce policy by the NAS. If a NAS does not
> recognize these attributes it will most likely ignore them
> and the desired policy will not be enforced. A method for the
> NAS advertising the capability to support these attributes
> would help the RADIUS server understand if the intended
> policies can be enforced. As a result, the attributes in this
> document, in particular NAS-Filter- Rule(TBD), can benefit
> from capability advertisement, if available.
>
> Requested changes:
>
> Should this entire section perhaps be part of the Security
> Considerations?
[ms]What is your rationale?
>
> Section 3.5: Clarification of the text.
>
> Requested changes:
>
> Furthermore, the concatenated filter list must abide to the
> following rules of precedence and ordering:
>
> 1) A flush rule MUST appear before all other rule types.
>
> Change "A flush rule" to "A flush rule, when present,".
>
> 2) Base encapsulation filter rules MUST appear after a flush
> rule and before IP tunnel, HTTP redirect, IP filter, and/or
> HTTP filter rules.
>
> Change "a flush rule" to "any flush rule".
[ms]This text changed due to actions decided upon for I102. Take a look
at resolution for this issue.
>
> dir "in" is from the terminal, "out" is to the terminal,
> "inout" is from and to the terminal.
>
> The term "terminal" is not defined in the draft. I suspect it
> identifies the network entity which contains the IEEE 802.1X
> Supplicant function, but this should perhaps be clarified.
[ms] This sentence comes by way of the IPFilterRule description found in
Diameter [RFC3588]. What would you suggest we do for RADIUS. Is
terminal not a globally known term in RADIUS, if not, is there any?
Perhaps can you suggest a definition to add to the terminology section.
>
> General comment: I'd much rather that we use ABNF to define
> the NAS-Filter-Rule formal syntax, however I'm not prepared
> to submit that text just now. :-)
[ms] Agree. It has been done (or at least started) due to resolution of
I102. :)
>
> Section 4.1
>
> 4.1. Acct-NAS-Filter-Rule
>
> The first eight octets of this string are used for a 64-bit
> value of the rule counter. The remaining octets are used to
> specify which filter rule the counter value is for. The rule
> specification MUST conform to the syntax rules specified for
> NAS-Filter-Rule[TODO].
>
> [TODO] indicates an open action item.
>
> Requested changes:
>
> Provide the [TODO].
[ms] TODO should actually be TBD. We don't have a IANA value associated
with this attribute, yet. All TBD's will change to the IANA assigned
values as the right juncture.
Cheers,
MS
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>