[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Comments on the draft-ietf-radext-filter-04 or.. -05



 

> -----Original Message-----
> From: Congdon, Paul T (ProCurve) [mailto:paul.congdon@hp.com] 
> Sent: 7. marraskuuta 2006 0:51
> To: Bernard Aboba; Korhonen, Jouni /TeliaSonera Finland Oyj; 
> radiusext@ops.ietf.org
> Subject: RE: Comments on the draft-ietf-radext-filter-04 or.. -05
> 
> 
> We are covering old ground here again...  The restriction 
> should remain to ensure interoperability and predictable operation. 

Right... just one more question to my clarification. What does a D->R
translator box do based on this draft? Drop the NAS-Filter-Rule if
Filter-ID also exists? What happens in D->R->D case (not that it is a
realistic case but could happen)?

/Jouni

> 
> > -----Original Message-----
> > From: owner-radiusext@ops.ietf.org
> > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> > Sent: Monday, November 06, 2006 12:39 PM
> > To: jouni.korhonen@teliasonera.com; radiusext@ops.ietf.org
> > Subject: RE: Comments on the draft-ietf-radext-filter-04 or.. -05
> > 
> > >Just a small note/question regarding the text stating 
> Filter-ID and 
> > >NAS-Filter-Rule must not appear in the same message. I don't
> > see this
> > >kind of "must" restriction on Diameter side (RFC4005) so 
> why should 
> > >RADIUS have it?
> > 
> > Right.  Diameter allows both Filter-ID and NAS-Filter-Rule AVPs, so 
> > adding a usage restriction within RADIUS might result in a 
> Diameter -> 
> > RADIUS translation issue.
> > 
> > >So e.g. in section 2 would
> > >"..attributes, and SHOULD NOT appear in the same RADIUS
> > packet." be better?
> > 
> > There might be a case where Filter-Id and NAS-Filter-Rule might be 
> > included in the same packet, but then the document would need to 
> > explain what happens when that occurs.
> > 
> > I don't think there would ever be a reason to include both 
> > NAS-Traffic-Rule and NAS-Filter-Rule in the same packet.
> > 
> > >Also it is not entirely clear to me why e.g. Filter-Id and 
> > >NAS-Filter-Rule must be mutually exclusive?
> > 
> > The question was what the resulting filter rule set would be. 
> >  Is the result consistent or unpredictable?  If it is 
> predictable, how 
> > does it work?
> > 
> > >This was questioned by some organizations that intend to use 
> > >NAS-Filter-Rule. I guess defining rule applying order 
> would also be 
> > >alternative..?
> > 
> > Do you have an opinion on how this should be handled?
> > 
> > For example, you could say that Filter-ID would be applied 
> first, then 
> > NAS-Filter-Rule.
> > 
> > 
> > 
> > --
> > 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/>