[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Issue 37: Merging of Filter Attributes
Nelson, David <> supposedly scribbled:
> Bernard Aboba writes...
>> RFC 2865 doesn't have much to say on this subject, other than
>> zero or more instances of Filter-Id can be included in an
> 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
I think that inadequacy is in the eye of the beholder: as with
"terrorists" and "freedom-fighters", one man's inadequacy is
>> In my experience, implementations merge the filters in the order
>> are specified. But perhaps there are implementations that do not
> We have implementations that treat multiple instances as Filter-ID
> alternative filters, rather than cumulative filters. The first
> Filter-ID attribute having a name matching a locally defined
> 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,
Why is it that most of the world's problems can't be solved by
listening to John Coltrane? -- Henry Gabriel
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.