[Dime] RE : Re: [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

<lionel.morand@orange.com> Tue, 02 May 2017 22:09 UTC

Return-Path: <lionel.morand@orange.com>
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 52A5C129ABE; Tue, 2 May 2017 15:09:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 SKgGCUes_GqX; Tue, 2 May 2017 15:09:30 -0700 (PDT)
Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F7B129BA2; Tue, 2 May 2017 15:07:23 -0700 (PDT)
Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id F33CC1004C0; Wed, 3 May 2017 00:07:21 +0200 (CEST)
Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.50]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id C539F180065; Wed, 3 May 2017 00:07:21 +0200 (CEST)
Received: from OPEXCNORM4D.corporate.adroot.infra.ftgroup ([fe80::604f:15da:866b:fd8b]) by OPEXCNORM52.corporate.adroot.infra.ftgroup ([fe80::c482:2589:c116:5790%21]) with mapi id 14.03.0339.000; Wed, 3 May 2017 00:07:21 +0200
From: lionel.morand@orange.com
To: Dave Dolson <ddolson@sandvine.com>, Alan DeKok <aland@deployingradius.com>
CC: "dime@ietf.org list" <dime@ietf.org>, "draft-ietf-dime-rfc4006bis@ietf.org" <draft-ietf-dime-rfc4006bis@ietf.org>, "Gardella, Maryse (Nokia - FR/Nozay)" <maryse.gardella@nokia.com>
Thread-Topic: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02
Thread-Index: AQHSw5B45YFQOC/YlECICNu6290Qhw==
Date: Tue, 02 May 2017 22:07:21 +0000
Message-ID: <20618_1493762841_59090319_20618_13578_1_6B7134B31289DC4FAF731D844122B36E0C0D8B65@OPEXCNORM4D.corporate.adroot.infra.ftgroup>
References: <FFB3377A-3F65-456E-8EFC-CBBA2B671566@gmail.com> <HE1PR0701MB2857B67205A4B3CD908191FCFC100@HE1PR0701MB2857.eurprd07.prod.outlook.com> <C43C255C7106314F8D13D03FA20CFE497007F6E1@wtl-exchp-1.sandvine.com> <E8355113905631478EFF04F5AA706E98705BA165@wtl-exchp-1.sandvine.com> <C43C255C7106314F8D13D03FA20CFE497007FABD@wtl-exchp-1.sandvine.com> <20170428113946.5161041.83399.10532@sandvine.com> <E8355113905631478EFF04F5AA706E98705C5971@wtl-exchp-1.sandvine.com> <670A9410-00F7-4883-B714-E0CA5E9A1234@deployingradius.com>, <E8355113905631478EFF04F5AA706E98705C5B5A@wtl-exchp-1.sandvine.com>
In-Reply-To: <E8355113905631478EFF04F5AA706E98705C5B5A@wtl-exchp-1.sandvine.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E0C0D8B65OPEXCNORM4Dcorp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/NOIlxyTQjSDnyfYhqi5eWxrpyAQ>
Subject: [Dime] RE : Re: [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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: Tue, 02 May 2017 22:09:32 -0000

I share Alan's view and using RFC 7542 as a reference is the thing to do when updating any Diameter spec using NAI today.

Regards,

Lionel

Le 2 mai 2017 23:54, Dave Dolson <ddolson@sandvine.com> a écrit :
Thanks Alan.
Do I correctly hear you saying we should replace all references to RFC 2486 with RFC 7542?


-Dave


-----Original Message-----
From: Alan DeKok [mailto:aland@deployingradius.com]
Sent: Tuesday, May 2, 2017 5:40 PM
To: Dave Dolson
Cc: Yuval Lifshitz; Gardella, Maryse (Nokia - FR/Nozay); jouni korhonen; dime@ietf.org list; draft-ietf-dime-rfc4006bis@ietf.org
Subject: Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02


> On May 2, 2017, at 5:29 PM, Dave Dolson <ddolson@sandvine.com> wrote:
>
> I guess the safest thing to do here is to continue to reference
> RFC2486 with END_USER_NAI in Subscription-Id-Type, and specify RFC7542 for the new Subscription-Id-NAI AVP.

  I would argue that there is no compatibility issues between RFC 7542 and RFC 2486.

  On top of that, referencing a document from 18 years ago which has been deprecated *twice* is probably a bad idea.

> Even though I suspect that in practice non-ASCII is being used in Subscription-Id-Type with END_USER_NAI.

  non-ASCII was forbidden by RFC 2486 Section 3.  It is allowed by RFC 4282, but I think that use-case is rare today.

  Responding to earlier messages in the thread:

> Following 3 issues are noted in appendix A of RFC4282:
>
>    o  International character set support has been added for both
>       usernames and realms.  Note that this implies character codes 128
>       - 255 may be used in the username portion, which may be
>       unacceptable to nodes that only support RFC 2486.  Many devices
>       already allow this behaviour, however.
>
>    o  Username privacy support has been added.  Note that NAIs without a
>       username (for privacy) may not be acceptable to RFC 2486-compliant
>       nodes.  Many devices already allow this behaviour, however.
>
>    o  A recommendation to support NAI length of at least 253 octets has
>       been added, and compatibility considerations among NAI lengths in
>       this specification and various AAA protocols are discussed.  Note
>       that long NAIs may not be acceptable to RFC 2486-compliant nodes.
>
> And from appendix A of RFC7542 (as you noted):
>
> *  The formal syntax in Section 2.1 has been updated to forbid
>       non-UTF-8 characters (e.g., characters with the "high bit" set).
>
> This means that there is incompatibility in both directions between RFC2486 and RFC7542.

  I think the issue is compatibility between 4282 and 7542.

> As I see it, operators require UTF-8 strings, and are probably already using them, so we should update the END_USER_NAI.

  Are any operators using non-UTF8 strings with the high bit set?  I would suggest that is rare to non-existent.

  It's one thing to use a non-standard character set within your private organization.   But as soon as you do roaming or other interoperation, UTF-8 is pretty much your only choice.

  Alan DeKok.

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

_________________________________________________________________________________________________________________________

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.