[Dime] M-bit setting in draft-ietf-dime-rfc4006bis-02
<lionel.morand@orange.com> Mon, 17 July 2017 15:29 UTC
Return-Path: <lionel.morand@orange.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138F2131C65; Mon, 17 Jul 2017 08:29:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.398
X-Spam-Level:
X-Spam-Status: No, score=-5.398 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_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 IwTWVfE6VLZx; Mon, 17 Jul 2017 08:29:16 -0700 (PDT)
Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1257C131C62; Mon, 17 Jul 2017 08:29:10 -0700 (PDT)
Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id DB83DA052D; Mon, 17 Jul 2017 17:29:08 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 85C1B1A00A6; Mon, 17 Jul 2017 17:29:08 +0200 (CEST)
Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0352.000; Mon, 17 Jul 2017 17:29:08 +0200
From: lionel.morand@orange.com
To: Dave Dolson <ddolson@sandvine.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-rfc4006bis@ietf.org" <draft-ietf-dime-rfc4006bis@ietf.org>
Thread-Topic: M-bit setting in draft-ietf-dime-rfc4006bis-02
Thread-Index: AdL/Dc/OHV8jIku1TbW+ki3uYtdcWQ==
Date: Mon, 17 Jul 2017 15:29:07 +0000
Message-ID: <13800_1500305348_596CD7C4_13800_63_1_6B7134B31289DC4FAF731D844122B36E2D1B6048@OPEXCLILM43.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E2D1B6048OPEXCLILM43corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/S36yB5hEC9pupZT5-1JPer6lJpI>
Subject: [Dime] M-bit setting in draft-ietf-dime-rfc4006bis-02
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Jul 2017 15:29:19 -0000
Hi,
Sorry for this late comment.
As stated in RFC6733,
It is the decision of the protocol designer when to develop a new
Diameter application rather than extending Diameter in other ways.
However, a new Diameter application MUST be created when one or more
of the following criteria are met:
M-bit Setting
An AVP with the M-bit in the MUST column of the AVP flag table is
added to an existing Command/Application. An AVP with the M-bit
in the MAY column of the AVP flag table is added to an existing
Command/Application.
Therefore, if it is proposed to keep the existing DCC application-id, the newly defined AVPs must be defined with the M-bit put in the MUST NOT column:
+---------------+
|AVP Flag rules |
|----+-----+----|
AVP Section | | |MUST|
Attribute Name Code Defined Data Type |MUST| MAY |NOT |
-----------------------------------------|----+-----+----|
QoS-Final-Unit- TBD17 8.68 Grouped | | M | V |
Indication | | | |
Redirect-Server TBD13 8.64 Grouped | | M | V |
-Extension | | | |
Redirect-Address TBD14 8.65 Address | | M | V |
-IPAddress | | | |
Redirect-Address TBD15 8.66 UTF8String | | M | V |
-URL | | | |
Redirect-Address TBD16 8.67 UTF8String | | M | V |
-SIP-URI | | | |
Subscription-Id TBD7 8.58 Grouped | | M | V |
-Extension | | | |
Subscription-Id TBD8 8.59 UTF8String | | M | V |
-E164 | | | |
Subscription-Id TBD9 8.60 UTF8String | | M | V |
-IMSI | | | |
Subscription-Id TBD10 8.61 UTF8String | | M | V |
-SIP-URI | | | |
Subscription-Id TBD11 8.62 UTF8String | | M | V |
-NAI | | | |
Subscription-Id TBD12 8.63 UTF8String | | M | V |
-Private | | | |
User-Equipment TBD1 8.52 Grouped | | M | V |
-Info-Extension | | | |
User-Equipment TBD2 8.53 OctetString| | M | V |
-Info-IMEISV | | | |
User-Equipment TBD3 8.54 OctetString| | M | V |
-Info-MAC | | | |
User-Equipment TBD4 8.55 OctetString| | M | V |
-Info-EUI64 | | | |
User-Equipment TBD5 8.56 OctetString| | M | V |
-Info-ModifiedEUI64 | | | |
User-Equipment TBD6 8.57 OctetString| | M | V |
Now, regarding existing AVPs with the M-bit put in the MAY column (listed below), I would recommend not to use the MAY column but to specific in which DCC commands the M-bit setting may change for some AVP, as indicated in RFC6733 and RFC7423.
>From RFC6733:
Note: The M-bit setting for a given AVP is relevant to an
Application and each command within that application that includes
the AVP. That is, if an AVP appears in two commands for
application Foo and the M-bit settings are different in each
command, then there should be two AVP flag tables describing when
to set the M-bit.
For AVPs for which there is no clear use case for change of the M-bit setting in the DCC app, the M-bit should be put in the MUST column. It may be the case for all the AVPs listed below (I've not checked). Other applications using DCC commands can decide to set or clear the M-bit of the related DCC commands' AVPs without any constraint.
+---------------+
|AVP Flag rules |
|----+-----+----|
AVP Section | | |MUST|
Attribute Name Code Defined Data Type |MUST| MAY |NOT |
-----------------------------------------|----+-----+----|
CC-Correlation-Id 411 8.1 OctetString| | M | V |
Service-Parameter 440 8.43 Grouped | | M | V |
-Info | | | |
Service- 441 8.44 Unsigned32 | | M | V |
Parameter-Type | | | |
Service- 442 8.45 OctetString| | M | V |
Parameter-Value | | | |
User-Equipment 458 8.49 Grouped | | M | V |
-Info | | | |
User-Equipment 459 8.50 Enumerated | | M | V |
-Info-Type | | | |
User-Equipment 460 8.51 OctetString| | M | V |
-Info-Value | | | |
User-Equipment TBD1 8.52 Grouped | | M | V |
-Info-Extension | | | |
User-Equipment TBD2 8.53 OctetString| | M | V |
-Info-IMEISV | | | |
User-Equipment TBD3 8.54 OctetString| | M | V |
-Info-MAC | | | |
User-Equipment TBD4 8.55 OctetString| | M | V |
-Info-EUI64 | | | |
User-Equipment TBD5 8.56 OctetString| | M | V |
-Info-ModifiedEUI64 | | | |
User-Equipment TBD6 8.57 OctetString| | M | V |
-Info-IMEI | | | |
Regards,
Lionel
De : Dave Dolson [mailto:ddolson@sandvine.com]
Envoyé : jeudi 11 mai 2017 17:03
À : Gardella, Maryse (Nokia - FR/Nozay); MORAND Lionel IMT/OLN; Alan DeKok
Cc : dime@ietf.org list; draft-ietf-dime-rfc4006bis@ietf.org
Objet : RE: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02
I have uploaded version -03 with the agreed changes to simply replace the reference 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<mailto:lionel.morand@orange.com>; Alan DeKok
Cc: dime@ietf.org<mailto:dime@ietf.org> list; draft-ietf-dime-rfc4006bis@ietf.org<mailto: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 Dolson [mailto:ddolson@sandvine.com]
Sent: vendredi 5 mai 2017 21:57
To: lionel.morand@orange.com<mailto:lionel.morand@orange.com>; Gardella, Maryse (Nokia - FR/Nozay) <maryse.gardella@nokia.com<mailto:maryse.gardella@nokia.com>>; Alan DeKok <aland@deployingradius.com<mailto:aland@deployingradius.com>>
Cc: dime@ietf.org<mailto:dime@ietf.org> list <dime@ietf.org<mailto:dime@ietf.org>>; draft-ietf-dime-rfc4006bis@ietf.org<mailto:draft-ietf-dime-rfc4006bis@ietf.org>
Subject: RE: RE : Re: [Dime] [ALU] WGLC #1 for draft-ietf-dime-rfc4006bis-02
Lionel,
OK, thanks. I'll make the changes.
-Dave
From: lionel.morand@orange.com<mailto: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<mailto:dime@ietf.org> list; draft-ietf-dime-rfc4006bis@ietf.org<mailto: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 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<mailto: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<mailto:dime@ietf.org> list; draft-ietf-dime-rfc4006bis@ietf.org<mailto: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<mailto:maryse.gardella@nokia.com>>; Alan DeKok <aland@deployingradius.com<mailto:aland@deployingradius.com>>
Cc: Yuval Lifshitz <ylifshitz@sandvine.com<mailto:ylifshitz@sandvine.com>>; jouni korhonen <jouni.nospam@gmail.com<mailto:jouni.nospam@gmail.com>>; dime@ietf.org<mailto:dime@ietf.org> list <dime@ietf.org<mailto:dime@ietf.org>>; draft-ietf-dime-rfc4006bis@ietf.org<mailto: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<mailto:dime@ietf.org> list; draft-ietf-dime-rfc4006bis@ietf.org<mailto: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<mailto:ddolson@sandvine.com>>
Cc: Yuval Lifshitz <ylifshitz@sandvine.com<mailto:ylifshitz@sandvine.com>>; Gardella, Maryse (Nokia - FR/Nozay) <maryse.gardella@nokia.com<mailto:maryse.gardella@nokia.com>>; jouni korhonen <jouni.nospam@gmail.com<mailto:jouni.nospam@gmail.com>>; dime@ietf.org<mailto:dime@ietf.org> list <dime@ietf.org<mailto:dime@ietf.org>>; draft-ietf-dime-rfc4006bis@ietf.org<mailto: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<mailto: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<mailto: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.
_________________________________________________________________________________________________________________________
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.
- [Dime] M-bit setting in draft-ietf-dime-rfc4006bi… lionel.morand
- Re: [Dime] M-bit setting in draft-ietf-dime-rfc40… Dave Dolson
- [Dime] RE : RE: M-bit setting in draft-ietf-dime-… lionel.morand
- Re: [Dime] RE : RE: M-bit setting in draft-ietf-d… Yuval Lifshitz