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

[Steve Donovan <[e-mail]>]

All,

We need to close these two issues to finish WGLC #2.

Please review an let me know if the alternatives I have outlined below 
are acceptable.

Thanks,

Steve

On 1/20/15 3:08 PM, Steve Donovan wrote:
>
> 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.
>>
>> [...]
>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
>