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

Dave Dolson <ddolson@sandvine.com> Tue, 02 May 2017 21:54 UTC

Return-Path: <ddolson@sandvine.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 CA60812EBF7; Tue, 2 May 2017 14:54:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 ao5ff4Yo73WI; Tue, 2 May 2017 14:54:13 -0700 (PDT)
Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC1A7129C1A; Tue, 2 May 2017 14:51:12 -0700 (PDT)
Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0319.002; Tue, 2 May 2017 17:51:11 -0400
From: Dave Dolson <ddolson@sandvine.com>
To: Alan DeKok <aland@deployingradius.com>
CC: Yuval Lifshitz <ylifshitz@sandvine.com>, "Gardella, Maryse (Nokia - FR/Nozay)" <maryse.gardella@nokia.com>, jouni korhonen <jouni.nospam@gmail.com>, "dime@ietf.org list" <dime@ietf.org>, "draft-ietf-dime-rfc4006bis@ietf.org" <draft-ietf-dime-rfc4006bis@ietf.org>
Thread-Topic: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02
Thread-Index: AQHSw4y4qV7yR/Gy6kGQdrOKlX57GKHhk7nw
Date: Tue, 02 May 2017 21:51:10 +0000
Message-ID: <E8355113905631478EFF04F5AA706E98705C5B5A@wtl-exchp-1.sandvine.com>
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>
In-Reply-To: <670A9410-00F7-4883-B714-E0CA5E9A1234@deployingradius.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.200.114]
x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/YgQOwkcBSKzUnzyBVbuKMHW_u7k>
Subject: Re: [Dime] [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 21:54:15 -0000

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.