RE: : Re: AAA URI draft

Roy,

At a high-level, the AAA URI scheme was introduce in RFC3588 to be able
to support NAPTR records for Diameter peer discovery - section 5.2.  
Advice was given to follow what SIP does, and so the AAA URI scheme
was based upon SIP.

I am not sure right now if a hierarchical model is warranted.

I'm curious to see if the WG has any opinion if there needs to be 
an expansion in the use of the Diameter URI for other purposes.

thanks,
John
> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]]On Behalf Of
> ext Roy T. Fielding
> Sent: 11 September, 2004 01:28
> To: [email protected]
> Cc: [email protected]
> Subject: [AAA-WG]: Re: AAA URI draft
> 
> 
> Here are my comments regarding the AAA URI draft
> 
>    http://www.ietf.org/internet-drafts/draft-ietf-aaa-uri-01.txt
> 
> update to RFC 3588.  Sorry for the late review.
> 
> The basic premise of this update, namely
> 
>     RFC 3588 [RFC3588] describes the Diameter base protocol for
>     authentication, authorization and accounting purposes.  The RFC
>     provides for the existence of a DiameterURI AVP that contains a "aaa"
>     or "aaas" URI.  That definition of the "aaa" and "aaas" URI schemes
>     follows the so-called hierarchical model specified in RFC 2396
>     [RFC2396], although aaa/aaas resources do not point to hierarchical
>     resources.
> 
> appears to be incorrect.  For one thing, use of a namespace delegation
> mechanism like DNS within the scheme is inherently hierarchical in
> nature and benefits from using the common syntax forms.  Furthermore,
> if Diameter is actually a deployed protocol, an arbitrary change in
> syntax to an existing scheme would significantly impact 
> interoperability.
> 
> What is more problematic, however, is that the "aaa" and "aaas"
> schemes seem to have been defined without a clear indication of
> what is being identified:
> 
>     RFC 3588 [RFC3588] does not provide semantics for the
>     "aaas" URI nor it provide instructions to IANA to register any of
>     those URI schemes in the official IANA registry of URI schemes.
> 
> Unfortunately, the new draft doesn't really define what kind of
> resources are being identified either.  It only says
> 
>     Both the "aaa" and the "aaas" URI schemes are used to identify
>     resources related to authentication, authorization and accounting
>     (AAA) functions that are accessed with AAA protocols such as RADIUS
>     [RFC2865] or Diameter [RFC3588].
> 
> 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).
> 
> 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.
> 
> A FAQ about URI scheme definitions is why doesn't the port component
> in authority come with parameterization, similar to that described
> in the draft for the aaa and aaas schemes?  The reason is because
> applications use URI schemes as a hook by which to select modular
> handlers for the processing of requests. Therefore, placing that
> distinction in the scheme allows handlers for different transports
> to be developed and deployed independently.  In contrast, embedding
> access parameters within a URI forces the application to choose
> either a generic handler that may be incapable of handling the URI,
> or to hard-code inspection of the URI path prior to URI handling
> (effectively breaking the orthogonality principle that is the
> central point of URI design).
> 
> 
> Cheers,
> 
> Roy T. Fielding                            <http://roy.gbiv.com/>
> Chief Scientist, Day Software              <http://www.day.com/>
> 
>