RE: Filter Separation using a NUL?

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Emile van Bergen <mailto:openradius-radextwg@e-advies.nl> supposedly
scribbled on Thursday, October 19, 2006 7:15 AM:

> Hi,
> 
> On Thu, Oct 19, 2006 at 01:52:39AM -0700, Glen Zorn (gwz) wrote:
> 
>> OK, I'm having a little trouble understanding the point of this & the
>> reasoning behind it.  I thought that the problem we were trying to
>> solve was the transmission of a filter set, consisting of one or more
>> rules, which is potentially larger than the data size of a RADIUS
>> attribute. Further, the document leads me to believe that it is
>> expected that 
>> this set will be used as such, giving explicit instructions for its
>> reconstruction on the client ("Where multiple NAS-Filter-Rule
>> attributes are included in a RADIUS packet, the String field of the
>> attributes are to be concatenated to form a set of filter rules.");
>> presumably, the client will need to parse these rules in order to
>> install them, since the syntax used is that of BSD (not the most
>> popular NAS OS on the planet, AFAIK).  So what is the point of taking
>> apart this nice set, parsing it into individual rules, then
>> reconcatenating the
>> (NUL-terminated) rules into a set again for transmission?  I suspect
>> that I'm just confused, but maybe somebody can help me out.
> 
> As far as I've understood the case so far, there is an encoding
> defined for individual rules, but no encoding for a complete rule
> set.  

"Where multiple NAS-Filter-Rule attributes are included in a RADIUS
packet, the String field of the
attributes are to be concatenated to form a set of filter rules."  This
appears to me to state that a filter rule set is exactly the result of
in-order concatenation of the individual rules.

> 
> The knowledge of where each rule begins and ends therefore needs to
> be transported out of band, along with the rule set string. 

OK, one more time: if the goal is to end up w/the concatenation of the
rules into a rule set, why is it necessary to know where the individual
rules begin or end (except, of course, for the first and last rules in
the set)?

> 
> DIAMETER uses separate attribute instances for that purpose; what's
> just been proposed is that RADIUS uses NUL characters instead. Thus,
> we first define a single long rule set string, and then say that it
> is to be transported in a 0-1 "single long" attribute (which is
> formed by concatenating all instances of a string attribute in their
> order of appearance in the packet).   

See above.  Maybe the text I'm quoting is in error?
  
> 
> Cheers,
> 
> 
> Emile.

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