[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on the draft-ietf-radext-filter-04 or.. -05
Just a small note/question regarding the text stating Filter-ID and
NAS-Filter-Rule must not appear in the same message. I don't see
this kind of "must" restriction on Diameter side (RFC4005) so why
should RADIUS have it?
Right. Diameter allows both Filter-ID and NAS-Filter-Rule AVPs, so adding a
usage restriction within RADIUS might result in a Diameter -> RADIUS
translation issue.
So e.g. in section 2 would
"..attributes, and SHOULD NOT appear in the same RADIUS packet." be better?
There might be a case where Filter-Id and NAS-Filter-Rule might be included
in the same packet, but then the document would need to explain what happens
when that occurs.
I don't think there would ever be a reason to include both NAS-Traffic-Rule
and NAS-Filter-Rule in the same packet.
Also it is not entirely clear to me why e.g. Filter-Id and NAS-Filter-Rule
must be mutually exclusive?
The question was what the resulting filter rule set would be. Is the result
consistent or unpredictable? If it is predictable, how does it work?
This was questioned by some organizations that intend to use
NAS-Filter-Rule. I guess
defining rule applying order would also be alternative..?
Do you have an opinion on how this should be handled?
For example, you could say that Filter-ID would be applied first, then
NAS-Filter-Rule.
--
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/>