RE: Issue 113: Attribute Concatenation

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

I'd like to revive this thread a bit.  I never finished the response to
Glenn about QoS-Filter-Rule for Radius...

As a warm-up, remember, what we are trying to do is simply import the
QoS-Filter-Rule AVP from Diameter into Radius.  We felt since it was
defined for Diameter (and presumable implemented), that we could easily
define it for Radius by addressing the differences and missing
funcationality.

> 
> > Taking Glen's suggested text, I'd like to close this issue out with 
> > the following proposed text for the Text field in section 3.6.
> > Please let me know if this will work.  
> > 
> > 
> >      Text
> > 
> >         The Text field contains a QoS filter, utilizing the syntax
> >         defined for the QoSFilterRule derived data type defined in
> >         [RFC3588], Section 4.3.  Note that this definition contained
> >         an error, so that the complete syntax is described in the
> >         definition of the QoS-Filter-Rule AVP, defined in [NASREQ].
> 
> Are you _sure_ that you want to use this syntax?  It's 
> awfully verbose.  Even if you really do want to use it, I 
> would suggest that you reproduce it (or rather, adapt it to 
> use w/RADIUS) in this document, rather than incorporating it 
> by reference.  There are several problems with the Diameter 
> definitions, not least of which is that the definition of the 
> QoS-Filter-Rule AVP depends upon the definition of 
> IPFilterRule which is derived from OctetString which doesn't 
> exist in RADIUS.
> 

Seems like we have a couple of options here:

1. completely define the attribute syntax, as we have done for
NAS-Filter-Rule.  Perhaps leveraging much of the same definition, but
providing new actions that match QoS-Filter-Rule actions.  The actions
are mark and meter.  The mark action could also take-on L2 functionality
such as setting 802.1p bits in addition to setting DSCP.

2. provide text that defines the missing pieces from IPFilterRule, such
as OctetString.

3. Drop the attribute all together.  I don't believe any other SDOs are
depending upon this attributre.  I'm sure the TNC is not currently using
it.  Also, there have been a number of concerns with QoS functionality
in general (as seen in the simple bandwidth draft).  However, Diamater
successfully has defined this AVP.

Option 1 would be most consistent with the rest of the document.  Option
3 is the easy way out.  I'm not sure exactly what would be needed for
option 2.

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