Subject: [AAA-WG]: Comments and questions on 03

From: "Yolanda Garcia-Serrano (ECE)" <[email-masked]>
Date: Wed, 9 May 2001 17:02:27 +0200

Hi, Pat and others

I have some questions on the base:

Is needed Proxy-Info AVP in MRI, STI, ASI, API ? If yes, what for? I think there is no need to keep any
state for indications, so update of those messages and table in section 16 would be needed.

Section 11.7 Max-Wait-Time AVP (change 'Max-Time-Wait' to Max-Wait-Time in 16.1)
This AVP does not appear in any message. I think it should be 0-1 at least in DRI, and maybe in DSI,
DWR, in order to inform the other peer about how your Diameter server is going to behave regarding
Responses. 
Otherwise, it should not be an AVP but a Diameter configurable parameters? Anyway, I think its good to 
givethe possibility of include it in some messages.

Section 10.1: {Destination-Realm] is missing in MRI

Section 11.9.1: *[Route-Record] is missing in STI.

Section 12.1 Realm-based Message Routing
2 first paragraphs still refers to NAIs. I think any reference to User-Name or NAI related to the 
routing mechanism is in the spec since the original routing mechanism was there, and it  should be 
removed from the spec, as we have now Destination-Realm for that, and there is no need to access
the realm part of User-Name AVP to route a message.

Section 12.1.1 I guess Extension Id on the Real-Based Routing Table should be updated to Acc-Extension-Id
and Auth-Extension-Id

Section 14.3 and 14.4: I don't understand the purpose of these ASI and API messages.
I guess only Diameter clients (the ones generating accounting) could sent this msg, not any Diameter
Node in general, right? Then, who they send the ASI to? is per peer, or to the corresponding Accounting servers?
If it is destined to a accounting server, {Destination-FQDN} is missing.

In case ASI with Accounting-State=DISABLED is received by an Accounting Server, what should it do?

Exactly when a Diameter client MUST sent ASI with Accounting-State=ENABLED? After a reboot, after
a previously sent DISABLED one, when previous accounting sessions were opened but it is not possible to
sent any more accounting info ? If the node is about to be taken out, even it can not grant the service.

In case ASI ENABLED is received by an Accounting server, what should it do?

API is sent by an accounting Diameter server to who? To the peers that have active accounting sessions in the
accounting server? Then, if it is a message destined to concrete nodes, is not per session and <Session-Id> should
be removed? Sending an API per session-Id could overload the server and the network.
It must state only one or the other: {Destination-FQDN}  vs [Destination-FQDN], but not both
What does the text about the warning in roaming networks mean? 
In case an accounting server wants to synchronize with any Diameter node generating accounting,
it can know which are the one having active accounting sessions, so Destination-FQDN is known, and it is not
the purpose of the message to be sent to _ANY peer, right?

And some other small details IMHO to be updated :

Table of Contents: chapter 6.1 is missing

Section 1.3
	"Downstream Server", the explanation refers to upstream, I think it should be downstream
	"Upstream Server", the explanation refers to downstream, I think it should be upstream
	"Session Record" -> I guess it should be "Accounting Record", as it has been modified
in 13.5.

12.5.  Instead of DIAMETER_NO_END_2_END_SECURITY, I think it has been agreed on a previous
mail DIAMETER_END_2_END_SECURITY

12.6. The text applies to both statefull and stateless proxies, so remove "Stateful" on first line ?

13.0 "authorization-server" should be changed by "server"

14.1 Remove CMS-Data in ACR and ACA commands

Table 16.2: API and ASI columns are interchanged, aren't they?

In NASREQ 03, section 11.1, columns AAA and AAR are interchanged ?
 Same for 11.2.1 and 11.2.2, API and ASI columns are also interchanged?

As always, thanks a lot for your attention
Best Regards
	/Yolanda

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 9 May 2001 14:33:11 -0700

> state for indications, so update of those messages and table in section 16 would be needed.

You are correct, but let's wait until we find the correct fix for the
MRI. If it is as I suspect, MRI will require a Proxy-Info AVP. The
others can be eliminated, I think.

> givethe possibility of include it in some messages.

Right. I think that it SHOULD be present in the STR, and ACR messages, at 
a minimum. As far as DWR, I am not sure that it really makes a whole lot of
sense since this message isn't proxyable.

> Section 10.1: {Destination-Realm] is missing in MRI

The AVP is present in -03, but as [optional]. Are you stating that it
should be {mandatory}?

> Section 11.9.1: *[Route-Record] is missing in STI.

Correct, but the routes added MUST NOT be in the STR. I will add text
to make sure this is clear.

> the realm part of User-Name AVP to route a message.

Wow, how did I miss that one. The two new paragraphs read:

"Diameter request, query and indication message routing is done via realms.
A Diameter entity creating a message that is proxyable MUST include the
realm in the Destination-Realm AVP. The realm MAY be retrieved from the
User-Name AVP, which is in the form of a Network Access Identifier (NAI).
The realm portion of the NAI is inserted in the Destination-Realm AVP.

Diameter servers have a list of locally supported realms, and MAY have a
list of externally supported realms. When a request, query or indication
message is received that includes a realm that is not locally supported,
the message is proxied to the Diameter entity configured in the "route"
table (see section 12.1.1)."

> Section 12.1.1 I guess Extension Id on the Real-Based Routing Table should be updated to Acc-Extension-Id

yes it now reads:

"- Extension Identifier. It is possible for a routing entry to have a different
destination based on the Auth-Extension-Id (for accounting messages) or
Acct-Extension-Id (for non-accounting messages) of the message. This field
is typically used as a secondary key field in routing table lookups."

> In case ASI ENABLED is received by an Accounting server, what should it do?

All good questions, and I wonder about it's usefulness as well. Perhaps
people that use this functionality in RADIUS could help me out?

To answer the routing of the message, though. I believe that this message
ONLY makes it to the first hop proxy. It is not proxyable.

> What does the text about the warning in roaming networks mean? 

Because I think this message stinks, and it doesn't scale in roaming networks.
This is my attempt to warn people NOT to use this message, but it appears
that there are people that find this useful.

Again, could those people please speak up?

> the purpose of the message to be sent to _ANY peer, right?

Right, but would a server poll ALL access devices in the 'net? That's the
point. So the Destination-FQDN is known, and MUST be present (according to
the ABNF).

> Table of Contents: chapter 6.1 is missing

thanks.

> 	"Upstream Server", the explanation refers to downstream, I think it should be upstream

These were changed because the text in the draft uses this particular 
direction when refering to the terms.

> 	"Session Record" -> I guess it should be "Accounting Record", as it has been modified

yes.
> mail DIAMETER_END_2_END_SECURITY

yes, I changed the code, but not the text :(

> 12.6. The text applies to both statefull and stateless proxies, so remove "Stateful" on first line ?

yes.

> 13.0 "authorization-server" should be changed by "server"

right.
> 14.1 Remove CMS-Data in ACR and ACA commands

correct.

> Table 16.2: API and ASI columns are interchanged, aren't they?

OOps

>  Same for 11.2.1 and 11.2.2, API and ASI columns are also interchanged?

correct.

Thanks for your comments. Very helpful.

PatC