Subject: [AAA-WG]: questions on the Diameter base protocol

From: Yiwen Jiang <[email-masked]>
Date: Thu, 26 Apr 2001 17:17:22 -0400

Hi Pat,

Sorry to bother you, but I was reading through the -02 I-D, and notice the
following... I don't think these are mentioned in the mails that have been
floating around, but I could be wrong..

- Section 10.0 (pg40) End-to-End Error Signaling lists five error conditions
in detail, but the first paragraph under 10.0 talks about having six
different types of error conditions. Is this a counting error, or is there
actually one more error that is not listed?
- Section 10.1.1 (pg42), MRI definition, should [Failed-AVP] have a '*' in
its front? Since in the second paragraph, it says there can be more than one
Failed-AVP AVPs.
- Section 11.2 (pg48), last paragraph says that session Id is done by the
client in most of the cases, but also said that "the Session-Id MUST be
globally unique at any given time" (3rd paragraph, same section). But there
can be more than one client requesting session connections at the same time,
right? If so, how can the clients guarantee the uniqueness of the session
id? Is there any subsequent session-id selection exchange happening once the
server discovers a duplicated session id suggested by the client?

Another stupid question I have, is regarding the peer connection
establishment: What if peer B receives a DRI message from peer A which does
not specify any extensions that are supported by peer B? (For example, say
peer A supports only NASREQ extension, and B supports only Mobile-IP
extension.) Does peer B send a MRI message back to peer A? If so, it is not
listed under section 10.1 for MRI descriptions (as far as I can see) What is
the correct behaviour for this situation, and where would I find it
described in the I-D? 

Thank you very much for your time and clarification...

Cheers,
Yiwen
---
Yiwen Jiang
Mobile IP Networking
Email: [email-masked]
Phone: (613)271-7710

Telecom Innovation Centre
505 March Road
Kanata, Ontario, Canada
K2K 2M5

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 27 Apr 2001 07:15:24 -0700

> floating around, but I could be wrong..

No bother at all. This is what I am here for (oh, and do some occasional work
for Sun :)

> actually one more error that is not listed?

I really need to go through the I-D, and get rid of all counters. This has 
bit me in the backside a few times. I will have this fixed up in -03.

> its front? Since in the second paragraph, it says there can be more than one

Yes.

> server discovers a duplicated session id suggested by the client?

If a session-id is constructed the way that the base protocol suggests, then
duplicate session identifiers would not occur. Perhaps I am mis-interpreting
your question, so if I haven't answered it, please try again.

> the correct behaviour for this situation, and where would I find it

As -02 stands, it *could* be because Peer A is simply asking for accounting
messages, which do not have an extension. However, if the proposal that I
sent out yesterday goes through, which introduced a new AVP in the
capabilities exchange, specifically for accounting, then this error could
occur. Perhaps then some text would be required in the base spec that
states that the expected behavior should be.

> Thank you very much for your time and clarification...

Not a problem. Thanks for the comments.

PatC