Re: [Dime] [dime] #48: Setting M-Bit gives wrong semantics

<lionel.morand@orange.com> Sat, 08 February 2014 16:34 UTC

Return-Path: <lionel.morand@orange.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 00A681A040A for <dime@ietfa.amsl.com>; Sat, 8 Feb 2014 08:34:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.801
X-Spam-Level:
X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 jHNNb8aBXPMd for <dime@ietfa.amsl.com>; Sat, 8 Feb 2014 08:34:42 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDCE1A03CC for <dime@ietf.org>; Sat, 8 Feb 2014 08:34:42 -0800 (PST)
Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id BB4CB1B8239; Sat, 8 Feb 2014 17:34:41 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 9A079180065; Sat, 8 Feb 2014 17:34:41 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Sat, 8 Feb 2014 17:34:41 +0100
From: lionel.morand@orange.com
To: "dime@ietf.org" <dime@ietf.org>, "draft-docdt-dime-ovli@tools.ietf.org" <draft-docdt-dime-ovli@tools.ietf.org>, "ben@nostrum.com" <ben@nostrum.com>
Thread-Topic: [Dime] [dime] #48: Setting M-Bit gives wrong semantics
Thread-Index: AQHPJFF6Ab6u61L6RkaLYcwLVhapC5qriYTA
Date: Sat, 08 Feb 2014 16:34:40 +0000
Message-ID: <27855_1391877281_52F65CA1_27855_6436_1_6B7134B31289DC4FAF731D844122B36E493891@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <057.cca16f1268987a869c0055728f3d7793@trac.tools.ietf.org>
In-Reply-To: <057.cca16f1268987a869c0055728f3d7793@trac.tools.ietf.org>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.197.38.3]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.8.115114
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: Sat, 08 Feb 2014 16:34:45 -0000

Hi Ben,

I don't think that there is something wrong here.

The setting of M-bit is per application, and it is true for any AVP.

I'm not sure to understand your example. The use of the DOIC is defined per application.
For a newly defined application:
- Either the node supports the new application and it will understand any AVP defined as AVP to understand;
- Either the node does not support new application and it will not receive messages for this application or it will be transparent to any unknown AVP (e.g. Relay).

Regards,

Lionel


-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker
Envoyé : vendredi 7 février 2014 23:11
À : draft-docdt-dime-ovli@tools.ietf.org; ben@nostrum.com
Cc : dime@ietf.org
Objet : [Dime] [dime] #48: Setting M-Bit gives wrong semantics

#48: Setting M-Bit gives wrong semantics

 Multiple sections indicate that a new application that incorporates DOIC
 can set the M-Bit on DOIC sub-avps. I don't think this ever does the right
 thing.

 IIUC, If a node that otherwise supports DOIC encounters a DOIC avp that it
 doesn't understand, and has the M-Bit set, it will cause a failure of the
 application command. I don't think we want the lack of support of some
 DOIC feature or extension to ever cause an application-level failure.  I
 think we are looking for something that would just cause the OLR to be
 ignored.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-docdt-dime-
  ben@nostrum.com        |  ovli@tools.ietf.org
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  draft-       |    Version:  1.0
  docdt-dime-ovli        |   Keywords:
 Severity:  Active WG    |
  Document               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/48>
dime <http://tools.ietf.org/wg/dime/>

_______________________________________________
DiME mailing list
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.