RE: Issue 113: Attribute Concatenation

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Congdon, Paul T (ProCurve) <mailto:paul.congdon@hp.com> supposedly scribbled:

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

> 
>         The RADIUS server can return multiple QoS-Filter-Rule
>         attributes in an Access-Accept or CoA-Request packet. Where
>         more than one QoS-Filter-Rule Rule attribute is included, it
>         is assumed that the attributes are to be concatenated to form
>         a single QOS filter.
> 
>         Whereas the maximum allowable AVP size in [NASREQ] is greater
>         than RADIUS' maximum allowable attribute size, it is assumed
>         that QOS filters that exceed RADIUS' allowable attribute size
>         will be broken into multiple QoS-Filter-Rule attributes by
>         the RADIUS server and concatenated back into a single QOS
>         filter by the NAS.

I still am puzzled by the reference to Diameter.  As I mentioned earlier, it is not possible to fit a maximum sized QOS-Filter-Rule AVP into a single RADIUS message, never mind a set of RADIUS attributes.  So why even talk about it?  I also think that it would be a very good idea to specify a maximum length for QOS filter rules themselves.  Also, if a filter is made up of filter rules, it makes sense that rules can be concatenated to form a filter; however, the paragraph above offers no guidance the case where a rule doesn't fit into a QoS-Filter-Rule attribute.

> 
>         As per the requirements of RFC 2865, Section 2.3, if multiple
>         QoS-Filter-Rule attributes are contained within an Access-
>         Request or Access-Accept packet, they MUST be maintained in
>         order. 
>         The attributes MUST be consecutive attributes in the
>         packet. 

Why?

>         RADIUS proxies MUST NOT reorder QoS-Filter-Rule
>         attributes.

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

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