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

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

Forwarding to the RADEXT list, at Dave Mitton's suggestion...

> Dave Mitton writes...
>
> > Sigh... this is another problem where some sort of NAS
> > version number or capabilities field would be useful.
> > I guess the best compromise would be to continue to allow
> > them to be sent together.
>
> > An older system would ignore the new rule and use the 
> > Filter-ID.
> > A newer system would use the new rules (if present) and 
> > either ignore the Filter-ID or have it defined as a 
> > Non-operation.  The provisioning of the rules behind a
> > Filter-ID are still not defined.
>
> This begs the question of multi-vendor interoperability. 
> If the interpretation and precedence rules for the "both" 
> scenario are left to the implementer, then any user who 
> wishes to take advantage of the "both" feature better 
> sole-source his NASes.  This is contrary to the spirit of
> Standards Track RFCs, IMHO.

(Dave Mitton, responding)

We should have this conversation on list.

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.


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