RE: [Technical Errata Reported] RFC5176 (2012)

["Bernard Aboba" <bernard_aboba@hotmail.com>]

The intent in writing that sentence was just to clarify use of Error-Cause
in CoA and Disconnect messages (the topic of RFC 5176).   So the intent was
not to update RFC 3579, or somehow imply that previous usages were
deprecated.  As you say, Error-Cause can be included in other messages as
well. 

Has there been confusion on this issue in the field?

-----Original Message-----
From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] 
Sent: Monday, January 25, 2010 7:43 PM
To: mchiba@cisco.com; gdommety@cisco.com; meklund@cisco.com;
david@mitton.com; bernarda@microsoft.com; dromasca@avaya.com;
rbonica@juniper.net; d.b.nelson@comcast.net; Bernard_Aboba@hotmail.com
Cc: avi@bridgewatersystems.com; radiusext@ops.ietf.org;
rfc-editor@rfc-editor.org
Subject: [Technical Errata Reported] RFC5176 (2012)


The following errata report has been submitted for RFC5176, "Dynamic
Authorization Extensions to Remote Authentication Dial In User Service
(RADIUS)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5176&eid=2012

--------------------------------------
Type: Technical
Reported by: Avi Lior <avi@bridgewatersystems.com>

Section: 3.5

Original Text
-------------
Values 200-299 represent successful completion, so that thesevalues may only
be sent within CoA-ACK or Disconnect-ACK packetsand MUST NOT be sent within
a CoA-NAK or Disconnect-NAK packet.

Corrected Text
--------------
Values 200-299 represent successful completion, so that thesevalues may be
sent in other reply messages such as Access-Reject, Access-Challenge,
CoA-ACK or Disconnect-ACK packetsand MUST NOT be sent within a CoA-NAK or
Disconnect-NAK packet.

Notes
-----
RFC 3579  allows for Error-Cause to be sent (specifically) in an
access-challenge and also in Reject messages as well.The specification in
5176 restricts the usage and should be clarified especially since 5176 was
published after 3579.I proposed minimal text but I think a broader approach
is needed for this attribute.  Here are some thoughts:1) Error-Cause is
needed in Access-Reject (as is allowed by 3579)2) IANA should have
procedures for defining new values (currently no procedure is defined). SDO
need to be able to use Error-Cause to report back why an
Authentication/Authorization failed.  Error-Cause seems to be the only
solution other than Reply-Message which is not really designed for reporting
error cause to the NAS.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please use
"Reply All" to discuss whether it should be verified or rejected. When a
decision is reached, the verifying party (IESG) can log in to change the
status and edit the report, if necessary. 

--------------------------------------
RFC5176 (draft-ietf-radext-rfc3576bis-13)
--------------------------------------
Title               : Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)
Publication Date    : January 2008
Author(s)           : M. Chiba, G. Dommety, M. Eklund, D. Mitton, B. Aboba
Category            : INFORMATIONAL
Source              : RADIUS EXTensions
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG


--
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/>