[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

questions/comments on draft-black-radius-lanedge-00.txt

I've read

and have some questions and comments:

1) Do access devices (such as IP DSLAMs) come under LAN Edge switches? What
exactly does a LAN Edge device mean?

2) When do we use the Location-ID and Location-Name attributes. I guess they
are used in wireless networks.  Can't NAS-ID be used to identify the
Location? Can you explain little further.

3) The draft proposes a new Time attribute (along with Location-ID and
Location Name).  Why can't we use Event-TimeStamp define in RFC-2869 which
is also in UTC format? Is there a specific reason to have a new attribute
defined here again?

4) Section 2.3.4 PVID (port VLAN ID) proposes to replace the use of
Tunnel-Type=VLAN (13), Tunnel-Medium-
   Type=802, and Tunnel-Private-Group-ID=VLANID as described in RFC 3580.
I'm wondering how can a VSA which is by definition  an optional can replace
the use of some thing that was standardized before. I also feel that Tunnel
Type usage doesn't look nice to carry VLAN-IDs. But I suggest that we define
a standard  attribute to carry VLAN-ID which can replace Tunnel Type usage.

5) I'm trying to undertand the difference between PVID and Egress-VID.  You
mean, PVID is the default-VLAN-ID and Egree-VIDs are allowed list of
VLAN-IDs. Right?

6) Section 2.3.6- How do we map the user-priority-generation-table? How is a
byte (rather than a bit) is useful to re-map the priorities.

7) Section 2.3.7 - IP Filter Name: Do we really need a new attribute for
this? Can't we use the Filter-ID defined in the standard. I agree that it
doesn't explicitly mean what filter it is.

8) I guess Bandwidth attributes "passes muster". I don't think the
standardization of these attributes cause any problem to the implementors
nor does it compell the radius client / proxy implementations to support
these attributes.  In the "Table of attributes" section, we can specify if
the attribute may not be present at all.

Comments welcome.


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/>