RE: Issue 37: Merging of Filter Attributes

[Bernard Aboba <aboba@internaut.com>]

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

I think it might be fodder, yes.


> > In my experience, implementations merge the filters in the order they
> > are specified.  But perhaps there are implementations that do not do
> > this?
>
> 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.

Yes.  Perhaps we should solicit interpretations?

BTW, it is interesting to be finding these differences years *after* RFC
2865 was approved as a Draft standard.

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