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

Ben,

On Mar 18, 2014, at 1:59 AM, Ben Campbell <ben@nostrum.com> wrote:

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

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.

- Jouni

> 
> 
> 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
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime