[Dime] RE : Re: [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 implementation 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 écrit :
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 UTF8String ... 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 names 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-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) <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-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 based on:
- assuming the TS 23.003 (Numbering, addressing and identification) is an important 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 END_USER_NAI in Subscription-Id-Type for RFC4006bis.
Whether to directly refer to RFC7542, I cannot confirm whether this is acceptable 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.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

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* implementations 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 confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

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