Subject: DIAMETER Base Protocol (Alpha 1)" draft / Minor Comments

From: "Bob Kopacz" <[email-masked]>
Date: Tue, 16 Jan 2001 11:27:48 -0500

Hi Pat,

Here's some further minor comments on the "DIAMETER Base
Protocol (Alpha 1)" draft.

Section 2.2.4.1 Example AVP with a Grouped value type
--------------------------------------------------------

This section gives an example of a Grouped-AVP which includes
the User-Name AVP and the Host-IP-Address AVP.  Since the
Host-IP-Address AVP is only present in the DRI packet
(according to section 2.5.4 Host-IP-Address AVP), and since
User-Name cannot be present in a DRI, maybe the example should
be revamped to a non-conflicting group of AVPs.

Section 2.3.1 "Host-Name AVP"
-----------------------------

The Host-Name AVP defines the value as being the "sender's"
identity, and later as the identity of the "originator" of the
Diameter message.

One could, like I did, interpret "sender" and "originator" as
the peer who sent this packet, treating Host-Name AVP as a
"Peer-Name" AVP, where each server in a proxy chain replaced the
AVP value with his name.

But the Host-Name seems to identify the original sender and
not necessarily the immediate sender which may be a proxy.  This
might be stated explicitly, else a proxy implementation may
replace the Host-Name AVP from a received packet with a
Host-Name AVP identifying himself, before forwarding the packet
to the next hop Diameter server.

Maybe some explicit clarifying text could be added, e.g:

    "This AVP identifies the endpoint which originated the 
    Diameter message, i.e. the NAS, home server, or broker.  
    Proxy servers do not modify this AVP".

3.1  Session-Id AVP
-------------------

An email (not mine) from a while back asked some questions about
the Session-ID AVP, i.e. "How is this encoded? All ASCII? A mix
of null-terminated strings and numbers in network byte order?
Something else?"

I think the answer was all ASCII, in network byte order, but
this hasn't made its way into the document.

Section 8.4
------------

Section 8.4 is inconsistent with section 5.2.  Section 8.4
states: 

   As defined in Section 5.2, the Result Code AVP (AVP Code 268) defines
   the values 0-8. ...

The values defined in section 5.2 are no longer 0-8.

Minor Typos/etc:
----------------

Section 6.1  Realm-Based Message Routing, 2nd paragragh:

<<<<<<<<<<<<<< 
   DIAMETER message, by using a DNIS or ANY to Routing-Realm association
   DIAMETER message, by using a DNIS or ANI to Routing-Realm association

Section  6.2.1  Proxy and Redirect Server handling of requests
 
<<<<<<<<<<<<<<
        contains the identities of the server the message must be
        contains the identities of the server(s) the message must be

6.3  Redirect Server, 2nd paragraph:
 
<<<<<<<<<<<<<<
   DIAMETER server that could satisfy the message. The home servers are
   encoded in one or more Redirect-Host-Address. If the Redirect-Host-
   DIAMETER servers that could satisfy the message. The home servers are
   encoded in one or more Redirect-Host-Address AVPs. If the Redirect-Host-

6.4  Proxy Server, 4th paragraph: 
 
<<<<<<< at Date + 1307 <<<<<<< [\email\draft-~2.txt + 1310]
   intensive purposes, stateful servers terminate an upstream "session",
>>>>>>> at Date + 1307 >>>>>>> [\ietf\dr03c4~1.txt + 1310]
   intents and purposes, stateful servers terminate an upstream "session",

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 19 Jan 2001 13:12:58 -0800 (PST)

Bob,

Thanks for taking the time to review the I-D and providing great feedback. My
responses are inline below.

PatC

> Section 2.2.4.1 Example AVP with a Grouped value type

Yes, good catch. Eliminating the User-Name AVP fixes the problem.

> Section 2.3.1 "Host-Name AVP"

Fixed (and thanks for the text!)

> 3.1  Session-Id AVP

check, now specifies UTF-8 encoding.

> Section 8.4

wow... can't believe I missed that one.

> Minor Typos/etc:
again, thanks for these as well.