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