Subject: [AAA-WG]: Issue #6: DSI

From: Pat Calhoun <[email-masked]>
Date: Tue, 15 May 2001 08:27:47 -0700

Paul opened another issue in regards to the DSI, and the fact that
the DSI really shouldn't claim to be a hop-by-hop error condition,
and should be end-to-end, allowing each proxy to take special action
on the error, if possible.

See http://www.merit.edu/mail.archives/aaa-wg/2001-05/msg00183.html to
see Paul's original e-mail.

First, I would like to examine each error condition, and provide my
thoughts:

DIAMETER_STILL_WORKING
	This DSI-Event really doesn't make a whole lot of sense. It
	is used to inform a peer that a request is still pending, and
	no response is available in the requested time, but the
	request is still being processed.

	I would claim that if a request cannot be satisfied in the
	requested time, return an error and be done with it. This
	error condition has the disadvantage of requiring that two
	messages (DSI and answer) will be returned with the same
	hop-by-hop and end-to-end ids, requiring special code in
	the Diameter base to handle.

	suggestion: move this error to Result-Code AVP, and make it
	such that the request is being abandoned.

DIAMETER_REDIRECT_INDICATION
	This event is a hop-by-hop event, and shouldn't be 
	combined with the Result-Code AVP.

DIAMETER_UNSUPPORTED_TRANSFORM
	This error is end-to-end, and really belongs in the Result-Code
	AVP. 

DIAMETER_INVALID_ROUTE_RECORD
	This error is used to inform the peer that there is a routing
	error. This most likely belongs in the Result-Code AVP since
	the protocol doesn't have a way to self correct routing problems.
	In fact, Diameter routing is static.

DIAMETER_COMMAND_UNSUPPORTED
	This command could be moved to the Result-Code, and a proxy
	*could* attempt to send the message to another peer, if it
	still has time (see Max-Wait-Time AVP). A proxy MAY decide that
	it isn't willing to send to another proxy, and abandon the
	request.

DIAMETER_UNABLE_TO_DELIVER
	Same conditions as DIAMETER_COMMAND_UNSUPPORTED.

DIAMETER_REALM_NOT_SERVED
	Same conditions as DIAMETER_COMMAND_UNSUPPORTED.

DIAMETER_TOO_BUSY
	Same conditions as DIAMETER_COMMAND_UNSUPPORTED.

DIAMETER_CANNOT_PROCESS_IN_TIME
	I dont' see the difference between this event, and the first one
	in this list. They could be combined.

DIAMETER_NO_COMMON_EXTENSION
	This one really is a hop-by-hop error, and can only occur as a
	result of DRIs being exchanged. However, it makes sense to move
	this one to the Result-Code, and simply have the DRI with the
	'F' bit set, indicating an Indication Failure. So it really
	doesn't need to be a DSI-Event.

DIAMETER_UNSUPPORTED_VERSION
	See DIAMETER_NO_COMMON_EXTENSION.

[end of DSI-Events]

So, of the above events, the only one that really does have some hop-by-hop
implications is the redirect event. I believe that all other errors could
be easily moved to the Result-Code AVP.

Alternatives
------------

Move all of the relevant DSI-Events to the Result-Code, fix up the text
in the base protocol to reflect this.

As far as indications, we have the following options:
1. Allow proxies to pretty much ignore the Result-Code AVP for most errors
   above, and replace the DSI with the Redirect-Indication message. I am 
   not sure this is a good idea, since I would prefer that proxies handle
   the Result-Code AVP properly, and take whatever action is necessary.
2. All of the errors in the Result-Code that require proxy action have its
   own class of errors. This was done in the base spec some time back, but
   the DSI was introduced at the interim meeting, and these messages moved
   to the DSI.
3. Move the errors into the Result-Code, not in a new class, and require
   that proxies know when they need to take special action.
4. Leave it as is, but not require that the Origin-FQDN be replaced,
   since this was Paul's original comment.

PatC