Bernard Aboba wrote:
As a result of the change, what will Section 2.2 look like?
Updated text after the first paragraph below:
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.
These desires have led vendors to define the following non-standard
VSA formats:
* Vendor types of 16 bits, followed by an 8 bit length and
then attribute-specific data.
* Vendor types of 32 bits, followed by no length field, and
then attribute-specific data.
* Vendor types of the RFC format, but where some VSAs are
defined as "grouped" or TLV attributes. These attributes
are then used to carry sub-attributes.
* "Bare" ASCII strings that immediately follow the Vendor-Id,
without using a Vendor type or Vendor length.
All of these formats are NOT RECOMMENDED. All VSA formats that do
not follow [RFC2865] are NOT RECOMMENDED. Examples of NOT
RECOMMENDED formats include 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.
Although [RFC2865] does not mandate it, implementations commonly
assume that the Vendor Id can be used as a key to determine the on-
the-wire format of a VSA. Vendors therefore SHOULD NOT use multiple
formats for VSAs that are associated with a particular Vendor Id. A
vendor wishing to use multiple VSA formats, SHOULD request one Vendor
Id for each VSA format that they will use.
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/>