Re: [Dime] Issue#32 status

["Wiehe, Ulrich (NSN - DE/Munich)" <[e-mail]>]

I agree. It seems we can close issue#32.

I assume editors will convert the agreed principles to propper specification text.

Ulrich

From: ext Steve Donovan [mailto:[e-mail]]
Sent: Tuesday, February 25, 2014 5:37 PM
To: Wiehe, Ulrich (NSN - DE/Munich); Ben Campbell
Cc: [e-mail] list
Subject: Re: [Dime] Issue#32 status

Ulrich,

Yes, with that period being long enough for the reporting node to be confident that all previously sent overload reports have expired.

Steve
On 2/25/14 10:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

Steve, Ben,



for my clarification, your proposal is to say



***

Sequence number is of type Unsigned64.



When generated, a new sequence number must be greater than the sequence number contained in the active overload report to which it applies (including over reboot of that node).  Note: this allows sequence numbers to start at 1 for the initial occurrence of an overload condition at a reporting node.

***



If so, what is meant by "initial occurrence of an overload condition"?



I guess it means something like moving from no overload to overload after a sufficiently long periode of no overload



Please clarify



Ulrich





From: DiME [mailto:[e-mail]] On Behalf Of ext Steve Donovan

Sent: Tuesday, February 25, 2014 4:02 PM

To: Ben Campbell

Cc: [e-mail]<mailto:[e-mail]> list

Subject: Re: [Dime] Issue#32 status



I agree with the suggested change.



Steve

On 2/24/14 5:00 PM, Ben Campbell wrote:

+ 1, except as noted:



On Feb 24, 2014, at 2:33 PM, Steve Donovan <[e-mail]><mailto:[e-mail]> wrote:



Ulrich,



Would you agree to the following to replace the first two statements:



Sequence number is of type Unsigned64.



When generated, a new sequence number must be greater than the sequence number contained in the active overload report to which it applies (including over reboot of that node).  Note: this allows sequence numbers to start at 1 for any occurrence of overload at a reporting node.  This, I think, allows us to ignore wraparound issues as wraparound will never happen.  Unless we are worried about a server staying in overload for billions of years (assuming reports with a ten minute validity period refreshed every five minutes).



s/ any occurrence of overload / the initial occurrence of an overload condition





The other two statements are good.



Steve