Dave responds... > > "A NAS MAY apply additional rules (deny, redirect, etc.) of its own > > before, in between, or after rules specified with > NAS-Traffic-Rule. > > For example, these additional rules may protect the access device > > owner's infrastructure. > > Management of these additional rules is out of scope and are not > > subject to the semantics or behaviors described for > NAS-Traffic-Rule." > > 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 guidelines for rule ordering are only relevant for those > > controlled via this RADIUS specification. I see it as out > of scope on > > mandating how non-RADIUS rules should behave. > > Fair enough. I still wonder how useful this attribute will > be if the administrator that sets it up has no idea which (if > any) of the elements he has specified will be enforced by the > NAS, and which (potentially > all) of the elements are superseded by a local NAS filtering rule. > > 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. Yes, I agree. What is assumed is vital to the overall predictibility of a solution. Fortuntately, I think in most instances it's safe to assume that the NAS doesn't have any locally configured NAS rules that will adversely interfere with those being provisioned by RADIUS. Maybe we're just going down a rat hole here. By even mentioning that there may be other rules in effect on the NAS, it feels like an opportunity for creating greater confusion. I'd rather just stick to detailing how a particular facet of the overall network service is provisioned, rather then define what the overall network service consists of. Would we better served by just yanking out the statement in question? Thoughts? MS
Attachment:
smime.p7s
Description: S/MIME cryptographic signature