Issue: Diameter-RADIUS gateway behavior not completely specified

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Description of issue: Diameter-RADIUS gateway behavior not completely
specified
Submitter name: Glen Zorn
Submitter email address: gwz@cisco.com
Date first submitted: 26 Aug 06
Document: draft-ietf-radext-filter-01.txt
Comment type: T
Priority: 1
Section: 4 
Rationale/Explanation of issue: The last sentence of section 4 says
"Note that since a Diameter AVP can be larger than the maximum RADIUS
packet size (4096), translation from Diameter to RADIUS may not be
possible in all cases."  While this is true, the behavior of the
Diameter-RADIUS gateway in this case is left unspecified.  Is the
response forwarded back toward the requests' originator without the
untranslatable AVPs?  In the case of an Access-Accept message, Section
1.2 says "If a NAS conforming to this specification receives an
Access-Accept packet containing a NAS-Filter-Rule attribute which it
cannot apply, it MUST act as though it had received an Access-Reject.",
it might be reasonable for the gateway to translate the Access-Accept
into an Access-Reject, since an attribute that is missing because
untranslatable can obviously not be applied.  In the case of a CoA
message with an untranslatable attribute, should the message be
translated into a Disconnect-Request or just discarded?  Or in both
cases, should the gateway respond to the originating/responding Diameter
peer with an appropriate error (e.g., DIAMETER_INVALID_AVP_LENGTH) and
let it figure out the next step?  If so, it still seems that the peers
behavior must be specified.

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