Subject: [AAA-WG]: API, latest draft

From: Cain Brian-BCAIN1 <[email-masked]>
Date: Fri, 20 Apr 2001 16:29:15 -0500

James, et al.,

	Comments below.

>4.3.2.4 Instance Methods
-      public AVPDescriptor findCommand(java.lang.String name)
+      public AAACommandDescriptor findCommand(java.lang.String name)
>
>   Return an AAACommandDescriptor for the command matching the name, or
>   null if none.

copy/paste error.

>4.2.2.4 Instance Methods
-      AAAMessage getMessage()
+      AAAMessage getStatusMessage()
>
>   Return the AAAMessage object containing the status message.

The method name 'getMessage' conflicts w/Throwable's getMessage().  Any name
other than 'getMessage' will do.

>        startSession(InetAddress host,AAACommandDictionary dictionary)
>
>   Open a new AAA session. The session is established with the indicated
>   host, and the command dictionary is used to drive command parsing and
>   checking.  This method performs the necessary Diameter messaging for
>   the state machine described in Section 8.0 of [1] in order to bring
>   up a Diameter connection, in addition to standard network sockets
>   bring up

Can we be certain Diameter messaging for a given session would be confined
to one dictionary?  Wouldn't all of the dictionaries be mutually exclusive
(i.e. a given command would show up in one and only one dictionary),
anyways?  It seems like the command dictionaries would lend themselves well
as global variables (global to the library, that is).  Even if each session
confines itself to a particular extension's dictionary, they would still use
the Base protocol's dictionary.  And it would probably be necessary to have
the other dictionaries in order to distinguish between a case where the
library should reject a message with response "EXTENSION_NOT_SUPPORTED" or
"UNKNOWN_COMMAND".  

>4.3.4.4 Instance Methods
...
>      public java.util.Map getAVPDictionary()
>
>   Return a dictionary with String AVP names as keys and AVPDescriptor
>   objects as values for AVPs in the command. If any of the AVPs is
>   Grouped, then the value is a Map containing the descriptors for the
>   AVPs in the Grouped.

I see.  So, AVP lookups are no longer "standalone".  In order to get an
AVPDescriptor, we must first have a command in mind.  I like this.

(from 4.3.6.4)
>      public AAACommandDescriptor
>        registerCommand(long code,
>                        long vendorCode,
>                        java.lang.String name,
>                        java.util.Map AVPDictionary,
>                        java.util.Map disallowedAVPDictionary)

Hmm..This is the only place I could see an AVP dictionary being input into
the library.  I saw no mention of a property for the AVP dictionary file.
I've got a couple of issues with this.  First, there is no correlation
between AVP code and type.  This is the bare minimum requirement for an AVP
dictionary.  Okay, I take that back, the library could put the
responsibility of casting the data to the appropriate type on the API user.
(I see that as pretty unsatisfactory).  That much aside, I really prefer
configuration files for AVP and Command dictionaries over methods.  I think
that having both serves only confusion.  In place of methods like
"registerXxxxx()", a hierarchy of files could be established to register
Extensions, Commands, and AVPs.

What would you think of making a (loose) analogy between AAA Extension and
java package, AAA Command and java class?  You know, how java and javac use
directories as package "grouping symbols", and .class files as individual
classes.  I'm thinking of something like this:

file /etc/aaa.conf:
~~~~~~~~~~~~~~~~
Extension NASREQ    = yes
Extension Mobile_IP = no

Vendor motorola = /etc/aaa/motorola/mot_aaa.conf
Vendor sun      = /etc/aaa/sun/sun_aaa.conf
~~~~~~~~~~~~~~~~
Extensions could be explicitly supported or not, but by default they would
not be.  (NB: I'm not trying to suggest a particular file syntax w/this
example)

file /etc/aaa/NASREQ.xml:
~~~~~~~~~~~~~~~
>XML description of commands 
 defined by NASREQ extension<
~~~~~~~~~~~~~~~

file /etc/aaa/NASREQ.avp.conf:
~~~~~~~~~~~~~~~
AVP "Fancy-New-AVP":
  Type = Float128
  Code = 0x3443
  ...
~~~~~~~~~~~~~~~
(again, not suggesting syntax here, there's no reason why this couldn't be
in XML, too)

file /etc/aaa/motorola/mot_aaa.conf:
~~~~~~~~~~~~~~~
Commands = /etc/aaa/motorola/commands.xml
AVPs     = /etc/aaa/motorola/mot_avp.conf

>add'l vendor-specific info, e.g. 
 constants like "Luna.Location", etc.<
~~~~~~~~~~~~~~~

Property org.ietf.aaa.configFile = "/etc/aaa.conf"

I may be reinventing the wheel a bit with the above suggestion, but the
point that I'm most adamant about is that there should be configuration
files, and they should be the sole way of notifying the library of the type
of AVPs, and the syntax of Commands, etc.  If it's necessary to be able to
update the dictionaries at runtime without restarting the server, the
AAASessionManager could have a reloadConfigFiles() method.

>6.0 References
...
>
>[7]  http://www.diameter.org/diameter.xml
>

FYI - not there (yet?).  I'd be happy to help w/the DTD, if work is still in
progress.  I imagine this is outside the scope of the Java API?  Who's
writing the DTD?

-Brian

--
Brian Cain