From nobody Tue May 2 14:33:05 2017 Return-Path: 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 4458D128DE7; Tue, 2 May 2017 14:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 uLsYaV3YiC4P; Tue, 2 May 2017 14:32:51 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BD78127B31; Tue, 2 May 2017 14:29:39 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-2.sandvine.com (192.168.194.177) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 2 May 2017 17:29:37 -0400 Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by blr-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Tue, 2 May 2017 17:29:37 -0400 From: Dave Dolson To: Dave Dolson , Yuval Lifshitz , "Gardella, Maryse (Nokia - FR/Nozay)" , jouni korhonen , "dime@ietf.org list" CC: "draft-ietf-dime-rfc4006bis@ietf.org" , Yuval Lifshitz Thread-Topic: [ALU] [Dime] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Thread-Index: AQHStz/24gA9nYAO5kyNlVyqvmNlc6HZRtuAgABM+YD///q4YIABD8kAgAAbciuABu1GAA== Date: Tue, 2 May 2017 21:29:37 +0000 Message-ID: References: , <20170428113946.5161041.83399.10532@sandvine.com> In-Reply-To: <20170428113946.5161041.83399.10532@sandvine.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: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E98705C5971wtlexchp1sandvi_" MIME-Version: 1.0 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 21:33:04 -0000 --_000_E8355113905631478EFF04F5AA706E98705C5971wtlexchp1sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I guess the safest thing to do here is to continue to reference RFC2486 wit= h END_USER_NAI in Subscription-Id-Type, and specify RFC7542 for the new Subscription-Id-NAI AVP. Even though I suspect that in practice non-ASCII is being used in Subscript= ion-Id-Type with END_USER_NAI. From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Friday, April 28, 2017 7:40 AM To: Yuval Lifshitz; Gardella, Maryse (Nokia - FR/Nozay); jouni korhonen; di= me@ietf.org list Cc: draft-ietf-dime-rfc4006bis@ietf.org; Yuval Lifshitz Subject: Re: [ALU] [Dime] WGLC #1 for draft-ietf-dime-rfc4006bis-02 If nodes accept RFC7542 in END_USER_NAI, is anything broken? Can we say "MAY accept..."? David Dolson Sandvine From: Yuval Lifshitz Sent: Friday, April 28, 2017 2:01 AM To: Dave Dolson; Gardella, Maryse (Nokia - FR/Nozay); jouni korhonen; dime@= ietf.org list Cc: draft-ietf-dime-rfc4006bis@ietf.org; Yuval Lifshitz Subject: RE: [ALU] [Dime] WGLC #1 for draft-ietf-dime-rfc4006bis-02 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. Therefore, if we want to preserver compatibility between RFC4006 and RFC400= 6bis, would suggest to use the new format only in the newly added AVP. From: Dave Dolson Sent: Thursday, April 27, 2017 9:10 PM To: Yuval Lifshitz; Gardella, Maryse (Nokia - FR/Nozay); jouni korhonen; di= me@ietf.org list Cc: draft-ietf-dime-rfc4006bis@ietf.org; Yuval Lifshitz Subject: RE: [ALU] [Dime] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Without digging too deeply, it seems the jump directly from RFC2486 to RFC7= 542 is backwards compatible, since UTF-8 is backwards compatible with 7-bit= ASCII. The gray area seems to be the binary encoding. Any RFC2486 string may incl= ude a binary value from %x00-7F, as I read it. So, we could say senders SHOULD conform to RFC7542, and receivers MAY accep= t RFC7542-invalid strings for backwards compatibility. As I see it, operators require UTF-8 strings, and are probably already usin= g them, so we should update the END_USER_NAI. -Dave From: Yuval Lifshitz [mailto:ylifshitz@sandvine.com] Sent: Thursday, April 27, 2017 10:08 AM To: Gardella, Maryse (Nokia - FR/Nozay); jouni korhonen; dime@ietf.org list Cc: draft-ietf-dime-rfc4006bis@ietf.org; Yuval Lifshitz Subject: RE: [ALU] [Dime] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Maryse and All, Seems like RFC4282 was also obsoleted = (in 2015) by RFC7542. And as noted in = Appendix A of both RFC4282 and RFC7542 they modified their predecessors in = non-backward-compatible manner. We should probably make the change only in the new AVP, so there is no comp= atibility issue with existing RFC4006 elements? Yuval From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com= ] Sent: Thursday, April 27, 2017 12:32 PM To: jouni korhonen; dime@ietf.org list Cc: draft-ietf-dime-rfc4006bis@ietf.org Subject: RE: [ALU] [Dime] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Hello all, One comment on the reference for the NAI format: In the existing: 8.47. Subscription-Id-Type AVP END_USER_NAI 3 The identifier is in the form of a Network Access Identifier, as defined in [RFC2486]. And the newly created : 8.62. Subscription-Id-NAI AVP The Subscription-Id-NAI (AVP Code TBD11) is of type UTF8String. The Subscription-Id-NAI AVP contains the identifier in the form of a Network Access Identifier, as defined in [RFC2486]. The reference is RFC 2486, however it is obsoleted by RFC 4282. Also RFC 67= 33 (which is the DBP reference now for RFC4006bis) refers to RFC 4282. BR Maryse -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of jouni korhonen Sent: lundi 17 avril 2017 08:01 To: dime@ietf.org list > Cc: draft-ietf-dime-rfc4006bis@ietf.org Subject: [ALU] [Dime] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Folks, This email starts a 2 week WGLC #1 for draft-ietf-dime-rfc4006bis-02. The W= GLC ends 4/30/17 23:59 pacific time. Submit your comments to issue tracker (https://trac.ietf.org/trac/dime/newt= icket) and to mailing list. If you think the document needs no work and is = ready, express that also on the list. Silence does not count as acceptance. - Jouni & Lionel _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_E8355113905631478EFF04F5AA706E98705C5971wtlexchp1sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I guess the safest thi= ng to do here is to continue to reference RFC2486 with END_USER_NAI in Subs= cription-Id-Type,

and specify RFC7542 fo= r the new Subscription-Id-NAI AVP.

 

Even though I suspect = that in practice non-ASCII is being used in Subscription-Id-Type with END_U= SER_NAI.

 

 

 

 

From: Dave Dol= son [mailto:ddolson@sandvine.com]
Sent: Friday, April 28, 2017 7:40 AM
To: Yuval Lifshitz; Gardella, Maryse (Nokia - FR/Nozay); jouni korho= nen; dime@ietf.org list
Cc: draft-ietf-dime-rfc4006bis@ietf.org; Yuval Lifshitz
Subject: Re: [ALU] [Dime] WGLC #1 for draft-ietf-dime-rfc4006bis-02<= o:p>

 

If nodes accept RFC7542 in END_USER_N= AI, is anything broken?

Can we say "MAY accept..."? 

 

David Dolson
Sandvine

From: Yuval Lifshitz

Sent: Friday, April 28, 2017 2:01 AM

To: Dave Dolson; Gardella, Maryse (Nokia - FR/Nozay); jo= uni korhonen; dime@ietf.org list

Subject: RE: [ALU] [Dime] WGLC #1 for draft-ietf-dime-rfc4006= bis-02

 

Following 3 issues are= noted in appendix A of RFC4282:

 

   o  International character s= et support has been added for both

      usernames and r= ealms.  Note that this implies character codes 128

      - 255 may be us= ed in the username portion, which may be

    &nbs= p; unacceptable to nodes that only support RFC 2486.&= nbsp; Many devices

      already allow t= his behaviour, however.

 

   o  Username privacy support = has been added.  Note that NAIs without a

      username (for p= rivacy) may not be acceptable to RFC 2486-compliant

    &nbs= p; nodes.  Many devices already allow this behaviour, how= ever.

 

   o  A recommendation to suppo= rt NAI length of at least 253 octets has

      been added, and= compatibility considerations among NAI lengths in

      this specificat= ion 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 upd=
ated to forbid

    =
  non-UTF-8 characters (e.g., chara=
cters with the "high bit" set).


 


This means that there =
is incompatibility in both directions between RFC2486 and RFC7542.



Therefore, if we want =
to preserver compatibility between RFC4006 and RFC4006bis, would suggest to=
 use the new format only in the newly added AVP.


 


 






From: Dave Dol=
son


Sent: Thursday, April 27, 2017 9:10 PM

To: Yuval Lifshitz; Gardella, Maryse (Nokia - FR/Nozay); jouni korho=
nen; 
dime@ietf.org list

Cc: draft-iet=
f-dime-rfc4006bis@ietf.org; Yuval Lifshitz

Subject: RE: [ALU] [Dime] WGLC #1 for draft-ietf-dime-rfc4006bis-02<=
/span>






 


Without digging too de=
eply, it seems the jump directly from RFC2486 to RFC7542 is backwards compa=
tible, since UTF-8 is backwards compatible with 7-bit ASCII.


 


The gray area seems to=
 be the binary encoding.  Any RFC2486 string may include a binary valu=
e from %x00-7F, as I read it.


 


So, we could say sende=
rs SHOULD conform to RFC7542, and receivers MAY accept RFC7542-invalid stri=
ngs for backwards compatibility.


 


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


 


 


 


-Dave


 


 


 






From: Yuval Li=
fshitz [mailto:ylifshitz@sandvine=
.com]


Sent: Thursday, April 27, 2017 10:08 AM

To: Gardella, Maryse (Nokia - FR/Nozay); jouni korhonen; 
dime@ietf.org list

Cc: draft-iet=
f-dime-rfc4006bis@ietf.org; Yuval Lifshitz

Subject: RE: [ALU] [Dime] WGLC #1 for draft-ietf-dime-rfc4006bis-02<=
/span>






 


Maryse and All,


Seems like 
RFC4282 was also obsoleted (in 2015) by 
RFC7542. And as noted in Appendix A of both RFC4282 and RFC7542 they mo=
dified their predecessors in non-backward-compatible manner.


We should probably mak=
e the change only in the new AVP, so there is no compatibility issue with e=
xisting RFC4006 elements?


 


Yuval


 






From: Gardella=
, Maryse (Nokia - FR/Nozay) [m=
ailto:maryse.gardella@nokia.com]


Sent: Thursday, April 27, 2017 12:32 PM

To: jouni korhonen; dime@ietf.org list

Cc: draft-iet=
f-dime-rfc4006bis@ietf.org

Subject: RE: [ALU] [Dime] WGLC #1 for draft-ietf-dime-rfc4006bis-02<=
/span>






 


Hello all, <=
o:p>


 <=
/o:p>


One comment on the =
reference for the NAI format:


 <=
/o:p>


In the existing:


  


8.47<=
a name=3D"section-8.47">.  Subscription-Id-Ty=
pe AVP


 


END_USER_NAI 3


 


   The identifier is in the form of a N=
etwork Access Identifier, as


   defined in [RFC2486].


 


And the newly creat=
ed :


 


8.62<=
a name=3D"section-8.62">.  Subscription-Id-NA=
I AVP


 


 


   The Subscription-I=
d-NAI (AVP Code TBD11) is of type UTF8String.  The

   Subscription-Id-NA=
I AVP contains the identifier in the form of a


   Network Access Ide=
ntifier, as defined 
in [RFC2486].


 


