RE: Issue 113: Attribute Concatenation

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

> ...
> 
> >> 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.
> >> 
> > 
> > I probably should have been more clear about using the 
> words 'general 
> > sense'.  All we are talking about is the string in the 
> Qos-Filter-Rule 
> > that might be too large to fit in the current Radius version of the 
> > attribute.  I am under the assumption that handling this type of 
> > scenario is common practice in Radius/Diameter proxies and 
> that is has 
> > been documented in a previous RFC, but perhaps I'm
> > wrong on this.   
> 
> OK, I'm a bit confused here: is this Qos-Filter-Rule 
> generated by a RADIUS server, a Diameter peer or either?
>

It is generated by a RADIUS server and is a RADIUS attribute.  We are
simply leveraging the format and syntax of the rule string.
   
> > 
> > I still think the existing text explains the issue and 
> solution fairly
> > clearly:
> > 
> >          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 message size in [NASREQ] is
> >          greater than RADIUS' maximum allowable message size, it is
> >          assumed that QOS filters that exceed RADIUS' allowable
> >          message 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.
> 
> But this makes no sense to me at all.  Do you mean "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"?
> 

Yes.  We can use this text as a replacement if you agree with this.


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