re: Issue 37: Merging of Filter Attributes

["Sanchez, Mauricio (PNB Roseville)" <mauricio.sanchez@hp.com>]

Dave Nelson and other argue over...

> 
> > "Filter-ID and NAS-Filter-Rule both define how filters are to be
> applied
> > in the NAS. They both should not appear in the same message and only
> one
> > of them should be processed.  If Filter-ID is present, it
> should take
> > precedence. Furthermore, multiple Filter-ID attributes may appear in
> the
> > same Radius message.   It is unclear how implementations should
> process
> > 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
> appended
> > 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 have no qualms in removing the last sentence as long as we all agree
that this is indeed input that should be further discussed in the RADIUS
Issues and Fixes document.  We were hoping to bring some clarity to what
we saw as an issue, but if this document is not the right forum, then so
be it.

Therefore, the additional description to section 2.7 NAS-Filter Rule
would read:

"Filter-ID and NAS-Filter-Rule both define how filters are to be applied
in the NAS. They both should not appear in the same message and only one
of them should be processed.  If Filter-ID is present, it should take
precedence. Furthermore, multiple Filter-ID attributes may appear in the
same Radius message.   It is unclear how implementations should process
these multiple attributes. Some implementation may append them to one
another; others may select only a single attribute to process." 

MS

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