The reference is RF=
C 2486, however it is obsoleted by
RFC 4282. Also RFC 6733 (which is =
the DBP reference now for RFC4006bis) refers to RFC 4282.=



 


BR


Maryse<=
/o:p>


 


-----Original Message-----

From: DiME [mailto:dime-bounces@ie=
tf.org] On Behalf Of jouni korhonen

Sent: lundi 17 avril 2017 08:01

To: dime@ietf.org list <dime@ietf.org>

Cc: draft-ietf-dime-=
rfc4006bis@ietf.org

Subject: [ALU] [Dime] WGLC #1 for draft-ietf-dime-rfc4006bis-02<=
/p>

 


Folks,


 


This email starts a 2 week WGLC #1 for draft-ietf=
-dime-rfc4006bis-02. The WGLC ends 4/30/17 23:59 pacific time.

Submit your comments to issue tracker (https://trac.ietf.org/trac/dime/newticket=
) and to mailing list. If you think the
 document needs no work and is ready, express that also on the list. Silenc=
e does not count as acceptance.


 


- Jouni & Lionel


 


 


_______________________________________________


DiME mailing list


DiME@ietf.org

https://www.iet=
f.org/mailman/listinfo/dime
--_000_E8355113905631478EFF04F5AA706E98705C5971wtlexchp1sandvi_-- From nobody Tue May 2 14:43:07 2017 Return-Path: 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 AA9CE12949A; Tue, 2 May 2017 14:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ENB0gYtVTTua; Tue, 2 May 2017 14:43:03 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id D142812751F; Tue, 2 May 2017 14:40:28 -0700 (PDT) Received: from [192.168.120.42] (23-233-24-114.cpe.pppoe.ca [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id 1E49C2C84; Tue, 2 May 2017 21:40:26 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Tue, 2 May 2017 17:40:25 -0400 Cc: Yuval Lifshitz , "Gardella, Maryse (Nokia - FR/Nozay)" , jouni korhonen , "dime@ietf.org list" , "draft-ietf-dime-rfc4006bis@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <670A9410-00F7-4883-B714-E0CA5E9A1234@deployingradius.com> References: <20170428113946.5161041.83399.10532@sandvine.com> To: Dave Dolson X-Mailer: Apple Mail (2.3124) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 21:43:06 -0000 > On May 2, 2017, at 5:29 PM, Dave Dolson wrote: >=20 > 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: > =20 > 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. > =20 > 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. > =20 > 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. > =20 > And from appendix A of RFC7542 (as you noted): > =20 > * The formal syntax in Section 2.1 has been updated to forbid > non-UTF-8 characters (e.g., characters with the "high bit" set). > =20 > 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. From nobody Tue May 2 14:54:16 2017 Return-Path: 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 To: Alan DeKok CC: Yuval Lifshitz , "Gardella, Maryse (Nokia - FR/Nozay)" , jouni korhonen , "dime@ietf.org list" , "draft-ietf-dime-rfc4006bis@ietf.org" Thread-Topic: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Thread-Index: AQHSw4y4qV7yR/Gy6kGQdrOKlX57GKHhk7nw Date: Tue, 2 May 2017 21:51:10 +0000 Message-ID: References: <20170428113946.5161041.83399.10532@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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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]=20 Sent: Tuesday, May 2, 2017 5:40 PM To: Dave Dolson Cc: Yuval Lifshitz; Gardella, Maryse (Nokia - FR/Nozay); jouni korhonen; di= me@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 wrote: >=20 > I guess the safest thing to do here is to continue to reference=20 > RFC2486 with END_USER_NAI in Subscription-Id-Type, and specify RFC7542 fo= r the new Subscription-Id-NAI AVP. I would argue that there is no compatibility issues between RFC 7542 and = RFC 2486. =09 On top of that, referencing a document from 18 years ago which has been d= eprecated *twice* is probably a bad idea. > Even though I suspect that in practice non-ASCII is being used in Subscri= ption-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: > =20 > 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. > =20 > 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. > =20 > 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. > =20 > And from appendix A of RFC7542 (as you noted): > =20 > * The formal syntax in Section 2.1 has been updated to forbid > non-UTF-8 characters (e.g., characters with the "high bit" set). > =20 > This means that there is incompatibility in both directions between RFC24= 86 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 us= ing 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 or= ganization. But as soon as you do roaming or other interoperation, UTF-8 = is pretty much your only choice. Alan DeKok. From nobody Tue May 2 15:09:36 2017 Return-Path: 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: To: Dave Dolson , Alan DeKok CC: "dime@ietf.org list" , "draft-ietf-dime-rfc4006bis@ietf.org" , "Gardella, Maryse (Nokia - FR/Nozay)" Thread-Topic: =?iso-8859-1?Q?RE=A0:_Re:_[Dime]_[ALU]__WGLC_#1_for_draft-ietf-dime-rfc40?= =?iso-8859-1?Q?06bis-02?= Thread-Index: AQHSw5B45YFQOC/YlECICNu6290Qhw== Date: Tue, 2 May 2017 22:07:21 +0000 Message-ID: <20618_1493762841_59090319_20618_13578_1_6B7134B31289DC4FAF731D844122B36E0C0D8B65@OPEXCNORM4D.corporate.adroot.infra.ftgroup> References: <20170428113946.5161041.83399.10532@sandvine.com> <670A9410-00F7-4883-B714-E0CA5E9A1234@deployingradius.com>, In-Reply-To: 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: Subject: [Dime] =?iso-8859-1?q?RE=A0=3A_Re=3A__=5BALU=5D__WGLC_=231_for_dr?= =?iso-8859-1?q?aft-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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 22:09:32 -0000 --_000_6B7134B31289DC4FAF731D844122B36E0C0D8B65OPEXCNORM4Dcorp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I share Alan's view and using RFC 7542 as a reference is the thing to do wh= en updating any Diameter spec using NAI today. Regards, Lionel Le 2 mai 2017 23:54, Dave Dolson a =E9crit : 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; di= me@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 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 fo= r 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 d= eprecated *twice* is probably a bad idea. > Even though I suspect that in practice non-ASCII is being used in Subscri= ption-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 RFC24= 86 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 us= ing 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 or= ganization. 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_6B7134B31289DC4FAF731D844122B36E0C0D8B65OPEXCNORM4Dcorp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

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@sandvin= e.com> a =E9crit :
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; di= me@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> w= rote:
>
> 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 b= een deprecated *twice* is probably a bad idea.

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

  non-ASCII was forbidden by RFC 2486 Section 3.  It is allowed b= y 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 t= hat this implies character codes 128
>       - 255 may be used in the username = portion, which may be
>       unacceptable to nodes that only su= pport RFC 2486.  Many devices
>       already allow this behaviour, howe= ver.
> 
>    o  Username privacy support has been added.&nbs= p; 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 cons= iderations among NAI lengths in
>       this specification and various AAA= protocols are discussed.  Note
>       that long NAIs may not be acceptab= le 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., charac= ters with the "high bit" set).
> 
> This means that there is incompatibility in both directions between RF= C2486 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 priva= te organization.   But as soon as you do roaming or other interop= eration, 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 confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_6B7134B31289DC4FAF731D844122B36E0C0D8B65OPEXCNORM4Dcorp_-- From nobody Tue May 2 15:49:34 2017 Return-Path: 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 EDA3C12942F; Tue, 2 May 2017 15:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 j8VTvMu93Nzi; Tue, 2 May 2017 15:49:30 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id D79321293F3; Tue, 2 May 2017 15:47:12 -0700 (PDT) Received: from [192.168.120.42] (23-233-24-114.cpe.pppoe.ca [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id 6C3852C83; Tue, 2 May 2017 22:47:11 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Tue, 2 May 2017 18:47:09 -0400 Cc: Yuval Lifshitz , "Gardella, Maryse (Nokia - FR/Nozay)" , jouni korhonen , "dime@ietf.org list" , "draft-ietf-dime-rfc4006bis@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3ABC7A8B-00DD-4032-85F0-D712A5517622@deployingradius.com> References: <20170428113946.5161041.83399.10532@sandvine.com> <670A9410-00F7-4883-B714-E0CA5E9A1234@deployingradius.com> To: Dave Dolson X-Mailer: Apple Mail (2.3124) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 22:49:32 -0000 On May 2, 2017, at 5:51 PM, Dave Dolson wrote: >=20 > Thanks Alan. > Do I correctly hear you saying we should replace all references to RFC = 2486 with RFC 7542? Yes. It's 2017. Independent of RFC 7542, *inter-operable* implementations = just have no business using non-UTF8 identifiers. Alan DeKok. From nobody Wed May 3 06:25:56 2017 Return-Path: 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 17E44127698; Wed, 3 May 2017 06:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.702 X-Spam-Level: X-Spam-Status: No, score=-4.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 uM8_0vy5HT-A; Wed, 3 May 2017 06:25:53 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50112.outbound.protection.outlook.com [40.107.5.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B9B3129B37; Wed, 3 May 2017 06:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ddUnGv6Dm+mMnuhme1Q/cy/9CokSVPNy+VDl1VyFeo8=; b=hxONHZplnyHTJ/BWyt+pzDTZPaZ6qIYiQF2NhXAIDTAth7J7s309Lbb0t3ejuXJN2ohUBguc+QGltqWsKt6lDu5QdgauujZ4yoolf6kgbb+KdVga87dVOjC4Lu9oDOP5RKQlS3rKDNNA4z5uNsITXfP2OxmL7Ftq4bhqNu9EZrk= Received: from HE1PR0701MB2857.eurprd07.prod.outlook.com (10.168.91.147) by HE1PR0701MB2858.eurprd07.prod.outlook.com (10.168.91.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.1; Wed, 3 May 2017 13:21:29 +0000 Received: from HE1PR0701MB2857.eurprd07.prod.outlook.com ([10.168.91.147]) by HE1PR0701MB2857.eurprd07.prod.outlook.com ([10.168.91.147]) with mapi id 15.01.1075.010; Wed, 3 May 2017 13:21:29 +0000 From: "Gardella, Maryse (Nokia - FR/Nozay)" To: Alan DeKok , Dave Dolson CC: Yuval Lifshitz , jouni korhonen , "dime@ietf.org list" , "draft-ietf-dime-rfc4006bis@ietf.org" Thread-Topic: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Thread-Index: AQHSw4y3iSssb1Vk+0CBBkhlVtGV+aHhlVEAgAAPpYCAAO2PwA== Date: Wed, 3 May 2017 13:21:29 +0000 Message-ID: References: <20170428113946.5161041.83399.10532@sandvine.com> <670A9410-00F7-4883-B714-E0CA5E9A1234@deployingradius.com> <3ABC7A8B-00DD-4032-85F0-D712A5517622@deployingradius.com> In-Reply-To: <3ABC7A8B-00DD-4032-85F0-D712A5517622@deployingradius.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: deployingradius.com; dkim=none (message not signed) header.d=none;deployingradius.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.21] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2858; 7:U+UINXdz0t3Je7ALJSqv+vwx1mkDIxg9ok476e4B2gKpkE1pIg3jm+u3YdUSA7O9Hczu2mkUdVYPeojfRyY8l9G0O7vCm8stJBmZnFUE/LrZ/phNquM8L/9LGAKRIHMzTwWScW6Tg+FRVF2UaYkVxlkYVZXZQAJDPm6F9vaMYSHBvPuax9u7Al8LEJeCkrdD3Jx6Jat60wRvT8VcfztSiPhMqOVxFpUEPJVvSCsiJ8aS5/jiAdw6aaylwiHHgFLcy5ky60FePxn7InFwYusJ4yTvZJkRRukUsKrWhYFfPWfGLP+YJdPHAQYQGPhHaMwUL3ev27aX0qYSpm4AUVpbGA== x-ms-office365-filtering-correlation-id: db9f76bc-0f38-405c-d90a-08d492274f28 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:HE1PR0701MB2858; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(82608151540597)(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123558100)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148); SRVR:HE1PR0701MB2858; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2858; x-forefront-prvs: 029651C7A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39450400003)(39400400002)(39850400002)(39860400002)(39840400002)(377454003)(13464003)(53754006)(24454002)(229853002)(189998001)(77096006)(6506006)(25786009)(53546009)(9686003)(86362001)(230783001)(53936002)(3846002)(93886004)(2950100002)(6436002)(7736002)(305945005)(39060400002)(4326008)(74316002)(5660300001)(54906002)(6116002)(55016002)(99286003)(102836003)(478600001)(3660700001)(66066001)(8936002)(76176999)(50986999)(2906002)(81166006)(54356999)(2900100001)(8676002)(6246003)(33656002)(7696004)(3280700002)(38730400002)(122556002)(17413003); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2858; H:HE1PR0701MB2857.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2017 13:21:29.2546 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2858 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 13:25:55 -0000 Hello all, For the new AVP, no question: RFC 7542 should be used. I have not the full overview of 3GPP specs used for reference to NAI, and b= ased on: - assuming the TS 23.003 (Numbering, addressing and identification) is an i= mportant spec to consider, the RFC 4282 is used - RFC 6377 DBP also referring to RFC 4282 =20 I would tend to agree on at least using RFC 4282 as the reference for the E= ND_USER_NAI in Subscription-Id-Type for RFC4006bis. Whether to directly refer to RFC7542, I cannot confirm whether this is acce= ptable or not. =20 BR Maryse -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com]=20 Sent: mercredi 3 mai 2017 00:47 To: Dave Dolson Cc: Yuval Lifshitz ; Gardella, Maryse (Nokia - FR/N= ozay) ; 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:51 PM, Dave Dolson wrote: >=20 > Thanks Alan. > Do I correctly hear you saying we should replace all references to RFC 24= 86 with RFC 7542? Yes. It's 2017. Independent of RFC 7542, *inter-operable* implementations jus= t have no business using non-UTF8 identifiers. Alan DeKok. From nobody Wed May 3 07:21:44 2017 Return-Path: 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 376D8128990; Wed, 3 May 2017 07:21:43 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 tGB9aoqVKFml; Wed, 3 May 2017 07:21:38 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99513128B8F; Wed, 3 May 2017 07:19:04 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by wtl-exchp-1.sandvine.com (192.168.194.176) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 3 May 2017 10:19:03 -0400 Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by blr-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Wed, 3 May 2017 10:19:02 -0400 From: Dave Dolson To: "Gardella, Maryse (Nokia - FR/Nozay)" , "Alan DeKok" CC: Yuval Lifshitz , jouni korhonen , "dime@ietf.org list" , "draft-ietf-dime-rfc4006bis@ietf.org" Thread-Topic: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Thread-Index: AQHSw4y4qV7yR/Gy6kGQdrOKlX57GKHhk7nwgABUS4CAAPRJgP//y4GQ Date: Wed, 3 May 2017 14:19:02 +0000 Message-ID: References: <20170428113946.5161041.83399.10532@sandvine.com> <670A9410-00F7-4883-B714-E0CA5E9A1234@deployingradius.com> <3ABC7A8B-00DD-4032-85F0-D712A5517622@deployingradius.com> In-Reply-To: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 14:21:43 -0000 RFC4282 is also obsolete, and RFC7542 explains the problems with it. I don't think we should introduce RFC4282 at this point. (And sorry, I don't see RFC 6377 referring to 4282) -----Original Message----- From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com= ]=20 Sent: Wednesday, May 3, 2017 9:21 AM To: Alan DeKok; Dave Dolson Cc: Yuval Lifshitz; jouni korhonen; dime@ietf.org list; draft-ietf-dime-rfc= 4006bis@ietf.org Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Hello all, For the new AVP, no question: RFC 7542 should be used. I have not the full overview of 3GPP specs used for reference to NAI, and b= ased on: - assuming the TS 23.003 (Numbering, addressing and identification) is an i= mportant spec to consider, the RFC 4282 is used - RFC 6377 DBP also referring to RFC 4282 =20 I would tend to agree on at least using RFC 4282 as the reference for the E= ND_USER_NAI in Subscription-Id-Type for RFC4006bis. Whether to directly refer to RFC7542, I cannot confirm whether this is acce= ptable or not. =20 BR Maryse -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com]=20 Sent: mercredi 3 mai 2017 00:47 To: Dave Dolson Cc: Yuval Lifshitz ; Gardella, Maryse (Nokia - FR/N= ozay) ; 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:51 PM, Dave Dolson wrote: >=20 > Thanks Alan. > Do I correctly hear you saying we should replace all references to RFC 24= 86 with RFC 7542? Yes. It's 2017. Independent of RFC 7542, *inter-operable* implementations jus= t have no business using non-UTF8 identifiers. Alan DeKok. From nobody Wed May 3 07:39:38 2017 Return-Path: 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 A4CE81275C5; Wed, 3 May 2017 07:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.702 X-Spam-Level: X-Spam-Status: No, score=-4.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 W4M-JYr7aXpw; Wed, 3 May 2017 07:39:33 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50107.outbound.protection.outlook.com [40.107.5.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F39C71200CF; Wed, 3 May 2017 07:36:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4Fv/ooiSct229TSsa+SW3mLUrrUBPG8ehH4dm6LCFGs=; b=RA6sNKvpHnwxnGBFqasNJmVbGP2+hw7Oo+7ilbV+nMK3HtY3O4t6m8INvx0g1XroFrPonAbNn2oeYaCnYSJ/zSDtIS2Q/7pMMtdEfO57YIQNRAF8NJkTeV3+3pCTp8ApMZiaK3AXPli6vUvWnVqExZzHtzTgfoGeqc8eTVEJ2E0= Received: from HE1PR0701MB2857.eurprd07.prod.outlook.com (10.168.91.147) by HE1PR0701MB2857.eurprd07.prod.outlook.com (10.168.91.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.1; Wed, 3 May 2017 14:36:35 +0000 Received: from HE1PR0701MB2857.eurprd07.prod.outlook.com ([10.168.91.147]) by HE1PR0701MB2857.eurprd07.prod.outlook.com ([10.168.91.147]) with mapi id 15.01.1075.010; Wed, 3 May 2017 14:36:35 +0000 From: "Gardella, Maryse (Nokia - FR/Nozay)" To: Dave Dolson , Alan DeKok CC: Yuval Lifshitz , jouni korhonen , "dime@ietf.org list" , "draft-ietf-dime-rfc4006bis@ietf.org" Thread-Topic: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Thread-Index: AQHSw4y3iSssb1Vk+0CBBkhlVtGV+aHhlVEAgAAPpYCAAO2PwIAAFs4AgAAE0rA= Date: Wed, 3 May 2017 14:36:35 +0000 Message-ID: References: <20170428113946.5161041.83399.10532@sandvine.com> <670A9410-00F7-4883-B714-E0CA5E9A1234@deployingradius.com> <3ABC7A8B-00DD-4032-85F0-D712A5517622@deployingradius.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sandvine.com; dkim=none (message not signed) header.d=none;sandvine.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.21] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2857; 7:Sqvq78tYOQ7rDy/twYntT9gj2xUa3DV2k1HZoxcXpstyDr7nyU80moxwDZH29T6NLTIRbqH53VkJtX0pheftFgNm40MWwl2luXCo2xdSMvpRI2v/cHP4JCPqwemalygjKfUPsot6jaX9R/CeC7dC2ikSiWW+CLTrKVE8AT6SZzwy39NQ8ioHETfNp2NdsFlXSkhc6ImQleCaTfSbE140zLOkbCyGdE7HJYAlXkQ5VOgB7jn9pvGCrOC/fw/NWTyPYgE9WB/bUpC3Vg78XJWzq1bVTlvuQcKfahAVTxIqefTq6kon8/UHbfgC6uy9vk7vZK2OEoAN+YQ4Jji5O95GyQ== x-ms-office365-filtering-correlation-id: be6442b2-1082-4e25-b6db-08d49231ccd9 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:HE1PR0701MB2857; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(82608151540597)(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:HE1PR0701MB2857; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2857; x-forefront-prvs: 029651C7A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39860400002)(39840400002)(39450400003)(39400400002)(39410400002)(13464003)(24454002)(53754006)(377454003)(6246003)(38730400002)(4326008)(229853002)(53546009)(25786009)(66066001)(39060400002)(2906002)(305945005)(3280700002)(7736002)(74316002)(2950100002)(189998001)(53936002)(3660700001)(8936002)(478600001)(102836003)(6116002)(3846002)(5660300001)(55016002)(99286003)(8676002)(81166006)(54906002)(6436002)(33656002)(86362001)(122556002)(9686003)(50986999)(76176999)(6506006)(7696004)(54356999)(77096006)(2900100001)(230783001)(93886004)(17413003); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2857; H:HE1PR0701MB2857.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2017 14:36:35.1933 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2857 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 14:39:36 -0000 My mistake, it should be RFC 6733 Maryse -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com]=20 Sent: mercredi 3 mai 2017 16:19 To: Gardella, Maryse (Nokia - FR/Nozay) ; Alan D= eKok Cc: Yuval Lifshitz ; jouni korhonen ; dime@ietf.org list ; draft-ietf-dime-rfc4006bis@i= etf.org Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 RFC4282 is also obsolete, and RFC7542 explains the problems with it. I don't think we should introduce RFC4282 at this point. (And sorry, I don't see RFC 6377 referring to 4282) -----Original Message----- From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com= ]=20 Sent: Wednesday, May 3, 2017 9:21 AM To: Alan DeKok; Dave Dolson Cc: Yuval Lifshitz; jouni korhonen; dime@ietf.org list; draft-ietf-dime-rfc= 4006bis@ietf.org Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Hello all, For the new AVP, no question: RFC 7542 should be used. I have not the full overview of 3GPP specs used for reference to NAI, and b= ased on: - assuming the TS 23.003 (Numbering, addressing and identification) is an i= mportant spec to consider, the RFC 4282 is used - RFC 6377 DBP also referring to RFC 4282 =20 I would tend to agree on at least using RFC 4282 as the reference for the E= ND_USER_NAI in Subscription-Id-Type for RFC4006bis. Whether to directly refer to RFC7542, I cannot confirm whether this is acce= ptable or not. =20 BR Maryse -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com]=20 Sent: mercredi 3 mai 2017 00:47 To: Dave Dolson Cc: Yuval Lifshitz ; Gardella, Maryse (Nokia - FR/N= ozay) ; 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:51 PM, Dave Dolson wrote: >=20 > Thanks Alan. > Do I correctly hear you saying we should replace all references to RFC 24= 86 with RFC 7542? Yes. It's 2017. Independent of RFC 7542, *inter-operable* implementations jus= t have no business using non-UTF8 identifiers. Alan DeKok. From nobody Wed May 3 07:55:34 2017 Return-Path: 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 B93D3129B42; Wed, 3 May 2017 07:55:31 -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 OTUyTK0hQtL2; Wed, 3 May 2017 07:55:29 -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 51BC312948F; Wed, 3 May 2017 07:52:42 -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; Wed, 3 May 2017 10:52:41 -0400 From: Yuval Lifshitz To: "Gardella, Maryse (Nokia - FR/Nozay)" , "Alan DeKok" , Dave Dolson CC: jouni korhonen , "dime@ietf.org list" , "draft-ietf-dime-rfc4006bis@ietf.org" , Yuval Lifshitz Thread-Topic: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Thread-Index: AQHSw4y42phkq1IZA0GgKzP7Ht2Kp6Hh2F8AgAAPpYCAAPRJgP//zCLw Date: Wed, 3 May 2017 14:52:40 +0000 Message-ID: References: <20170428113946.5161041.83399.10532@sandvine.com> <670A9410-00F7-4883-B714-E0CA5E9A1234@deployingradius.com> <3ABC7A8B-00DD-4032-85F0-D712A5517622@deployingradius.com> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.142.1] 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 14:55:32 -0000 Hi All, If 3GPP is already referencing RFC 4282, than, as Alan noted, the main comp= atibility issues is with using binary values in the unused bits of the asci= i chars - which probably wasn't their intent anyway. Other compatibility is= sues (e.g. maximum length) are actually discussed inside the spec. Think we can reference RFC 7542 for both the existing and the new AVP safel= y. Yuval -----Original Message----- From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com= ]=20 Sent: Wednesday, May 03, 2017 4:21 PM To: Alan DeKok; Dave Dolson Cc: Yuval Lifshitz; jouni korhonen; dime@ietf.org list; draft-ietf-dime-rfc= 4006bis@ietf.org Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Hello all, For the new AVP, no question: RFC 7542 should be used. I have not the full overview of 3GPP specs used for reference to NAI, and b= ased on: - assuming the TS 23.003 (Numbering, addressing and identification) is an i= mportant spec to consider, the RFC 4282 is used - RFC 6377 DBP also referring to RFC 4282 =20 I would tend to agree on at least using RFC 4282 as the reference for the E= ND_USER_NAI in Subscription-Id-Type for RFC4006bis. Whether to directly refer to RFC7542, I cannot confirm whether this is acce= ptable or not. =20 BR Maryse -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com]=20 Sent: mercredi 3 mai 2017 00:47 To: Dave Dolson Cc: Yuval Lifshitz ; Gardella, Maryse (Nokia - FR/N= ozay) ; 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:51 PM, Dave Dolson wrote: >=20 > Thanks Alan. > Do I correctly hear you saying we should replace all references to RFC 24= 86 with RFC 7542? Yes. It's 2017. Independent of RFC 7542, *inter-operable* implementations jus= t have no business using non-UTF8 identifiers. Alan DeKok. From nobody Fri May 5 11:04:57 2017 Return-Path: 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 44CBB129437; Fri, 5 May 2017 11:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, 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 B4JG9i2lYpxR; Fri, 5 May 2017 11:04:53 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A95B1286CA; Fri, 5 May 2017 11:04:53 -0700 (PDT) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by wtl-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Fri, 5 May 2017 14:04:51 -0400 From: Dave Dolson To: "Gardella, Maryse (Nokia - FR/Nozay)" , "Alan DeKok" CC: Yuval Lifshitz , jouni korhonen , "dime@ietf.org list" , "draft-ietf-dime-rfc4006bis@ietf.org" Thread-Topic: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Thread-Index: AQHSw4y4qV7yR/Gy6kGQdrOKlX57GKHhk7nwgABUS4CAAPRJgP//y4GQgABJeoCAAxT7wA== Date: Fri, 5 May 2017 18:04:50 +0000 Message-ID: References: <20170428113946.5161041.83399.10532@sandvine.com> <670A9410-00F7-4883-B714-E0CA5E9A1234@deployingradius.com> <3ABC7A8B-00DD-4032-85F0-D712A5517622@deployingradius.com> In-Reply-To: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 18:04:55 -0000 Maryse, Thanks for doing some research and pointing this out. In RFC 6733, RFC4282 is used for two things: 1. to define "Network Access Identifier", for use as realm names, which are= "piggybacked on the administration of the DNS namespace" - so DNS restrictions would have to apply here. 2. Defining User-Name AVP, which is a NAI, but specifically "of type UTF8St= ring ... in a format consistent with the NAI specification [RFC4282]" - (see section 8.14 of RFC6733) - so User-Name is defined to be the UTF8 subset of RFC4282. So I claim that although RFC4282 is mentioned, RFC6733 intends that user na= mes in Diameter be limited to UTF-8, hence compatible with RFC7542. -Dave -----Original Message----- From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com= ]=20 Sent: Wednesday, May 3, 2017 10:37 AM To: Dave Dolson; Alan DeKok Cc: Yuval Lifshitz; jouni korhonen; dime@ietf.org list; draft-ietf-dime-rfc= 4006bis@ietf.org Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 My mistake, it should be RFC 6733 Maryse -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com]=20 Sent: mercredi 3 mai 2017 16:19 To: Gardella, Maryse (Nokia - FR/Nozay) ; Alan D= eKok Cc: Yuval Lifshitz ; jouni korhonen ; dime@ietf.org list ; draft-ietf-dime-rfc4006bis@i= etf.org Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 RFC4282 is also obsolete, and RFC7542 explains the problems with it. I don't think we should introduce RFC4282 at this point. (And sorry, I don't see RFC 6377 referring to 4282) -----Original Message----- From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com= ]=20 Sent: Wednesday, May 3, 2017 9:21 AM To: Alan DeKok; Dave Dolson Cc: Yuval Lifshitz; jouni korhonen; dime@ietf.org list; draft-ietf-dime-rfc= 4006bis@ietf.org Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Hello all, For the new AVP, no question: RFC 7542 should be used. I have not the full overview of 3GPP specs used for reference to NAI, and b= ased on: - assuming the TS 23.003 (Numbering, addressing and identification) is an i= mportant spec to consider, the RFC 4282 is used - RFC 6377 DBP also referring to RFC 4282 =20 I would tend to agree on at least using RFC 4282 as the reference for the E= ND_USER_NAI in Subscription-Id-Type for RFC4006bis. Whether to directly refer to RFC7542, I cannot confirm whether this is acce= ptable or not. =20 BR Maryse -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com]=20 Sent: mercredi 3 mai 2017 00:47 To: Dave Dolson Cc: Yuval Lifshitz ; Gardella, Maryse (Nokia - FR/N= ozay) ; 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:51 PM, Dave Dolson wrote: >=20 > Thanks Alan. > Do I correctly hear you saying we should replace all references to RFC 24= 86 with RFC 7542? Yes. It's 2017. Independent of RFC 7542, *inter-operable* implementations jus= t have no business using non-UTF8 identifiers. Alan DeKok. From nobody Fri May 5 12:42:29 2017 Return-Path: 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 23BD312878D; Fri, 5 May 2017 12:42:28 -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 EbiYmFV4xuCe; Fri, 5 May 2017 12:42:25 -0700 (PDT) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C258126C25; Fri, 5 May 2017 12:42:25 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 09385120519; Fri, 5 May 2017 21:42:24 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id DA86860060; Fri, 5 May 2017 21:42:23 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0339.000; Fri, 5 May 2017 21:42:17 +0200 From: To: Dave Dolson , "Gardella, Maryse (Nokia - FR/Nozay)" , Alan DeKok CC: "dime@ietf.org list" , "draft-ietf-dime-rfc4006bis@ietf.org" Thread-Topic: =?iso-8859-1?Q?RE=A0:_Re:_[Dime]_[ALU]__WGLC_#1_for_draft-ietf-dime-rfc40?= =?iso-8859-1?Q?06bis-02?= Thread-Index: AQHSxdezncprdQlUnEmjPhv12RTPGQ== Date: Fri, 5 May 2017 19:42:16 +0000 Message-ID: <22018_1494013343_590CD59F_22018_16050_1_6B7134B31289DC4FAF731D844122B36E0C0E47C6@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <20170428113946.5161041.83399.10532@sandvine.com> <670A9410-00F7-4883-B714-E0CA5E9A1234@deployingradius.com> <3ABC7A8B-00DD-4032-85F0-D712A5517622@deployingradius.com> , In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E0C0E47C6OPEXCLILM43corp_" MIME-Version: 1.0 Archived-At: Subject: [Dime] =?iso-8859-1?q?RE=A0=3A_Re=3A__=5BALU=5D__WGLC_=231_for_dr?= =?iso-8859-1?q?aft-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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 19:42:28 -0000 --_000_6B7134B31289DC4FAF731D844122B36E0C0E47C6OPEXCLILM43corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, RFC 6733 was published before RFC 7542, obsoleting RFC 4282. It is why RFC = 4282 was still used as reference in RFC 6733. Using IETF rules, RFC 7242 should be used anyway for any Diameter implement= ation based on RFC 6733 and using NAI. Therefore, when updating RFC 4006, RFC 7242 should be used as reference. Regards, Lionel Le 5 mai 2017 20:05, Dave Dolson a =E9crit : Maryse, Thanks for doing some research and pointing this out. In RFC 6733, RFC4282 is used for two things: 1. to define "Network Access Identifier", for use as realm names, which are= "piggybacked on the administration of the DNS namespace" - so DNS restrictions would have to apply here. 2. Defining User-Name AVP, which is a NAI, but specifically "of type UTF8St= ring ... in a format consistent with the NAI specification [RFC4282]" - (see section 8.14 of RFC6733) - so User-Name is defined to be the UTF8 subset of RFC4282. So I claim that although RFC4282 is mentioned, RFC6733 intends that user na= mes in Diameter be limited to UTF-8, hence compatible with RFC7542. -Dave -----Original Message----- From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com] Sent: Wednesday, May 3, 2017 10:37 AM To: Dave Dolson; Alan DeKok Cc: Yuval Lifshitz; jouni korhonen; dime@ietf.org list; draft-ietf-dime-rfc= 4006bis@ietf.org Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 My mistake, it should be RFC 6733 Maryse -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: mercredi 3 mai 2017 16:19 To: Gardella, Maryse (Nokia - FR/Nozay) ; Alan D= eKok Cc: Yuval Lifshitz ; jouni korhonen ; dime@ietf.org list ; draft-ietf-dime-rfc4006bis@i= etf.org Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 RFC4282 is also obsolete, and RFC7542 explains the problems with it. I don't think we should introduce RFC4282 at this point. (And sorry, I don't see RFC 6377 referring to 4282) -----Original Message----- From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com] Sent: Wednesday, May 3, 2017 9:21 AM To: Alan DeKok; Dave Dolson Cc: Yuval Lifshitz; jouni korhonen; dime@ietf.org list; draft-ietf-dime-rfc= 4006bis@ietf.org Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Hello all, For the new AVP, no question: RFC 7542 should be used. I have not the full overview of 3GPP specs used for reference to NAI, and b= ased on: - assuming the TS 23.003 (Numbering, addressing and identification) is an i= mportant spec to consider, the RFC 4282 is used - RFC 6377 DBP also referring to RFC 4282 I would tend to agree on at least using RFC 4282 as the reference for the E= ND_USER_NAI in Subscription-Id-Type for RFC4006bis. Whether to directly refer to RFC7542, I cannot confirm whether this is acce= ptable or not. BR Maryse -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com] Sent: mercredi 3 mai 2017 00:47 To: Dave Dolson Cc: Yuval Lifshitz ; Gardella, Maryse (Nokia - FR/N= ozay) ; 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:51 PM, Dave Dolson wrote: > > Thanks Alan. > Do I correctly hear you saying we should replace all references to RFC 24= 86 with RFC 7542? Yes. It's 2017. Independent of RFC 7542, *inter-operable* implementations jus= t have no business using non-UTF8 identifiers. 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_6B7134B31289DC4FAF731D844122B36E0C0E47C6OPEXCLILM43corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

