Re: [Dime] WLGC #2 for draft-ietf-dime-ovli-06

[Ben Campbell <[e-mail]>]

> On Jan 20, 2015, at 12:42 PM, Steve Donovan <[e-mail]> wrote:
> 
> The following is the resolution of Ben's issues that were not addressed directly in an email thread started by Ulrich.
> 
> Regards,
> 
> Steve 
> 
>> 
>> -- 5.3, 4th paragraph:
>> 
>> As I mentioned in previous discussion, after re-reading the related text in 6733, it's no longer clear to me this works like we thought it did. That is, I think any attempt to make sub-AVPs mandatory risks causing errors in the enclosing Diameter transaction. I don't know how to solve this, other just disallowing mandatory sub-AVPs. (Jouni previously convinced me 6733 treatment of the m-bit in sub-avps worked like we wanted--perhaps he can re-convince me :-)  
>> 
> SRD>Given that Jouni successfully convinced Ben about the 6733 treatment, I'm not planning to make any changes, as I'm assuming he can be just as successful the second time. 

I think that's a bad assumption.

We had previously assumed that if a node receives a grouped AVP (without the m-bit set) that includes an unrecognized sub-avp with the m-bit set, then the receiver could just ignore the entire grouped AVP, and otherwise process the transaction. But 6733 actually says the following:

"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.  The
   rule applies even if the encapsulated AVP with its 'M' (mandatory)
   bit set is further encapsulated within other sub-groups, i.e., other
   Grouped AVPs embedded within the Grouped AVP."

Note the "... if the Grouped AVP itself is unrecognized." clause.

The case we have in mind is when you receive a _recognized_ grouped AVP (that is, you implement DOIC), but it includes an unrecognized sub-avp with the M-bit set. This is not covered by the exception. This would seem to indicate that the entire request must fail. I don't think that's what we want.

At this point, I think we need to either say that sub-avps of DOIC grouped AVPs either 1) MUST NOT have the m-bit set, or 2) MUST NOT have the m-bit set unless the sub-avp is part of an extension explicitly negotiated in the feature vector.


>> 
>> -- 6.3, paragraph 2:
>> 
>> This is stronger than the SHOULDs in the general behavior section (5.2.2)
>> 
> SRD> Section 5.2.2 says:
> 
>    If the request matches an active OCS then the reacting node MUST use
>    the overload abatement algorithm indicated in the OCS to determine if
>    the request is to receive overload abatement treatment.
> 
> Section 6.3 says:
> 
>    When receiving an OC-OLR in an answer message where the algorithm
>    indicated in the OC-Supported-Features AVP is the loss algorithm, the
>    reacting node MUST apply abatement treatment to the requested
>    percentage of request messages sent.
> 
> I don't see the issue.

I was referring to the "SHOULD apply diversion, else SHOULD apply throttling" language. But that's been fixed as part of a separate discussion.

>> 
>> Paragraph 5: 
>> 
>> Is this redundant to the last paragraph of 5.2.2?
>> 
> SRD> I don't see an issue.  One is general and the other specific to the loss algorithm.  They don't conflict.

The one in 5.2.2 is specific to situations where an OLR quenches all requests, and says MUST. So is this, and says RECOMMENDED (which means SHOULD in 2119).

If the idea is that the text in 6.3 is the recommended way to fulfill the MUST in 5.2.2, then that's okay I guess (although I would prefer one of the two to be non-normative.)

Another approach would to leave this to 6.3, and add something to the effect that any new algorithm that can cause total quenching of requests must address how the reacting node restarts from that state. 

[...]