Re: philosophy of the Design Guidelines document

[Alan DeKok <aland@deployingradius.com>]

Bernard Aboba wrote:
> For example, the Design Guidelines document, by articulating the RADIUS Design Guidelines,
> allows, and even *encourages* SDOs to create their own RADIUS attribute specifications.  

  I think this philosophy needs to be articulated more strongly in the
document.  I will post suggested text.

> So, as I read it, the goal of the Design Guidelines document isn't to lead to further ossification
> of the IETF process  -- but rather to a more productive and cooperative relationship
> between the IETF and SDOs.   For example. the guidelines on complex attributes only 
> apply to the RADIUS standard attribute space, not to the Extended Attribute space, or 
> to SDO-Specific attributes.   So as I read it, the document isn't saying "you can't do 
> this for an SDO-specific purpose", but rather, "if you wish to create attributes that are 
> unlikely to be widely deployed outside your SDO, do so using SDO-specific attributes 
> so as to to minimize impact on existing implementations". 

  I will make that point more strongly in the document.

> Discussion of Extended Attribute design is out of scope of the Design Guidelines
> document.  However, it *is* in scope for the Extended Attributes document.

  We could make it clearer that the this document allows [EXTENDED]
attributes, too.

> By looking at all existing RADIUS implementations, I am sure we could find 
> support for a considerable number of additional data types.  However, the
> question being considered by this document is not "what is the union of
> all implemented RADIUS datatypes", but rather "what is the likely 
> intersection of data types used in RADIUS standard attributes".  
> That question has been answered by examining existing RADIUS RFCs. 

  I agree.  Implementations use other data types primarily for
compliance with non-IETF RADIUS specifications.  I don't see anyone
implementing data types that aren't necessary.

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