Subject: RE: [AAA-WG]: Re: questions and comments regarding the Diameter A PI draft

From: Yiwen Jiang <[email-masked]>
Date: Wed, 2 May 2001 10:26:02 -0400

Thanks for the comments, Dave. 

I forgot to list some questions/comments about the configuration files in my
last mail. SO here it is, followed by my comments to your reply.

Yiwen

I read some thread in the mailing list earlier that the configuration file
was taken out of the I-D on purpose to allow flexible user defined
configuration. The end result, from my interpretation to the thread, was
that the configuration file was going to be put back in again, but only one
file is. Could you verify this for me please?

Another comment I have regarding Sec. 2.2.3 was the use of "value" in the
configuration file. I went through the dictionary file that was provided by
the Sun's aaa server, and it seems that the "value" for AVPs in the
dictionary file is actually the AVP code. This is quite confusing with the
actual value of the AVP, which should be assigned by the server
application/extension when messages are created, rather than from the
configuration file. Is there any chance we can change the word "value" to
"code" in the AVP definitions? (Sec. 2.2.3.1).. I'm assuming the value
definition in Sec. 2.2.3.2 is the valid values for various AVPs described in
the AVP definitions earlier in the dictionary?

> > 	+ 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.
If a server's application does register callback for message such as DRI,
one would assume that the callback for DRI  is invoked *after* the action in
the state machine is processed, right? If so, could we add that in the I-D?

> > 	+ 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.
hmm... So you are saying neither of the sections listed above is correct?
  
> > 	+ 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.
But the signature of AAARespondToMessage, it only contains one reference to
the message to respond to... To set  these information correctly, wouldn't
you need to have another AAAMessage somewhere in the signature for the
respond message?

> > 	+ 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).
So are we agreeing that the signature of AAAJoinAVPList be:
	AAAReturnCode AAAJoinAVPLists(AAA_AVP_LIST *dest, 
						AAA_AVP_LIST *source);  

> > 	+ 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.
but if one calls AAAOpen(), at the return of  the function call, a peer
connection is created. And there can be only one peer connection between two
servers, right?

---

From: David Frascone <[email-masked]>
Date: Wed, 2 May 2001 10:26:23 -0500

> the state machine is processed, right? If so, could we add that in the I-D?

I don't think so.  We might want to mention that a server *might* handle 
DRI's itself, but that is kind of implementation specific.  Remember, we're
not designing a server here, just an API to do AAA work.  If "Bob's
AAA Server" decides to allow applications to register for DRI's, that
is Bob's perrogative.

> you need to have another AAAMessage somewhere in the signature for the

That is assumed to be handled internally. -- In other words, when you do
an AAARespondToMessage(), it massages the current message from incoming
to outgoing, and allows you to modify fields.