Issue 39: Backward Compatibility of Filter Attributes

[Bernard Aboba <aboba@internaut.com>]

Issue 39: Backward Compatibility of Filter Attributes
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: December 13, 2004
Reference:
Document: Congdon-02
Comment type: T
Priority: S
Section: 1.3
Rationale/Explanation of issue:
I am not sure that use of a "M" andatory bit is the right way to
go for this document. This requires substantial changes
to RADIUS and will make it more difficult to deploy the IEEE 802
Extensions.

In the CUI document, it has been suggested that an empty CUI
attribute be used for the NAS to advertise CUI support within
the Access-Request.

This approach does not seem to work for this document, which
includes multiple attributes that might be considered mandatory,
such as security-related attributes such (e.g. NAS-Filter-Rule).

A simpler way to handle backward compatibility would be to define a
"Capabilities" attribute that would contain the Type values
for all new attributes that the NAS supports. Since one
Capabilities attribute can be 253 octets in size, up to 253
attributes could be advertised by the NAS in a single attribute.
That RADIUS server would then only include a NAS-Filter-Rule attribute
in an Access-Accept if support was advertised in the Capabilities
attribute.


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