RE: Last comments on design guidelines document

["Bernard Aboba" <bernard_aboba@hotmail.com>]

Alan DeKok said: 

"  The following text should be added to the document during the RFC
editor process, as suggested in the call last week:


1) Note on "MUST" and "MUST NOT" in the text.  Section 1.3, before the
final paragraph, add the following new sentence:


   The suggestions given below specify no mandatory behavior
   on new implementations.  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.

   The advice in this document applies to attributes used to encode
   ..."


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


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

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? 
The third bullet still says:

"   * for purposes other than authentication or security?"

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? 

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

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


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