[radext] #53: Notes

["radext issue tracker" <trac@tools.ietf.org>]

#53: Notes
---------------------------------------+------------------------------------
 Reporter:  Hannes.Tschofenig@â        |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  minor                      |   Milestone:  milestone1
Component:  design                     |     Version:  1.0       
 Severity:  Submitted WG Document      |    Keywords:            
---------------------------------------+------------------------------------
 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.

-- 
Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/53>
radext <http://tools.ietf.org/radext/>


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