RE: Issue 113: Attribute Concatenation

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

At IETF-64, we discussed this issue and concluded that we would remove
QoS-Filter-Rule from the draft. 

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Congdon, 
> Paul T (ProCurve)
> Sent: Tuesday, October 25, 2005 10:20 AM
> To: Glen Zorn (gwz)
> Cc: radiusext@ops.ietf.org; gdweber@cisco.com
> Subject: RE: Issue 113: Attribute Concatenation
> 
> 
> 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/>
> 

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