Re: [Dime] [radext] [IANA #1118137] error in IANA allocations for RFC 5447 (attributes 124 and 125)

I agree with the proposal.
It is important that the types defined in RFC5447 are the ones listed in the IANA registry.
For information, there are existing implementations relying on these AVPs and it is important to be consistent between the RFC and registry.

Regards,

Lionel

> -----Message d'origine-----
> De : radext [mailto:radext-bounces@ietf.org] De la part de Amanda Baber via
> RT
> Envoyé : lundi 6 août 2018 22:33
> Cc : radext@ietf.org; dime@ietf.org; kaduk@mit.edu
> Objet : [radext] [IANA #1118137] error in IANA allocations for RFC 5447
> (attributes 124 and 125)
> 
> Hi,
> 
> On Mon Aug 06 13:00:05 2018, aland@deployingradius.com wrote:
> > On Aug 6, 2018, at 8:01 AM, Denis Ovsienko <denis@ovsienko.info>
> > wrote:
> > > Recently I was reviewing some code that adds support for two RFC 5447
> > > RADIUS AVPs below:
> > >
> > > The MIP6-Home-Link-Prefix AVP (AVP Code 125) is of type OctetString
> > > The MIP6-Feature-Vector AVP (AVP Code 124) is of type Unsigned64 and
> > >
> > > It turned out, the current RADIUS Types registry at
> > > https://www.iana.org/assignments/radius-types/radius-types.xhtml
> > > lists both attributes with wrong types:
> > >
> > > 125   MIP6-Home-Link-Prefix   ipv6prefix      [RFC5447]
> >
> > That is definitely wrong.  The "ipv6prefix" format is different than
> > the one used by MIP6-Home-Link-Prefix in RFC 5337.
> >
> > > 124   MIP6-Feature-Vector     string  [RFC5447]
> >
> > That issue is a bit different.  64-bit integers were defined in RFC
> > 6929 (https://tools.ietf.org/html/rfc6929#section-2.5) long after RFC
> > 5447 was published.
> >
> > So at the time RFC 5447 was published, "string" was the correct
> > definition.
> >
> > > Those incorrect types had propagated from the IANA registry into
> > > FreeRADIUS and Wireshark (both have been fixed now for MIP6-Home-
> > > Link-Prefix, see the discussion and the follow-ups at
> > > https://github.com/the-tcpdump-group/tcpdump/pull/636 if interested).
> > >
> > > Having studied this discrepancy thoroughly, I had concluded the AVP
> > > definitions are correct in RFC 5447, so I did not file an erratum.
> > > The problem seems to be with those IANA allocations only. Could
> > > somebody review this issue and put the IANA allocations right?
> >
> > In the end, I think that the incorrect IANA allocations were a result
> > of the updates done in RFC 8044.  The early drafts had a table which
> > updated all of the IANA data types, e.g.:
> >
> > https://tools.ietf.org/html/draft-ietf-radext-datatypes-05#section-4.2
> 
> Right, we took the entries from here when the document was approved:
> 
> https://tools.ietf.org/html/draft-ietf-radext-datatypes-08#section-4.2
> 
> > The MIP6 attributes are listed there as "ipv6prefix" and "string".  As
> > the author of RFC 8044, I think that's my mistake.  Updating hundreds
> > of attributes required reading many RFCs, and it's understandable that
> > a few mistakes were made.
> >
> > Unless there are objections from DIME or RADEXT, I think it would be
> > best for IANA to update the registry as follows:
> >
> > 125     MIP6-Home-Link-Prefix   string  [RFC5447]
> > 124     MIP6-Feature-Vector     integer64       [RFC5447]
> >
> > We may need approval from the AD (Ben).  Explicit consensus from the
> > WG would also be helpful.
> >
> > Alan DeKok.
> 
> If there's no errata report required, we can move ahead once the AD lets us
> know that any appropriate consensus has been reached (if we haven't heard
> from the chairs first) and gives us the go-ahead.
> 
> Best regards,
> 
> Amanda Baber
> Lead IANA Services Specialist
> 
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.