RFC 6733 was published before RFC 7542, obsoleting RFC 4282. It is why RFC = 4282 was still used as reference in RFC 6733.
Using IETF rules, RFC 7242 should be used anyway for any Diameter implement= ation based on RFC 6733 and using NAI.
Therefore, when updating RFC 4006, RFC 7242 should be used as reference.
Regards,

Lionel

Le 5 mai 2017 20:05, Dave Dolson <ddolson@sandvin= e.com> a =E9crit :
Maryse,
Thanks for doing some research and pointing this out.

In RFC 6733, RFC4282 is used for two things:
1. to define "Network Access Identifier", for use as realm names,= which are "piggybacked on the administration of the DNS namespace&quo= t;
- so DNS restrictions would have to apply here.

2. Defining User-Name AVP, which is a NAI, but specifically "of type U= TF8String ... in a format consistent with the NAI specification [RFC4282]&q= uot;
- (see section 8.14 of RFC6733)
- so User-Name is defined to be the UTF8 subset of RFC4282.

So I claim that although RFC4282 is mentioned, RFC6733 intends that user na= mes in Diameter be limited to UTF-8, hence compatible with RFC7542.


-Dave


-----Original Message-----
From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com]
Sent: Wednesday, May 3, 2017 10:37 AM
To: Dave Dolson; Alan DeKok
Cc: Yuval Lifshitz; jouni korhonen; dime@ietf.org list; draft-ietf-dime-rfc= 4006bis@ietf.org
Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

