[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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