: Re: authors 48 hours: RFC 4005

Suggested changes
Dave.

------
Text changes for RFC 4005 <draft-ietf-aaa-diameter-nasreq-17.txt>

Section 9.6.  RADIUS Vendor Specific Attributes

para 1:  s/recommended/example/

after para 1: <add >
    A system communicating between Diameter and RADIUS MAY have specific
    knowledge of vendor formats, and MAY be able translate between the
    two formats. However, given the deployment of many RADIUS vendor
    formats that do not follow the example format in RFC 2865 [RADIUS],
    (e.g. those that use a longer vendor type code) the translations in
    the next two sections, will not work in general for those VSAs.  RFC
    2865 states that a robust implementation SHOULD support the field as
    undistinguished octets.

    Systems that don't have vendor format knowledge, MAY discard such
    attributes not knowing a suitable translation. An alternative format is
    under consideration [VSAdraft] that proposes encodings that would
    preserve the native information and not require vendor knowledge in
    the gateway system.

    The following sections are an example for translating RADIUS VSAs
    that use the example RADIUS format, and Diameter VSAs that have type
    codes less than 255, and value field lengths less than 252.
<endadd>


9.6.1.  Forwarding a Diameter Vendor AVP as a RADIUS VSA

Add to para 1, first sentence:
    For Type codes less than 255, the value field length MUST be less
    than 252 or the AVP will be discarded.


Section: 9.6.2.  Forwarding a RADIUS VSA as a Diameter Vendor Specific AVP

Change from:
       Diameter AVP length = length of AVP (heade
To:
       Diameter AVP length = length of AVP (header + data)



Informative References (section 13.2, page 79)
<Add after [DiamMIP]>

[VSAdraft] D. Mitton "Diameter/RADIUS Vendor Specific AVP Translation",
draft-mitton-diameter-radius-vsas-00.txt, "Work in Progress", April 2005

<endadd>