My mistake, it should be RFC 6733
Maryse

-----Original Message-----
From: Dave Dolson [mailto:ddolson@s= andvine.com]
Sent: mercredi 3 mai 2017 16:19
To: Gardella, Maryse (Nokia - FR/Nozay) <maryse.gardella@nokia.com>; = Alan DeKok <aland@deployingradius.com>
Cc: Yuval Lifshitz <ylifshitz@sandvine.com>; jouni korhonen <jouni= .nospam@gmail.com>; dime@ietf.org list <dime@ietf.org>; draft-ietf= -dime-rfc4006bis@ietf.org
Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

RFC4282 is also obsolete, and RFC7542 explains the problems with it.
I don't think we should introduce RFC4282 at this point.

(And sorry, I don't see RFC 6377 referring to 4282)


-----Original Message-----
From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com]
Sent: Wednesday, May 3, 2017 9:21 AM
To: Alan DeKok; Dave Dolson
Cc: Yuval Lifshitz; jouni korhonen; dime@ietf.org list; draft-ietf-dime-rfc= 4006bis@ietf.org
Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

Hello all,

For the new AVP, no question: RFC 7542 should be used.
I have not the full overview of 3GPP specs used for reference to NAI, and b= ased on:
- assuming the TS 23.003 (Numbering, addressing and identification) is an i= mportant spec to consider, the RFC 4282 is used
- RFC 6377 DBP also referring to RFC 4282
 
