Issue 61: Multiple Filter-ID Attributes

[Bernard Aboba <aboba@internaut.com>]

Issue 61: Multiple Filter-ID Attributes
Submitter name: David Nelson
Submitter email address: dnelson@enterasys.com
Date first submitted: January 25, 2005
Reference: http://ops.ietf.org/lists/radiusext/2005/msg00077.html
Document: Issues and Fixes
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

Does this issue exist in "merging" two or more instances of Filter-ID?

[Bernard Aboba]

RFC 2865 doesn't have much to say on this subject, other than that zero
or more instances of Filter-Id can be included in an Access-Accept.  In
my experience, implementations merge the filters in the order they are
specified.  But perhaps there are implementations that do not do this?

[David Nelson]

That is why this subject might be fodder for the Issues and Fixes
document.  To clarify, or at least highlight, an inadequate
specification in RFC 2865 of what to do with multiple instances of
Filter-ID.

We have implementations that treat multiple instances as Filter-ID as
alternative filters, rather than cumulative filters.  The first
Filter-ID attribute having a name matching a locally defined filter is
used.  The remaining ones are ignored.

In the absence of guidance to the contrary, this is a permissible
interpretation, and I presume there might be others.

[Glen Zorn]

I don't actually think that this is a discovery.  As I recall, at
least two interpretations were discussed in the RADIUS WG, David's
among them and the interpretation of multiple Filter-Id Attributes
was purposely left undefined.

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