Subject: [AAA-WG]: [issue] Minor corrections to draft-base-08

From: "Bob Kopacz" <[email-masked]>
Date: Tue, 26 Feb 2002 11:35:05 -0500

Issue :         Minor corrections to draft-base-08 
Submitter name: Bob Kopacz 
Submitter email address: [email-masked] 
Date first submitted: 02-26-2002 
Reference: 
Document:       base 08 
Comment type:   Editorial 
Priority:       1 
Section: 

Rationale/Explanation of issue: 

  Minor corrections. 

Requested change: 
 
In Section 2.7 "Peer Table"

>   The Diameter Peer Table is used in message forwarding, and referenced
>   by the Realm Routing Table. A Peer Table entry contains the following
>   fields:
>      - Host identity. following the conventions described for the
>        DiameterIdentity derived AVP data format in section 4.4. This
>        field contains the contents of the Origin-Host AVP found in the
>        CER or CEA message.
>      - Status. This is the state of the peer entry, and MUST match one
>        of the values listed in section 5.6.
>      - Role. This field specifies whether a peer is a primary,
>        secondary or alternate. 

Remove the "-Role" entry.  Section 5.1 makes the observation: "Note
that a given peer MAY act as a primary for a given realm, while acting
as a secondary for another realm."

- - - - - 

In Section 4.5.1 "Example AVP with a Grouped Data type"
    
>   The Example AVP (AVP Code 999999) is of type Grouped and is used to
>   clarify how Grouped AVP values work.  The Grouped Data field has the
>   following ABNF grammar:
>    
>      Example-AVP  ::= < AVP Header: 999999 >
>                       { Origin-Host }
>                     1*{ Session-Id }
>                      *[ AVP ]
>   
>   An Example AVP with Grouped Data follows.
>   
>   The Origin-Host AVP is required.  In this case:
>   
>      Origin-Host = "example.com".  
    
This example is just for illustrative purposes, but it might be better
if the Origin-Host value followed the syntax for DiameterIdentity
[whatever that is these days :) ].

- - - - - 

In Section 4.6 "Diameter Base Protocol AVPs"

>                   AVP  Section             |    |     |
>   Attribute Name  Code Defined  Data Type  |MUST| MAY |
>   -----------------------------------------|----+-----+
>   Firmware-        267  5.3.4   Unsigned32 |    |  P  |
>     Revision                               |    |     |
>   Product-Name     269  5.3.7   UTF8String |    |  P  |

I think the 'P' should move from the MAY to the MUST NOT column for
AVPs that appear only in CER/CEA messages, such as Firmware-Revision
and Product-Name.  To my understanding, at the time the CERs/CEAs are
exchanged, there couldn't yet be a security assocation between the
peers.

- - - - - 

In Section  8.9 "Authorization-Lifetime AVP"
    
>   A value of zero (0) means that immediate re-auth is necessary by the
>   access device. This is typically used in cases where multiple
>   authentication methods are used, and a successful auth response with
>   this AVP set to one is used to signal that the next authentication

Change "this AVP set to one" to "this AVP set to zero" in the last line.

- - - - - 

In Section 8.10 "Auth-Grace-Period AVP"

>   This AVP MAY be provided by the client as a hint of the maximum
>   lifetime that it is willing to accept. However, the server MAY return
>   a value that is equal to, or smaller, than the one provided by the
>   client.

Remove this paragraph entirely.  This is a duplicate of the last
paragraph of the section 8.9; looks like a cut&paste error.

- - - - - 

In Section 10.2 "Accounting AVP Table"
    
>   Attribute Name                | ACR | ACA |
>   ------------------------------|-----+-----+
>   ...                           | ... | ... |
>   Max-Time-Wait                 | 0+  | 0   |

Remove the obsoleted Max-Time-Wait AVP entry.