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

Hi,

In the London meeting, I agreed that this issue was invalid based on statements in the room that the 6733 correct treatment of an unknown mandatory AVP inside a grouped AVP was to ignore the grouped AVP.

On rereading that section of RFC 6733, I disagree with that interpretation. Section 4.4 says:

> Receivers of a Grouped AVP that
>    does not have the 'M' (mandatory) bit set and one or more of the
>    encapsulated AVPs within the group has the 'M' (mandatory) bit set
>    MAY simply be ignored if the Grouped AVP itself is unrecognized.

That text only applies for _unrecognized_ grouped AVPs. The case in question is when you _recognize_ an optional grouped AVP, but do not recognize a mandatory AVP imbedded in it. The exception in 4.4 does not seem to cover that case.

So I no longer believe that the issue is invalid. I think the best option is to simply forbid setting of the m-bit on any DOIC related AVP.

To address other comments on the issue:

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.

On Feb 7, 2014, at 4:10 PM, dime issue tracker <trac+dime@grenache.tools.ietf.org> wrote:

> #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