# HG changeset patch
# User Sebastien Decugis <sdecugis@nict.go.jp>
# Date 1245040633 -32400
# Node ID 844f921713d5d3e3de9e543dbab558a8a3416a1e
# Parent  2d1f1c6ae1cd66d31d2f282357a2a4fb75d6c58b
Updated design notes for sessions

diff -r 2d1f1c6ae1cd -r 844f921713d5 extensions/radius_gw/design.txt
--- a/extensions/radius_gw/design.txt	Mon Jun 15 13:35:01 2009 +0900
+++ b/extensions/radius_gw/design.txt	Mon Jun 15 13:37:13 2009 +0900
@@ -30,7 +30,7 @@
      - (eventually for later) An immediate RADIUS answer must be sent, without going to Diameter network. This can be used for example for 
        fragmented RADIUS requests (not supported in initial version, may require change in the design...).
  - When all extensions have been called, the Diameter message is checked for consistency. If it is a valid message,
-   it is sent on the Diameter Network, and the RADIUS message is saved in the session.
+   it is sent on the Diameter Network, and the RADIUS message is saved until an answer is received.
    
 When the Diameter answer is received, the radius_gw retrieves the corresponding RADIUS request, 
 then a similar process happens (extensions are the same as for the request). 
@@ -40,12 +40,12 @@
    - RADIUS answer (to add attributes)
    - Diameter answer (with linked Diameter Request inside)
  - When all extensions have been called, the RADIUS answer is generated, with appropriate authenticator and all, and 
-   sent to the RADIUS client.
+   sent to the RADIUS client. The session is deleted (radius gateways are stateless).
 
 
 *** About sessions ***
 
 The session is created the first time an Access-Request is received.
-Then a State attribute in the form "Diameter/..." is used to store the information.
+Then a State or Class attribute in the form "Diameter/..." is used to store the information.
 More details in http://tools.ietf.org/html/rfc4005#section-9