RE: : Re: authors 48 hours: RFC 4005 <draft-ietf-aaa-diameter-nasreq-17.txt>

I agree with Jari, but otherwise David's text looks good to me.

John

> -----Original Message-----
> From: ext Jari Arkko [mailto:[email protected]]
> Sent: 18 April, 2005 08:34
> To: David Mitton
> Cc: Bernard Aboba; [email protected]; Pat Calhoun; Loughney John
> (Nokia-NRC/Helsinki); [email protected]; Bert Wijnen; Kessens David
> (Nokia-NET/MtView)
> Subject: Re: [AAA-WG]: Re: authors 48 hours: RFC 4005
> <draft-ietf-aaa-diameter-nasreq-17.txt>
> 
> 
> This text is otherwise fine, but I'm wondering about the part
> that discards messages. As nasreq section 9.6.2 states, RADIUS
> VSAs are considered optional. So I wonder if the text should
> be changed from
> 
>    Systems that don't have vendor format knowledge, MAY discard such
>    messages not knowing a suitable translation.
> 
> to
> 
>    Systems that do not have vendor format knowledge, MAY discard
>    such attributes not knowing a suitable translation.
> 
> --Jari
> 
> David Mitton wrote:
> 
> >
> > 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
> >    messages 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>
> >
> > 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>
> >
> 
>