RE: Issue 37: Merging of Filter Attributes

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

Mauricio Sanchez writes...

> "Filter-ID and NAS-Filter-Rule both define how filters are to be
applied
> in the NAS. They both should not appear in the same message and only
one
> of them should be processed.  If Filter-ID is present, it should take
> precedence. Furthermore, multiple Filter-ID attributes may appear in
the
> same Radius message.   It is unclear how implementations should
process
> these multiple attributes. Some implementation may append them to one
> another; others may select only a single attribute to process.  This
> document recommends that all recognized Filter-ID attributes be
appended
> to one another in the order they appear in the message."

I would recommend omitting the last sentence.  This tends to have the
effect of updating RFC2865 and adding new normative requirements.

I would further recommend that the multi-vendor interoperability
questions that arise out of the way multiple instances of the Filter-ID
attribute are specified (or not specified) in RFC2865 be discussed in
the context of the RADIUS Issues and Fixes Draft.  Is there an issue?
We seem to think so, in terms of how Filter-ID specified behavior can or
cannot be "merged" with NAS-Filter-Rule specified behavior.  Does this
issue exist in "merging" two or more instances of Filter-ID?


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