Subject: Re: Issue: Data Type Advice

From: Alan DeKok <[email-masked]>
Date: Sun, 04 Jan 2009 19:50:52 +0100

Bernard Aboba wrote:
> Section A.1.1 reads:
> 
>    Does the data fit within the existing RADIUS data model, as outlined
>    below?  If so, it SHOULD be encapsulated in a [RFC2865 <http://tools.ietf.org/html/rfc2865>] format RADIUS
>    attribute, or in a [RFC2865 <http://tools.ietf.org/html/rfc2865>] format RADIUS VSA.
> 
> As noted in an earlier issue, Appendix B does not cover data types
> utilized within RADIUS VSAs,
> only the data types in standard RADIUS attributes.

  When the VSAs use standard data types, they are compatible with the
RADIUS data model.  This practice should be encouraged.

>   Therefore the
> "existing RADIUS data model
> as outlined below" is really just the data model for standard RADIUS
> attributes.

  And a RECOMMENDED one for VSAs.  Non-standard data types can be
problematic.

>   On that basis
> the sentence might better read:
> 
>    Does the data fit within the RADIUS standard attribute data model, as outlined
>    below?  If so, it MAY be encapsulated either in a [RFC2865 <http://tools.ietf.org/html/rfc2865>] format RADIUS
>    attribute, or in a [RFC2865 <http://tools.ietf.org/html/rfc2865>] format RADIUS VSA.

  I'm not sure that change is necessary.  The data model applies to
VSA's, too.  Looking at the dictionaries I have access to, I see:

  * ~4K VSA definitions
  * 3 vendors with non-standard data types
  * 7 non-standard data types of
     * abinary
     * byte
     * short
     * polymorphic ipv4/ipv6 address
     * signed
     * tlv  (e.g. 3GPP2 && WiMAX)

  The "abinary" is the old Ascend binary filter attribute.  Everything
else is used by the WiMAX standards, though other vendors use some of
the types, too.

  This last survey isn't *quite* accurate, as a number of non-standard
types are treated as "string" in the dictionaries.

> Assuming that the promised survey of ad-hoc data model extensions is
> actually included in the
> document, then this could be referenced to in a subsequent sentence:

  I would prefer to not survey the ad-hoc extensions to the data model.
 There may be a fair number, and I would conjecture that most offer

  I think we should recommend that VSAs use the existing data types.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 4 Jan 2009 11:24:02 -0800

Alan DeKok said:

"The data model applies to VSA's, too.  Looking at the dictionaries I have
access to, I see:

  * ~4K VSA definitions

  This last survey isn't *quite* accurate, as a number of non-standard
types are treated as "string" in the dictionaries."

  I would prefer to not survey the ad-hoc extensions to the data model.
 There may be a fair number. "

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

---

From: Alan DeKok <[email-masked]>
Date: Sun, 04 Jan 2009 22:08:21 +0100

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

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 4 Jan 2009 18:04:46 -0800

> data type for the "data" portion of an attribute, other than

That might be worth adding (maybe in the Extended Attributes section?)

---

From: Alan DeKok <[email-masked]>
Date: Mon, 05 Jan 2009 11:41:40 +0100

> That might be worth adding (maybe in the Extended Attributes section?)

  I'll add some text in the "what not do to" section (A.2.1).

  I think calling these "nested AVP's" may make the most sense.

  When I have some more edits done, I'll post a URL to the documents
with suggested text.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 08 Jan 2009 11:45:11 +0100

Bernard Aboba wrote:
>> Much of this is already in the document. What can we do to clarify
>> the text to avoid repeated questions?
> 
> I'd suggest that a revision of Section 1.1 is needed to clarify this. 
> Right now,
> this section seems to suggest that SDO specifications utilizing existing
> RADIUS standard data types can avail themselves of IETF review.  Also,
> as David notes, the document can be read as suggesting IETF review
> of all SDO RADIUS attribute documents. 

  I've updated the document, and put suggested text on
http://ietf.freeradius.org.

>> The most I would do is to provide horrific examples of what *not* to
>> do. i.e. putting arbitrary text strings into the "data" portion of a
>> VSA (no... no VSA-type/VSA-length/VSA-data... just Vendor-Id/text..)
> 
> Describing why this is a bad idea would probably be useful.

  I will add that to my "to do" list, and then update the web site with
suggested text.

  Alan DeKok.