Re: [Dime] RFC 6733 Commands

"Jouni" <> Wed, 19 July 2017 10:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 393C0131C77 for <>; Wed, 19 Jul 2017 03:00:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rxI__lnX9KKO for <>; Wed, 19 Jul 2017 03:00:21 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1131812F24E for <>; Wed, 19 Jul 2017 03:00:21 -0700 (PDT)
Received: by with SMTP id z78so4006526lff.2 for <>; Wed, 19 Jul 2017 03:00:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-language:thread-index; bh=90SA1TP39rakV9b8XVpS0XSisyJFfhMzihPr0fhv0/o=; b=tK+HgftROTl4m85xksgUQl7buzwd2Jwrw9fVvELWD6ujA1bFHKYRtfOeJXEY7Z3t2x 5psCoIbIFBC/EyLX49+5Y/aN+5VulrdKtC1u2aooLFYql5ZvbfGNQlGJHsF6XaB65kzx kSZzn8RVpFT1jwLRgo1zO8HvWdu/xh5hGNDvbHnnC+E1E3PV3MPlu1iO6xUs0MDQBGue C4imbonUTDebz4Kdj71foIZLD7PeHqcQB7J8q5BZF1zkQG2OiSPjnV74CMcYeZIFCj2b KzOtfdtJb+nzlRbPj86Pi94vm/RxWJ8JTGJiSeAQ/V/8AUoBXLRbK8/6TyxvXdoXcuwh KN8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-language:thread-index; bh=90SA1TP39rakV9b8XVpS0XSisyJFfhMzihPr0fhv0/o=; b=eOTwSbwYTL6+FxtEymZ12++GTIpAjt/PwAv0hb1jHFRvhA5/EKflM02HKUFreb6RYe OQaY6npLwr9QuzKcadbNdrATcYPblBmr5yc3PhK3QhXQKdvFsc/srwNRe3jiMUyLuCmQ MawFaBdrmTLOCvYYBz/w+iUhuO2r0ow6vFBLct5toi2KyrqZk9UyyOzhk8CIBpwKxsi1 uBYny/DCHRLa51CjIapL4Ropwz+QJ7HSC7RcxF9OXltWpEBqS50ymQozLGlw2k4upFjv sY7WtYftFAbq9b4Vjx3w0I9b5mtjziGWwIqwJTfEn9vTPY4pTKmZ164RXXPjVXw+wnlF +JhQ==
X-Gm-Message-State: AIVw110FmjSMBEIhFfDkWJYo2VLXZ55OWmnhvQwZub5jd4J4K6Oa73If 0qsOg0XTAGGalURB
X-Received: by with SMTP id h7mr2178258ljb.22.1500458419157; Wed, 19 Jul 2017 03:00:19 -0700 (PDT)
Received: from JOKO ([]) by with ESMTPSA id s20sm1202377ljd.65.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 03:00:18 -0700 (PDT)
From: "Jouni" <>
To: "'Yuval Lifshitz'" <>, "'Bertz, Lyle T [CTO]'" <>, <>, <>
References: <>, <8331_1500301978_596CCA9A_8331_333_1_6B7134B31289DC4FAF731D844122B36E2D1B5E23@OPEXCLILM43.corporate.adroot.infra.ftgroup> <> <>
In-Reply-To: <>
Date: Wed, 19 Jul 2017 13:00:17 +0300
Message-ID: <559e01d30075$d36b13e0$7a413ba0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_559F_01D3008E.F8BF50C0"
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQJ4SKXtVleed+r8bygyRJbzSNgxvwI0ElhcAq0/UBgBqfvIxKDb/TTA
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 10:00:23 -0000

Unless you extend and existing application within the rules in Section 1.3.4
you always get a new application. And if you wish to extend the existing
base protocol application with new commands that most likely would require a
new protocol version. I think we are good here with the current text.


-        Jouni 


From: DiME [] On Behalf Of Yuval Lifshitz
Sent: Wednesday, July 19, 2017 12:32 PM
To: Bertz, Lyle T [CTO] <>om>;; list <>
Subject: Re: [Dime] RFC 6733 Commands


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




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






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

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.