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

Agree with Lionel.

For existing application, the M-bit will never be set.
For new applications, which are defined after the DOIC, the M-bit could be set.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
Sent: Saturday, February 08, 2014 10:05 PM
To: dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org; ben@nostrum.com
Subject: Re: [Dime] [dime] #48: Setting M-Bit gives wrong semantics

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.

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime