Re: Guidelines suggested text for checklist:

[Alan DeKok <aland@deployingradius.com>]

  After some weeks...

Bernard Aboba wrote:
> For a checklist, I was think of a list of questions, with references to
> the document itself.  So I'd prefer that this list not be repeated
> twice.  Instead you could say "Does the attribute match a type described
> in Section X?"

  I've updated the document to follow that suggestion:

   Does the data fit within the existing RADIUS data model, as outlined
   below?  If so, it SHOULD be encapsulated in a [RFC2865] format RADIUS
   attribute, or in a [RFC2865] format RADIUS VSA.

>>    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.
> 
> This sentence should probably be in the main text.

  Done.

>> 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.
> 
> This statement should be moved to the main text.  Here you could put the
> question "Does the attribute define a complex data type for purposes
> other than authentication or security?  See Section Y for a description
> of why this is problematic."

  Text:

   As can be seen in Appendix B, most of the complex attributes involve
   authentication or security functionality.  Supporting this
   functionality requires 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, and does not create additional interoperability or
   deployment issues.

  Appendix:

   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.

>> A.3. Improper data types
...
> I'd consolidate this with the previous data type section, and rephrase
> as a question:
> "Does the attribute use any of the following data types?"
> 
> Example:
> 
> * Signed integers of any size?  These SHOULD NOT be used.

  Having per-type questions is fatiguing for the reader.  How about this:

   Does the attribute use any of the following data types?  If so, the
   data type SHOULD be replaced with the suggested alternatives, or
   SHOULD NOT be used at all.

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

>> A.4. Vendor-Specific formats
...
> Large SDOs with multiple groups would probably do better with a 16-bit
> attribute space.  Given this, is the suggested format still a SHOULD, or
> do we say "suggested format, using an 8 or 16-bit attribute space."

  Text:

   Also, an SDO can be comprised of multiple subgroups,
   each of whom can desire autonomy over the definition of attributes
   within their group.  In such a situation, a 16-bit Vendor type field
   would be more appropriate:

  Appendix:

   We recognize that SDOs may require more than 256 attributes, which is
   the limit of the 8-bit [RFC2865] Vendor-Specific space.  Those SDOs
   SHOULD use Vendor types of 16 bits.  However, SDOs SHOULD NOT use
   Vendor types of 16 bits unless there are immediate requirements.
   Future-proofing a specification is insufficient grounds for using
   16-bit Vendor types.

>> A.5. New functionality in RADIUS.
...
> Since the document is about attributes, I think this should say
> "Defining new RADIUS commands using attributes."  We're not talking
> about restricting new standards-track documents defining new commands
> (e.g. RFC 3576).

  Text:

   RADIUS also SHOULD NOT be extended to new commands via attributes.
   New commands (i.e. the Code field in the packet header) are allocated
   only through "IETF Consensus" as noted in [RFC3575] Section 2.1.
   Specifications SHOULD NOT use new attributes to modify the
   interpretation of existing RADIUS commands.

>>       * 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.
> 
> Since the focus is on attributes, I'm not sure what this refers to. 
> Would this apply to the GEOPRIV document, for example?

  No.  It's for people who decide "well, we have a protocol between A
and B, we might as well overload it to do something else..."

  Maybe saying "... transport protocol for non-AAA data" would be better.


>>       * 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.
> 
> This duplicates existing text, so I'd rephrase as a question:  "Does the
> attribute match any of the following critiera?  If so, then...."

  Updated and clarified:

   Does the attribute have a limited scope of applicability, as outlined
   below?  If so, then the attributes SHOULD be allocated from the
   Vendor-Specific space.

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

   Note that the points listed above do not relax the recommendations
   discussed in this document.  Instead, they recognize that the RADIUS
   data model has limitations.  In certain situations where inter-
   operability can be strongly constrained, a data model extended by the
   SDO or vendor MAY be used.  We recommend, however, that the RADIUS
   data model SHOULD be used, even if it is marginally less efficient
   than alternatives.

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