RE: : Re: AAA URI draft

Hi,

> - Make the aaa/aaas URI schemes protocol agnostic; remove all the 
> parameters (including protocol and transport).

I think we should keep aaa and aaas schemes including the parameters.


> - Define diameter and diameters URI schemes. Make them protocol 
> specific, obviously. Add a parameter that specifies the transport.

I'm not sure if we need Diameter-specific uri-schemes, but if 
such schemes are defined I'd suggest shorter forms 'dia:' and 'dias:' :)


BR,
Mikko


> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]]On Behalf Of
> ext Miguel Garcia
> Sent: 21 October, 2004 10:03
> To: Rui Carmo
> Cc: [email protected]
> Subject: Re: [AAA-WG]: Re: AAA URI draft
> 
> 
> Rui:
> 
> I am not the advocate of any proposal, but I will give you my 
> opinion on 
> this.
> 
> 1) The aaa URI scheme is already specified in RFC 3588 (though not 
> registered with IANA). Although I personally don't like URIs that are 
> not protocol specific, this is a common practice today. Think of the 
> mailto, im and pres URI schemes for e-mail, instant messaging and 
> pressence, respectively. All of them are protocol independent.
> 
> 2) As far as I know, it is not feasible to expose the combination of 
> protocol/transport/security in the URI scheme itself, because the 
> combination will be growing with time and makes unfeasible to have a 
> future compatible deployment of Diameter. As far as I know, 
> the IESG has 
> typically allowed to differentiate the security requirements 
> in the URI, 
> but not other aspects such as the transport protocol. For 
> instance, http 
> and https URIs differentiate the security aspects of HTTP. Well, HTTP 
> runs over TCP so it is not a big issue. But take as an 
> example the sip 
> URI scheme. SIP can run over TCP, UDP, and SCTP. There are not such 
> thing as sip.tcp, sip.udp, sip.sctp, sips.tcp, sips.sctp URI schemes. 
> Instead, there are only sip and sips URI schemes.
> 
> Therefore my opinion is that we shouldn't go in a direction where the 
> transport protocol is visible in the URI scheme. I think we 
> should try 
> to keep the aaa and aaas URI schemes.
> 
> 3) Having said that, I agree with Roy that the combinations 
> of different 
> AAA protocols, transport protocols and security protocols looks a bit 
> complicated. I wonder if we could make things easier by defining a 
> diameter and diameters URI schemes. If we go in this 
> direction I think 
> we would have to do the following:
> - Make the aaa/aaas URI schemes protocol agnostic; remove all the 
> parameters (including protocol and transport).
> - Define diameter and diameters URI schemes. Make them protocol 
> specific, obviously. Add a parameter that specifies the transport.
> - Somebody (we could do it if assigned) should do similar thing with 
> radius URI scheme.
> - We should define guidelines or even procedures to translate between 
> aaa/aaas URI schemes and their corresponding diameter/radius 
> URI schemes.
> 
> Comments?
> 
> BR,
> 
>       Miguel
> 
> Rui Carmo wrote:
> > 
> > On Sep 10, 2004, at 11:28 PM, Roy T. Fielding wrote:
> > 
> >> but as near as I can tell, the only resources ever 
> provided by those
> >> protocols are the service points (i.e., the fact that 
> there is an AAA
> >> listener at that address).  Why, then, is there a desire 
> for a grab-bag
> >> identification scheme like "aaa", which hides the most 
> important bits
> >> of information at the end of the URI, when the same thing can be
> >> better accomplished by specific URI schemes for each service?
> >>
> >> In other words, what I would propose is the following:
> >>
> >>    d      = "diameter"         "://" authority    ; Diameter/sctp
> >>    d-tcp  = "diameter.tcp"     "://" authority    ; Diameter/tcp
> >>    d-tls  = "diameter.tls"     "://" authority    ; 
> Diameter/tls/sctp
> >>    dtc    = "diameter.tls.tcp" "://" authority    ; 
> Diameter/tls/tcp
> >>
> >>    r      = "radius"           "://" authority    ; RADIUS/udp
> >>
> >>    t      = "tacacs"           "://" authority    ; TACACS+/sctp
> >>    t-udp  = "tacacs.udp"       "://" authority    ; TACACS+/udp
> >>
> >> 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.).
> > 
> > Rui Carmo
> > 
> > 
> 
> -- 
> Miguel A. Garcia           tel:+358-50-4804586
> Nokia Research Center      Helsinki, Finland
>