Subject: [AAA-WG]: draft-ietf-aaa-diameter-01 / minor corrections

From: "Bob Kopacz" <[email-masked]>
Date: Wed, 28 Mar 2001 21:33:41 -0500

Hi Pat,

Here's some suggested minor corrections.

Here's the Legend for the line prefixes:

 ">" is a existing line from the draft.
 "-" is a existing line from the draft which should be deleted.
 "+" is a proposed line to be added.
 ">  [...]" means two or more existing lines
 "!" is a comment about the preceding line.

3.0 Diameter Header
===================

1. The last sentence of the Hop-by-Hop-Identifier description
says:

  "Diameter servers should consider a message to be unique by
  examining the source address, source port, Session-Id and
  Identifier field of the message"

I think this sentence should be deleted.  The last sentence of the
End-to-End-Identifier description is the correct duplicate message
check.

2. Grammar: The next-to-last sentence of the Hop-by-Hop-Identifier 
description begins "For The..."

3. In the descriptions of hop-by-hop and end-to-end identifier,
the general term "identifier" is used without the "hop-by-hop"
or "end-to-end" qualifier, though I guess by context it is clear
which of the two identifiers is being referred to.
 
3.1  Command Codes
==================

>    [...]
> 
>       qual             = [min] "*" [max]
>                           ; See ABNF conventions, RFC 2234 section 6.6.
>                           ; The absence of any qualifiers implies that one
>                           ; and only one such AVP MUST be present.
>                           ;
>                           ; NOTE:  "[" and "]" have a different meaning
>                           ; than in ABNF (see the optional rule, above).
-                           ; These braces cannot be used to express an
+                           ; These braces cannot be used to express
>                           ; optional fixed rules (such as an optional
>                           ; ICV at the end.)  To do this, the convention
>                            ; is '0*1fixed'.
>  

4.5  Diameter Base Protocol AVPs
=================================

Maybe alphabetize the list of AVPs

6.0  Capabilities Exchange
==========================

>    [...]
> 
>    With the exception of the Device-Reboot-Ind message, a message of
>    type Request, Query or Indication that includes the Extension-Id AVP,
+    or a message with an extension-specific command code,
-    MAY only be forwarded to a host that has explicitely advertised
+    MAY only be forwarded to a host that has explicitly advertised
>    support for the extension (or has advertised the Wildcard Extension).
> 
 
6.1.1  Vendor-Id AVP
====================

>    [...]
> 
>    This MAY be used in order to know which vendor specific attributes
+    and vendor specific commands 
>    may be sent to the peer. It is also envisioned that the combination
>    of the Vendor-Name and the Firmware-Revision (section 6.1.2) AVPs MAY
>    provide very useful debugging information.
>  
 
9.1  Device-Status-Ind
======================

>    [...]
> 
>    When a Diameter node issues a DSI message downstream, the target peer
>    MUST attempt to rectify the problem, or issue a similar message
>    downstream. The Device-Status-Ind message MUST NOT be proxied, but
-    MAY be forwarded, as long as the Origin-FQDN AVP is replaced to
-    include the local node's identity.
+    MAY be forwarded, as long as the Origin-FQDN and Origin-Realm
+    AVPs are replaced to include the local node's identity.
 
10.1.1  Failed-AVP AVP
======================

>    A Diameter message MAY contain one or more Failed-AVP AVPs, each
>    containing a complete AVP that could not be processed successfully.
>    The possible reasons for this AVP are the presence of an improperly
>    constructed AVP, an unsupported or unrecognized AVP, an invalid AVP
-    value; or the omission of a required AVP.
+    value, the omission of a required AVP, the presence of an 
+    explicitly excluded AVP (see table 14.0), or the presence of two
+    or more occurances of an AVP which table 14.0 restricts to 0, 1,
+    or 0-1 occurances..

11.7.2  Session-Termination-Request
===================================

>    [...]
> 
>       <Session-Termination-Request>  ::= < Diameter Header: 275 >
>                                          < Session-Id >
>                                          { Origin-FQDN }
>                                          { Origin-Realm }
>                                          { User-Name }
>                                          { Destination-Realm }
+                                          { Destination-FQDN }
>                                        * [ AVP ]
>                                        * [ Proxy-State ]
>                                        * [ Route-Record ]
>                                       0*1< Integrity-Check-Value >

15.2  Command Code Values
=========================

>    As defined in section 3.0, the Command Code field has an associated
>    value maintained by IANA. Values 0-255 are reserved for backward
-    RADIUS compatibility, and values 257, 259, 274, 275 and 276 are
+    RADIUS compatibility, and values 257,259,274,275,276,280,281, and 282 are
>    defined in this specification. The remaining values are available for
>    assignment via Designated Expert [12].
 
17.0  Diameter protocol related configurable parameters

>    [...]
> 
>       Maximum Age of an outstanding message
>          Messages older than the maximum age SHOULD be rejected, as
>          described in section 13.3.  The recommended value is 4 seconds.

! Since the Timestamp AVP is part of ICV, and ICV is going away,
! does this configuration parameter go away, along with the references
! to time synchronization?