Subject: [Dime] Ben's suggested change on 5.2.1

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 15 Jan 2015 09:58:42 +0000

Ben wrote:
-- section 5.2.1, and subsections:

We still have some awkward use of SHOULDs and MAYs that I think are there to indicate that nodes don't really have to structure their internal state any particular way. But as written, it can be interpreted to allow them to ignore critical pieces of info. We would be better either removing the normative language entirely, or preface the section to say that these represent logical information, and that we do not assume any particular physical structure. (I prefer the latter at this point.) Details:

-- 5.2.1.1: "A reacting node SHOULD maintain...", "The host-type and realm-type OCS entries MAY include..."

What if it doesn't? I think things fail.

Also, I'm still confused by the first part of this section. The reacting node keeps state for every reported and active overload condition. Each will be the result of a realm report or a host report. The text makes it sound like it needs to keep OCS for both report types, even if it had not received both.

<Ulrich> At the reacting node, when there is no overload, e.g. a previous OLR expired or end of overload has been explicitly signalled, it is up to implementations whether to store an OCS containing "no overload" or whether "no overload" is internally indicated by absence of an OCS.

-- 5.2.1.1: "A reporting node SHOULD maintain OCS entries..." and "An OCS entry is identified ... and MAY include ..."

What if it doesn't?

-- 5.2.1.4: "A reporting node MUST NOT update the abatement algorithm in an active OCS entry."

I thought we agreed to remove that, and replace it with the note at the beginning of 5.1?

---

From: Steve Donovan <[email-masked]>
Date: Thu, 15 Jan 2015 07:27:53 -0600

On 1/15/15 3:58 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> We still have some awkward use of SHOULDs and MAYs that I think are 
> there to indicate that nodes don't really have to structure their 
> internal state any particular way. But as written, it can be 
> interpreted to allow them to ignore critical pieces of info. We would 
> be better either removing the normative language entirely, or preface 
> the section to say that these represent logical information, and that 
> we do not assume any particular physical structure. (I prefer the 
> latter at this point.) Details:
SRD> How about the following added to section 5.2.1:

"The contents of the OCS in the reporting node and in the reacting node 
represent logical constructs.  The actual internal physical structure of 
the state included in the OCS is an implementation decision."

SRD> I'm also ok with removing the normative language. I'll show 
examples below.

> realm-type OCS entries MAY include..."
SRD> Change:

A reacting node SHOULD maintain the following OCS per supported
    Diameter application:

to:

A reacting node maintains the following OCS per supported
    Diameter application:

Change:

    The host-type and realm-type OCS entries MAY include the following
    information (the actual information stored is an implementation
    decision):

to:

    The host-type and realm-type OCS entries include the following
    information (the actual information stored is an implementation
    decision):

SRD> And so on.  This looks better and I don't think we lose anything.

> Also, I'm still confused by the first part of this section. The 
> reacting node keeps state for every reported and active overload 
> condition. Each will be the result of a realm report or a host report. 
> The text makes it sound like it needs to keep OCS for both report 
> types, even if it had not received both.
> <Ulrich> At the reacting node, when there is no overload, e.g. a 
> previous OLR expired or end of overload has been explicitly signalled, 
> it is up to implementations whether to store an OCS containing “no 
> overload” or whether “no overload” is internally indicated by absence 
> of an OCS.
SRD> How about changing the first paragraph to the following:

    A reacting node SHOULD maintain the following OCS per supported
    received overload report:

> -- 5.2.1.1: "A reporting node SHOULD maintain OCS entries..." and "An 
> OCS entry is identified ... and MAY include ..."
> What if it doesn't?
SRD> This concern is addressed if we remove the SHOULDs and MAYs.
> I thought we agreed to remove that, and replace it with the note at 
SRD> You are correct, the paragraph was entered but some of the 
normative statements were missed.  There is also a statement in the 
overview that still says reporting nodes can't change the algorithm 
during an active overload condition.  This will need to be removed as well.
>
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Ben Campbell <[email-masked]>
Date: Thu, 15 Jan 2015 09:17:23 -0600

> On Jan 15, 2015, at 7:27 AM, Steve Donovan <[email-masked]> wrote:
> 
> 
> "The contents of the OCS in the reporting node and in the reacting node represent logical constructs.  The actual internal physical structure of the state included in the OCS is an implementation decision."

+1

> 
> SRD> I'm also ok with removing the normative language.  I'll show examples below.
> 
> 
>>  

WFM

>> <Ulrich> At the reacting node, when there is no overload, e.g. a previous OLR expired or end of overload has been explicitly signalled, it is up to implementations whether to store an OCS containing “no overload” or whether “no overload” is internally indicated by absence of an OCS. 

WFM

> SRD> You are correct, the paragraph was entered but some of the normative statements were missed.  There is also a statement in the overview that still says reporting nodes can't change the algorithm during an active overload condition.  This will need to be removed as well.

Agreed (and i had a separate comment on the statement in the overview.)