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

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

>Since the "extended attributes" document will need to deal with VSA formats
>(and Diameter translation of same),
>
>[gwz] I'm not sure why?

Because the extended attribute draft uses Attribute 26, but with a vendor 
code of 0, which currently isn't supported by RFC 4005?
[gwz] 
Wel, it's true that 4005 doesn't explicitly support a vendor code of zero,
but I don't think that it explicitly _doesn't_ support it, either.  Here's
the section on translating RADIUS VSAs to Diameter:


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

   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.
[gwz] 
It seems as if all we'd really have to do in the extended attributes draft
is to specify that the'M' bit has to be set in the Diameter AVP.


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