I would tend to agree on at least using RFC 4282 as the reference for the E= ND_USER_NAI in Subscription-Id-Type for RFC4006bis.
Whether to directly refer to RFC7542, I cannot confirm whether this is acce= ptable or not. 

BR
Maryse

-----Original Message-----
From: Alan DeKok [mailto:aland= @deployingradius.com]
Sent: mercredi 3 mai 2017 00:47
To: Dave Dolson <ddolson@sandvine.com>
Cc: Yuval Lifshitz <ylifshitz@sandvine.com>; Gardella, Maryse (Nokia = - FR/Nozay) <maryse.gardella@nokia.com>; jouni korhonen <jouni.nos= pam@gmail.com>; dime@ietf.org list <dime@ietf.org>; draft-ietf-dim= e-rfc4006bis@ietf.org
Subject: Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

On May 2, 2017, at 5:51 PM, Dave Dolson <ddolson@sandvine.com> wrote:=
>
> Thanks Alan.
> Do I correctly hear you saying we should replace all references to RFC= 2486 with RFC 7542?

  Yes.

  It's 2017.  Independent of RFC 7542, *inter-operable* implement= ations just have no business using non-UTF8 identifiers.

  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 confiden=
tielles 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 el=
ectroniques 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 inf=
ormation 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 dele=
te 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.
--_000_6B7134B31289DC4FAF731D844122B36E0C0E47C6OPEXCLILM43corp_-- From nobody Fri May 5 12:57:35 2017 Return-Path: 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 BDFE712878D; Fri, 5 May 2017 12:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 KiUJxgXy-y26; Fri, 5 May 2017 12:57:30 -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 0E3FE124217; Fri, 5 May 2017 12:57:30 -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; Fri, 5 May 2017 15:57:28 -0400 From: Dave Dolson To: "lionel.morand@orange.com" , "Gardella, Maryse (Nokia - FR/Nozay)" , Alan DeKok CC: "dime@ietf.org list" , "draft-ietf-dime-rfc4006bis@ietf.org" Thread-Topic: =?iso-8859-1?Q?RE=A0:_Re:_[Dime]_[ALU]__WGLC_#1_for_draft-ietf-dime-rfc40?= =?iso-8859-1?Q?06bis-02?= Thread-Index: AQHSw4y4qV7yR/Gy6kGQdrOKlX57GKHhk7nwgABUS4CAAPRJgP//y4GQgABJeoCAAxT7wIAAZRcA///AwQA= Date: Fri, 5 May 2017 19:57:27 +0000 Message-ID: References: <20170428113946.5161041.83399.10532@sandvine.com> <670A9410-00F7-4883-B714-E0CA5E9A1234@deployingradius.com> <3ABC7A8B-00DD-4032-85F0-D712A5517622@deployingradius.com> , <22018_1494013343_590CD59F_22018_16050_1_6B7134B31289DC4FAF731D844122B36E0C0E47C6@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: <22018_1494013343_590CD59F_22018_16050_1_6B7134B31289DC4FAF731D844122B36E0C0E47C6@OPEXCLILM43.corporate.adroot.infra.ftgroup> 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: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E98705CC43Fwtlexchp1sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] =?iso-8859-1?q?RE=A0=3A_Re=3A__=5BALU=5D__WGLC_=231_for_d?= =?iso-8859-1?q?raft-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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 19:57:33 -0000 --_000_E8355113905631478EFF04F5AA706E98705CC43Fwtlexchp1sandvi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lionel, OK, thanks. I'll make the changes. -Dave From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] Sent: Friday, May 5, 2017 3:42 PM To: Dave Dolson; Gardella, Maryse (Nokia - FR/Nozay); Alan DeKok Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ietf.org Subject: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Hi, RFC 6733 was published before RFC 7542, obsoleting RFC 4282. It is why RFC = 4282 was still used as reference in RFC 6733. Using IETF rules, RFC 7242 should be used anyway for any Diameter implement= ation based on RFC 6733 and using NAI. Therefore, when updating RFC 4006, RFC 7242 should be used as reference. Regards, Lionel Le 5 mai 2017 20:05, Dave Dolson > a =E9crit : Maryse, Thanks for doing some research and pointing this out. In RFC 6733, RFC4282 is used for two things: 1. to define "Network Access Identifier", for use as realm names, which are= "piggybacked on the administration of the DNS namespace" - so DNS restrictions would have to apply here. 2. Defining User-Name AVP, which is a NAI, but specifically "of type UTF8St= ring ... in a format consistent with the NAI specification [RFC4282]" - (see section 8.14 of RFC6733) - so User-Name is defined to be the UTF8 subset of RFC4282. So I claim that although RFC4282 is mentioned, RFC6733 intends that user na= mes in Diameter be limited to UTF-8, hence compatible with RFC7542. -Dave -----Original Message----- From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com= ] Sent: Wednesday, May 3, 2017 10:37 AM To: Dave Dolson; Alan DeKok Cc: Yuval Lifshitz; jouni korhonen; dime@ietf.org lis= t; draft-ietf-dime-rfc4006bis@ietf.org Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 My mistake, it should be RFC 6733 Maryse -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: mercredi 3 mai 2017 16:19 To: Gardella, Maryse (Nokia - FR/Nozay) >; Alan DeKok > Cc: Yuval Lifshitz >;= jouni korhonen >; di= me@ietf.org list = >; draft-ietf-dime-rfc4006bis@ietf.org Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 RFC4282 is also obsolete, and RFC7542 explains the problems with it. I don't think we should introduce RFC4282 at this point. (And sorry, I don't see RFC 6377 referring to 4282) -----Original Message----- From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com= ] Sent: Wednesday, May 3, 2017 9:21 AM To: Alan DeKok; Dave Dolson Cc: Yuval Lifshitz; jouni korhonen; dime@ietf.org lis= t; draft-ietf-dime-rfc4006bis@ietf.org Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Hello all, For the new AVP, no question: RFC 7542 should be used. I have not the full overview of 3GPP specs used for reference to NAI, and b= ased on: - assuming the TS 23.003 (Numbering, addressing and identification) is an i= mportant spec to consider, the RFC 4282 is used - RFC 6377 DBP also referring to RFC 4282 I would tend to agree on at least using RFC 4282 as the reference for the E= ND_USER_NAI in Subscription-Id-Type for RFC4006bis. Whether to directly refer to RFC7542, I cannot confirm whether this is acce= ptable or not. BR Maryse -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com] Sent: mercredi 3 mai 2017 00:47 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:51 PM, Dave Dolson > wrote: > > Thanks Alan. > Do I correctly hear you saying we should replace all references to RFC 24= 86 with RFC 7542? Yes. It's 2017. Independent of RFC 7542, *inter-operable* implementations jus= t have no business using non-UTF8 identifiers. 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_E8355113905631478EFF04F5AA706E98705CC43Fwtlexchp1sandvi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Lionel,=

OK, thanks. I’ll ma= ke the changes.

 <= /p>

-Dave

 <= /p>

 <= /p>

From: lionel.m= orand@orange.com [mailto:lionel.morand@orange.com]
Sent: Friday, May 5, 2017 3:42 PM
To: Dave Dolson; Gardella, Maryse (Nokia - FR/Nozay); Alan DeKok
Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ietf.org
Subject: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4= 006bis-02

 

Hi,

