[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Issue 113: Attribute Concatenation
> >
> > 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).
>
Yes, what is important is that the order is maintained, not that the
attributes are consecutive. Since this sentence is in direct conflict
with 2865, we need to remove it. Also I agree that Section 5 appears to
be the better reference. The last paragraph should read:
As per the requirements of RFC 2865, Section 5, if multiple
QoS-Filter-Rule attributes are contained within an Access-
Request or Access-Accept packet, they MUST be maintained in
order. RADIUS proxies MUST NOT reorder QoS-Filter-Rule
attributes.
I'm still working on a response to the rest of Glen's comments...
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/>