RE: review of draft-ietf-radext-ieee802-01.txt

["Congdon, Paul T (ProCurve)" <paul.congdon@hp.com>]

No, it was not you that argued for the new attributed.  Here is what I
remember of the meeting at IETF-64...

The changes we have made are not simply extensions and the attribute we
are defining is not purely a superset.  There is no RADIUS attribute for
this functionality and it has proven very difficult to take Diameter
AVPs and try to move them back into RADIUS (as was seen with
QoS-Filter-Rule) because of issues with data types, field lengths and
other subtle problems.  Also, I remember someone (maybe Glenn?) saying
that there were problems with the current definition of IP-Filter rule
that NAS-Filter-Rule in Diameter is based upon.  Finally, since Diameter
can much more easily support a Radius attribute than the other way
around, we agreed that we should create a new Radius attribute.

I agree with you that we do not want to make this the default behavior
and we should strive to make consistent extensions.  I think the
complexity of this attribute didn't allow us to follow that path.

Paul

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net] 
> Sent: Friday, January 27, 2006 8:57 AM
> To: Sanchez, Mauricio (PNB Roseville)
> Cc: Congdon, Paul T (ProCurve); radiusext@ops.ietf.org
> Subject: Re: review of draft-ietf-radext-ieee802-01.txt
> 
> 
> >Yes, this one fell through the cracks.  Are there any suggestions in 
> >terms of names?  How about something like  NAS-Traffic-Rule 
> or perhaps 
> >to reduce confusion possibility drop the 'NAS-' prefix and 
> just call it 
> >'Traffic-Rule'?
> >  
> >
> Before we start inventing new names, do you guys remember why 
> we decided in IETF-64 that the second approach, a different 
> attribute, was the right one? I'm hoping it was not me who 
> argued for that, but can't remember the discussion at all...
> 
> The reason I dislike new attributes because if we do it on 
> every extension, we'll end up with a messy attribute set. 
> From a RADIUS point of view this is a new attribute now, but 
> not from Diameter. What happens when you do the next filter 
> extension -- which IMHO seems likely? Yet another attribute? 
> I hope not.
> 
> --Jari
> 
> 

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