RE: : Re: AAA URI draft

Rui,


> > Note that the above removes all of the complexity described in
> > section 3 regarding the various combinations of AAA protocol,
> > transport, and session-based security that are not allowed.  If you
> > simply define the URI schemes such that illegitimate combinations
> > aren't even an option, then you don't have to require that
> > applications keep track of what combination of parameters
> > are allowed.  Likewise, all of the aliases (multiple URIs for the
> > same service) are removed by specifying that the short scheme
> > defines the most common protocol case (just as the "http" scheme
> > defines HTTP over TCP, not HTTP over any transport).
> 
> I like it. It is consistent with the need to manage different sorts of 
> AAA servers during the migration to Diameter and can cater for all the 
> usual O&M issues (like custom port numbers, defaults, etc.) in a 
> non-ambiguous way that will minimize the chances for human error.
> 
> > Furthermore, if we later discover that there are more resources
> > hidden within the Diameter, TACACS+, and RADIUS servers beyond
> > the mere existence of the service points, then all we need to
> > do is add a path to the URI definition and those new services
> > can be used by other information systems beyond AAA.
> 
> Yes, and applications handling the URI, as you put it quite nicely, can 
> process it in a standard way (with the proper validations, I can 
> envision using the URI as an XPath into a XML configuration file, 
> etc.).

Before expanding the use of the URI, I'd like to get some input on 
how the WG feels about this.  Is this functionality needed?  Also,
it might be useful to get some input from RADIUS folks, etc.

thanks,
John