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

From: "dime issue tracker" <[email-masked]>
Date: Fri, 07 Feb 2014 22:10:45 -0000

#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-
  [email-masked]        |  [email-masked]
     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/>

---

From: <[email-masked]>
Date: Sat, 8 Feb 2014 16:34:40 +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:[email-masked]] De la part de dime issue tracker
Envoyé : vendredi 7 février 2014 23:11
À : [email-masked]; [email-masked]
Cc : [email-masked]
Objet : [Dime] [dime] #48: Setting M-Bit gives wrong semantics

_______________________________________________
DiME mailing list
[email-masked]
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.

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Mon, 10 Feb 2014 06:58:36 +0000

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:[email-masked]] On Behalf Of [email-masked]
Sent: Saturday, February 08, 2014 10:05 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Dime] [dime] #48: Setting M-Bit gives wrong semantics

Hi Ben,

Regards,

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de dime issue tracker Envoyé : vendredi 7 février 2014 23:11 À : [email-masked]; [email-masked] Cc : [email-masked] Objet : [Dime] [dime] #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-
  [email-masked]        |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  draft-       |    Version:  1.0
  docdt-dime-ovli        |   Keywords:
 Severity:  Active WG    |
  Document               |
-------------------------+----------------------------------------------
-------------------------+---

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.