RE: RADEXT charter for comment...

["Nelson, David" <dnelson@enterasys.com>]

Bernard Aboba writes...

I think this version is moving us toward a reasonable consensus.  A few
comments are included, in-line.

Regards,
 
Dave
 
> The RADIUS Extensions Working Group will focus on extensions
> to the RADIUS protocol required to enable its use in applications
> such as Local Area Network authentication authorization and
accounting.
> 
> In order to ensure backward compatibility with RADIUS as well as the
> Diameter, the following restrictions are imposed on extensions
considered
> by the RADIUSEXT WG:
> 
> - All work MUST be backward compatible with existing RADIUS RFCs,
>   including RFCs 2816-2820, 2865-2869, 3162, 3575, 3576, 3579, and
3580.
> - All work MUST be compatible with equivalent facilities in Diameter,
>   including the RADIUS/Diameter gateway specified in the Diameter
>   NASREQ specification.
> - The RADIUS maximum packet size (4K) will not be increased.
> - No new RADIUS transports (e.g. TCP, SCTP) will be defined.
> - Sub-attributes MUST be utilized only in a manner compatible with RFC
>   2865.

The relevant text from RFC 2865 is:

      "It SHOULD be encoded as a sequence of vendor type / vendor length
      / value fields, as follows.  The Attribute-Specific field is
      dependent on the vendor's definition of that attribute.  An
      example encoding of the Vendor-Specific attribute using this
      method follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |  Length       |            Vendor-Id
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Vendor-Id (cont)           | Vendor type   | Vendor length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Attribute-Specific...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

      Multiple subattributes MAY be encoded within a single Vendor-
      Specific attribute, although they do not have to be."

So the "SHOULD" (above) is being promoted to a "MUST" for work within
the scope of RADEXT, correct?  Is it clear from this snippet of RFC 2865
that the nesting of sub-attributes is only one layer deep?  That is my
interpretation.

> - The RADIUS maximum packet size (4K) will not be increased.

This last line is a duplicate.

> - No new RADIUS security mechanisms will be defined.
> 
> Work Items
> 
> The immediate goals of the RADIUSEXT working group are to address the
> following issues:
> 
> - RADIUS design guidelines.  This document will provide guidelines
>   for design of RADIUS attributes, including discussion of the
>   appropriate use of RADIUS SDO-Specific Attributes (SSAs).

Should this not be the first deliverable, given that it may serve as a
"quality control guideline" for other WG work items?


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