Re: Last comments on design guidelines document

[Alan DeKok <aland@deployingradius.com>]

Bernard Aboba wrote:
> [BA] They don't specify mandatory behavior in existing implementations
> either, correct? How about this? 

  Yes, that is correct.

>    "The uses of "MUST" and "MUST NOT" in this
>    document are limited to (a) requirements to follow the IETF process
>    for IETF standards, and (b) quotes from other documents.  As a result,
>    the use of MUST and MUST NOT in this document does not prescribe 
>    mandatory behavior within implementations."

  OK.  Looks good to me.

> Alan also said:
> 
> "2) Notes on attributes for authentication and security.  Section A.2.2.
>  Current text:
> 
>    * That a RADIUS server and/or client is expected to parse?
>      i.e. A type that cannot be treated as opaque data (Section A.1.3)
> 
> Replacement text:
> 
>    * That a RADIUS server and/or client is expected to parse, validate,
>      or create the contents of via a computation?
>      i.e. A type that cannot be treated as opaque data (Section A.1.3)"
> 
> [BA] Doesn't this still leave the broad authentication/security exemption in
> place? 

  Hmm... maybe we could simply delete the third bullet.

> The third bullet still says:
> 
> "   * for purposes other than authentication or security?"

  Yes.  It's probably better to remove that exemption, and instead to
rely on the "computation" text above.

> Also, the text in Section 2.1.3 remains unchanged:
> 
> "  As a
>    result, the introduction of new complex data types within RADIUS
>    attribute specifications SHOULD be avoided, except in the case of
>    complex attributes involving authentication or security
>    functionality."
> 
> My understanding was that the security/authentication exemption was
> considered too broad.  How about this? 

  Yes.

> In Section 2.1.3, change the text to the following:
> 
> "As a result, the introduction of new complex data types within RADIUS
> attribute specifications SHOULD be avoided.  A potential exception to
> this recommendation occurs for attributes that inherently require
> code changes on both the client and server.  For example, as described
> in Appendix B, complex attributes have been used in situations 
> involving authentication and security attributes that need to be
> dynamically computed and verified."

  That looks good to me.

> A suggestion for the text in Section A.2.2:
> 
> " A.2.2. Complex Data Types
> 
>    Does the attribute:
> 
>    * define a complex data type that a RADIUS server and/or client
>      is expected to parse? (i.e. a type that cannot be treated as
>      opaque data (Section A.1.3). 
> 
>    * involve functionality that could be implemented without code
>      changes on both the client and server?  (i.e. a type that
>      doesn't require dynamic computation and verification, such
>      as authentication or security attributes)
> 
>    If so, this data type SHOULD be replaced with simpler types, as
>    discussed above in Appendix A.2.1.  Also see Section 2.1.3 for a
>    discussion of why complex types are problematic.

  OK.  I think that's clearer.

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