RE: Inclusion of Filter-Id and NAS-Filter-Rule AVPs

["Nelson, David" <dnelson@enterasys.com>]

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.

I can certainly _wish_ it.  How practical that wish might be is another
issue, of course.

> There will be mixed deployments, and the definition of the 
> new feature should accommodate the existing systems as best 
> as possible.

I believe Diameter made a big mistake in allowing both Filter-ID and
Filter-Rule semantics in the same AVP without explicit rules of
precedence.  Can we go back and correct that "mistake"?  You are
suggesting that we can't, and further that we need to continue that
"mistake" into the RADIUS work.

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


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