RE: Issue 113: Attribute Concatenation

[gwz@cisco.com]

Congdon, Paul T (ProCurve) <> supposedly scribbled:

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

Actually, Diameter AVPs can be larger than a RADIUS _message_.  If you really want to support fragmentation and reassembly in the general sense, then you need to deal with that, too.
  
> 
> 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

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