Subject: Re: Jari's DISCUSS on draft-ietf-radext-design-07.txt

From: Alan DeKok <[email-masked]>
Date: Tue, 06 Oct 2009 16:27:23 +0200

Bernard Aboba wrote:
> How about this?
> 
> All VSA schemes that do not follow the [RFC2865] recommendations
> are NOT RECOMMENDED since these formats will typically not be
> implementable without RADIUS server code changes.  This includes all
> the above formats, as well as Vendor types of more than 8 bits, vendor
> lengths of less than 8 bits, vendor lengths of more than 8 bits and
> Vendor-Specific contents that are not in Type-Length-Value format.

  Looks good to me.

  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: Alan DeKok <[email-masked]>
Date: Tue, 06 Oct 2009 16:29:14 +0200

Bernard Aboba wrote:
> How about this?
> 
> "Note that the Vendor type field in the recommended VSA format is only
> a single octet, like the RADIUS type field. While this limitation
> results in an efficient encoding, there are situations in which a
> vendor or SDO will eventually wish to define more than 255
> attributes. Also, an SDO can be comprised of multiple subgroups,
> each of whom can desire autonomy over the definition of attributes
> within their group.  The most interoperable way to address these
> issues is for the vendor or SDO to request allocation of multiple
> Vendor identifiers.
> 
> However, instead of doing this, vendors have defined the following
> non-standard VSA formats:"

  Looks good to me.

  Alan DeKok.