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

From: "Yolanda Garcia-Serrano (ECE)" <[email-masked]>
Date: Fri, 11 May 2001 09:55:44 +0200

Hi, Pat
See interspaced comments:

Thanks
	/YolandaG

> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Wednesday, May 09, 2001 11:33 PM
> To: Yolanda Garcia-Serrano (ECE)
> Cc: [email-masked]'; [email-masked]';
> Subject: [AAA-WG]: Re: Comments and questions on 03
> 
> On Wed, May 09, 2001 at 05:02:27PM +0200, Yolanda 
> Garcia-Serrano (ECE) wrote:

> > 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}?
YES

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

O.K. But maybe it should be mandatory (instead of 'possible' -> MUST) to support 
routing based on Acc-Extension-Id, in order to support routing of accounting messages.

In I-D 04-alpha 1:
- 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.

I guess it should be 'on the Auth-Extension-Id (for non-accounting
messages) or Acct-Extension-Id (for accounting messages)'.

> > 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?
> 
> All good questions, and I wonder about it's usefulness as 
> well. Perhaps
> people that use this functionality in RADIUS could help me out?
Then, waiting for responses about that. Maybe Jari can help us.

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

Then this needs to be clarified in the text. But in case in only to
the first hop I do not understand at all the utility of it.

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

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

Jari?

> > 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?
> 
> 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).
Then only {Destination-FQDN} should state in the ABNF, and remove
[Destination-FQDN]

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 11 May 2001 06:46:05 -0700

> >The AVP is present in -03, but as [optional]. Are you stating that it

well, MRI is gone, so we don't have to worry about this one :)

> messages) or Acct-Extension-Id (for accounting messages)'.

My general idea was to allow these extensions to be hard coded into
the routing table. I believe that you are referring to auto config
via the capabilities exchange, right?

If so, then I agree that the text is confusing and needs clarification.

> the first hop I do not understand at all the utility of it.

Where would a node proxy the message to??? How would it know which home
servers it should proxy it to?

So, perhaps it can "recreate" the message and forward a copy to each home
server that it believes cares, but the NAS isn't going to send multiple
copies to its first hop server, right?

> Then only {Destination-FQDN} should state in the ABNF, and remove

Ah, *now* I understand the original comment. The AVP was present twice
in the ABNF. I've fixed it.

Thanks,

PatC