Re: [Dime] [dime] #48: Setting M-Bit gives wrong semantics
"TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> Tue, 25 March 2014 08:07 UTC
Return-Path: <jean-jacques.trottin@alcatel-lucent.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24CC1A012F for <dime@ietfa.amsl.com>; Tue, 25 Mar 2014 01:07:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
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 ThdMimsOyhVL for <dime@ietfa.amsl.com>; Tue, 25 Mar 2014 01:07:30 -0700 (PDT)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 13CA91A0076 for <dime@ietf.org>; Tue, 25 Mar 2014 01:07:29 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s2P87R66021408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <dime@ietf.org>; Tue, 25 Mar 2014 03:07:28 -0500 (CDT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s2P87Qrk022362 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <dime@ietf.org>; Tue, 25 Mar 2014 09:07:26 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 25 Mar 2014 09:07:26 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com>
To: "dime@ietf.org" <dime@ietf.org>
Thread-Topic: [Dime] [dime] #48: Setting M-Bit gives wrong semantics
Thread-Index: AQHPQgrXESB9RsUdU0edWfJzJEYY2prrxWUAgAAQ0YCAAIMrgIAAMw6AgAOWP4CAAVCG4A==
Date: Tue, 25 Mar 2014 08:07:25 +0000
Message-ID: <E194C2E18676714DACA9C3A2516265D202672B74@FR712WXCHMBA12.zeu.alcatel-lucent.com>
References: <057.cca16f1268987a869c0055728f3d7793@trac.tools.ietf.org> <752FBBF3-DF13-4BCC-A613-E61D00038E2E@nostrum.com> <6A4050BC-908A-439C-BF41-2992CF0F58B6@gmail.com> <E25B5473-253C-44B8-BF99-5A2F86328E09@nostrum.com> <ED6F296B-F167-4007-87C3-DB8D75D35964@gmail.com> <512F9D8C-BE9B-4365-8D89-402AC0A81D99@nostrum.com> <53302397.7020006@usdonovans.com>
In-Reply-To: <53302397.7020006@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.40]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D202672B74FR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/gXjUirEGkAW3hhLI4XgN_Qhn3r0
Subject: Re: [Dime] [dime] #48: Setting M-Bit gives wrong semantics
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Tue, 25 Mar 2014 08:07:34 -0000
Hi Effectively we should be cautious with M bit for AVPS inside a grouped AVP such as OC-OLR AVP, and as Ben proposed, I am also rather in favour of not using the Mbit inside a DOC group AVP, including application specific AVPs. In the thread discussion it was mentioned the use of OC-feature and also relay node that is application independent. Hereafter my case: After our IETF draft having become a RFC, IETF standardizes an extension, which adds a new flag in OC-feature AVP. This extension is not specific to a Diameter application - A relay oonly supporting our IETF draft, will observe that OC-feature value does not fit to what it knows. I expect here that relay will do nothing about DOC as the meaning of the OC-OLR may be different of what it knows. OK? I als othink it applies to a proxy DA - If the relay supports the extension, it will recognize the OC-feature value and will behave according this value. So OK. Should we have some text in the IETF draft? Now, this is a Diameter application (eg a 3GPP one) that will define an extension for its own use . Is this application is allowed to use bits of OC-Features AVP to indicate this application specific feature (or even algorithm). How to avoid the application to use the same bits as future IETF extensions? Will we be driven to use another OC-Application-Specific-Feature AVP, or have bits in OC-Feature reserved for application specific extensions., or other? A constraint is that a relay (application unaware) should nevertheless detect there is application specific extensions (without knowing their meaning) so to not do DOC actions. I understand this is not directly linked to our immediate scope, but we may try to be future proof allowing application specific extensions and Relay node supporting the generic DOC. Do you agree on this potential issue? If yes may be to analyse what to add in the IETF draft to be future proof. Best regards JJacques De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoyé : lundi 24 mars 2014 13:23 À : dime@ietf.org Objet : Re: [Dime] [dime] #48: Setting M-Bit gives wrong semantics Do we have proposed wording to be included in the -02 version of the draft on this issue? Steve On 3/22/14 12:36 AM, Ben Campbell wrote: On Mar 21, 2014, at 9:33 PM, Jouni Korhonen <jouni.nospam@gmail.com><mailto:jouni.nospam@gmail.com> wrote: Ben, On Mar 22, 2014, at 2:44 AM, Ben Campbell <ben@nostrum.com><mailto:ben@nostrum.com> wrote: On Mar 21, 2014, at 12:43 PM, Jouni Korhonen <jouni.nospam@gmail.com><mailto:jouni.nospam@gmail.com> wrote: Consider the case of a Diameter _relay_ that supports DOIC. It is not aware of any application-specific rules about m-bits. It receives an OC-Supported-Features or an OC-OLR that has a mandatory AVP that it doesn't recognize. Logically, it should probably ignore the entire OC-Supported-Features or OC-OLR grouped-AVP. But it won't. Being a relay, it's not going to reject the message. Rather it's likely to try to apply the OC-Supported-Features or OC-OLR incorrectly. RFC6733 also says that relays perform not do any application level processing. If a relay supports DOIC and does something goofy that is left for implementation, we should no care nor try to fix the situation. The implementation is already bending the rules in that case. Hi Jouni, I'm not talking about the case of the relay doing something goofy. Rather, I mean when a relay tries to perform basic DOIC processing of an OLR as described in the base DOIC spec, but ignores some extension AVP that changes the meaning of the OLR. It's not bending the rules so much as failing to recognize someone else changing the rules. Ah, I see your point. But if one adds AVPs to the default algorithm that change he behaviour and does not a) declare it as a new algorithm or b) add a new supported feature flag, then that is a proprietary (broken) implementation. We cannot really protect against those.. I think that's reasonable. My original point was that extensions should not try to use the m-bit for that purpose. If they have something that is not backwards compatible, it needs to be negotiated in the feature vector. _______________________________________________ DiME mailing list DiME@ietf.org<mailto:DiME@ietf.org> https://www.ietf.org/mailman/listinfo/dime
- [Dime] [dime] #48: Setting M-Bit gives wrong sema… dime issue tracker
- Re: [Dime] [dime] #48: Setting M-Bit gives wrong … lionel.morand
- Re: [Dime] [dime] #48: Setting M-Bit gives wrong … Nirav Salot (nsalot)
- Re: [Dime] [dime] #48: Setting M-Bit gives wrong … Ben Campbell
- Re: [Dime] [dime] #48: Setting M-Bit gives wrong … Jouni Korhonen
- Re: [Dime] [dime] #48: Setting M-Bit gives wrong … Ben Campbell
- Re: [Dime] [dime] #48: Setting M-Bit gives wrong … Jouni Korhonen
- Re: [Dime] [dime] #48: Setting M-Bit gives wrong … Ben Campbell
- Re: [Dime] [dime] #48: Setting M-Bit gives wrong … Jouni
- Re: [Dime] [dime] #48: Setting M-Bit gives wrong … Steve Donovan
- Re: [Dime] [dime] #48: Setting M-Bit gives wrong … TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
- Re: [Dime] [dime] #48: Setting M-Bit gives wrong … Jouni Korhonen
- Re: [Dime] [dime] #48: Setting M-Bit gives wrong … lionel.morand
- [Dime] OC-Supported features and application spec… TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
- Re: [Dime] OC-Supported features and application … lionel.morand
- Re: [Dime] [dime] #48 (draft-ietf-dime-ovli): Set… dime issue tracker
- Re: [Dime] [dime] #48 (draft-ietf-dime-ovli): Set… dime issue tracker