Re: [Dime] RFC 6733 Commands
"Jouni" <jouni.nospam@gmail.com> Wed, 19 July 2017 12:25 UTC
Return-Path: <jouni.nospam@gmail.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 1450A131CEC for <dime@ietfa.amsl.com>; Wed, 19 Jul 2017 05:25:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 0DkPByNP-_xQ for <dime@ietfa.amsl.com>; Wed, 19 Jul 2017 05:25:38 -0700 (PDT)
Received: from mail-lf0-x242.google.com (mail-lf0-x242.google.com [IPv6:2a00:1450:4010:c07::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC92D131CE8 for <dime@ietf.org>; Wed, 19 Jul 2017 05:25:35 -0700 (PDT)
Received: by mail-lf0-x242.google.com with SMTP id l125so202842lfg.5 for <dime@ietf.org>; Wed, 19 Jul 2017 05:25:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-language:thread-index; bh=p626eL0GCg8ge4d8FRYnOINPeZFpDspmx0yMcKUa5DI=; b=vLVLiC8q2NlTBucD0dnaYpNA5Che8xck9r5GK+/ZmCbbKUtvpKrEkpCZOEstcjtB6B 7ZCmRjNqJ6xHKezr9dZla5o5raK8zLpfkhdPeG5M44+6kfwrbWI9wKKF6k7GQ0zQ6Tw9 zRbeavq10BvwPeCn5lWURIuyAIz1BMSXJjfoFon7V0KAhgtDwOQM9VV6YWkS61+x2rcU prfe/zEl9b7DAlx774RneL0M114K82J/YFnpNK1NvN/kRvyMu45IflVngBDBxk0sMK8W 0sngymFvAdZ67vDhtoOYuQQjFcnF2FpXqoOpBejVhHku8C0fm8wVNomU8G6hcnEa/gEB 1qxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-language:thread-index; bh=p626eL0GCg8ge4d8FRYnOINPeZFpDspmx0yMcKUa5DI=; b=s9SMVesY0+K8GcKHAsJQBjtod5ZpIcsCHOPTDS58y3oJpiCwqKgN2mkU8Qa+SkjMl7 B9CRvwRoZJLmi/84AwhcQRdqnEuEyZCmXkmPvzZ6834Qr6KPPqZFUf2MShFJ21rzkucU LxjrynqTgYyfcJ37K95kXRx7HSZOeMfYioDF+vhlY9oPXlmRooOCFD/7cZq9wu5BNOIn 9rHHV5IGXgpfARkkV0FvbFOED2aBDHOYNXQe18GXdfU6WZF2O58NXBj4p8FYjEzhJkpE tb0p+4Jt2N2hSrhPQQ1/CtadR/eUpksb7VRX/mRCKEzdHmcEsHgcDJgYXwd4CGnOiJmv zD3A==
X-Gm-Message-State: AIVw110lUjJP9HWe9K4z6KQuHSn6FOsWG2NW1xSjwA7wFhzIA/rR5Lg8 IC21IJud/HEwBb6X
X-Received: by 10.25.31.213 with SMTP id f204mr2383063lff.58.1500467133657; Wed, 19 Jul 2017 05:25:33 -0700 (PDT)
Received: from JOKO ([83.150.126.201]) by smtp.gmail.com with ESMTPSA id t7sm239604lfi.53.2017.07.19.05.25.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 05:25:32 -0700 (PDT)
From: Jouni <jouni.nospam@gmail.com>
To: "'Bertz, Lyle T [CTO]'" <Lyle.T.Bertz@sprint.com>, 'Yuval Lifshitz' <ylifshitz@sandvine.com>, lionel.morand@orange.com, dime@ietf.org
References: <1500286334617.86980@sprint.com>, <8331_1500301978_596CCA9A_8331_333_1_6B7134B31289DC4FAF731D844122B36E2D1B5E23@OPEXCLILM43.corporate.adroot.infra.ftgroup> <1500303827591.97405@sprint.com> <C43C255C7106314F8D13D03FA20CFE49A8AB7250@wtl-exchp-2.sandvine.com> <559e01d30075$d36b13e0$7a413ba0$@gmail.com> <C43C255C7106314F8D13D03FA20CFE49A8AB729D@wtl-exchp-2.sandvine.com>, <561801d3007e$b95bd940$2c138bc0$@gmail.com> <1500465352738.7744@sprint.com>
In-Reply-To: <1500465352738.7744@sprint.com>
Date: Wed, 19 Jul 2017 15:25:30 +0300
Message-ID: <567b01d3008a$1d8be2b0$58a3a810$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_567C_01D300A3.42E1A630"
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQJ4SKXtVleed+r8bygyRJbzSNgxvwI0ElhcAq0/UBgBqfvIxAIor9D3AXCTSNgCba78QgGaFlwOoJ8e6JA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/vQdLbI6ns5rMSpSE00ZMwgOCq-M>
Subject: Re: [Dime] RFC 6733 Commands
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 12:25:42 -0000
There is Acct-Application-Id in the CCF.. so whats the difference? If present in a message other than CER and CEA, the value of the Acct-Application-Id AVP MUST match the Application Id present in the Diameter message header. - JOuni From: Bertz, Lyle T [CTO] [mailto:Lyle.T.Bertz@sprint.com] Sent: Wednesday, July 19, 2017 14:56 PM To: Jouni <jouni.nospam@gmail.com>; 'Yuval Lifshitz' <ylifshitz@sandvine.com>; lionel.morand@orange.com; dime@ietf.org Subject: Re: [Dime] RFC 6733 Commands My issue (and the motive for the e-mail) is that some lazy implementors tied the ACR/ACA to 0 which should not have happened. Although optional, having placed the App ID of 3 in the ACR/ACA would have at least begged the question of how did you miss that? It is pretty clear to me that the dev only looked @ the CCF and not the rest of the document. However, if the app id was in the CCF that specific issue would have been avoided. We can't fix one's inability to read the whole document but we can take steps to lower the probability of an error when they take shortcuts. _____ From: Jouni <jouni.nospam@gmail.com <mailto:jouni.nospam@gmail.com> > Sent: Wednesday, July 19, 2017 6:03 AM To: 'Yuval Lifshitz'; Bertz, Lyle T [CTO]; lionel.morand@orange.com <mailto:lionel.morand@orange.com> ; dime@ietf.org <mailto:dime@ietf.org> Subject: RE: [Dime] RFC 6733 Commands If you go for new protocol version that opens a door for a lot of things. Generally adding commands to base protocol using app-id 0 is not possible without a new protocol version. I do not see a reason for any extra clarifications. I would be reluctant to assume app-id 0 is forever for peer level commands. We have other ways to impose that restriction at the AVP level where such things actually belong (see Section 6.1). - JOuni From: Yuval Lifshitz [mailto:ylifshitz@sandvine.com] Sent: Wednesday, July 19, 2017 13:20 PM To: Jouni <jouni.nospam@gmail.com <mailto:jouni.nospam@gmail.com> >; 'Bertz, Lyle T [CTO]' <Lyle.T.Bertz@sprint.com <mailto:Lyle.T.Bertz@sprint.com> >; lionel.morand@orange.com <mailto:lionel.morand@orange.com> ; dime@ietf.org <mailto:dime@ietf.org> Cc: Yuval Lifshitz <ylifshitz@sandvine.com <mailto:ylifshitz@sandvine.com> > Subject: RE: [Dime] RFC 6733 Commands You mean, that if someone implement a new protocol but does not change definitions from base, not add any new stuff which is mandatory, they are allowed to use application-id zero for commands other than (CERA, DPR/A, DWR/A)? Shouldnt we block that? Would imagine there are implementations where they assume zero is only for peer level messages? From: Jouni [mailto:jouni.nospam@gmail.com] Sent: Wednesday, July 19, 2017 1:00 PM To: Yuval Lifshitz; 'Bertz, Lyle T [CTO]'; lionel.morand@orange.com <mailto:lionel.morand@orange.com> ; dime@ietf.org <mailto:dime@ietf.org> Subject: RE: [Dime] RFC 6733 Commands 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 [mailto:dime-bounces@ietf.org] On Behalf Of Yuval Lifshitz Sent: Wednesday, July 19, 2017 12:32 PM To: Bertz, Lyle T [CTO] <Lyle.T.Bertz@sprint.com <mailto:Lyle.T.Bertz@sprint.com> >; lionel.morand@orange.com <mailto:lionel.morand@orange.com> ; dime@ietf.org <mailto:dime@ietf.org> list <dime@ietf.org <mailto:dime@ietf.org> > 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 [mailto:dime-bounces@ietf.org] On Behalf Of Bertz, Lyle T [CTO] Sent: Monday, July 17, 2017 6:04 PM To: lionel.morand@orange.com <mailto:lionel.morand@orange.com> ; dime@ietf.org <mailto:dime@ietf.org> 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: lionel.morand@orange.com <mailto:lionel.morand@orange.com> <lionel.morand@orange.com <mailto:lionel.morand@orange.com> > Sent: Monday, July 17, 2017 9:32 AM To: Bertz, Lyle T [CTO]; dime@ietf.org <mailto:dime@ietf.org> 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. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Bertz, Lyle T [CTO] Envoyé : lundi 17 juillet 2017 12:12 À : dime@ietf.org <mailto:dime@ietf.org> 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? Lyle _____ 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.
- [Dime] RFC 6733 Commands Bertz, Lyle T [CTO]
- Re: [Dime] RFC 6733 Commands lionel.morand
- Re: [Dime] RFC 6733 Commands Bertz, Lyle T [CTO]
- Re: [Dime] RFC 6733 Commands Yuval Lifshitz
- Re: [Dime] RFC 6733 Commands Jouni
- Re: [Dime] RFC 6733 Commands Yuval Lifshitz
- Re: [Dime] RFC 6733 Commands Jouni
- Re: [Dime] RFC 6733 Commands Bertz, Lyle T [CTO]
- Re: [Dime] RFC 6733 Commands Jouni
- Re: [Dime] RFC 6733 Commands Bertz, Lyle T [CTO]