Wow. In other words, the entity that creates a NAS-Traffic-Rule attribute really has no idea what the aggregate traffic filtering behavior of a given NAS will be. So what makes this new attribute useful?
The Filter-Id attribute refers to a particular set of filters provisioned on the NAS. This document says that NAS-Traffic-Rule is not to be sent along with Filter-Id. Yet somehow a filter set described by Filter-Id can be activated without any explicitly indications from the RADIUS server? This seems to be contradictory.
I can see this mechanism working in a predictable fashion only in certain situations, based on assumptions of the locally configured NAS rules that take precedence.
As I understood it, the whole point of this attribute was to enable the RADIUS server to explicitly specify the filters that would be in operation, even in situations where the server had no knowledge of what filters are provisioned on the NAS. So this new approach does not make sense to me.
-- 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/>