RE: Issue: Error-Cause Attribute in Disconnect-ACK?

[Bernard Aboba <bernard_aboba@hotmail.com>]

I also noticed another oddity in usage of the Error-Cause Attribute. 
 
It is stated that a CoA-NAK MUST always be sent in response to a CoA-Request including a Service-Type Attribute with value "Authorize Only".  If the CoA-Request can be processed, then sending an Error-Cause Attribute with value 507 (Request Initiated) is required.  However, if the CoA-Request cannot be processed, sending an Error-Cause attribute is optional.  Given that NAS implementations supporting a Service-Type attribute with value "Authorize Only" have to be able to send the Error-Cause Attribute in the event that the Request can be processed, why isn't sending an Error-Cause attribute a SHOULD in the event of an error?  
 


> From: bernard_aboba@hotmail.com
> To: radiusext@ops.ietf.org
> Subject: Issue: Error-Cause Attribute in Disconnect-ACK?
> Date: Tue, 22 May 2007 10:31:40 -0700
> 
> 
> Issue: Error-Cause Attribute in Disconnect-ACK?
> Submitter name: Bernard Aboba
> Submitter email address: aboba@internaut.com
> Date first submitted: May 22, 2007
> Reference: 
> Document: RFC3576bis-05
> Comment type: Technical
> Priority: S
> Section: 3.4
> Rationale/Explanation of issue:
> 
> In the process of editing the attribute table to address Issue 226, I noticed an oddity. 
> 
> RFC 3576 Section 3.1 states the following:
> 
> It is possible that the NAS cannot honor Disconnect-Request or
> CoA-Request messages for some reason. The Error-Cause Attribute
> provides more detail on the cause of the problem. It MAY be
> included within Disconnect-ACK, Disconnect-NAK and CoA-NAK
> messages.
> 
> Why would an Error-Cause Attribute be included in a Disconnect-ACK? It is not allowed in a CoA-ACK, for example. 
> --
> to unsubscribe send a message to radiusext-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>