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

From: "Marta Morant-Artazkotz (ECE)" <[email-masked]>
Date: Fri, 27 Jul 2001 15:04:32 +0200

Hi Pat,
do not worry about the latency and thanks for your answer. Most of these comments were just editorial ones, things I missed in the ABNF definitios of the commnads. They are not very important while the concepts are clear but, as you say, it is nice to hace some consistency. Just as clarification, see enclosed commands.
Best regards,
Marta

> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Thursday, July 26, 2001 10:11 PM
> To: Marta Morant-Artazkotz (ECE)
> Cc: [email-masked]
> Subject: Re: [AAA-WG]: draft-ietf-aaa-diameter-07.txt first comments
> 
> 
> 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
> 
> On Tue, Jul 24, 2001 at 03:14:11PM +0200, Marta 
> Morant-Artazkotz (ECE) wrote:
> > Hi,
> > - 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.
> 
> 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.
> 
> > 
> > - 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. 
> 
> 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 :(
> 
> > 
> > - 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.
> 
> 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.
> 
> > 
> > - 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.
> 
> 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.

I agree. Because there are some request whose answers should have Session-Id and other that do not, I think  Session-Id AVP should appear as optional in the ABNF definition of the protocol-related error message (a message that could be answer to any message, as I undertand it). I miss it there.

> > - 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.
> 
> 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.

I agree. Because intermediate proxies may change the Result-Code AVP and then insert the Error-Reporting-Host AVP, I think Error-Reporting-Host AVP should appear as optional in the ABNF definition of any answer message. I miss it in the STA and ASA messages.

> Thanks,
> PatC

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 27 Jul 2001 06:57:40 -0700

> I agree. Because there are some request whose answers should have Session-Id and other that do not, I think  Session-Id AVP should appear as optional in the ABNF definition of the protocol-related…

I don't quite understand your point. The messages that do not include the
Session-Id actually do not need it, so adding it as optional would cause
confusion.

> I agree. Because intermediate proxies may change the Result-Code AVP and then insert the Error-Reporting-Host AVP, I think Error-Reporting-Host AVP should appear as optional in the ABNF definition…

Ah, ok then this should be raised in an official issue. In fact, include
all of your editorial changes in a single issue, and submit it. That's less
work for both of us :)

PatC