Subject: Re: [Dime] Handling of mandatory sub-avps

From: Ben Campbell <[email-masked]>
Date: Mon, 5 Jan 2015 17:05:15 -0600

> On Dec 29, 2014, at 10:33 AM, Steve Donovan <[email-masked]> wrote:
> 
> Ben,
> 
> As you suggesting that just the AVP that isn't understood is ignored or the entire grouped AVP it is part of is ignored?  If the "sub-avp" is marked as mandatory then it would seem that the entire grouped AVP should be ignored.

I wasn't really talking about mandatory AVPs [1]. I was talking about DOIC errors in general. Basically, if you get an OC-OLR or OC-S-F that is bogus for some reason, you can ignore it--but the enclosing Diameter transaction is unaffected.

[1]  But on re-reading the M-bit rules in 6733, I once again think we have a disconnect for sub-avps with the m-bit set. I thought that the rules allows us to ignore a whole grouped AVP if it had an unrecognized sub-avp with the m-bit set. But on re-reading that part, I think that may only be true if the grouped AVP is also not understood.

> 
> Steve
> 
> On 12/22/14 10:34 PM, Ben Campbell wrote:
>> Martin, I think we are violently agreeing. A DOIC "failure" doesn't impact the Diameter transaction.
>> 
>> 
>>> On Dec 22, 2014, at 8:42 PM, DOLLY, MARTIN C <[email-masked]> wrote:
>>> 
>>> To be clear, ignore what one does not understand.
>>> 
>>> -----Original Message-----
>>> From: DiME [mailto:[email-masked]] On Behalf Of DOLLY, MARTIN C
>>> Sent: Monday, December 22, 2014 9:34 PM
>>> To: Ben Campbell; Steve Donovan
>>> Cc: [email-masked]
>>> Subject: Re: [Dime] Handling of mandatory sub-avps
>>> 
>>> *** Security Advisory: This Message Originated Outside of AT&T ***.
>>> Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
>>> 
>>> NO, WRONG
>>> 
>>> -----Original Message-----
>>> From: DiME [mailto:[email-masked]] On Behalf Of Ben Campbell
>>> Sent: Monday, December 22, 2014 7:16 PM
>>> To: Steve Donovan
>>> Cc: [email-masked]
>>> Subject: Re: [Dime] Handling of mandatory sub-avps
>>> 
>>> My opinion is that any DOIC error (i.e. something wrong in OC-S-F or OC-OLR) should never cause an error or other failure of the enclosing transaction. Normally the only way DOIC should affect a transaction is via abatement.
>>> 
>>> I would grudgingly accept the ability for a Diameter application spec to say that the application must not be used without DOIC (and potentially certain DOIC features.), as long as such a requirement was explicit (including explicit on _how_ it should fail), but I think that's a different use case.
>>> 
>>>> On Dec 22, 2014, at 10:57 AM, Steve Donovan <[email-masked]> wrote:
>>>> 
>>>> All,
>>>> 
>>>> The following is an open issue from Ben's suggested editorial changes that still needs to be addressed.
>>>> 
>>>> Regards,
>>>> 
>>>> Steve
>>>>>> -- 4.3, para 4:
>>>>>> 
>>>>>> We should clarify that this is talking about mandatory to understand for DOIC, but not for the enclosing transaction.
>>>>> SRD> i'm not clear on what you are suggesting.
>>>> We need to be clear that receiving a DOIC avp with a mandatory AVP that you don't understand means you ignore the DOIC AVPs, but does not cause the Diameter transaction to fail. Or was it your intent to allow an application to say that if you get a DOIC avp that you can't process, you have to fail the Diameter transaction?
>>>> 
>>>>> Do you have suggested wording?
>>>> Depends on the answer to the question above.
>>>> 
>>>> _______________________________________________
>>>> DiME mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/dime
>>> _______________________________________________
>>> DiME mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/dime
>>> 
>>> _______________________________________________
>>> DiME mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/dime
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Ben Campbell <[email-masked]>
Date: Mon, 5 Jan 2015 17:11:16 -0600

> On Jan 5, 2015, at 5:05 PM, Ben Campbell <[email-masked]> wrote:
> 
> 
> I wasn't really talking about mandatory AVPs [1].

Well, I guess the email subject really _was_ about mandatory AVPs :-)

> I was talking about DOIC errors in general. Basically, if you get an OC-OLR or OC-S-F that is bogus for some reason, you can ignore it--but the enclosing Diameter transaction is unaffected.
> 
>

---

From: Steve Donovan <[email-masked]>
Date: Wed, 07 Jan 2015 09:37:34 -0600

Ben,

I agree with the behavior you are suggesting.  It isn't, however, clear 
to me what changes need to be made to the specification.

Steve