Subject: [AAA-WG]: [issue] Minor corrections/clarifications to base-10

From: "Bob Kopacz" <[email-masked]>
Date: Tue, 26 Mar 2002 14:15:35 -0500

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: Bernard Aboba <[email-masked]>
Date: Wed, 27 Mar 2002 11:16:35 -0800 (PST)

Assigned Issue #314. 

See http://www.drizzle.com/~aboba/AAA/issues.html for details.