[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
questions/comments on draft-black-radius-lanedge-00.txt
I've read
http://www.drizzle.com/~aboba/IEEE/draft-black-radius-lanedge-00.txt
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.
Regards
Nagi.
--
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/>