Subject: [AAA-WG]: RE: [issue] User-Name AVP optional in ACR (base#10)

From: "Harri Hakala (LMF)" <[email-masked]>
Date: Thu, 11 Apr 2002 13:15:24 +0200

Hi,

I think that same applies to the ASR and STR commands.
See 8.4.1, 8.5.1 and 10.1.

Regards.......Harri  

-----Original Message-----
From: Carolina Canales Valenzuela (ECE) 
Sent: 11. huhtikuuta 2002 13:52
To: aaa-wg
Cc: Harri Hakala (LMF); Victor Manuel Avila Gonzalez (ECE); Tony
Johansson (EUS); Kevin Purser (EUS)
Subject: [issue] User-Name AVP optional in ACR (base#10)

Issue:                    User-Name AVP optional in ACR, ACA
Submitter name:           Carolina Canales
Submitter email address:  [email-masked]
Date first submitted:     04-11-2002
Reference:			  
Document:                 diameter-base-10
Comment type:             Technical
Priority:                 S
Section:                  9.7.1, 9.7.2, 10.2

Rationale:

It seems there is a contradiction between the use of the User-Name AVP stated in ABNF definition of the ACR, ACA commands (sect 9.7.1, 9.7.2), and what is stated in the AVP table (sect. 10.2).

In the ABNF of the ACR the User-Name AVP is optional:

<ACR> ::= < Diameter Header: 271, REQ, PXY >               
		 	< Session-Id >
             	{ Origin-Host }                
			{ Origin-Realm }
                ......
                  [ User-Name ]

however in the AVP table in sect. 10.2 it is stated as mandatory for ACR (1)

                                 +-----------+
                                 |  Command  |
                                 |    Code   |
                                 |-----+-----+
   Attribute Name                | ACR | ACA |
   ------------------------------|-----+-----+
   User-Name                     | 1   | 0-1 |

Requested Change:

Change the AVP table in sect 10.2 to reflect that User-Name is optional in ACR (it was agreed by the WG in previous emails that sometimes the accounting client might not know the user name, or at least with a NAI format as it is required by the User-Name definition).

                                 |  Command  |
                                 |    Code   |
                                 |-----+-----+
   Attribute Name                | ACR | ACA |
   ------------------------------|-----+-----+
   User-Name                     | 0-1 | 0-1 |

Carolina Canales-Valenzuela
Systems Engineer 
UMTS/GSM Systems Management
R&D Center 
Ericsson España, S.A.        

Ombú, 3                  	Phone: +34 91 339 2680              
28045 Madrid		Fax:    +34 91 339 2538 
SPAIN 
e-mail: [email-masked]

>-----Original Message-----
>From: Bob Kopacz [mailto:[email-masked]]
>Sent: Tuesday, March 26, 2002 8:16 PM
>To: John Loughney
>Cc: aaa-wg
>Subject: [AAA-WG]: [issue] Minor corrections/clarifications to base-10
>
>
>Hi John,
>
>Issue :                 Minor corrections/clarifications to base-10
>Submitter name:         Bob Kopacz 
>Submitter email address:[email-masked] 
>Date first submitted:   03-26-2002 
>Reference: 
>Document:               draft-base-10
>Comment type:           Technical 
>Priority:               1 
>Section: 
>
>Rationale/Explanation of issue: 
>
>  Minor corrections/clarifications to base-10.
>
>Requested change:
>
>
>In section 1.1.1 Differences from Radius
>
>Change "Radius" to all caps in the section title.
>
>- - -
>
>In section 6.1.8 Relaying and Proxying Requests
>
>Change the first two lines of the following paragraph:
>
>  Relay and Proxy agents MAY include the Proxy-Info AVP in requests if
>  it requires access any local state information when the corresponding
>  response is received. Alternatively, it MAY simply use local storage
>  to store state information.
>
>To (four changes "A"... "or"... "agent"... "to"):
>
>  A Relay or Proxy agent MAY include the Proxy-Info AVP in requests if
>  it requires access to any local state information when the 
>corresponding
>  response is received. Alternatively, it MAY simply use local storage
>  to store state information.
>
>- - -
>
>In section 7.1 Result-Code AVP
>
>  The Result-Code AVP (AVP Code 268) is of type Unsigned32 and
>  indicates whether a particular request was completed successfully or
>  whether an error occurred. All Diameter answer messages MUST include
>  one Result-Code AVP.  A non-successful Result-Code AVP (one 
>containing
>  a non 2xxx value) MUST include the Error-Reporting-Host AVP if the
>  host setting the Result-Code AVP is different from the identity
>  encoded in the Origin-Host AVP.
>
>Change the parenthesized phrase in the preceding paragraph:
>
>  (one containing a non 2xxx value) 
>  
>To:
>
>  (one containing a non 2xxx value other than 
>DIAMETER_REDIRECT_INDICATION) 
>
>- - -
>
>In section 8 DIAMETER USER SESSIONS
>
>  Services provided past the expiration of the Authorization-
>  Lifetime and Auth-Grace-Period AVPs is the responsibility of the
>  access device.
>
>Change "is the responsibility" to "are the responsibility".
>
>- - -
>
>In section 8.4 Session Termination
>
>  It is also possible that a session that was authorized is never
>  actually started due to action of a proxy. For example, a proxy may
>  modify an authorization answer, converting the result from success to
>  failure, prior to forwarding the message to the access device. A
>  proxy that causes an authorized session not to be started MUST issue
>  an STR to the Diameter server that authorized the session, since the
>  access device has no way of knowing that the session had been
>  authorized.
>
>Change the last sentence of the preceding paragraph to:
>
>  If the answer did not contain an Auth-Session-State AVP with 
>the value
>  NO_STATE_MAINTAINED, a proxy that causes an authorized 
>session not to be
>  started MUST issue an STR to the Diameter server that authorized the
>  session, since the access device has no way of knowing that 
>the session
>  had been authorized.
>
>- - -
>
>In section 8.12 Re-Auth-Request-Type AVP
>
>Following this sentence:
>
>  The Re-Auth-Request-Type AVP (AVP Code 285) is of type Enumerated and
>  is included in application-specific auth answers to inform the client
>  of the action expected upon expiration of the Authorization-Lifetime.
>
>Add the following sentence:
>
>  If the answer message contains an Authorization-Lifetime AVP with a
>  positive value, the Re-Auth-Request-Type AVP MUST be present 
>in an answer
>  message.
>
>- - -
>
>In section 8.13 Session-Timeout AVP
>
>Change the following sentence:
>
>  A Session-Timeout AVP MAY be present in a re-authorization message,
>  and contains the number of seconds from the beginning of the re-auth.
>
>To:
>
>  A Session-Timeout AVP MAY be present in a re-authorization 
>answer message,
>  and contains the remaining number of seconds from the 
>beginning of the
>  re-auth.
>
>- - -
>
>In section 8.17 Session-Binding AVP
>
>Change:
>
>  ACCOUNTING                 4
>    When set, all accounting messages for this session MUST NOT
>    include the Destination-Host AVP. When cleared, the default
>    value, the Destination-Host AVP MUST be present in all
>    accounting messages for this session.
>
>To:
>
>  ACCOUNTING                 4
>    When set, all accounting messages for this session MUST NOT
>    include the Destination-Host AVP. When cleared, the default
>    value, the Destination-Host AVP, if known, MUST be present in all
>    accounting messages for this session.
>
>The reason for adding the "if known" phrase is this: The 
>accounting server
>may be different from the authentication server, and if so, 
>probably isn't
>known when the first accounting message is sent.  For subsequent
>accounting messages, the accounting server is known by the 
>client and the
>Destination-Host can be included from then on.
>
>- - -
>
>Throughout the document:
>
>Change "Accounting-Multi-Session-Id" to "Acct-Multi-Session-Id".  Since
>this is an AVP inherited from RADIUS, it should retain the RADIUS name.
>
>- - -
>
>In section 10.1 Base Protocol Command AVP Table
>
>Change:
>
>  Attribute Name      |CER|CEA|...
>  --------------------|---+---+...
>  Supported-Vendor-Id |0+ |0  |...
>
>To:
>
>  Attribute Name      |CER|CEA|...
>  --------------------|---+---+...
>  Supported-Vendor-Id |0+ |0+ |...
>
>- - -
>
>In section 10.2 Accounting AVP Table
>
>Change the sentence:
>
>  The table in this section is used to represent which AVPs defined in
>  this document are to be present in the Accounting messages.
>
>To:
>
>  The table in this section is used to represent which AVPs 
>defined in this
>  document are to be present in the Accounting messages.  These AVP
>  occurrence requirements are guidelines which may be expanded and/or
>  overriden by application-specific requirements in the Diameter
>  applications documents.
>
>- - -
>
>In section 10.2 Accounting AVP Table
>
>Add these entries:
>
>  Attribute Name                | ACR | ACA |
>  ------------------------------|-----+-----+
>  Auth-Application-Id           | 0   | 0   |
>  Termination-Cause             | 0-1 | 0-1 |
>  Event-Timestamp               | 0-1 | 0-1 |
>
>- - -
>
>In section 10.2 Accounting AVP Table
>
>Change:
>
>  Attribute Name                | ACR | ACA |
>  ------------------------------|-----+-----+
>  User-Name                     | 0+  | 0+  |
>
>To:
>
>  Attribute Name                | ACR | ACA |
>  ------------------------------|-----+-----+
>  User-Name                     | 1   | 0-1 |
>
>The thinking is, that since the Session-Id AVP requirement is "1", this
>means the accounting message is for a specific session and hence for a
>specific user, so the User-Name requirement is also "1".  And the
>User-Name is optionally echoed back in the ACA (per 
>issue#264), hence the
>"0-1".
>
>- - -
>

---

From: <[email-masked]>
Date: Mon, 15 Apr 2002 12:42:44 +0300

Hi Harri,

>                                  |    Code   |

Just to make sure: ACR, ACA, ASR & STR should all have:

    User-Name                     | 0-1 | 0-1 |

is this correct?

John

---

From: "Harri Hakala (LMF)" <[email-masked]>
Date: Mon, 15 Apr 2002 12:01:26 +0200

Hi John,

Yes, According to the ABNF definition of the STR and ASR commands 
(sections 8.4.1 and 8.5.1) there are stated that the User Name 
is optional.

So ACR/ACA, ASR/ASA and STR/STA should all have:

  User-Name                     | 0-1 | 0-1 |

/ Harri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 15. huhtikuuta 2002 12:43
To: [email-masked]; [email-masked]
Cc: [email-masked];
[email-masked]; [email-masked];
[email-masked]
Subject: RE: [AAA-WG]: RE: [issue] User-Name AVP optional in ACR
(base#10)

Hi Harri,

    User-Name                     | 0-1 | 0-1 |

is this correct?

John

---

From: <[email-masked]>
Date: Mon, 15 Apr 2002 13:08:53 +0300

Hi Harri,

> So ACR/ACA, ASR/ASA and STR/STA should all have:

That is what I thought, the correction has been made.

John