[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Issue 37: Merging of Filter Attributes
Mauricio Sanchez writes...
> "Filter-ID and NAS-Filter-Rule both define how filters are to be
> in the NAS. They both should not appear in the same message and only
> of them should be processed. If Filter-ID is present, it should take
> precedence. Furthermore, multiple Filter-ID attributes may appear in
> same Radius message. It is unclear how implementations should
> 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
> 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 email@example.com with
the word 'unsubscribe' in a single line as the message text body.