RFC 6733 was published before RFC 7542, obsoleting RFC 4282. It is why RFC = 4282 was still used as reference in RFC 6733.
Using IETF rules, RFC 7242 should be used anyway for any Diameter implement= ation based on RFC 6733 and using NAI.
Therefore, when updating RFC 4006, RFC 7242 should be used as reference.
Regards,

Lionel

Le 5 mai 2017 20:05, Dave Dolson <ddolson@sandvine.com> a =E9crit :

Maryse,
Thanks for doing some research and pointing this out.

In RFC 6733, RFC4282 is used for two things:
1. to define "Network Access Identifier", for use as realm names,= which are "piggybacked on the administration of the DNS namespace&quo= t;
- so DNS restrictions would have to apply here.

2. Defining User-Name AVP, which is a NAI, but specifically "of type U= TF8String ... in a format consistent with the NAI specification [RFC4282]&q= uot;
- (see section 8.14 of RFC6733)
- so User-Name is defined to be the UTF8 subset of RFC4282.

So I claim that although RFC4282 is mentioned, RFC6733 intends that user na= mes in Diameter be limited to UTF-8, hence compatible with RFC7542.


-Dave


-----Original Message-----
From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com]
Sent: Wednesday, May 3, 2017 10:37 AM
To: Dave Dolson; Alan DeKok
Cc: Yuval Lifshitz; jouni korhonen; dime@i= etf.org list; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

My mistake, it should be RFC 6733
Maryse

-----Original Message-----
From: Dave Dolson [mailto:ddolson@s= andvine.com]
Sent: mercredi 3 mai 2017 16:19
To: Gardella, Maryse (Nokia - FR/Nozay) <maryse.gardella@nokia.com>; Alan DeKok <aland@deployingradius.com>
Cc: Yuval Lifshitz <ylifshitz@= sandvine.com>; jouni korhonen <jouni.nospam@gmail.com>; dime@ietf.org list <dime@ietf.org>; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

RFC4282 is also obsolete, and RFC7542 explains the problems with it.
I don't think we should introduce RFC4282 at this point.

(And sorry, I don't see RFC 6377 referring to 4282)


-----Original Message-----
From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com]
Sent: Wednesday, May 3, 2017 9:21 AM
To: Alan DeKok; Dave Dolson
Cc: Yuval Lifshitz; jouni korhonen; dime@i= etf.org list; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

Hello all,

For the new AVP, no question: RFC 7542 should be used.
I have not the full overview of 3GPP specs used for reference to NAI, and b= ased on:
- assuming the TS 23.003 (Numbering, addressing and identification) is an i= mportant spec to consider, the RFC 4282 is used
- RFC 6377 DBP also referring to RFC 4282
 
I would tend to agree on at least using RFC 4282 as the reference for the E= ND_USER_NAI in Subscription-Id-Type for RFC4006bis.
Whether to directly refer to RFC7542, I cannot confirm whether this is acce= ptable or not. 

BR
Maryse

-----Original Message-----
From: Alan DeKok [mailto:aland= @deployingradius.com]
Sent: mercredi 3 mai 2017 00:47
To: Dave Dolson <ddolson@sandvin= e.com>
Cc: Yuval Lifshitz <ylifshitz@= sandvine.com>; Gardella, Maryse (Nokia - FR/Nozay) <maryse.gardella@nokia.com>; jouni ko= rhonen <jouni.nospam@gmail.com= >; dime@ietf.org list <dime@ietf.org>; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

On May 2, 2017, at 5:51 PM, Dave Dolson <ddolson@sandvine.com> wrote:
>
> Thanks Alan.
> Do I correctly hear you saying we should replace all references to RFC= 2486 with RFC 7542?

  Yes.

  It's 2017.  Independent of RFC 7542, *inter-operable* implement= ations just have no business using non-UTF8 identifiers.

  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 con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.
