[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Issue 113: Attribute Concatenation
Congdon, Paul T (ProCurve) <mailto:firstname.lastname@example.org> 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.
> 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
> The attributes MUST be consecutive attributes in the
> RADIUS proxies MUST NOT reorder QoS-Filter-Rule
Hope this helps,
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 email@example.com with
the word 'unsubscribe' in a single line as the message text body.