Design Guidelines draft

["Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>]

Hi all, 

thanks for improving the document. 

I had a brief look again at the latest version of the design guidelines draft and noticed 2 points that I would like to highlight: 

1) Repetition

Section 2.1 lists the basic data types. Section 3.2.1 lists them again. And so does Appendix A.1.1.

I would argue that we should only have them once listed in the document (at least I would argue to get rid of A.1.1). Appendix A in general repeats what was said in the previous section again. Appendix B is good since it shows some of the examples. 

The line drawn between the basic and the complex data types is still arbitrarily, which leaves a bad taste behind. 

2) Inconsistent story

To avoid complex attributes the document argues to split them. But then the document furthermore argues that the attribute code space is going to be exhausted pretty soon. 

The story from the RADEXT group, at least if I understood it correctly, was the extended attribute format, see http://datatracker.ietf.org/doc/draft-ietf-radext-extended-attributes/. This would solve the "exhaustion" issue. However, it does not nicely fit in the story of basic vs. complex attributes since the extended attribute format is a complex attribute that by definition in the document has to be avoided at all cost (because of security vulnerabilities, etc.). 

Additionally there are a few minor notes: 

a) What is a "service definition"? (see Section 2.3)

A reference to an example would help to understand what is actually meant (and what isn't). The term "service" is so generic that it has to lead to confusion. For example, is the recently proposed SAML messaging work over RADIUS a negative example for this?

b) Section 3.2.3: 

"
      * it is easier for the user to enter the data as well-known
        types, rather than complex structures;
"

please replace the term "user" with something else, particularly since the rest of the document talks about the user in the sense of the person gaining access to the network. here we are talking about the person doing the system administration. 

c) Section 3.2.3: A general comment

With the following bullets I would like to have a sentence added that this is very implementation specific: 


"
      * it is easier for the user to enter the data as well-known
        types, rather than complex structures;

      * it enables additional error checking by leveraging the
        parsing and validation routines for well-known types;

      * it simplifies implementations by eliminating special-case
        attribute-specific parsing.

"

Regarding the first item: It depends how you provision the data. if you type them with an ASCII editor then I fully agree. If you have tools then I disagree. For larger systems you are not using an ASCII editor, IMHO. 

Regarding the second item: It depends when you do the error checking. If you do it as post-processing (for example, when the data ends up in the database) then there isn't an issue at all. if you do it in real-time when you get the data provided then you will in many cases have to have a more sophisticated policy language; the capabilities of the policy language has never been clearly described nor investigated as part of a survey of available implementations. 

Regarding item three: I agree with this item to some extend but splitting attributes into multiple attributes (or even multiple messages, as suggested in the text) requires some mechanism to correlate them. This also requires code and potentially state to be maintained. 


I would encourage the group to investigate the existing RADIUS server implementation features (independently of the document; certainly not blocking the progress of the document) because it could lead to interesting insights. I would also be in favor of suggesting that people think about how they are going to process attributes (on the sending and on the receiving side and what the required code changes are). Being explicit about these aspects would improve the quality of the specification IMHO. 

Ciao
Hannes

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