Either Bernard or Dave attest..
>Issue 39: Backward Compatibility of Filter Attributes
>Submitter name: Bernard Aboba
>Submitter email address: mailto:dnelson@enterasys.com
>I am not sure that use of a "M" andatory bit is the right way to
vgo 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.
Paul and I have come to agree that the 'M' bit does not work very well in this instance. I propose striking all references to the 'M' bit from the document and defer to the outcome of the capabilities attribute discussion.
Cheers,
MS
--------------------------------------------
Mauricio Sanchez, CISSP
Network Security Architect
Procurve Networking Business
Hewlett Packard
8000 Foothills Boulevard, ms 5555
Roseville CA, 95747-5557
916.785.1910 Tel
916.785.1815 Fax
mauricio.sanchez@hp.com
--------------------------------------------