Subject: [AAA-WG]: Re: questions and comments regarding the Diameter API draft

From: David Frascone <[email-masked]>
Date: Tue, 1 May 2001 23:05:34 -0500

Below are responses from the three original authors.  There are some un-
answered questions for the WG.

> 
> I have some questions regarding the ID. If you could clarify them, it would
> be great. My apologies for it being a long mail...
> 
> Thank you very much!
> 
> Yiwen
> 
> - General questions
> 	+ Language: Why is there a Java API for server? Is C API for server
> not good enough? 'cause people can use JNI to put a wrapper around the C
> API. Or is the intent to standardize the server interface despite the fact
> that C API provides the same functionality? 
> 	+ Callback: Is callback associated with *all* existing commands or
> is it only have one-to-one mapping with all extension commands? E.g., does
> it make sense to have a callback for DRI messages which is only used during
> the peer connection establishment?

The Sun aaa server handles DRIs itself.  But, there is no reason why
another server's applications can't register for all messages,
including DRIs.
 
> - Section specific questions:
> 	3 questions for callbacks:
> 	+ Sec. 3.1.13, Pg. 11. last three paragraphs, description on
> AAA_APP_INSTALL_FIRST and LAST. "If subsequent callbacks are installed with
> this code, the callback is moved down/up the list". THis is inconsistent
> with the description of the callback processing order in section 3.5.4 (pg
> 39), which says that "If the API client adds another, any existing pre- and
> post-processors are removed". 
 
The document needs to be updated. If another application requests first or last
and the slot is already in use, then an error should be returned.
 
> 
> 	+ Sec. 3.4.2.1, Pg. 20. From the signature of the function, does
> this mean that there can be > 1 callbacks for the same command, but for
> different extensions? (an example would be any accounting commands that can
> be for MIP or NASREQ, etc)?
 
yes that is correct.
 
> 	+ Sec. 3.5.4, Pg. 40. Last paragraph. Does this imply that the LAST
> callback is for error handling of message processing (since if ANY completes
> successful, the LAST callback is not called)?
 
This is correct. If a callback returns a successful return code, it implies to
the library that the message was locally consumed, and therefore it isn't
processed by any other callbacks.
 
So returning a success is only done in few instances.
 
> 	6 questions for messages:
> 	+ Sec. 3.2.4, Pg 16. first line, identifier. Is this hop-by-hop ID
> or End-to-End ID? Shouldn't there be another ID in the message?
 
Yes, there needs to be another identifier added.  The API is
slightly behind the AAA specification.
 
> 	+ Sec. 3.2.4, Pg 16. 4th line, appHandle. Is this handle for user
> session only? What about peer connection handle? Why would these two handles
> be handled different?
 
The API is slightly behind the AAA specification, in reguards
to sessions.
 
> 	+ Sec. 3.4.5.1, Pg. 28. First paragraph. What is the
> "Initialization-Vector AVP"? I can't find it in the base protocol. (base ID,
> pg. 24).
 
The API is slightly behind the AAA specification.  The document
will be updated.
 
> 	+ Sec. 3.4.5.2, Pg. 28. Shouldn't the signature be: 
> 		  AAAReturnCode AAAFreeMessage(AAAMessage **message)
> Note: ** instead of *? I would assume that after the successful return,
> value of message would be NULL.?
 
This question has fostered much debate between the authors. 
For now, our implementation takes an AAAMessage *, and it is
the application's duty to make sure that he null's his own
pointer (just like calling free()).
 
But, if you feel otherwise, this would be a good question for the
aaa-wg list.
 
> 	+ Sec. 3.4.5.3, Pg. 29. When would I use the AAARespondToMessage()?
> Can't I just do:
> 	  AAANewMessage();
> 	  AAASetServer();
> 	  AAASendMessage();
 
Yes, but AAARespondToMessage will set the flags right (indicating a
response), and will include any Proxy-State type information that
the application shouldn't have to mess with.
 
> 	+ Sec. 3.4.6.2, Pg. 36. Why is the AAASendMessage() responsible for
> assigning the msg ID to the message, wouldn't this be the responsibility of
> AAANewMessage() function call? Also, what is the server id mentioned in this
> paragraph?
 
Actually that is not a bad idea.
 
> 
> 	2 questions on AVPs:
> 	+ Sec. 3.4.5.9, Pg. 32. Shouldn't this function be associated with
> AAA_AVP_LIST pointers rather than AAA_AVP pointers? The logic behind having
> an Extended_AAA_AVP structure specified on Pg 39 is to hide the fact that
> AVP actually is a node of a doubly linked list. In which case,
> AAAJoinAVPList() should not be dealing with AAA_AVPs.
 
It would be perfectly acceptable to have the function deal with AVPLists (and
I thought it did).
 
> 
> 
> 	+ Sec. 3.4.5.11, Pg. 33. Shouldn't the avp passed into the function
> be **? I.e.
> 		AAAReturnCode AAAFreeAVP(AAA_AVP **avp)
 
See my comments above.  Currently, our api DOES pass a **, which
is very ugly compared to AAAFreeMessage (and departs from the API).
Definately one of the styles needs to be chosen.  Again, this is
a WG opinion question
 
> ? Successful return of this function would have avp to be NULL.
> 
> 	one question on session:
> 	+ Sec. 3.4.3.1. THis is to start a user session, and *not* a peer
> connection, correct?
> 

Correct. There is no way to kick start a peer connection via the API. This is
transparent to the application.