[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue 113: Attribute Concatenation

Hi,

On Tue, Sep 27, 2005 at 08:27:56AM -0700, Congdon, Paul T (ProCurve) wrote:

> 
> 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]. 
>        
>         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.
>   
>         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. RADIUS proxies MUST NOT reorder QoS-Filter-Rule 
>         attributes. 

I think the relevant section of RFC 2865 is Section 5, and it states:

   If multiple Attributes with the same Type are present, the order of
   Attributes with the same Type MUST be preserved by any proxies.  The
   order of Attributes of different Types is not required to be
   preserved.  A RADIUS server or client MUST NOT have any dependencies
   on the order of attributes of different types.  A RADIUS server or
   client MUST NOT require attributes of the same type to be contiguous.

So I see two issues. 1: the conflict between the "consecutive
attributes" requirement and the last sentence of the text quoted above,
and 2. it would probably be clearer if the reference pointed to Section
5 (Attributes) instead of section 2.3 (Proxy behaviour).

Cheers,


Emile.

-- 
E-Advies - Emile van Bergen           emile@e-advies.nl      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

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