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

From: <[email-masked]>
Date: Wed, 27 Mar 2002 15:14:33 +0200

Hi Bob,

Thasnks for all of the catches.  I've updated the document.

John

> -----Original Message-----
> From: ext Bob Kopacz [mailto:[email-masked]]
> Sent: 26 March, 2002 21:16
> To: Loughney John (NRC/Helsinki)
> Cc: aaa-wg
> Subject: [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".
> 
> - - -
> 
>