--_000_E8355113905631478EFF04F5AA706E98705CC43Fwtlexchp1sandvi_-- From nobody Fri May 5 23:59:41 2017 Return-Path: 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 6F48E1292AE; Fri, 5 May 2017 23:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 z67Ad6hScEcD; Fri, 5 May 2017 23:59:36 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0096.outbound.protection.outlook.com [104.47.2.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 841AB129353; Fri, 5 May 2017 23:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KyxHWwQUVFFKds04Htd0WCqNlNd3l9GXXb6jTyfPvk0=; b=NfJpAQ9flNoKSfMFX73uEUm9bE7pCtM9QRYGNDcojvzFZpxFY6tpuFtUZQ3dO5qixPm24eMhRqHzm1Agi+dXj/6Ui5EFTSf4AqaUMX3g6/rTp62NKiKtmsS9RS5WU3R2ANdg8UWQUZ0mInLKJdxf46iX5PNw5nmh7pRiMaLtuZY= Received: from HE1PR0701MB2857.eurprd07.prod.outlook.com (10.168.91.147) by HE1PR0701MB2857.eurprd07.prod.outlook.com (10.168.91.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Sat, 6 May 2017 06:59:32 +0000 Received: from HE1PR0701MB2857.eurprd07.prod.outlook.com ([10.168.91.147]) by HE1PR0701MB2857.eurprd07.prod.outlook.com ([10.168.91.147]) with mapi id 15.01.1084.011; Sat, 6 May 2017 06:59:32 +0000 From: "Gardella, Maryse (Nokia - FR/Nozay)" To: Dave Dolson , "lionel.morand@orange.com" , Alan DeKok CC: "dime@ietf.org list" , "draft-ietf-dime-rfc4006bis@ietf.org" Thread-Topic: =?iso-8859-1?Q?RE=A0:_Re:_[Dime]_[ALU]__WGLC_#1_for_draft-ietf-dime-rfc40?= =?iso-8859-1?Q?06bis-02?= Thread-Index: AQHSw4y3iSssb1Vk+0CBBkhlVtGV+aHhlVEAgAAPpYCAAO2PwIAAFs4AgAAE0rCAA17uAIAAGzkAgAAEPoCAALfEcA== Date: Sat, 6 May 2017 06:59:31 +0000 Message-ID: References: <20170428113946.5161041.83399.10532@sandvine.com> <670A9410-00F7-4883-B714-E0CA5E9A1234@deployingradius.com> <3ABC7A8B-00DD-4032-85F0-D712A5517622@deployingradius.com> , <22018_1494013343_590CD59F_22018_16050_1_6B7134B31289DC4FAF731D844122B36E0C0E47C6@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sandvine.com; dkim=none (message not signed) header.d=none;sandvine.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [213.174.99.139] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2857; 7:FAnY4kdTpIbichyXC+MW9M1HfAtl4U6yaniH0jFypEnAvsaSTp5eUBUQuWCqAwFJLgwHi661cy50JdRVshzT/kkII0em4Mkl/eDcAR5JIB/PqY6Y4rxwiS25ko9cL6PF7P3VpSieg46pebrYVHb0YSDgnehXof6Zdr+e8BpEmcaREIUONZsfuHx2OE8Myjl39XcB4W3OJUQFTQVphONCf2QDesN0pRmLMizugcGxVoN/9VRsdgoatmvhmggBQ50HLCagD4+poZuSyrDKAf9nRLDeiBZmD1yT2ZD0/s3FLcdxklgejArKkzzmRywSzNStuREPZfiGmVP1uXYzBBZPsA== x-ms-office365-filtering-correlation-id: 5db0fadf-f323-421e-d191-08d4944d728e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:HE1PR0701MB2857; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(82608151540597)(788757137089)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700033)(100105000095)(100000701033)(100105300095)(100000702033)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(100000703033)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123558100)(20161123562025)(20161123560025)(20161123564025)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(20161123555025)(6072148)(100000704033)(100105200095)(100000705033)(100105500095); SRVR:HE1PR0701MB2857; BCL:0; PCL:0; RULEID:(100000800033)(100110000095)(100000801033)(100110300095)(100000802033)(100110100095)(100000803033)(100110400095)(100000804033)(100110200095)(100000805033)(100110500095); SRVR:HE1PR0701MB2857; x-forefront-prvs: 029976C540 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(39410400002)(39400400002)(39850400002)(39860400002)(39450400003)(39840400002)(24454002)(53754006)(13464003)(377454003)(122556002)(3660700001)(6506006)(7736002)(7906003)(229853002)(86362001)(3280700002)(74316002)(76176999)(606005)(230783001)(54356999)(50986999)(5660300001)(6436002)(33656002)(790700001)(4326008)(7696004)(38730400002)(25786009)(2900100001)(6246003)(53546009)(189998001)(77096006)(2501003)(5890100001)(19609705001)(81166006)(53936002)(2950100002)(55016002)(99286003)(3846002)(6116002)(9686003)(93886004)(6306002)(8936002)(54896002)(54906002)(508600001)(2906002)(102836003)(66066001)(236005)(17413003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2857; H:HE1PR0701MB2857.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB28575BA9E7D33BC1E18D7FDCFCE80HE1PR0701MB2857_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2017 06:59:31.9966 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2857 Archived-At: Subject: Re: [Dime] =?iso-8859-1?q?RE=A0=3A_Re=3A__=5BALU=5D__WGLC_=231_for_d?= =?iso-8859-1?q?raft-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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 06:59:39 -0000 --_000_HE1PR0701MB28575BA9E7D33BC1E18D7FDCFCE80HE1PR0701MB2857_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Therefore it makes sense to do so. Thanks Maryse From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: vendredi 5 mai 2017 21:57 To: lionel.morand@orange.com; Gardella, Maryse (Nokia - FR/Nozay) ; Alan DeKok Cc: dime@ietf.org list ; draft-ietf-dime-rfc4006bis@ietf.org Subject: RE: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-0= 2 Lionel, OK, thanks. I'll make the changes. -Dave From: lionel.morand@orange.com [mailto:lio= nel.morand@orange.com] Sent: Friday, May 5, 2017 3:42 PM To: Dave Dolson; Gardella, Maryse (Nokia - FR/Nozay); Alan DeKok Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ie= tf.org Subject: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Hi, RFC 6733 was published before RFC 7542, obsoleting RFC 4282. It is why RFC = 4282 was still used as reference in RFC 6733. Using IETF rules, RFC 7242 should be used anyway for any Diameter implement= ation based on RFC 6733 and using NAI. Therefore, when updating RFC 4006, RFC 7242 should be used as reference. Regards, Lionel Le 5 mai 2017 20:05, Dave Dolson > a =E9crit : Maryse, Thanks for doing some research and pointing this out. In RFC 6733, RFC4282 is used for two things: 1. to define "Network Access Identifier", for use as realm names, which are= "piggybacked on the administration of the DNS namespace" - so DNS restrictions would have to apply here. 2. Defining User-Name AVP, which is a NAI, but specifically "of type UTF8St= ring ... in a format consistent with the NAI specification [RFC4282]" - (see section 8.14 of RFC6733) - so User-Name is defined to be the UTF8 subset of RFC4282. So I claim that although RFC4282 is mentioned, RFC6733 intends that user na= mes in Diameter be limited to UTF-8, hence compatible with RFC7542. -Dave -----Original Message----- From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com= ] Sent: Wednesday, May 3, 2017 10:37 AM To: Dave Dolson; Alan DeKok Cc: Yuval Lifshitz; jouni korhonen; dime@ietf.org lis= t; draft-ietf-dime-rfc4006bis@ietf.org Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 My mistake, it should be RFC 6733 Maryse -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: mercredi 3 mai 2017 16:19 To: Gardella, Maryse (Nokia - FR/Nozay) >; Alan DeKok > Cc: Yuval Lifshitz >;= jouni korhonen >; di= me@ietf.org list = >; draft-ietf-dime-rfc4006bis@ietf.org Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 RFC4282 is also obsolete, and RFC7542 explains the problems with it. I don't think we should introduce RFC4282 at this point. (And sorry, I don't see RFC 6377 referring to 4282) -----Original Message----- From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com= ] Sent: Wednesday, May 3, 2017 9:21 AM To: Alan DeKok; Dave Dolson Cc: Yuval Lifshitz; jouni korhonen; dime@ietf.org lis= t; draft-ietf-dime-rfc4006bis@ietf.org Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Hello all, For the new AVP, no question: RFC 7542 should be used. I have not the full overview of 3GPP specs used for reference to NAI, and b= ased on: - assuming the TS 23.003 (Numbering, addressing and identification) is an i= mportant spec to consider, the RFC 4282 is used - RFC 6377 DBP also referring to RFC 4282 I would tend to agree on at least using RFC 4282 as the reference for the E= ND_USER_NAI in Subscription-Id-Type for RFC4006bis. Whether to directly refer to RFC7542, I cannot confirm whether this is acce= ptable or not. BR Maryse -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com] Sent: mercredi 3 mai 2017 00:47 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:51 PM, Dave Dolson > wrote: > > Thanks Alan. > Do I correctly hear you saying we should replace all references to RFC 24= 86 with RFC 7542? Yes. It's 2017. Independent of RFC 7542, *inter-operable* implementations jus= t have no business using non-UTF8 identifiers. 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_HE1PR0701MB28575BA9E7D33BC1E18D7FDCFCE80HE1PR0701MB2857_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Therefore it makes sense to do so.

 

Thanks

Maryse

 

From: Dave Dolson [mailto:ddolson@sa= ndvine.com]
Sent: vendredi 5 mai 2017 21:57
To: lionel.morand@orange.com; Gardella, Maryse (Nokia - FR/Nozay) &l= t;maryse.gardella@nokia.com>; Alan DeKok <aland@deployingradius.com&g= t;
Cc: dime@ietf.org list <dime@ietf.org>; draft-ietf-dime-rfc400= 6bis@ietf.org
Subject: RE: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-= rfc4006bis-02

 

Lionel,

OK, thanks. I’ll make the chang= es.

 

-Dave

 

 

From: lionel.morand@orange.com [<= a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<= /a>]
Sent: Friday, May 5, 2017 3:42 PM
To: Dave Dolson; Gardella, Maryse (Nokia - FR/Nozay); Alan DeKok
Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ietf.org
Subject: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4= 006bis-02

 

Hi,

RFC 6733 was published before RFC 7542, obsoleting RFC 4282. It is why RFC = 4282 was still used as reference in RFC 6733.
Using IETF rules, RFC 7242 should be used anyway for any Diameter implement= ation based on RFC 6733 and using NAI.
Therefore, when updating RFC 4006, RFC 7242 should be used as reference.
Regards,

Lionel

Le 5 mai 2017 20:05, Dave Dolson <ddolson@sandvine.com> a =E9crit :

Maryse,
Thanks for doing some research and pointing this out.

In RFC 6733, RFC4282 is used for two things:
1. to define "Network Access Identifier", for use as realm names,= which are "piggybacked on the administration of the DNS namespace&quo= t;
- so DNS restrictions would have to apply here.

2. Defining User-Name AVP, which is a NAI, but specifically "of type U= TF8String ... in a format consistent with the NAI specification [RFC4282]&q= uot;
- (see section 8.14 of RFC6733)
- so User-Name is defined to be the UTF8 subset of RFC4282.

So I claim that although RFC4282 is mentioned, RFC6733 intends that user na= mes in Diameter be limited to UTF-8, hence compatible with RFC7542.


-Dave


-----Original Message-----
From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com]
Sent: Wednesday, May 3, 2017 10:37 AM
To: Dave Dolson; Alan DeKok
Cc: Yuval Lifshitz; jouni korhonen; dime@i= etf.org list; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

My mistake, it should be RFC 6733
Maryse

-----Original Message-----
From: Dave Dolson [mailto:ddolson@s= andvine.com]
Sent: mercredi 3 mai 2017 16:19
To: Gardella, Maryse (Nokia - FR/Nozay) <maryse.gardella@nokia.com>; Alan DeKok <aland@deployingradius.com>
Cc: Yuval Lifshitz <ylifshitz@= sandvine.com>; jouni korhonen <jouni.nospam@gmail.com>; dime@ietf.org list <dime@ietf.org>; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

RFC4282 is also obsolete, and RFC7542 explains the problems with it.
I don't think we should introduce RFC4282 at this point.

(And sorry, I don't see RFC 6377 referring to 4282)


-----Original Message-----
From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com]
Sent: Wednesday, May 3, 2017 9:21 AM
To: Alan DeKok; Dave Dolson
Cc: Yuval Lifshitz; jouni korhonen; dime@i= etf.org list; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

Hello all,

For the new AVP, no question: RFC 7542 should be used.
I have not the full overview of 3GPP specs used for reference to NAI, and b= ased on:
- assuming the TS 23.003 (Numbering, addressing and identification) is an i= mportant spec to consider, the RFC 4282 is used
- RFC 6377 DBP also referring to RFC 4282
 
I would tend to agree on at least using RFC 4282 as the reference for the E= ND_USER_NAI in Subscription-Id-Type for RFC4006bis.
Whether to directly refer to RFC7542, I cannot confirm whether this is acce= ptable or not. 

BR
Maryse

-----Original Message-----
From: Alan DeKok [mailto:aland= @deployingradius.com]
Sent: mercredi 3 mai 2017 00:47
To: Dave Dolson <ddolson@sandvin= e.com>
Cc: Yuval Lifshitz <ylifshitz@= sandvine.com>; Gardella, Maryse (Nokia - FR/Nozay) <maryse.gardella@nokia.com>; jouni ko= rhonen <jouni.nospam@gmail.com= >; dime@ietf.org list <dime@ietf.org>; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

On May 2, 2017, at 5:51 PM, Dave Dolson <ddolson@sandvine.com> wrote:
>
> Thanks Alan.
> Do I correctly hear you saying we should replace all references to RFC= 2486 with RFC 7542?

  Yes.

  It's 2017.  Independent of RFC 7542, *inter-operable* implement= ations just have no business using non-UTF8 identifiers.

  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 con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.
--_000_HE1PR0701MB28575BA9E7D33BC1E18D7FDCFCE80HE1PR0701MB2857_-- From nobody Thu May 11 07:57:34 2017 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1854129B6C; Thu, 11 May 2017 07:57:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dime@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149451464780.16728.734238112522313901@ietfa.amsl.com> Date: Thu, 11 May 2017 07:57:27 -0700 Archived-At: Subject: [Dime] I-D Action: draft-ietf-dime-rfc4006bis-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 14:57:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions of the IETF. Title : Diameter Credit-Control Application Authors : Lyle Bertz David Dolson Yuval Lifshitz Filename : draft-ietf-dime-rfc4006bis-03.txt Pages : 121 Date : 2017-05-11 Abstract: This document specifies a Diameter application that can be used to implement real-time credit-control for a variety of end user services such as network access, Session Initiation Protocol (SIP) services, messaging services, and download services. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dime-rfc4006bis-03 https://datatracker.ietf.org/doc/html/draft-ietf-dime-rfc4006bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-rfc4006bis-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 11 08:10:12 2017 Return-Path: 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 1F7191314E4; Thu, 11 May 2017 08:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 db3UMr2a3Vgi; Thu, 11 May 2017 08:10:07 -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 6B40012ECA4; Thu, 11 May 2017 08:03:05 -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; Thu, 11 May 2017 11:03:04 -0400 From: Dave Dolson To: "Gardella, Maryse (Nokia - FR/Nozay)" , "lionel.morand@orange.com" , Alan DeKok CC: "dime@ietf.org list" , "draft-ietf-dime-rfc4006bis@ietf.org" Thread-Topic: =?iso-8859-1?Q?RE=A0:_Re:_[Dime]_[ALU]__WGLC_#1_for_draft-ietf-dime-rfc40?= =?iso-8859-1?Q?06bis-02?= Thread-Index: AQHSw4y4qV7yR/Gy6kGQdrOKlX57GKHhk7nwgABUS4CAAPRJgP//y4GQgABJeoCAAxT7wIAAZRcA///AwQCAAPx4gIAIHk0w Date: Thu, 11 May 2017 15:03:03 +0000 Message-ID: References: <20170428113946.5161041.83399.10532@sandvine.com> <670A9410-00F7-4883-B714-E0CA5E9A1234@deployingradius.com> <3ABC7A8B-00DD-4032-85F0-D712A5517622@deployingradius.com> , <22018_1494013343_590CD59F_22018_16050_1_6B7134B31289DC4FAF731D844122B36E0C0E47C6@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: 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: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E98705D5C47wtlexchp1sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] =?iso-8859-1?q?RE=A0=3A_Re=3A__=5BALU=5D__WGLC_=231_for_d?= =?iso-8859-1?q?raft-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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 15:10:10 -0000 --_000_E8355113905631478EFF04F5AA706E98705D5C47wtlexchp1sandvi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have uploaded version -03 with the agreed changes to simply replace the r= eference with RFC7542. https://tools.ietf.org/html/draft-ietf-dime-rfc4006bis-03 From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com= ] Sent: Saturday, May 6, 2017 3:00 AM To: Dave Dolson; lionel.morand@orange.com; Alan DeKok Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ietf.org Subject: RE: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-0= 2 Hi all, Therefore it makes sense to do so. Thanks Maryse From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: vendredi 5 mai 2017 21:57 To: lionel.morand@orange.com; Gardella, Ma= ryse (Nokia - FR/Nozay) >; Alan DeKok > Cc: dime@ietf.org list >; draft-ietf-dime-rfc4006bis@ietf.org Subject: RE: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-0= 2 Lionel, OK, thanks. I'll make the changes. -Dave From: lionel.morand@orange.com [mailto:lio= nel.morand@orange.com] Sent: Friday, May 5, 2017 3:42 PM To: Dave Dolson; Gardella, Maryse (Nokia - FR/Nozay); Alan DeKok Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ie= tf.org Subject: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Hi, RFC 6733 was published before RFC 7542, obsoleting RFC 4282. It is why RFC = 4282 was still used as reference in RFC 6733. Using IETF rules, RFC 7242 should be used anyway for any Diameter implement= ation based on RFC 6733 and using NAI. Therefore, when updating RFC 4006, RFC 7242 should be used as reference. Regards, Lionel Le 5 mai 2017 20:05, Dave Dolson > a =E9crit : Maryse, Thanks for doing some research and pointing this out. In RFC 6733, RFC4282 is used for two things: 1. to define "Network Access Identifier", for use as realm names, which are= "piggybacked on the administration of the DNS namespace" - so DNS restrictions would have to apply here. 2. Defining User-Name AVP, which is a NAI, but specifically "of type UTF8St= ring ... in a format consistent with the NAI specification [RFC4282]" - (see section 8.14 of RFC6733) - so User-Name is defined to be the UTF8 subset of RFC4282. So I claim that although RFC4282 is mentioned, RFC6733 intends that user na= mes in Diameter be limited to UTF-8, hence compatible with RFC7542. -Dave -----Original Message----- From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com= ] Sent: Wednesday, May 3, 2017 10:37 AM To: Dave Dolson; Alan DeKok Cc: Yuval Lifshitz; jouni korhonen; dime@ietf.org lis= t; draft-ietf-dime-rfc4006bis@ietf.org Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 My mistake, it should be RFC 6733 Maryse -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: mercredi 3 mai 2017 16:19 To: Gardella, Maryse (Nokia - FR/Nozay) >; Alan DeKok > Cc: Yuval Lifshitz >;= jouni korhonen >; di= me@ietf.org list = >; draft-ietf-dime-rfc4006bis@ietf.org Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 RFC4282 is also obsolete, and RFC7542 explains the problems with it. I don't think we should introduce RFC4282 at this point. (And sorry, I don't see RFC 6377 referring to 4282) -----Original Message----- From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com= ] Sent: Wednesday, May 3, 2017 9:21 AM To: Alan DeKok; Dave Dolson Cc: Yuval Lifshitz; jouni korhonen; dime@ietf.org lis= t; draft-ietf-dime-rfc4006bis@ietf.org Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02 Hello all, For the new AVP, no question: RFC 7542 should be used. I have not the full overview of 3GPP specs used for reference to NAI, and b= ased on: - assuming the TS 23.003 (Numbering, addressing and identification) is an i= mportant spec to consider, the RFC 4282 is used - RFC 6377 DBP also referring to RFC 4282 I would tend to agree on at least using RFC 4282 as the reference for the E= ND_USER_NAI in Subscription-Id-Type for RFC4006bis. Whether to directly refer to RFC7542, I cannot confirm whether this is acce= ptable or not. BR Maryse -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com] Sent: mercredi 3 mai 2017 00:47 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:51 PM, Dave Dolson > wrote: > > Thanks Alan. > Do I correctly hear you saying we should replace all references to RFC 24= 86 with RFC 7542? Yes. It's 2017. Independent of RFC 7542, *inter-operable* implementations jus= t have no business using non-UTF8 identifiers. 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 confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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. --_000_E8355113905631478EFF04F5AA706E98705D5C47wtlexchp1sandvi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I have uploaded version -= 03 with the agreed changes to simply replace the reference with RFC7542.

https://tools.ietf.org/html/dr= aft-ietf-dime-rfc4006bis-03

 <= /p>

 <= /p>

From: Gardella= , Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com]
Sent: Saturday, May 6, 2017 3:00 AM
To: Dave Dolson; lionel.morand@orange.com; Alan DeKok
Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ietf.org
Subject: RE: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-= rfc4006bis-02

 

