[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.