[Dime] RE : RE: M-bit setting in draft-ietf-dime-rfc4006bis-02

<lionel.morand@orange.com> Mon, 17 July 2017 21:47 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 2CFE8128BA2; Mon, 17 Jul 2017 14:47:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level:
X-Spam-Status: No, score=-2.618 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, 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 WDJ7OgVDbSBI; Mon, 17 Jul 2017 14:47:05 -0700 (PDT)
Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2A14126CC7; Mon, 17 Jul 2017 14:47:04 -0700 (PDT)
Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 85AE42056F; Mon, 17 Jul 2017 23:47:03 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.72]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 39B751C006F; Mon, 17 Jul 2017 23:47:03 +0200 (CEST)
Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541%19]) with mapi id 14.03.0352.000; Mon, 17 Jul 2017 23:47:03 +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: =?Windows-1252?Q?RE=A0:_RE:_M-bit_setting_in_draft-ietf-dime-rfc4006bis-0?= =?Windows-1252?Q?2?=
Thread-Index: AQHS/0Y5aJJaUsU+AkWDYMLzgtR+Ng==
Date: Mon, 17 Jul 2017 21:47:01 +0000
Message-ID: <20138_1500328023_596D3057_20138_295_1_6B7134B31289DC4FAF731D844122B36E2D1B6758@OPEXCLILM43.corporate.adroot.infra.ftgroup>
References: <13800_1500305348_596CD7C4_13800_63_1_6B7134B31289DC4FAF731D844122B36E2D1B6048@OPEXCLILM43.corporate.adroot.infra.ftgroup>, <E8355113905631478EFF04F5AA706E98A906566A@wtl-exchp-2.sandvine.com>
In-Reply-To: <E8355113905631478EFF04F5AA706E98A906566A@wtl-exchp-2.sandvine.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E2D1B6758OPEXCLILM43corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/boGbs7SeJtwl9xwWIUKsJ0Bo8bQ>
Subject: [Dime] =?windows-1252?q?RE=A0=3A_RE=3A_M-bit_setting_in_draft-iet?= =?windows-1252?q?f-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 21:47:08 -0000

Hi Dave,

Speaking about the existing AVPs, I don't think that we need a specific errata report on RFC4006 if it is what you meant.
I consider it more as a clarification on the M-bit setting included while revising the specification, based on requirements/guidelines provided after the publication of the RFC4006.
As it is, the MAY column is not wrong. It is just useless and it is why its use was deprecated.

Lionel

Le 17 juil. 2017 18:05, Dave Dolson <ddolson@sandvine.com> a écrit :
Lionel,
Do you consider those to be errata against RFC4006 ?


From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]
Sent: Monday, July 17, 2017 5:29 PM
To: Dave Dolson; Gardella, Maryse (Nokia - FR/Nozay); Alan DeKok
Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ietf.org
Subject: M-bit setting in draft-ietf-dime-rfc4006bis-02

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<mailto:dime@ietf.org> list; draft-ietf-dime-rfc4006bis@ietf.org<mailto: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.

_________________________________________________________________________________________________________________________

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.