Subject: [AAA-WG]: draft-ietf-aaa-diameter-07.txt first comments

From: "Marta Morant-Artazkotz (ECE)" <[email-masked]>
Date: Tue, 24 Jul 2001 15:14:11 +0200

Hi,
I need some clarification regarding some points in the last Diameter Base Protocol draft, version -07. These are my first comments:

- First of all, as a general comment, IMHO any reference to the "Domain Routing Table" should be change to "Realm Routing Table" and any reference to "domain" while talking about the key of this table should be changed to "realm". Those concepts are piggybacked, as the NAI rfc2486 states: "administration of the NAI realm namespace will piggyback on the administration of the DNS namespace", but they are not neccessary identical.

- Status attribute of a Diameter peer
This attribute of a Diameter peer, an entry in the Peer Table, is described in section 2.6 to have the values listed in section 5.6 where the peer state machine is described. According to the description of peer connections made in sectio 5.1, I miss the "suspicious" state to describe a connection that might be broken but on which failover procedures has not been applied yet. IMHO, the values of the status in the Peer Control Block described section 5.5.3 should be added in the possible state values in the peer state machine. Per peer, there should be an entry in a table as described in 2.6, adding the state values in 5.5.3 to status and the flag and the related pending request queue. 

- Oigin-State-Id AVP
In 8.16, page 94, it is stated that this AVP may be includeded in any Diameter message. IMHO, that means that [ Origin-State-Id ] should appear in all ABNF Diameter message definitions. In this draft, it does not appear in the Device Watchdog messages, nor *[ AVP ], perhaps attempting to make those messages simpler.

- Session-Id AVP
In 7.2, page 79, there is the ABNF definition of the protocol-related error answer message with the line < Session-Id >. For request of the type per peer, non proxiable messages (the others are Capabilities Exchange and Device Watchdog messages), the aswer must not include the Session-Id AVP, must it? The anwer must contain Session-Id AVP only if it was included in the request, as it is satated in 5.2, page 44: "if the Session-Id is present in the request, it MUST be included in the answer". IMHO, this AVP should be left optional in the ABNF definition.

- Error-Reporting-Host AVP,
In 7.1, page 74, it is stated that "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. IMHO, that means that this AVP should be included in any answer message. I miss it in the STA and ASA ABNF definitions in the base protocol draft.

I will keep sending doubts as I collect them.
Regards,
Marta

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 26 Jul 2001 13:10:35 -0700

Sorry for the latency. See my response below. For any outstanding issues,
please file an official issue and I'll have the changes taken care of in
the next release.

PatC

> - First of all, as a general comment, IMHO any reference to the "Domain Routing Table" should be change to "Realm Routing Table" and any reference to "domain" while talking about the key of this ta…

ok, consistency would be a good thing, and the use of realm instead of domain
can be made, assuming no one objects. This is really simply an editorial 
issue, so I don't expect any push back.

> This attribute of a Diameter peer, an entry in the Peer Table, is described in section 2.6 to have the values listed in section 5.6 where the peer state machine is described. According to the descr…

Yes, the values should be added, but as a separate field. We don't want to mix
the state machine states with the peer status. I'll have to come up with
some clever name :(

> In 8.16, page 94, it is stated that this AVP may be includeded in any Diameter message. IMHO, that means that [ Origin-State-Id ] should appear in all ABNF Diameter message definitions. In this dra…

The Device-Watchdog messages doesn't need this AVP, since a reboot will cause
a loss of the transport connection, which will cause a subsequent reconnect,
capabilities exchange, etc. It is useful in situations where there is a peer
between two communicating nodes.

> In 7.2, page 79, there is the ABNF definition of the protocol-related error answer message with the line < Session-Id >. For request of the type per peer, non proxiable messages (the others are Cap…

Well, it simply means that if a command requires it in the request, then it 
MUST be present in the response. The non-proxiable messages you refer to
above don't require the Session-Id because they aren't "session" related
messages, but rather messages that are used for connection management.

> In 7.1, page 74, it is stated that "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…

hmmmm... not at all. It means that if an intermediate proxy wants to
change the Result-Code AVP (because of a locally generated auth failure),
then it MUST inserts its identity in the Error-Reporting-Host AVP. This allows
the access device and/or server to know who caused the failure.

Thanks,

PatC