Subject: [AAA-WG]: Issue 79: Error handling editorial changes

From: Pat Calhoun <[email-masked]>
Date: Tue, 19 Jun 2001 07:08:01 -0700

All,

I tried to address some of these in -06, but was unable to in some cases. Here are
my comments on this issue:

> - In 9.0, in the result-code AVPs that require Failed-AVPs, need a 
> clarification whether this is done only by the home server, or by any 
> proxy/relay on the way 

done

> - In 9.0, what about errors regarding invalid length (packet or AVP)? 
> Especially for AVPs, since it will be difficult to include a correctly 
> formatted AVP if length is wrong anyway? 

done

> - In 5.3.2/9.1, DIAMETER_REDIRECT_INDICATION is not defined. 

done

> - clarify the difference between UNABLE_TO_DELIVER and NOT_SERVED? i.e. in 
> which case is which sent? -- "I know the domain, but cannot reach any 
> servers" vs "I don't know the domain". 

done

> - any specific messages for DNS errors (transient such as timeouts, or 
> permanent such as NXDOMAIN)? -- I'd prefer we not have any, buy if you feel 
> it is necessary, please propose some text. 

don't think it is necessary, so let's agree to drop it.

> - the difference between AUTHORIZATION_REJECTED and AUTHORIZATION_FAILED 
> is, er, unclear. 

done. AUTHORIZATION_FAILED was renamed to:

      DIAMETER_RESOURCES_EXCEEDED        5007
         A request was received that cannot be authorized because the
         user has already expended allowed resources. An example of this
         error condition is a user that is restricted to one dial-up PPP
         port, attempts to establish a second PPP connection.

> - NO_COMMON_APPLICATION and UNSUPPORTED_VERSION would be better off in 
> Protocol errors? -- except that protocol errors MUST only be used in MRA... 
> see the problem :) 

hmmmm..... well we have three options:
1. leave it as-is. 
2. Move it to protocol errors, and a CER that fails would cause an MRA
3. Eliminate MRA, and just use error classes (as I've mentioned numerous
   times, this is my preferred approach!)

> - protocol errors should be usable in any non-'P' messages 

this fails my parser check.... please try again :)

> - missing errors for message or AVP length errors 

done.

> - missing errors for unknown not-proxiable commands? 

how is this any different from DIAMETER_COMMAND_UNSUPPORTED?

> - missing errors for incorrectly set proxiable/not-proxiable flag? 

ok, I suppose this could be added in -07

> - missing errors for unknown application 

hmmm..... this used to exist :( it will be added in -07

> - classification of transient/permanent/protocol errors to review 

no comprendo, as a wise man once said :)

PatC