Re: Reminder for review of Design Guidelines document

[Alan DeKok <aland@deployingradius.com>]

David B. Nelson wrote:
> Section 1.3, Applicability, reads in part:
> 
>    It is RECOMMENDED that SDOs and vendors seek review of RADIUS
>    attribute specifications from the IETF.  However, when specifications
>    are SDO specific, re-use existing data types, and follow these
>    guidelines, they do not require IETF review.
> 
> I assume that the phrase "they do not require IETF review" is not
> intended to Update RFC 3575, or to modify the RADIUS IANA considerations
> provisions thereof.

  Yes.  I'll see if I can clarify that.  I have some text suggesting
more clearly that vendors own their own VSA space.  The above text could
say:

    a) anything they do in their own VSA space does not require review
    b) referencing existing RFCs does not require review

  That should be compatible with 3575, I think.

> Section ZZZ
> 
> Placeholder that requires resolution?

  To 3.1, I think.

> Section 2.1, Data Types, reads in part:
> 
>    Nested groups or attributes do not qualify as "basic data types", and
>    SHOULD NOT be used.
> 
> Should that read "groups *of* attributes"?

  Hmm... maybe "groups of attributes or nested attributes".

>    All other data formats are defined to be "complex data types", and
>    are NOT RECOMMENDED.  However, there may be situations where complex
>    attributes are beneficial because they reduce complexity in the non-
>    RADIUS systems.  Unfortunately, there are no "hard and fast" rules
>    for where the complexity would best be located.  Each situation has
>    to be decided on a case-by-case basis.
> 
> Should the first sentence read ""are *generally* NOT RECOMMENDED"?  It seems to me that the qualification of the remainder of this paragraph substantially qualifies the traditional RFC 2119 keyword NOT RECOMMENDED.

  Possibly, yes.

> Section 3.1, RADIUS Operational Model, reads in part:
> 
>       * The protocol provices for authentication and integrity
>         protection of packets;
> 
> s/provices/provides/

  Fixed, thanks.

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