[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Issue 113: Attribute Concatenation
At IETF-64, we discussed this issue and concluded that we would remove
QoS-Filter-Rule from the draft.
> -----Original Message-----
> From: firstname.lastname@example.org
> [mailto:email@example.com] On Behalf Of Congdon,
> Paul T (ProCurve)
> Sent: Tuesday, October 25, 2005 10:20 AM
> To: Glen Zorn (gwz)
> Cc: firstname.lastname@example.org; email@example.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
> > 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.
> to unsubscribe send a message to
> firstname.lastname@example.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 email@example.com with
the word 'unsubscribe' in a single line as the message text body.