[radext] #17: 4005bis Dependency

["radext issue tracker" <trac@tools.ietf.org>]

#17: 4005bis Dependency
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@â            |       Owner:  bernard_aboba@â          
     Type:  defect                     |      Status:  new                      
 Priority:  major                      |   Milestone:  milestone1               
Component:  Extended                   |     Version:  1.0                      
 Severity:  Active WG Document         |    Keywords:                           
---------------------------------------+------------------------------------
 Date first submitted:  December 10, 2008
 Reference:   http://www.watersprings.org/pub/id/draft-mitton-diameter-
 radius-vsas-01.txt
 Section:  7
 Rationale/Explanation of issue:

 Section 7 of this document contains the following text on Diameter
 Considerations:

    Since the Extended Attributes are encoded as Vendor-Specific RADIUS
    Attributes (see [IANA]), no special handling is required by Diameter
    [RFC3588] entities; see [RFC4005] for details on the Diameter
    treatment of RADIUS VSAs.
 Unfortunately, this text is wrong.  RFC 4005 does not in fact describe how
 to translate RADIUS Extended Attributes to Diameter.

 RFC 4005 Section 9 defines the RADIUS/Diameter gateway.   Unfortunately,
 Section 9.6 assumes that RADIUS VSAs follow the format recommended in RFC
 2865, Section 5.26.  As noted in Section 9.6.2:

    The Diameter AVP will consist of the following fields:

       Diameter Flags: V=1, M=0, P=0
       Diameter Vendor code = RADIUS VSA Vendor code
       Diameter AVP code = RADIUS VSA Vendor type code
       Diameter AVP length = length of AVP (header + data)
       Diameter Data = RADIUS VSA vendor data

    Note that the VSAs are considered optional by RADIUS rules, and this
    specification does not set the Mandatory flag.  If an implementor
    desires a VSA be made mandatory because it represents a required
    service policy, the RADIUS gateway should have a process to set the
    bit on the Diameter side.

    If the RADIUS receiving code knows of vendor specific field
    interpretations for the specific vendor, it may employ them to parse
    an extended AVP code or data length.  Otherwise the recommended
    standard fields will be used.

    Nested Multiple vendor data fields MUST be expanded into multiple
    Diameter AVPs.
 Since the RADIUS Extended Attribute format does not conform to the
 recommended RADIUS VSA format in RFC 2865, RFC 4005 Section 9.6.2 does not
 apply.  As a result, an alternative mechanism for translating RADIUS
 Extended Attributes to Diameter needs to be defined (RFC 4005bis).  The
 RADIUS Extended Attributes document has a normative dependency on this
 document (which probably should be handled in the DIME WG).

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/17>
radext <http://tools.ietf.org/radext/>


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