[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Issue: Error-Cause Attribute in Disconnect-ACK?
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: firstname.lastname@example.org
> To: email@example.com
> 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: firstname.lastname@example.org
> Date first submitted: May 22, 2007
> 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
> 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 email@example.com with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>