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

"Amanda Baber via RT" <iana-matrix@iana.org> Wed, 08 August 2018 01:59 UTC

Return-Path: <iana-shared@icann.org>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96C3130DDA; Tue, 7 Aug 2018 18:59:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.18
X-Spam-Level:
X-Spam-Status: No, score=-3.18 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52_t-2vea8Kt; Tue, 7 Aug 2018 18:59:32 -0700 (PDT)
Received: from smtp01.icann.org (smtp01.icann.org [192.0.46.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24E34127332; Tue, 7 Aug 2018 18:59:32 -0700 (PDT)
Received: from request4.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp01.icann.org (Postfix) with ESMTP id 46B2DE0158; Wed, 8 Aug 2018 01:59:31 +0000 (UTC)
Received: by request4.lax.icann.org (Postfix, from userid 48) id 0D710207E6; Wed, 8 Aug 2018 01:59:31 +0000 (UTC)
RT-Owner: amanda.baber
From: "Amanda Baber via RT" <iana-matrix@iana.org>
Reply-To: iana-matrix@iana.org
In-Reply-To: <rt-4.4.3-5784-1533629029-1033.1118137-7-0@icann.org>
References: <RT-Ticket-1118137@icann.org> <1650f1cabeb.100024af647180.2934901912766753218@ovsienko.info> <A54682E8-B80C-4992-877C-218B492882E3@deployingradius.com> <rt-4.4.3-14398-1533587606-1786.1118137-7-0@icann.org> <11227_1533629007_5B69524E_11227_192_1_6B7134B31289DC4FAF731D844122B36E3951AE20@OPEXCLILM43.corporate.adroot.infra.ftgroup> <rt-4.4.3-5784-1533629029-1033.1118137-7-0@icann.org>
Message-ID: <rt-4.4.3-9839-1533693570-817.1118137-7-0@icann.org>
X-RT-Loop-Prevention: IANA
X-RT-Ticket: IANA #1118137
X-Managed-BY: RT 4.4.3 (http://www.bestpractical.com/rt/)
X-RT-Originator: amanda.baber@icann.org
CC: radext@ietf.org, lionel.morand@orange.com, kaduk@mit.edu, dime@ietf.org
Content-Type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
Precedence: bulk
Date: Wed, 08 Aug 2018 01:59:31 +0000
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/pzuAqedaJI_hdVsTu_POwnN--DY>
Subject: [Dime] [IANA #1118137] error in IANA allocations for RFC 5447 (attributes 124 and 125)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.27
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Aug 2018 01:59:35 -0000

Hi Benjamin,

Given Lionel's confirmation, should we go ahead and make these changes at https://www.iana.org/assignments/radius-types?

OLD:

124	MIP6-Feature-Vector	string	[RFC5447]
125	MIP6-Home-Link-Prefix	ipv6prefix	[RFC5447]

NEW:

124     MIP6-Feature-Vector     integer64       [RFC5447]
125     MIP6-Home-Link-Prefix   string  [RFC5447]

thanks,
Amanda

On Tue Aug 07 08:03:49 2018, lionel.morand@orange.com wrote:
> 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.