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

Yuval Lifshitz <ylifshitz@sandvine.com> Wed, 19 July 2017 10:12 UTC

Return-Path: <ylifshitz@sandvine.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 D2560131C60; Wed, 19 Jul 2017 03:12:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 sEUvy9dMmPV6; Wed, 19 Jul 2017 03:12:08 -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 92635131A78; Wed, 19 Jul 2017 03:12:07 -0700 (PDT)
Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-3.sandvine.com (192.168.196.177) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 19 Jul 2017 06:12:06 -0400
Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Wed, 19 Jul 2017 06:12:05 -0400
From: Yuval Lifshitz <ylifshitz@sandvine.com>
To: "lionel.morand@orange.com" <lionel.morand@orange.com>, 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>, Yuval Lifshitz <ylifshitz@sandvine.com>
Thread-Topic: =?iso-8859-1?Q?RE=A0:_RE:_M-bit_setting_in_draft-ietf-dime-rfc4006bis-02?=
Thread-Index: AdL/Dc/OHV8jIku1TbW+ki3uYtdcWQACO2swABRAjoAAQ2kQsA==
Date: Wed, 19 Jul 2017 10:12:05 +0000
Message-ID: <C43C255C7106314F8D13D03FA20CFE49A8AB727F@wtl-exchp-2.sandvine.com>
References: <13800_1500305348_596CD7C4_13800_63_1_6B7134B31289DC4FAF731D844122B36E2D1B6048@OPEXCLILM43.corporate.adroot.infra.ftgroup>, <E8355113905631478EFF04F5AA706E98A906566A@wtl-exchp-2.sandvine.com> <20138_1500328023_596D3057_20138_295_1_6B7134B31289DC4FAF731D844122B36E2D1B6758@OPEXCLILM43.corporate.adroot.infra.ftgroup>
In-Reply-To: <20138_1500328023_596D3057_20138_295_1_6B7134B31289DC4FAF731D844122B36E2D1B6758@OPEXCLILM43.corporate.adroot.infra.ftgroup>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.142.10]
x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794
Content-Type: multipart/alternative; boundary="_000_C43C255C7106314F8D13D03FA20CFE49A8AB727Fwtlexchp2sandvi_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/bD8ljMWKY16OgUS1wVdnEATHOYA>
Subject: Re: [Dime] =?iso-8859-1?q?RE=A0=3A_RE=3A_M-bit_setting_in_draft-ietf?= =?iso-8859-1?q?-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: Wed, 19 Jul 2017 10:12:12 -0000

Lionel,
The AVPs newly added to RFC4006bis were not added to the MAY column because they are mandatory in some messages and not in other - reason was specifically to "workaround" the RFC6733 directive :-)

·         If an equipment that support RFC4006bis, works in a mixed environment, where RFC4006 also exist, it should not set the M-bit on the new AVPs, so that legacy equipment can just ignore them

·         While, if working in pure RFC4006bis environment, it can set the M-bit for the AVPs that replace existing AVPs that has the M-bit set for them

If this approach is not acceptable, we would have other 2 options:

1.       Say that the M-bit must be set - this would define a new protocol in RFC4006bis, which would, IMO, decrease the probability of adoption to zero :-(

2.       Say that the M-bit must not be set - this makes the new AVPs "weaker" as they may be ignored even if they carry critical information
So, if we have to change, I would go for (2).

Yuval

From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]
Sent: Tuesday, July 18, 2017 12:47 AM
To: Dave Dolson; Gardella, Maryse (Nokia - FR/Nozay); Alan DeKok
Cc: dime@ietf.org list; draft-ietf-dime-rfc4006bis@ietf.org
Subject: RE : RE: M-bit setting in draft-ietf-dime-rfc4006bis-02


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