Dave Mitton writes... > I've changed my view of this issue of being that of forwards > compatibility. > > You are adding a new feature, and there is existing deployment > of the old feature. You cannot just wish them to disappear. > > There will be mixed deployments, and the definition of the > new feature should accommodate the existing systems as best > as possible. > > Perhaps leaving it to the vendor is insufficient. But the > situation cannot be outlawed. Well, if anyone truly cares about multi-vendor interoperability, something needs to be done. IMHO, the current Diameter spec is badly flawed in this regard. In the absence of a set of well-defined precedence rules, users can't reasonably expect to see consistent application of access control policy, in multi-vendor NAS deployments, when using a combination of Filter-ID and Filter-Rule semantics.
Perhaps the best solution is simply to say this in the document. For example:
"The NAS-Filter-Rule attribute is not intended to be used concurrently with any other filter rule attribute, including Filter-Id (11) and NAS-Traffic-Rule [Traffic] attributes. NAS-Filter-Rule and NAS-Traffic-Rule attributes MUST NOT appear in the same RADIUS packet. If a NAS-Traffic-Rule attribute is present, a NAS implementing this specification MUST silently discard NAS-Filter-Rule attributes, if present. Filter-Id and NAS-Filter-Rule attributes SHOULD NOT appear in the same RADIUS packet. Given the absence in [RFC4005] of well-defined precedence rules for combining Filter-Id and NAS-Filter-Rule attributes into a single rule set, the behavior of NASes receiving both attributes is undefined, and therefore a RADIUS server implementation cannot assume a consistent behavior."
-- 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/>