Re: Issue: Data Type Advice

[Alan DeKok <aland@deployingradius.com>]

Bernard Aboba wrote:
> [BA] I would agree that a comprehensive survey is not needed.  However,
> it would seem useful to go over the above types and advise how they
> can be dealt with.   For example, "byte" and "short" could be 
> replaced by the Integer type; tlvs can be accommodated in Extended 
> Attributes;  ipv4 & ipv6 types should be dealt with separately, etc. 

  The document already discusses signed, byte, short, and polymorphic types:

A.2.1
...
      * Signed integers of any size.
        SHOULD NOT be used.  SHOULD be replaced with one or more
        unsigned integer attributes.  The definition of the attribute
        can contain information that would otherwise go into the sign
        value of the integer.
      * 8 bit unsigned integers.
        SHOULD be replaced with 32-bit unsigned integer.  There is
        insufficient justification to save three bytes.
      * 16 bit unsigned integers.
        SHOULD be replaced with 32-bit unsigned integer.  There is
        insufficient justification to save two bytes.
...
      * Polymorphic attributes.
        Multiple attributes, each with a static data type SHOULD be
        defined instead.


  The "abinary" type is covered in A.2.2.:

A.2.2. Complex Data Types

   Does the attribute define a complex data type for purposes other than
   authentication or security?  If so, this data type SHOULD be replaced
   with simpler types, as discussed above in Section A.2.1.  Also see
   Section 2.1.3 for a discussion of why complex types are problematic.


  The document doesn't specifically discuss sub-TLV's (i.e. TLV's as a
data type for the "data" portion of an attribute, other than
Vendor-Specific)

  Alan DeKok.

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