RE: philosophy of the Design Guidelines document

[Bernard Aboba <bernard_aboba@hotmail.com>]

"There are more things in
heaven and earth, Horatio,

Than are dreamt of in your philosophy." 
WILLIAM SHAKESPEARE / Hamlet Act 1.
Scene V abt. 1601
> No. I am asking for considering the needs of some of the other usage environments as well.

At the risk of offending Shakespeare, perhaps its time to talk about the philosophy of the Design
Guidelines document. 

The Design Guidelines document has two major aspects to it:

  1. Articulating Design Guidelines for RADIUS standard attributes (e.g. not Extended Attributes). 
  2. Improving the efficiency and scalability of the standardization process for RADIUS attributes,
    both within the IETF as well as in other SDOs. 

Through aspects #1 and 2, the goal is to be able to address a wide range of needs in an
efficient way.  

> If you believe that different requirements may lead to different results then you are essentially with me.

By recognizing the unique needs of SDOs, and by establishing a new process for the creation and
review of RADIUS attribute document, the Design Guidelines document would seem
to be in agreement with this philosophy. 

For example, the Design Guidelines document, by articulating the RADIUS Design Guidelines,
allows, and even *encourages* SDOs to create their own RADIUS attribute specifications.  
As we learned in the process of developing RFC 4663 (and also to some extent after long 
experience with RFC 3427), it is becoming increasingly difficult for SDO participants to attend 
both SDO and IETF meetings in order to complete management (MIB or AAA) document.  
These documents are more efficiently done in only one SDO, and if the document doesn't 
involve protocol changes,  then the work can most efficiently be done outside the IETF. 

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

The overall philosophy that the IETF needs to focus its energy on the
*intersection* of requirements (including those from SDOs), not on the *union*
of requirements.  At the same time, the IETF needs to provide the mechanisms
by which SDOs that need work done can do that work themselves.  In principle
this approach enables design coherence to be maintained while at the same time
getting the IETF out of the critical path for much of the work that the SDOs need
to get done. 

> At least I am asking to capture these aspects in the draft as there are
> really two types of complex attributes, namely those captured with the
> RADIUS extended attributes draft and then more complex onces that can be
> found also in the Diameter space. Reading through the draft one could easily
> get the impression that that document now allows the Diameter AVP structure
> to be easily supported, which is not true.

Discussion of Extended Attribute design is out of scope of the Design Guidelines
document.  However, it *is* in scope for the Extended Attributes document.  So
I think you are pointing out an issue with the Extended Attributes document here. 

> It is fine not to align it 100% with Diameter. I just want the differences
> to be documented in the document.

This is indeed a valid concern -- with respect to the Extended Attributes document. 

> Using a dictionary based approach is not a bad thing and will work for many
> cases. The question is only how powerful the language for the dictionary has to be.
> It could be just a "attribute name", "attribute code" and "data type".
>
> Regarding the "data type: Looking at the dictionary provided with FreeRADIUS
> I noticed that there are datatypes support that are not listed in the RADIUS
> Design Guidelines document.

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. 

However, the question of addition of data types *would* be relevant
to the Extended Attributes document, where presumably we are not
as concerned with backward compatibility. 

> BUT:
>
> * If I take certain Diameter documents and I want to provide the
> same/similar functionality in RADIUS then I cannot use the "simple"
> attribute encoding. Example: Diameter QoS attribute. In that case I have to
> come up with my own RADIUS attribute encoding for this purpose.

I do think this is a useful question to consider -- but I think that question
should be considered in the context of the Extended Attributes document,
not the Design Guidelines document. 

> Even though these cases seem to be implicitly covered by the RADIUS design
> guidelines document I still got beaten up with the RADIUS GEOPRIV document.

If you have suggestions for clarifying the language, feel free to submit an issue. 
However, in general, IETF beatings do not have to be linked to an offense, real
or imagined.  Rather the general philosophy seems to be "beatings will continue
until morale improves". :)

> I believe there is value in documenting what the perceived mode of operator
> for a protocol is.

Sure.  The WMF has produced hundreds, even thousands of pages of
documentation, most of which is publicly available.  That they have
been able to utilize RADIUS for this purpose without changing the
protocol seems like a good example of the approach advocated by
the Design Guidelines document. 

> I think that's a Very Bad Idea (tm) and falls under the recommendation against
> polymorphic attribute design.

It should be noted that the Design Guidelines document is a BCP, and the
IETF is not the protocol police.  As a result,  SDOs are free to create
polymorphic attributes within their SDO-specific attribute spaces.   

>I believe that the argument that complex
>attributes lead to interoperability, deployment and security
>issues as stated in the draft is incorrect and can of course happen
>from certain implementation choices.

I would agree that a greenfield implementation could indeed support
a wider range of attribute complexity with little ill effects.  For example,
most Diameter implementations support a considerably wider range
of data types, grouping formats, etc. than most RADIUS implementations
do, because they were designed from the start to do this.

Where greenfield capabilities are being created (such as in the Extended
Attributes work), these arguments can and should be entertained.  However,
where we are talking about a protocol with dozens of legacy implementations,
the bar is set much higher, because the WG not only has to take into 
account the interests of those who want to do new things, but also the
impact on existing deployments.  Manding a forklist upgrade for existing
RADIUS servers which may be long off maintenance in order to add modest
new capabilities is not something that network administrators will appreciate. 

> As an example: Consider the work in the NEA working group that has an impact
> to the AAA server. Simple? Not really. Will people use and deploy it? Who knows.

As far as I can tell, the "statements of health"/"posture attributes"
that are being designed in NEA WG fit within the "opaque blob" concept
articulated in the Design Guidelines document.  That is, there is no requirement
that a AAA server not implementing NEA change a single line of code.  

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