Re: [Dime] RFC 6733 Commands

Yuval Lifshitz <> Wed, 19 July 2017 09:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 91018131C60 for <>; Wed, 19 Jul 2017 02:32:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5RtsmVpUzKCi for <>; Wed, 19 Jul 2017 02:32:20 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2626C131C5F for <>; Wed, 19 Jul 2017 02:32:20 -0700 (PDT)
Received: from ([fe80::68ac:f071:19ff:3455]) by ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0319.002; Wed, 19 Jul 2017 05:32:18 -0400
From: Yuval Lifshitz <>
To: "Bertz, Lyle T [CTO]" <>, "" <>, " list" <>
Thread-Topic: RFC 6733 Commands
Thread-Index: AQHS/uUJB8h6U5QREEmZorl9T0AXrqJYEfmAgAAL0HqAAscIwA==
Date: Wed, 19 Jul 2017 09:32:18 +0000
Message-ID: <>
References: <>, <8331_1500301978_596CCA9A_8331_333_1_6B7134B31289DC4FAF731D844122B36E2D1B5E23@OPEXCLILM43.corporate.adroot.infra.ftgroup> <>
In-Reply-To: <>
Accept-Language: en-CA, en-US
Content-Language: en-US
x-originating-ip: []
x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794
Content-Type: multipart/alternative; boundary="_000_C43C255C7106314F8D13D03FA20CFE49A8AB7250wtlexchp2sandvi_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Dime] RFC 6733 Commands
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Jul 2017 09:32:23 -0000

Actually, we may have an issue there. The spec says that zero must be used for base protocol messages (page 23):

Diameter messages pertaining to peer connection
   establishment and maintenance such as CER/CEA, DWR/DWA, and DPR/DPA
   MUST carry an Application Id of zero (0).

But does not say that it must not be used for anything else (or at least I failed to find such text). Do you think such text should be added?
Note that there is such text regarding vendor-id.

From: DiME [] On Behalf Of Bertz, Lyle T [CTO]
Sent: Monday, July 17, 2017 6:04 PM
To:; list
Subject: Re: [Dime] RFC 6733 Commands

agreed, we have encountered some folks tying the ACR/ACA to app id 0 in open source.

From:<> <<>>
Sent: Monday, July 17, 2017 9:32 AM
To: Bertz, Lyle T [CTO];<> list
Subject: RE: RFC 6733 Commands

Hi Lyle,

I think that there is no specific reason. By definition, the command is independent of any application. So when describing the command code, it may or may not be contained in the command code header. It is consistent with the CCF specification:

   header           = "<Diameter-Header:" command-id
                         [r-bit] [p-bit] [e-bit] [application-id]">"

The CCF is mainly used to identify the set of AVP that can be present in the command.



De : DiME [] De la part de Bertz, Lyle T [CTO]
Envoyé : lundi 17 juillet 2017 12:12
À :<> list
Objet : [Dime] RFC 6733 Commands

In the spec was there a particular reason why we did not specify the application Identifier in the header for each of the command codes, e.g. ACR/ACA assigned to application ID 3?



This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.


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.