RE: Issue 37: Merging of Filter Attributes

[Avi Lior <avi@bridgewatersystems.com>]

I belive yes it would be an interoperability issue.

> -----Original Message-----
> From: Congdon, Paul T (ProCurve) [mailto:paul.congdon@hp.com] 
> Sent: Tuesday, December 14, 2004 6:20 PM
> To: Bernard Aboba
> Cc: radiusext@ops.ietf.org
> Subject: RE: Issue 37: Merging of Filter Attributes
> 
> 
> 
> Would there be an interoperability issue if it was specified 
> that they can't re-order these, even though they are 
> different types?  Sounds like RFC 2865 only puts the re-order 
> restriction on attributes of the same type.
> 
> Paul
> 
> > -----Original Message-----
> > From: Bernard Aboba [mailto:aboba@internaut.com]
> > Sent: Tuesday, December 14, 2004 3:16 PM
> > To: Congdon, Paul T (ProCurve)
> > Cc: radiusext@ops.ietf.org
> > Subject: RE: Issue 37: Merging of Filter Attributes
> > 
> > I think the issue here is that RADIUS proxies could re-order
> > Filter-Id and NAS-Filter-Rule attributes relative to each other.
> > 
> > On Tue, 14 Dec 2004, Congdon, Paul T (ProCurve) wrote:
> > 
> > >
> > > I agree that if both of these attributes appear in the 
> packet, they
> > > should append one another.  Given that order is important 
> > (as seen in
> > > Issue 38), why wouldn't we want to indicate that a
> > NAS-Filter-Rule can
> > > also pre-pend the Filter-ID if it appears before the 
> Filter-ID?  It
> > > seems kind of limiting to only allow NAS-Filter-Rule to 
> follow the 
> > > Filter-ID.
> > >
> > > Consider the following text...
> > >
> > > "If both Filter-ID and NAS-Filter-Rule attributes are
> > included within
> > > an Access-Request or Access-Accept packet, the filters are
> > appended to
> > > one another.  If the filter specified by the
> > NAS-Filter-Rule attribute
> > > appears after the filter list specified by the Filter-ID 
> attribute,
> > > the filter is considered to be appended to the end of the 
> > filter list.
> > > If the filter specified by the NAS-Filter-Rule attribute appears
> > > before the filter list specified by the Filter-ID attribute, the 
> > > filter is pre-pended to the filter list.
> > >
> > > As a result, if either of the filters specify that a packet
> > is to be
> > > discarded, then the filter(s) specified by the other attribute can
> > > have no effect on the processing of that packet."
> > >
> > > Paul
> > 
> 
> --
> 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/>
> 

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