Re: [Dime] Ulrich's suggested change #15

With this clarification I withdraw my request for explicit statements; simply deleting the paragraph is sufficient.
Ulrich

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Wiehe, Ulrich (NSN - DE/Munich)
Sent: Tuesday, December 23, 2014 5:54 PM
To: ext Ben Campbell
Cc: dime@ietf.org
Subject: Re: [Dime] Ulrich's suggested change #15

Thank you for the clarification.

-----Original Message-----
From: ext Ben Campbell [mailto:ben@nostrum.com] 
Sent: Tuesday, December 23, 2014 5:41 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext Steve Donovan; dime@ietf.org
Subject: Re: [Dime] Ulrich's suggested change #15

> On Dec 23, 2014, at 9:55 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:
> 
> When the reporting node is doing things wrong, i.e. sends an OLR of a type that was not advertized (implicitly or explicitly), or sends two OLRs of same type, although the spec says "MUST NOT do so", we cannot expect the reacting node to sort things out.

Given the current MUST NOT, I agree. As I've mentioned in the past, we don't need to specify behavior on what you do when the peer violates the protocol. If a reacting node receives an answer with two OLRs of the same type, or with an OLR of a type it doesn't recognize, what it does is local policy. It could ignore all further DOIC information from that reacting node, and treat it like a non-supporting node. It could ignore all the OLRs in the message, but continue to exchange OC-S-Fs. It could process some (or one) of the OLRs and ignore the rest. It's up to the implementors to decide.

BTW, we don't need text to say that, unless we want to actually favor one strategy over another.

> I do not agree to relax the "MUST NOT do so" requirement for the reporting node.
> 

I did not seriously expect us to. I just tossed it out as something to think about.

