Subject: [AAA-WG]: MRI Fix posted for preview

From: Pat Calhoun <[email-masked]>
Date: Thu, 10 May 2001 17:55:12 -0700

All,

Given that the fix to remove the MRI has received alot of
support, I have made the change. If the WG decides that this
is the wrong approach, I can back it out, but a fix is
necessary, and there haven't been any alternatives proposed.

Given that removing the MRI involved quite a bit of text,
I am making an alpha version of the base specification
available on the diameter web site. It cannot be found
on the actual main web page, but can be retrieved at
http://www.diameter.org/draft-ietf-aaa-diameter-04-alpha1.txt.

I would really appreciate any comments. Although I have
checked the document, it can always use an extra pair of
eyes :)

Thanks,

PatC

---

From: Paul Funk <[email-masked]>
Date: Fri, 11 May 2001 11:32:13 -0400

Pat,

The 04-alpha1 draft eliminates the confusion associated with 
the erstwhile EIR bits. One of the big benefits is that a proxy 
can determine exactly how to handle a message by examining the 
FAIR bits, without having to understand the command code.

Plus, Query/Response were redundant and we're well rid of them. 

I have just a couple points:

Device-Status-Ind handling
--------------------------
If a proxy receives a DSI response, it may try to rescue the 
request by proxying (with the same Identifier) to other servers. 
But if all else fails, it must return a DSI to the client from 
whence it came.

My quibble is that it must replace Origin-FQDN/Realm with its 
own identity. But why should the proxy take the rap for some 
home server that doesn't understand some command code? You 
wouldn't want the client to think that such a command code 
should not be sent via that proxy. By obfuscating the source 
of the error you lose valuable information.

I think the proxy should be free to treat the DSI as an ordinary 
response and just return it as is to the peer from which it 
received the request. If it wants to alter the DSI-Event or other 
AVPs to provide better information to that peer, only then should 
it be required to replace Origin-FQDN/Realm; but not if it is 
merely the messenger of a failure not of its own making.

We shouldn't get carried away by the notion that DSI is a 
hop-by-hop message. I think the philosophy should be that 
it may be intercepted at any hop, retried, revised, whatever. 
But it may also be forwarded upstream unmodified just as 
an Answer would.

Failed Indications
------------------
Calling DSI an "Indication" and setting both I and F bits is 
misleading. Let's rename "Device-Status-Ind" to 
"Device-Status-Failure" and set only the F bit. There is a 
fundamental difference between an originated Indication such as 
STI or Accounting-Status-Ind and a failure indication such as 
DSI. 

For example, the originator of an STI manufactures its own 
Identifier, and expects its response to be proxied. But a DSI 
echoes the Identifier of the request, and is returned to the 
issuer of the request. A proxy works in fundamentally different 
ways in the request and response directions: in requests, it 
makes routing decisions based on NAI or Destination-Realm/FQDN; 
in responses, it uses Proxy-Info or its own saved state to return 
the response in the reverse direction.

Paul

>checked the document, it can always use an extra pair of

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 11 May 2001 12:33:35 -0700

> Device-Status-Ind handling

Ok, I can buy your argument. In fact, I thought a distinction was
required to differentiate the MRI from the DSI. However, looking
at the list of DSI-Events, and the fact that responding to requests
(or indications) doesn't require support of the extension, I would
argue that all DSI-Events should either:
1. be folded into the Result-Code AVP, or
2. Kept as a separate AVP, but included in normal responses.

My biggest issue with the removal of the DSI, is interoperability. If
some new extension is developed later on, and some new "events" are
created, proxies that do not support the extension wouldn't know how to
handle the event notification.

Comments?

> Failed Indications

I have added text in section 3.3.2 and in the individual definition
of the commands. I have added text to cover this.

PatC