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

["Nelson, David" <dnelson@enterasys.com>]

Comments on this thread ---

On NAS-Identifier vs. Location-ID:

If the proposed Location-ID is defined to contain X.500 format location
information, and the syntax is standardized and interoperable, it makes
sense to add this as a separate attribute and leave NAS-Identifier alone
(as it is typically the FQDN of the NAS).

On the new time attribute vs. Event-Timestamp:

Allowing an existing attribute, Event-Timestamp, to be included in other
packet types is preferable to creating a new attribute.

On Port-VLAN-ID vs. Tunnel-Private-Group-ID:

I have a mixed opinion on this one.  over-loading existing attributes
for new uses is less than desirable.  However, if the new use is
relatively compatible with the original use, and the exact usage is
absolutely clear from context (as it is in this case), I think that the
"protocol neatness" obtained from having a separate and distinct
Port-VLAN-ID, in preference to the Tunnel-Private-Group-ID is somewhat
marginal.  I could probably support either way, although we should be
clear on the status of the RFC 3580 usage -- are we going to deprecate
it?  Will we support the use of both attributes?  It should be made
clear what is the correct behavior if both attributes are contained in a
single Access-Accept and do not contain exactly the same value. 

On IP-Filter-Name vs. Filter-ID:

I think that the new attribute is redundant and Filter-ID works just
fine for this purpose.  If one was to suggest (and I'm not doing so)
that it was desirable to have separately specified L2 and L3 filters
working "in series connection", this might make sense, but I don't think
that was the initial intent.

On the Bandwidth attributes:

If these are part of the over-all QoS solution, then I favor an
attribute or attributes that specify an authorized class of QoS for the
user, and favor leaving the provisioning of specific parameters and
rules to implement the various QoS classes to a more appropriate
protocol.  I don't think that detailed QoS parameter provisioning falls
into the scope of AAA protocols.

On etymology:

As to the colloquial phrase "passes muster", it evolves from military
terminology, in which early militias would "muster" and be inspected by
the command staff for battle readiness and other military fitness
requirements.

What I meant in using this phrase is that the proposed attributes obtain
broad Internet Community consensus and demonstrate multi-vendor
interoperability.

-- Dave



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