Subject: [AAA-WG]: A proposal for the elimination of MRI

From: Pat Calhoun <[email-masked]>
Date: Fri, 4 May 2001 09:19:55 -0700

All,

Following an e-mail by Paul Funk a few days ago, it is clear that the MRI
message can be problematic (see the earlier message for details). I have
been thinking about this for a couple of days now, and have come to the
conclusion that the MRI message can be completely eliminated. This e-mail
contains the necessary justifications.

Currently, the base draft contains four error conditions that cause an MRI.
They are:

1. Poorly formatted message. 

	I would argue that a poorly formatted message is really a per-hop
	problem, since the first hop would recognize that the message is
	malformed, and would return an error to the originator of the
	message. So this error condition could be handled by the DSI.

2. Unknown command code.

	This error occurs when a proxy receives the message, but has no
	servers that supports the extension in the home domain. The
	initial reason why the MRI was used, instead of the natural 
	request's answer, was that the proxy may not recognize the
	request, and wouldn't know what to set the command code to.

	However, in -03, it is now mandatory that servers support
	all extensions, so it is now possible for the proxy to
	simply return the natural answer with an error condition stating
	that the message couldn't be delivered. 

	I therefore believe that this use of the MRI is no longer needed.

3. AVP marked mandatory is unsupported.

	This error can occur in two directions; towards the home domain
	(request) and towards the NAS (response) [note, of course for
	server initiated messages, this would be inversed, but I am just
	using this terminology for clarity].

	If a proxy had received a request, and it contained an unrecognized
	AVP with the 'M' bit set, it would have to return an error. Again,
	since servers must support all extensions, the proxy can now
	return the natural answer with the Result-Code AVP set to the
	correct value.

	If a proxy had received an answer, and it contained the same
	error, the proxy would have to overwrite the Result-Code AVP
	with the local error. This means that the Result-Code AVP MAY
	appear more than once in a message. I would also prefer to
	see the Result-Code combined with the Error-Reporting-FQDN AVP.
	Perhaps this is needed as a Grouped AVP?

	So now a NAS would have to look at more than one possible Result-
	Code AVP, and if one contained an error, it would have to
	reject the answer.

	Now a new problem presents itself. How does the home server know
	that the answer was rejected? We can do one of two things:

	1. Introduce a new -Ind message that is used to inform the
	   home server that an answer was bad, and therefore ignored.
	   This is hard, and has the same issues as the MRI one that
	   were discussed on the list.

	2. Have the NAS issue an STR, with a Termination-Cause. This
	   seems to be the best approach.

4. An AVP is received with an unknown or illegal value

	I would argue that this error is VERY similar to case #3, and
	should be handled the same way.

So as you can see, now that the Diameter protocol has evolved, the need for
the MRI isn't there anymore. So I would propose that we make the necessary
changes described above, and eliminate the command code.

Thoughts?

PatC