FW: Issue 113: Attribute Concatenation

["Congdon, Paul T (ProCurve)" <paul.congdon@hp.com>]

Responding to Greg's issue 113...

>I didn't understand how the language in section 3.6 about concatenating

>QoS-Filter-Rule(s) works.  If these are simply concatenated, how does 
>an implementation distinguish between multiple 'small' QoS-Filter-Rules

>and a single larger attribute?  What if I want to send one 
>QoS-Filter-Rule which spans 253, followed by one which does not?

Actually I believe the editorial note needs to be removed since there is
text just after the note that explains the problem.  As you know,
Diameter attributes may be larger than what will fit in the Radius
attribute so we need to support fragmentation and reassembly in the
general sense.

The assumption with concatenation is that you are building a 'list' of
QoS-Filter-Rules, just like you are building a 'list' of
NAS-Filter-Rules.  So, as the text states, if there are multiple
QoS-Filter-Rules, you simply concatenate them together (whether they are
multiple little rules or one large split rule) and treat them as a
'list'

The proposed resolution to this comment is to remove the editorial note.
If this is not acceptable, please propose some new text in this section
which helps clarify things for you - provided I've made that clear.

Thanks,

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