RE: Proposed Resolution to Issue 198: Attribute Concatenation/Splitting

["Avi Lior" <avi@bridgewatersystems.com>]

Bernard and all,

This TAG thing is very complex. We can get rid of the '0' tag
requirement by saying that every NAS Filter Rule MUST have a unique
non-zero TAG value in the range of 0x01 to 0x3F.
If an NAS filter rule attribute needs to be fragmeneted (length is
greater then 252) then the fragments is placed in a subsequent
NAS-Filter-Rule attribute and the same TAG value is used. 

Anyway...here are some comments on the proposed text... See inline...

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> Sent: Friday, September 29, 2006 4:30 PM
> To: barney@databus.com
> Cc: radiusext@ops.ietf.org
> Subject: Re: Proposed Resolution to Issue 198: Attribute 
> Concatenation/Splitting
> 
> How about this?
> 
>    Tag
> 
>       The Tag field is used to identify the filter rule that is
>       represented; 

The tag field is not identifying the filter rule because filter rules
that are not fragmented will have a tag of '0'. My proposal above makes
the TAG identify the filter rule uniquely.


> the length of the Tag field is one octet 
> and it MUST
>       always be present.  The Tag field value MUST be in the range
>       0x01-0x3F; NAS-Filter-Rule attributes with a Tag field value of
>       0x00 are ignored upon receipt.
> 
>       Where a single filter rule is less than or equal to 252 
> octets in
>       length, it MUST be encoded with a tag value of '0' 
> (0x30) and MUST
>       NOT be split between multiple NAS-Filter-Rule 
> attributes.  Where a
>       single filter rule is split into multiple NAS-Filter-Rule
>       attributes, the attributes SHOULD be sent consecutively, without
>       intervening attributes with another Tag field value.  

I think you want to say:

"the attributes MUST be sent consecutively, without intervening
NAS-Filter-Rule attributes with a different Tag field value."

RADIUS already covers in order delivery.

Yes the above statement does allow for a RADIUS server to insert other
attributes between two NAS-Filter-Rules.  And yes receivers have to cope
with that. However that is allowed behavior of RADIUS and we must not
change that even with a SHOULD.

> On receipt,
>       attributes with a Tag value of '0' (0x30) MUST NOT be 
> concatenated
>       to form a single filter rule.
> 
>       Where a single filter rule exceeds 252 octets in 
> length, the rule
>       MUST be encoded across multiple NAS-Filter-Rule attributes, each
>       with the same Tag value which MUST NOT be '0' (0x30).  
> Tag values
>       MUST be unique for each filter rule present in a RADIUS packet
>       with the exception of a Tag value of '0' (0x30), which 
> may be used
>       in multiple attributes, each describing a single filter rule.
> 
> 
> >From: Barney Wolff <barney@databus.com>
> >To: Bernard Aboba <bernard_aboba@hotmail.com>
> >CC: radiusext@ops.ietf.org
> >Subject: Re: Proposed Resolution to Issue 198: Attribute 
> >Concatenation/Splitting
> >Date: Fri, 29 Sep 2006 14:57:30 -0400
> >
> >On Thu, Sep 28, 2006 at 11:27:23PM -0700, Bernard Aboba wrote:
> > >   Tag
> > >
> > >      The Tag field is one octet, and MUST always be 
> present.  It is
> > >      used to identify the filter rule that is 
> represented.  Where a
> > >      single filter rule exceeds 253 octets in length, the 
> rule MUST be
> > >      encoded across multiple NAS-Filter-Rule attributes, 
> each with the
> > >      same Tag value; Tag values MUST be unique for each 
> filter rule
> > >      present in a RADIUS packet with the exception of a 
> Tag value of
> > >      '0' (0x30).  The value of '0' (0x30) in the Tag 
> field indicates
> > >      that the attribute contains a filter rule that does 
> not exceed 253
> > >      octets in length; as a result attributes with a Tag 
> value of 0x30
> > >      MUST NOT be concatenated, and one or more 
> Filter-Rule attributes
> > >      with a tag value of 0x30 may be included in a single RADIUS
> > >      packet, each describing a single filter rule.
> >
> >May I suggest that NAS-Filter-Rule attributes with different 
> tag values 
> >MUST NOT appear between the segments into which a long rule is split?
> >There is no benefit to the sender to allowing anything else, and 
> >considerable nuisance to the receiver.
> >
> >Also, I suggest that a rule which is not split MUST have tag 
> value '0'.
> >Again, there is no value to the sender for anything else, 
> and this way 
> >the receiver can know whether a rule is going to be 
> extended.  Perhaps 
> >the language implying that a rule <252 octets MUST NOT be 
> split should 
> >be made more explicit, too.
> >
> >As an aside, it is a general misfeature of RADIUS that senders are 
> >allowed to do things, such as random ordering of attributes, 
> that have 
> >little value for the sender but cause hardship for the receiver.  We 
> >are all so used to this nuisance that we hardly perceive it as such.
> >
> >--
> >Barney Wolff         I never met a computer I didn't like.
> >
> >--
> >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/>
> 
> 
> 
> --
> 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/>
> 

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