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

[Steve Donovan <[e-mail]>]

On 1/20/15 1:20 PM, Ben Campbell wrote:
>> 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.
SRD> I see how it could be interpreted that way.
>
> 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.
SRD> I'm ok either way but prefer number 2).
>
>
>
[...]
>>> 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).
SRD>Actually 5.2.2 isn't only about quenching.  It's also about the 
reacting node having sent no traffic, because it had no traffic to send, 
and now needs to send traffic soon after the OCS expires. The reporting 
node might still be in an overload state but the reacting node doesn't 
know until the first request is sent.
>
> 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.)
SRD> 6.3 deals specifically with quenching, thus is a little different 
than 5.2.2, although there is overlap.
>
> 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.
SRD> I prefer to leave it as it currently is.
>
> [...]