Guidelines suggested text for checklist:

[Alan DeKok <aland@nitros9.org>]

  The following text is a first draft of a checklist-style outline for
guidelines.  It re-iterates some of the text in the rest of the
document, but in a shorter format.

---
Appendix A - Design Guidelines

   The following text provides guidelines for the design of attributes
   used by the RADIUS protocol.

A.1. Transport of simple data

   The following kinds of data fit within the existing RADIUS data
   model, and can be encapsulated in a [RFC2865] format RADIUS
   attribute, or in a [RFC2865] format RADIUS VSA:

      * 32-bit unsigned integer, most significant octet first.
      * Enumerated data types, represented as a 32-bit unsigned integer
        with a list of name to value mappings.  (e.g. Service-Type)
      * 64-bit unsigned integer, most significant octet first.
      * IPv4 address in network byte order.
      * IPv6 address in network byte order.
      * IPv6 prefix.
      * time as 32 bit unsigned value, most significant octet first, in
        seconds since 00:00:00 UTC, January 1, 1970.
      * string (i.e. binary data), totalling 253 octets or less in
        length. This includes the opaque encapsulation of data
        structures defined outside of RADIUS.
      * UTF-8 text, totalling 253 octets or less in length.

   For [RFC2865] RADIUS VSAs, the length limitation of the "string" and
   "text" types is 247 octets instead of 253 octets, due to the
   additional information included in the Vendor-Specific attribute.

A.2. Transport of new authentication protocols

   New authentication or security functionality in RADIUS requires
   require code changes on both the RADIUS client and server, regardless
   of the attribute format.  As a result, in most cases the use of
   complex attributes to represent these methods is acceptable.

A.3. Improper data types

   The following kinds of data do not fit within the RADIUS data model,
   and should be replaced with the suggested alternatives, or should not
   be used at all.

      * Signed integers of any size.
        SHOULD NOT be used.
      * 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.
      * Tagged data types as in [RFC2868].
        These data types SHOULD NOT be used in new specifications.  The
        attribute grouping method defined in [EXTEN] SHOULD be used
        instead.
      * Complex data structures defined only within RADIUS.
        The additional functionality defined in [EXTEN] SHOULD be used
        instead.  This recommendation does not apply to new
        authentication or security functionality, as described above in
        Section A.2.
      * Multi-field text strings.
        Each field SHOULD be encapsulated in a separate attribute.
        Where grouping of fields is desired, the additional
        functionality defined in [EXTEN] SHOULD be used instead.
      * Polymorphic attributes.
        Multiple attributes, each with a fixed data type SHOULD be
        defined instead.

A.4. Vendor-Specific formats

   Vendor-Specific attributes SHOULD follow the [RFC2865] suggested
   format, or the [EXTEN] format if more functionality or a larger
   attribute space is necessary.  Vendor-Specific attributes matching
   any of the following formats SHOULD NOT be used.

      * Vendor types of more than 16 bits.
      * Vendor lengths of less than 8 bits.  (i.e. zero bits)
      * Vendor lengths of more than 8 bits.
      * Vendor-Specific contents that are not in Type-Length-Value
        format.

A.5. New functionality in RADIUS.

   Some implementations have extended RADIUS by a number of methods.
   The following practices are NOT RECOMMENDED:

      * Defining new commands in RADIUS.
        This restriction includes new commands created by overloading
        the Service-Type attribute to define new values that modify
        the functionality of Access-Request packets.
      * Using RADIUS as a transport protocol.
        This restriction is partially a subset of the previous one.
        Note that using RADIUS to transport authentication methods
        (e.g. EAP) is explicitly permitted, even if those methods
        require the transport of relatively large amounts of data.
      * Extending the RADIUS packet length limitation past 4096 octets.
        A multi-packet sequence of Access-Request / Access-Challenge
        SHOULD be used instead.  If that is not possible, then a method
        other than RADIUS SHOULD be used to transport the data.

A.6. Allocation of attributes

   RADIUS attribute specifications SHOULD allocate attributes from the
   vendor space, rather than requesting an allocation from the RADIUS
   standard attribute space, for attributes matching any of the
   following criteria:

      * attributes relying on data types not defined within RADIUS
      * attributes intended primarily for use within an SDO
      * attributes intended primarily for use within a group of SDOs.

   Even if attributes are allocated from the vendor space, it is often
   useful for SDOs to publish the specification as an informational RFC,
   as with [RFC4679].

   Note that the first bullet point above relaxes many of the previous
   guidelines on data types, but only within a narrowly defined scope.
   Extensions to RADIUS that may not be appropriate for widespread use
   may be acceptable within a limited context.

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