> 
> -----Original Message-----
> From: ext Ben Campbell [mailto:ben@nostrum.com] 
> Sent: Tuesday, December 23, 2014 4:06 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: ext Steve Donovan; dime@ietf.org
> Subject: Re: [Dime] Ulrich's suggested change #15
> 
> I don't object to allowing that behavior. But thinking of a less extreme case, where you have two OC-OLRs and only recognize one, I think it would be poor design to ignore the one you do recognize. OTOH, it's not the IETF's job to prevent bad design, as long as it's interoperable and doesn't break everyone else (and the network.)
> 
> But we might want to consider the fact that this puts the work upon the overloaded reporting node to make things right, rather than on the reacting node to figure it out. For example, the use cases I've describe in a separate thread, where you have multiple reacting nodes with different capabilities, might could be mitigated by allowing (not requiring) the reporting node put the OC-OLRs for both in each answer. We don't currently allow that unless they are different types, but I wonder if we should think about relaxing that.
> 
>> On Dec 23, 2014, at 6:30 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:
>> 
>> No, that was not what I’m after.
>> 
>> Imagine the (unlikely) case where an answer message contains hundreds of OC-OLR AVPs.
>> 
>> In this case I want the reacting node to be allowed
>> -          Not to scan through all the OC-OLR AVPs to see whether there is a supported  and not duplicated OLR
>> -          To ignore the complete set of OC-OLR AVPs if at least one of the OLR contains an unsupported report-type or at least two of the OLRs contain  the same report type.
>> 
>> As soon as the reacting node detects that there is something wrong with the set of OLRs it may ignore the complete set of OLRs.
>> 
>> Regards
>> Ulrich
>> 
>> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] 
>> Sent: Monday, December 22, 2014 3:12 PM
>> To: Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell
>> Cc: dime@ietf.org
>> Subject: Re: [Dime] Ulrich's suggested change #15
>> 
>> I have added the following statements:
>> 
>>   When receiving an answer message with multiple OLRs and multiple of
>>   the OLRs are of the same supported report types, a reporting node
>>   SHOULD ignore the duplicated OLRs.
>> 
>>   A reacting node SHOULD ignore an OC-OLR with a OC-Report-Type AVP
>>   that contains an unrecognized value.
>> Regards,
>> 
>> Steve
>> 
>> On 12/17/14 2:49 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> Yes please.
>> 
>> -----Original Message-----
>> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] 
>> Sent: Tuesday, December 16, 2014 3:51 PM
>> To: Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell
>> Cc: dime@ietf.org
>> Subject: Re: [Dime] Ulrich's suggested change #15
>> 
>> I'll delete the paragraph.
>> 
>> Do we need explicit statements for the two conditions below?
>> 
>> Steve
>> 
>> 
>> On 12/15/14, 11:56 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> Steve, Ben,
>> 
>> I'm fine with deleting the paragraph.
>> But for my clarification please confirm that ignoring the complete set of OLRs is allowed when one of these OLRs contains a report type that was not advertized, or two of the OLRs contain the same report type.
>> 
>> Regards
>> Ulrich
>> 
>> 
>> 
>> -----Original Message-----
>> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
>> Sent: Thursday, December 11, 2014 8:26 PM
>> To: Ben Campbell
>> Cc: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
>> Subject: Re: [Dime] Ulrich's suggested change #15
>> 
>> 
>> On 12/11/14, 12:51 PM, Ben Campbell wrote:
>> On Dec 11, 2014, at 8:05 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:
>> 
>> I thought this paragraph was covering unrecognized values for all AVPs.
>> I agree that's what it covered. But I think we failed to cover the unrecognized AVP case. If we don't have anything to say beyond what 6733 says, then it might not be strictly necessary, but it might still be worth saying that "unrecognized sub-AVPs are treated as per RFC6733".
>> That is probably worth saying.
>>   Maybe it is better to remove the paragraph entirely and make sure that the definition of each AVP addresses what is done with unrecognized values.
>> Possibly. There are AVPs where there's no such thing as an unrecognized value. There may be AVPs where the allowed values vary by algorithm. If we do take that route, we probably need language here that says unrecognized values are handled as described by the AVP definition or the algorithm.
>> Agreed.
>> Steve
>> 
>> On 12/10/14, 5:26 PM, Ben Campbell wrote:
>> On Dec 10, 2014, at 6:48 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:
>> 
>> Ulrich,
>> 
>> Actually, the wording you suggested wasn't quite right.  It should be:
>> 
>>    When receiving an OC-OLR AVP with unknown values, the overload report
>>    SHOULD be silently discarded by reacting nodes and the event SHOULD
>>    be logged.
>> 
>> It's not just about report type values but unknown values for any of the AVPs in the OLR.
>> 
>> This seems like a good requirement to include in the specification to ensure common behavior in reacting nodes.  I don't feel strongly about this but I would like to hear other opinions.
>> I think this is still not quite complete.
>> 
>> If you receive a sub-AVP that you don't understand, then you should ignore that sub-avp, not the whole OC-OLR AVP.  (Unless of course the unknown AVP has the m-bit set.) If you receive a known sub-AVP, with a value you don't understand, the behavior should be AVP specific. For Report-Type, that means ignore the whole OLR.
>> 
>> It's not clear to me whether the original text was about arbitrary avps, or Report-Type.
>> 
>> Steve
>> 
>> On 12/9/14, 11:04 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> Hi Steve,
>> 
>> I think it was pointed out by Ben that we do not specify behaviour of a node for cases where it detects that another node is breaking the rule.
>> The rule is:
>>     A reporting node MUST NOT send overload reports of a type that has
>>     not been advertised as supported by the reacting node.
>> See section 4.2.3.
>> 
>> Regards
>> Ulrich
>> 
>>    From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
>> Sent: Tuesday, December 09, 2014 2:52 PM
>> To: dime@ietf.org
>> Subject: [Dime] Ulrich's suggested change #15
>> 
>> Ulrich,
>> 
>> For your suggested change #15:
>> Section 4.2.1.3, 4th paragraph:
>> Existing text:
>>     When receiving an OC-OLR AVPs with unknown values, a reacting node
>>     SHOULD be silently discarded by reacting nodes and the event SHOULD
>>     be logged.
>> Comment: text is confusing. Maybe the intention was to say:
>>     When receiving an OC-OLR AVPs with an unsupported report type value, a reacting node
>>     SHOULD silently discarded the OC-OLR AVP and the event SHOULD
>>     be logged.
>> But even that is not correct.
>> Proposal: Remove the paragraph.
>> The intent was that an OC-OLR that contains unknown values should be discarded.  I agree that the wording needs to be changes as you suggested.  I don't agree with removing the paragraph.  Can you elaborate on why you think it is not correct when changed as you suggested?
>> 
>> Regards,
>> 
>> Steve
>> 
>> _______________________________________________
>> 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