RE: Issue 37: Merging of Filter Attributes

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Nelson, David <> supposedly scribbled:

> Bernard Aboba writes...
> 
>> 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.
> 
> 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 that inadequacy is in the eye of the beholder: as with
"terrorists" and "freedom-fighters", one man's inadequacy is
another's flexibility...

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

Seems perfectly reasonable to me, and much simpler than the merging
approach.  For example, suppose that 2 Filter-ID attributes identify
actual filters which are self-contradictory?  This might not be a
matter of misconfiguration, just of a Filter-ID having different
meanings on different devices (switch vs. AP, for example.

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

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
  listening to John Coltrane? -- Henry Gabriel

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