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

From: Steve Donovan <[email-masked]>
Date: Tue, 09 Dec 2014 07:51:45 -0600

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

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 9 Dec 2014 17:04:50 +0000

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:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Tuesday, December 09, 2014 2:52 PM
To: [email-masked]
Subject: [Dime] Ulrich's suggested change #15

Ulrich,

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

---

From: Steve Donovan <[email-masked]>
Date: Wed, 10 Dec 2014 06:48:55 -0600

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.

Steve

---

From: Ben Campbell <[email-masked]>
Date: Wed, 10 Dec 2014 17:26:11 -0600

> 
> On Dec 10, 2014, at 6:48 AM, Steve Donovan <[email-masked]> wrote:
> 
> Ulrich,
> 
> 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.

> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 11 Dec 2014 08:32:03 +0000

Ben,
for my clarification:
you wrote: "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."

I would have thought that "For Report-Type, that means ignore the whole set of OLRs".
At least it should be allowed to do that.

The requirement for the reporting node is to not send OLRs with report type values that are unknown/unsupported by the reacting node. 
The reporting node cannot assume that, when breaking this rule, the reacting node will act in a predictable way. It should even be ok for the reporting node to ignore the complete answer message.

Please let me know your comments.

Ulrich

---

From: Steve Donovan <[email-masked]>
Date: Thu, 11 Dec 2014 08:05:12 -0600

I thought this paragraph was covering unrecognized values for all AVPs.  
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.

Steve

---

From: Ben Campbell <[email-masked]>
Date: Thu, 11 Dec 2014 12:45:01 -0600

> On Dec 11, 2014, at 2:32 AM, Wiehe, Ulrich (NSN - DE/Munich) <[email-masked]> wrote:
> 
> Ben,
> for my clarification:
> The reporting node cannot assume that, when breaking this rule, the reacting node will act in a predictable way.

 I think we should allow ignoring the whole set, but not require that. Postel's Maxim might suggest that if there are other properly constructed OLRs, the reacting node can still reasonably assume that the reporting node meant them, but it's up to the implementation.

> It should even be ok for the reporting node to ignore the complete answer message.
> 

Except that. I don't think we _ever_ want a DOIC error to cause the enclosing transaction to fail.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 11 Dec 2014 12:51:18 -0600

> On Dec 11, 2014, at 8:05 AM, Steve Donovan <[email-masked]> wrote:
> 

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".

>  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.

---

From: Steve Donovan <[email-masked]>
Date: Thu, 11 Dec 2014 13:25:35 -0600

> 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 mig…
That is probably worth saying.
> 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…
Agreed.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 15 Dec 2014 17:56:10 +0000

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:[email-masked]] 
Sent: Thursday, December 11, 2014 8:26 PM
To: Ben Campbell
Cc: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Subject: Re: [Dime] Ulrich's suggested change #15

Agreed.

---

From: Steve Donovan <[email-masked]>
Date: Tue, 16 Dec 2014 08:50:59 -0600

I'll delete the paragraph.

Do we need explicit statements for the two conditions below?

Steve

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 17 Dec 2014 08:49:27 +0000

Yes please.

-----Original Message-----
From: ext Steve Donovan [mailto:[email-masked]] 
Sent: Tuesday, December 16, 2014 3:51 PM
To: Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell
Cc: [email-masked]
Subject: Re: [Dime] Ulrich's suggested change #15

Steve

---

From: Steve Donovan <[email-masked]>
Date: Mon, 22 Dec 2014 08:12:24 -0600

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

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 23 Dec 2014 12:30:37 +0000

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:[email-masked]]
Sent: Monday, December 22, 2014 3:12 PM
To: Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell
Cc: [email-masked]
Subject: Re: [Dime] Ulrich's suggested change #15

Steve

Yes please.

-----Original Message-----

Cc: [email-masked]<mailto:[email-masked]>

Steve

Steve, Ben,

Regards

Ulrich

-----Original Message-----

To: Ben Campbell

Cc: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]<mailto:[email-masked]>

On Dec 11, 2014, at 8:05 AM, Steve Donovan <[email-masked]><mailto:[email-masked]> wrote:

Agreed.

Steve

On Dec 10, 2014, at 6:48 AM, Steve Donovan <[email-masked]><mailto:[email-masked]> wrote:

Ulrich,

    be logged.

Steve

Hi Steve,

The rule is:

See section 4.2.3.

Regards

Ulrich

To: [email-masked]<mailto:[email-masked]>

Ulrich,

Existing text:

     be logged.

     be logged.

Regards,

Steve

DiME mailing list

[email-masked]<mailto:[email-masked]>

---

From: Ben Campbell <[email-masked]>
Date: Tue, 23 Dec 2014 09:05:50 -0600

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) <[email-masked]> wrote:
> 
> No, that was not what I’m after.
>

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 23 Dec 2014 15:55:26 +0000

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.
I do not agree to relax the "MUST NOT do so" requirement for the reporting node.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 23 Dec 2014 10:40:39 -0600

> On Dec 23, 2014, at 9:55 AM, Wiehe, Ulrich (NSN - DE/Munich) <[email-masked]> wrote:
> 

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.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 23 Dec 2014 16:54:19 +0000

Thank you for the clarification.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 23 Dec 2014 18:54:34 +0000

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