Subject: [AAA-WG]: Proposed fix for issues 26, 38 and 48

From: Pat Calhoun <[email-masked]>
Date: Tue, 5 Jun 2001 08:49:25 -0700

All,

Here is my proposed fix for issues 26, 38 and 48. This proposed text is
similar to Mark's text earlier this week, but also addresses other issues.

PatC
----

10.12  Session-Binding AVP

   The Session-Binding AVP (AVP Code TBD) is of type Unsigned32, and MAY
   be present in application-specific authorization answer messages. If
   present, this AVP MAY inform the Diameter client that all future
   application-specific re-auth messages for this session MUST be sent
   to the same authorization server. This AVP MAY also specify that a
   Session-Termination-Request message for this session
    MUST be sent to the same authorizing server. The following values
   are supported:

      DONT_CARE                  0
         The Destination-Host AVP does not need to be present in future
         re-auth and STR messages for this session.

      RE_AUTH_ONLY               1
         The Destination-Host AVP in future re-auth messages for this
         session MUST be set to the value of the Origin-Host AVP in the
         authorization answer message.

      STR_ONLY                   2
         The Destination-Host AVP in Session-Termination-Request message
         for this session MUST be set to the value of the Origin-Host
         AVP in the authorization answer message.

      DO_BOTH                    3
         The Destination-Host AVP in future re-auth and the Session-
         Termination-Request message for this session MUST be set to the
         value of the Origin-Host AVP in the authorization answer
         message.

10.13  Session-Server-Failover AVP

   The Session-Server-Failover AVP (AVP Code TBD) is of type Unsigned32,
   and MAY be present in application-specific authorization answer
   messages that include the Session-Binding AVP with a non-zero value.
   If present, this AVP MAY inform the Diameter client that if a re-auth
   or STR message fails due to a delivery problem, the Diameter client
   SHOULD issue a subsequent message without the Destination-Host AVP.

      REFUSE_SERVICE             0
         If either the re-auth or the STR message delivery fails,
         terminate service with the user, and do not attempt any
         subsequent attempts.

      TRY_AGAIN                  1
         If either the re-auth or the STR message delivery fails, resend
         the failed message without the Destination-Host AVP present.

---

From: Mark Eklund <[email-masked]>
Date: Tue, 5 Jun 2001 16:05:17 -0400 (EDT)

Pat,
Two thoughts.

>          AVP in the authorization answer message.

1. If the AVP is not present, is the default DO_BOTH?

>          the failed message without the Destination-Host AVP present.

2. If the AVP is not sent, is the default REFUSE_SERVICE?
3. Any possibility of adding the below two?

        ALLOW_SERVICE		   2
           If re-auth message delivery fails, assume that re-authorization
           succeeded.  If STR message delivery fails, terminate
           the session.

        TRY_AGAIN_ALLOW_SERVICE    3
           If either the re-auth or the STR message delivery fails, resend
           the failed message without the Destination-Host AVP
           present.  If the second delivery fails for re-auth,
           assume re-authorization succeeded.  If the second
           delivery fails for STR, terminate the session.
-mark

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 6 Jun 2001 16:26:35 -0700

> 1. If the AVP is not present, is the default DO_BOTH?

No, if absent, default is DONT_CARE. I will add clarifying text.

> 2. If the AVP is not sent, is the default REFUSE_SERVICE?
yes. new text will be added.

>            delivery fails for STR, terminate the session.

ok.

PatC