RE: Revisions to RFC 4005 (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt)

["Glen Zorn" <glenzorn@comcast.net>]

>9.6.2.  Forwarding a RADIUS VSA as a Diameter Vendor Specific AVP
>
>    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

Won't using a RADIUS VSA Vendor code of 0 result in a conflict between the 
RADIUS
"extended" attributes and already allocated Diameter AVPs?
[gwz] 
Maybe.  What do you have in mind?  I don't think so, because standard
Diameter AVPs don't have the 'V' bit set & AFAIK, no existing VSAs of any
variety have a Vendor code of 0.  We may have a problem translating the new
RADIUS "grouped attributes" to Diameter, though, because don't Diameter
grouped AVPs have a fixed syntax?  The RADIUS groupings could be created in
an ad hoc fashion, though...in addition, 4005 says that "Nested Multiple
vendor data fields MUST be expanded into multiple Diameter AVPs.".  I'm not
really sure that that really works even with current v-s subattributes,
since it seems to assume that there is no important relation between the
subattributes that could be lost by breaking them apart.



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


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