e-mail: Miguel.An.Garcia@nokia.com AAA and AAAS URI Miguel A. Garcia draft-garcia-dime-aaa-uri-00.txt IETF 66, DIME WG e-mail: Miguel.An.Garcia@nokia.com

Problem definition RFC 3588 apparently defines the AAA and AAAS URI schemes, "aaa://" FQDN [ port ] [ transport ] [ protocol ] but they are buried in Section 4.3 Derived AVP formats although this is not a problem they are common for Diameter, Radius and Tacacs+ although RFC 3588 is about Diameter Section 11 IANA considerations does not provide instructions to IANA to register these URI schemes, therefore, IANA didn’t register them. See: http://www.iana.org/assignments/uri-schemes.html this is the problem

draft-garcia-dime-aaa-uri-00.txt Started as a request to IANA to register the AAA URI originally defined in RFC 3588: http://www.iana.org/assignments/uri-schemes.html The document was originally drafted as an update RFC 3588. This document was, at some point in the past, a WG item in AAA WG. Pass a review in the URI-review list. Pass WGLC in AAA WG.

draft-garcia-dime-aaa-uri-00.txt On updating the document it was detected than an update was needed to make the URI definition compatible with RFC 2396 / RFC 3986. The original definition created a hierarchical URI (aaa:// ) But AAA URIs are not hierarchical : RFC 4395 (Registration of URI schemes say): Avoid improper use of "//". The use of double slashes in the first part of a URI is not an artistic indicator that what follows is a URI: Double slashes are used ONLY when the syntax of the URI's <scheme-specific-part> contains a hierarchical structure as described in RFC 3986. In URIs from such schemes, the use of double slashes indicates that what follows is the top hierarchical element for a naming authority. (See Section 3.2 of RFC 3986 for more details.) URI schemes that do not contain a conformant hierarchical structure in their <scheme-specific-part> SHOULD NOT use double slashes following the "<scheme>:" string. Some parts were underspecified. ‘FQDN’ is not formally defined -> apparently IP addresses are not allowed No clear semantics to AAAS: “transport security used”. No strategy for adding parameters to the URI.

What is next? Possible options: We don’t care, so we do nothing Let’s hope none ever defines a AAA/AAAS URI scheme for another purpose. We fix the IANA the AAA/AAAS URI scheme in a backwards compatible way, and we register with IANA. Looks like a challenge... Not much margin for maneuver. We register with IANA the AAA/AAAS URI scheme (with no changes towards RFC 3588) and work in a definition of a ‘diameter’ URI scheme that need not necessarily be backwards compatible with the AAA URI scheme. Implicitly we would be deprecating the usage of AAA URIs in favor of the new ‘diameter’ URI scheme. We register with IANA the AAA/AAAS URI scheme (with no changes towards RFC 3588).