Hi all,

 

Therefore it makes sense to do so.

 

Thanks

Maryse

 

From: Dave D= olson [mailto:ddolson@sandvine.com<= /a>]
Sent: vendredi 5 mai 2017 21:57
To: lionel.morand@orange= .com; Gardella, Maryse (Nokia - FR/Nozay) <maryse.gardella@nokia.com>; Alan DeKok <aland@deployingradius.com> Cc: dime@ietf.org list <dime@ietf.org>; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: RE: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-= rfc4006bis-02

 

Lionel,=

OK, thanks. I’ll ma= ke the changes.

 <= /p>

-Dave

 <= /p>

 <= /p>

From: lionel.morand@orange.com [<= a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<= /a>]
Sent: Friday, May 5, 2017 3:42 PM
To: Dave Dolson; Gardella, Maryse (Nokia - FR/Nozay); Alan DeKok
Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ietf.org
Subject: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4= 006bis-02

 

Hi,

RFC 6733 was published before RFC 7542, obsoleting RFC 4282. It is why RFC = 4282 was still used as reference in RFC 6733.
Using IETF rules, RFC 7242 should be used anyway for any Diameter implement= ation based on RFC 6733 and using NAI.
Therefore, when updating RFC 4006, RFC 7242 should be used as reference.
Regards,

Lionel

Le 5 mai 2017 20:05, Dave Dolson <ddolson@sandvine.com> a =E9crit :

Maryse,
Thanks for doing some research and pointing this out.

In RFC 6733, RFC4282 is used for two things:
1. to define "Network Access Identifier", for use as realm names,= which are "piggybacked on the administration of the DNS namespace&quo= t;
- so DNS restrictions would have to apply here.

2. Defining User-Name AVP, which is a NAI, but specifically "of type U= TF8String ... in a format consistent with the NAI specification [RFC4282]&q= uot;
- (see section 8.14 of RFC6733)
- so User-Name is defined to be the UTF8 subset of RFC4282.

So I claim that although RFC4282 is mentioned, RFC6733 intends that user na= mes in Diameter be limited to UTF-8, hence compatible with RFC7542.


-Dave


-----Original Message-----
From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com]
Sent: Wednesday, May 3, 2017 10:37 AM
To: Dave Dolson; Alan DeKok
Cc: Yuval Lifshitz; jouni korhonen; dime@i= etf.org list; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

My mistake, it should be RFC 6733
Maryse

-----Original Message-----
From: Dave Dolson [mailto:ddolson@s= andvine.com]
Sent: mercredi 3 mai 2017 16:19
To: Gardella, Maryse (Nokia - FR/Nozay) <maryse.gardella@nokia.com>; Alan DeKok <aland@deployingradius.com>
Cc: Yuval Lifshitz <ylifshitz@= sandvine.com>; jouni korhonen <jouni.nospam@gmail.com>; dime@ietf.org list <dime@ietf.org>; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

RFC4282 is also obsolete, and RFC7542 explains the problems with it.
I don't think we should introduce RFC4282 at this point.

(And sorry, I don't see RFC 6377 referring to 4282)


-----Original Message-----
From: Gardella, Maryse (Nokia - FR/Nozay) [mailto:maryse.gardella@nokia.com]
Sent: Wednesday, May 3, 2017 9:21 AM
To: Alan DeKok; Dave Dolson
Cc: Yuval Lifshitz; jouni korhonen; dime@i= etf.org list; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: RE: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

Hello all,

For the new AVP, no question: RFC 7542 should be used.
I have not the full overview of 3GPP specs used for reference to NAI, and b= ased on:
- assuming the TS 23.003 (Numbering, addressing and identification) is an i= mportant spec to consider, the RFC 4282 is used
- RFC 6377 DBP also referring to RFC 4282
 
I would tend to agree on at least using RFC 4282 as the reference for the E= ND_USER_NAI in Subscription-Id-Type for RFC4006bis.
Whether to directly refer to RFC7542, I cannot confirm whether this is acce= ptable or not. 

BR
Maryse

-----Original Message-----
From: Alan DeKok [mailto:aland= @deployingradius.com]
Sent: mercredi 3 mai 2017 00:47
To: Dave Dolson <ddolson@sandvin= e.com>
Cc: Yuval Lifshitz <ylifshitz@= sandvine.com>; Gardella, Maryse (Nokia - FR/Nozay) <maryse.gardella@nokia.com>; jouni ko= rhonen <jouni.nospam@gmail.com= >; dime@ietf.org list <dime@ietf.org>; draft-ietf-dime-rfc4= 006bis@ietf.org
Subject: Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02

On May 2, 2017, at 5:51 PM, Dave Dolson <ddolson@sandvine.com> wrote:
>
> Thanks Alan.
> Do I correctly hear you saying we should replace all references to RFC= 2486 with RFC 7542?

  Yes.

  It's 2017.  Independent of RFC 7542, *inter-operable* implement= ations just have no business using non-UTF8 identifiers.

  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 con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
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.
--_000_E8355113905631478EFF04F5AA706E98705D5C47wtlexchp1sandvi_-- From nobody Mon May 22 11:10:01 2017 Return-Path: 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 EA18B1270AC; Mon, 22 May 2017 11:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 WI3jUo_XrG0O; Mon, 22 May 2017 11:09:58 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1015126D46; Mon, 22 May 2017 11:09:55 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id n23so89526620pfb.2; Mon, 22 May 2017 11:09:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=7uizu3MU0zbvFG9MJX49BpKHjD8MZAGAmrvk2RILQ18=; b=FZMAaiBfqMos1EYTOFlKXWr5zg0MiqFcwGVe6/2OXAQ2HuN9JyoTRGHJdfbTQrdljq ra7soyni6jbJQSn35f7eTe9XCXANg1SU6cAiEt6qJcPz2gq5IFUjXas1xKmMM8qtYmi1 K7OyA4KQmM7+cDatk9nLlqUipJgyZXCd38v0Qho/i3nzIpDL7Z4kwQeBaDkhSJSX2odr xQG7yQA9vfjNbZuuJANg8O6tnTUbJxH+HVfXD7M5O6zsdy513p72oFL5JJRpWfE9XZtM LN/sVL8zCBbQT8TTq2klvT0gahDq2L4rW3munpUBIKJ03/NqVf5O9jtZRW9eZEIBehGX HOFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=7uizu3MU0zbvFG9MJX49BpKHjD8MZAGAmrvk2RILQ18=; b=nnhQuBjjwtGMBeUzgpcMwmtu8mVomB4Ar2t21CC1cbzS1KWtohgBxPbNPyhtg61wjp MGwPpvzT/66cofsyMCQMi/BGcZY1tTORJZGzLgFPmuAKTNZzpDrdJ0fzclAkBWYfI9vQ sRjpCfKnAA/tJ9tJjVEruE0oQ8qLfIP/trcXiEieYnPvXdfDtrbqQgnLA+UCFFqLd3Uf l6C341+A0LYRgO492/a0JSth4p5gW0NwwZL+33jED1/6E9gMullUsY8xZ1GPjzjOrC0L 2eDamNNt//dzF+vVNNaqmdXehgNpyI/4rAXaIO0aLghEcwNiMap5gKgnShjGTAwpgarK ik5Q== X-Gm-Message-State: AODbwcAJR2+bFEMtMCmJbodpCYdeyoV2ZtSxAKk7X3Qs9m/ZAqv7tARU jtVb23yKnn09QIw3VOE= X-Received: by 10.98.2.85 with SMTP id 82mr26481812pfc.52.1495476595112; Mon, 22 May 2017 11:09:55 -0700 (PDT) Received: from [192.168.89.94] ([216.31.219.19]) by smtp.gmail.com with ESMTPSA id q64sm38184177pfi.69.2017.05.22.11.09.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 May 2017 11:09:53 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Mon, 22 May 2017 11:09:52 -0700 Cc: draft-ietf-dime-group-signaling.all@ietf.org To: "dime@ietf.org list" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Dime] WGLC #1 for draft-ietf-dime-group-signaling-08 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 18:10:00 -0000 Folks, This email starts a two week WGLC #1 for draft-ietf-dime-group-signaling-08. The WGLC ends June 5th, 2017 EOB Pacific time. Send your approval, comments and objections to the mailing list. Note that no reviews mean the document did not pass the WGLC. - Jouni & Lionel