Subject: [AAA-WG]: Small Questions about locally processing and proxying!

From: [email-masked]
Date: Mon, 5 Nov 2001 12:22:09 +0200

Hi, Pat and all

Could you please give us a clarification about the following case?

------------------------------------------------------------------------
			domain: nokia.com
domain: cisco.com
	           aaaf.nokia.com
aaah.cisco.com
		      AAAF ---------------AAA Proxy -------------AAAH
			  /
\
			 /
\
			FA
HA							      
	           /
		    MN ([email-masked])
 
------------------------------------------------------------------------
-
Our questions are:
	1. When AAAF receives MN([email-masked])'s AMR from FA, will
AAAF locally process 
	   this AMR or proxy this AMR to AAA Proxy? Deos Locally
processing mean the message
	   being processed reaches its destination?
	   (I think AAAF should proxy the AMR to AAA Proxy after AAAF
records the session
	    or transaction state information. The AMR will not be passed
to Application 	    process, that is to say the callback function for
AMR registered in              	    AAAF will not be called when
received the AMR. When AAA Proxy receives the AMR 		    from
AAAF, it almost does the same processing as in AAAF)
	2. Do you have a standard definition about how to maintain a
transaction state 	   information?

BR.

Li ChunAn (andy)

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 5 Nov 2001 07:18:24 -0800

> Could you please give us a clarification about the following case?

First confusion. You imply that the MN issues the AMR, which is incorrect.
The FA does. When the AAAF receives the message, it is forwarded to the
AAAH. The AAAF may be configured to do some checks on the message (e.g.
policy checks), but this is purely an implementation detail, and has nothing
to do with the protocol.

> AAAF, it almost does the same processing as in AAAF)

Again, that is an implementation detail. The local provider may want to keep
track of active mobiles, and the AAAF could be a place to do this. It may
also want to perform additional policy checks.

> transaction state 	   information?

sure
	trans_state_control_block = malloc(sizeof(foobar));
	queue(trans_state_queue, trans_state_control_block);
:)

(seriously, it is an implementation detail)

PatC