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

From: James Kempf <[email-masked]>
Date: Fri, 20 Apr 2001 15:03:32 -0700 (PDT)

Hi Brian,

Thanx for your comments.

>>        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".  
>

I agree that all sessions will need to use the base protocol's dictionary.

So it sounds like the issue is the following. If a command shows up
for a given session but the command is known in a dictionary of
another session, this design will return an UNKNOWN_COMMAND when
it should return an EXTENSION_NOT_SUPPORTED, is that it? 

The intent of including the dictionary in this fashion was to allow
Diameter applications to running in the same virtual machine
to handle separate applications, and so that they could define
their commands in separate configuration files. I'm not strongly
tied to this design, but I had thought it might be simpler from
the application's perspective. It sounds like you would rather
simply have a global command dictionary?

>(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.

Typically, the AVP dictionary is defined as part of the command definition
configuration file. I believe there has been agreement by the group
that AVPs are standardized as part of extensions, not separately. Thus,
it seems to make sense to include them as part of the commands.

In addition, the API has to provide a way for programmatic definition
of commands, separate from parsing the command definition file. This
method is defined for the latter. The Java code implementing an
extension that wants to build up a dictionary would do it by
building up the AVP dictionary programmaticaly, then building up
the command, etc.

>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

I guess I don't understand. The AVPs and AVPDescriptors are indexed by name, and 
the AVPDescriptor object contains a type indicator (AVPDescriptor.getType()). 
Would you rather have them indexed by code?

>dictionary.  Okay, I take that back, the library could put the
>responsibility of casting the data to the appropriate type on the API user.

It is true that the return type from the AVP.getData() method is
Object, but there are only possible 9 data types, and that
can easily be handled by a typecase. 

We could have individual AVP types with different getData() return
type methods, but then you would have to run the typecase when
you extract the AVP from the Map. This seems like one area where
dynamic type checking is advantageous.

>(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.
>

I agree that configuration files are preferable, but I think we need
to keep open the possibility of programmatic update. In addition,
the library implementation itself can use the programmatic interface when 
parsing the configuration files.

>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.
>

I believe Erik already has some syntax for this in the DTD. I'd rather not
tie people down to having to map extensions into packages and
commands into classes. I can think of cases where an extension might
span a bunch of packages.

>>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?
>

I guess Pat didn't post it before he went on vacation. I will talk to
him when he gets back next week. If you would like to help writing the DTD,
send email to Erik Guttman ([email-masked]).

		jak