: Re: authors 48 hours: RFC 4005

Any update on where we are with this?

On Tue, 28 Jun 2005, RFC Editor wrote:

> David and Glen,
>
> We have not heard further from you regarding this documents readiness
> for publication as an RFC.  Please review the document and let us know
> if you are content with the text as it now appears at:
>
>     ftp://ftp.rfc-editor.org/in-notes/authors/rfc4005.txt
>     ftp://ftp.rfc-editor.org/in-notes/authors/rfc4005-diff.html
>
> We will wait to hear from you before continuing on with the
> publication process.
>
> Thank you.
>
> RFC Editor
>
>
> On Thu, Jun 23, 2005 at 10:37:42AM -0700, RFC Editor wrote:
> > David,
> >
> > We have corrected the text as requested and posted the revised version
> > of the document at:
> >
> >    ftp://ftp.rfc-editor.org/in-notes/authors/rfc4005.txt
> >
> >
> > We have placed a new diff file at:
> >
> >    ftp://ftp.rfc-editor.org/in-notes/authors/rfc4005-diff.html
> >
> > Please be sure to review the document again to ensure satisfaction as
> > we do not make changes once the draft has been published as an RFC.
> >
> > Note that it may be necessary for you to refresh your browser to view
> > the most up-to-date version of the document.
> >
> > We will wait to hear from you again before continuing on with the
> > publication process.
> >
> > Thank you.
> >
> > RFC Editor
> >
> >
> >
> > On Mon, May 30, 2005 at 11:46:14PM -0400, David Mitton wrote:
> > > 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>
>