Subject: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR

From: "dime issue tracker" <[email-masked]>
Date: Tue, 04 Feb 2014 08:49:38 -0000

#32: Sequence-Number Time-Stamp values within OC-OLR

 The -01 draft says in clause 4.4:
    From the functionality point of view, the OC-Sequence-Number AVP MUST
    be used as a non-volatile increasing counter between two overload
    control endpoints (neglecting the fact that the contents of the AVP
    is a 64-bit NTP timestamp [RFC5905]).  The sequence number is only
    required to be unique between two overload control endpoints.
    Sequence numbers are treated in uni-directional manner, i.e. two
    sequence numbers on each direction between two endpoints are not
    related or correlated.

    When generating sequence numbers, the new sequence number MUST be
    greater than any sequence number previously seen between two
    endpoints within a time window that tolerates the wraparound of the
    NTP timestamp (i.e. approximately 68 years).

 With this mechanism it is difficult to get back to sync once you are out
 of sync (for whatever reason).
 It is proposed to mandate that the Sequence Number is a real 64-bit NTP
 timestamp (RFC5905) indicating the point in time when the OLR was created,
 and to mandate that  OLRs with a time stamp higher than time of reception
 must be ignored by the reacting node.

-- 
--------------------------------------+--------------------------
 Reporter:  [email-masked]  |      Owner:  Ulrich Wiehe
     Type:  defect                    |     Status:  new
 Priority:  major                     |  Milestone:
Component:  draft-docdt-dime-ovli     |    Version:
 Severity:  Active WG Document        |   Keywords:
--------------------------------------+--------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/32>
dime <http://tools.ietf.org/wg/dime/>

---

From: <[email-masked]>
Date: Tue, 4 Feb 2014 18:19:58 +0000

The existing wording seems actually fuzzy.
If it is "like an NTP timestamp", be proud and say it loud!

In summary: ok with the proposal if it clarifies this handling of this sequence-number.

Lionel

-----Message d'origine-----
De : dime issue tracker [mailto:[email-masked]] 
Envoyé : mardi 4 février 2014 09:50
À : MORAND Lionel IMT/OLN
Cc : [email-masked]
Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Wed, 5 Feb 2014 04:27:27 +0000

I also agree.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, February 04, 2014 11:50 PM
To: [email-masked]
Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR

Lionel

-----Message d'origine-----

 With this mechanism it is difficult to get back to sync once you are out  of sync (for whatever reason).
 It is proposed to mandate that the Sequence Number is a real 64-bit NTP  timestamp (RFC5905) indicating the point in time when the OLR was created,  and to mandate that  OLRs with a time stamp higher than time of reception  must be ignored by the reacting node.

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

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

---

From: Steve Donovan <[email-masked]>
Date: Wed, 05 Feb 2014 08:33:36 -0600

How the sequence number is implemented is an implementation decision. 
There is no reason to mandate that is be an NTP timestamp.  That should
be included only as one way of addressing the requirement.

Steve

---

From: <[email-masked]>
Date: Wed, 5 Feb 2014 15:37:03 +0000

I think the out-of-sync failover described by Ulrich is a good use case to mandate a specific semantic.

Is there any specific NOT to mandate the use of NTP timestamps if it is a simple way to solve the possible issues and please everyone?

Lionel

De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : mercredi 5 février 2014 15:34
À : [email-masked]
Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR

How the sequence number is implemented is an implementation decision.  There is no reason to mandate that is be an NTP timestamp.  That should be included only as one way of addressing the requirement.

Steve

I also agree.

Regards,

Nirav.

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

From: DiME [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>

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

Lionel

-----Message d'origine-----

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

    related or correlated.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 5 Feb 2014 09:46:37 -0600

I concur with Steve on this one. Using a time stamp is a good way to meet the requirements, but it's not our job to normatively state an implementation. In fact, it violates an RFC 2119 "MUST" level requirement to do so. Section 6 of 2119 includes the following:

"In particular, [normative requirements] MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  "

The only appropriate reason to require a timestamp would be if we expected peers to interpret the field as a point in time. OTOH, it would be perfectly reasonable to state the actual interop requirements, then add a non-normative (probably indented) paragraph suggesting that a timestamp is a good way to do this.

---

From: <[email-masked]>
Date: Wed, 5 Feb 2014 15:53:43 +0000

Not sure to understand: if there is a kind of "interop requirement", it is a case for a "MUST".
We are not violating anything.

Reporting and reacting nodes will just rely on the Diameter interfaces to know how to handle the received sequence-number. So any MUST on the format of the sequence-number is acceptable if it avoids interop issues.

-----Message d'origine-----
De : Ben Campbell [mailto:[email-masked]] 
Envoyé : mercredi 5 février 2014 16:47
À : MORAND Lionel IMT/OLN
Cc : Steve Donovan; [email-masked]
Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR

---

From: Ben Campbell <[email-masked]>
Date: Wed, 5 Feb 2014 09:56:45 -0600

My point is, we have an interop requirement that the sequence number always increases over time scope. We do not have the interop requirement that the sequence number be implemented as a time stamp. A time stamp is probably a good way to  meet the interop requirements, but it is not, in itself, an interop requirement.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 6 Feb 2014 13:12:09 +0000

I cannot understand what is the problem with mandating timestamp.
But I can see interoperability problems with the current definition:

Assume the sender sends sequence numbers
1, 1, ... 1, 2, 2, ... 2, 3, 3, 3,  ... 3, 4, 4, ... 4, 5,.... 
but the receicer for any reason receives 
1, 1, ... 1, 2, 2, ... 2, 3, 30000, 3,  ... 3, 4, 4, ... 4, 5,.... 
The receiver would accept
1, 1, ... 1, 2, 2, ... 2, 3, 30000
and then silently discards
3,  ... 3, 4, 4, ... 4, 5,....  4, 5, .... 
with no way to come back to sync.

Are we sure that this cannot happen?

Mandating timestamp for sequence number generation at the sender and plausibility checking (i.e. received value must be between stored value and time of reception) for the receiver may not be the only way to solve the problem. But in the moment I don't see another way.

Ulrich

---

From: Steve Donovan <[email-masked]>
Date: Thu, 06 Feb 2014 09:49:33 -0600

A couple of things -

The requirement is that the sequence number increase monotonically over
time, including over a reboot.  Use of NTP time is one way of doing this
but is not the only way.  Someone could, for instance, use a time stamp
to set the sequence number for the first overload report sent after a
reboot and then increment the sequence number value by one for each
subsequent overload report sent.  This actually has better properties
than an NTP time stamp as it would take much longer to roll over.  One
could also create a global sequence number service that is not tied to
time and have a Diameter server query that global sequence number server
after each reboot.

We also have a duration timer on overload reports.  This gives us one
way to reset.  It should only be required to remember the sequence
number of an active overload report.  Once the overload report expires
there is no reason to remember anything about it and the next overload
report received could, conceivably have any value.

The requirement we need is similar to the session-id in the base
Diameter specification.  The wording there is -- "The Session-Id MUST be
globally and eternally unique".  We just need eternally as the spacial
differentiation is based on the context of the message carrying the
overload report.

It would be perfectly valid for the DOIC draft to suggest the use of NTP
timestamps to populate the sequence number but it should be worded in a
similar fashion as the Diameter base RFC -- The Session-Id includes a
mandatory portion and an implementation-defined portion; a recommended
format for the implementation-defined portion is outlined below..."

Steve

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 7 Feb 2014 12:25:43 +0200

My personal take is that we should simply say it is
a NTP timestamp and not fuzzy around it with other
possible treatment possibilities.

- Jouni

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 7 Feb 2014 11:00:06 +0000

Steve,

sounds like an acceptable proposal which allows to come back to sync after OLR expiry.
This requires however an update of clause 5.5.2 to clearly state
Once the overload report expires there is no reason to remember anything about it and the next overload report received could, conceivably have any value.

Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Thursday, February 06, 2014 4:50 PM
To: [email-masked]
Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR

A couple of things -

The requirement is that the sequence number increase monotonically over time, including over a reboot.  Use of NTP time is one way of doing this but is not the only way.  Someone could, for instance, use a time stamp to set the sequence number for the first overload report sent after a reboot and then increment the sequence number value by one for each subsequent overload report sent.  This actually has better properties than an NTP time stamp as it would take much longer to roll over.  One could also create a global sequence number service that is not tied to time and have a Diameter server query that global sequence number server after each reboot.

We also have a duration timer on overload reports.  This gives us one way to reset.  It should only be required to remember the sequence number of an active overload report.  Once the overload report expires there is no reason to remember anything about it and the next overload report received could, conceivably have any value.

The requirement we need is similar to the session-id in the base Diameter specification.  The wording there is -- "The Session-Id MUST be globally and eternally unique".  We just need eternally as the spacial differentiation is based on the context of the message carrying the overload report.

It would be perfectly valid for the DOIC draft to suggest the use of NTP timestamps to populate the sequence number but it should be worded in a similar fashion as the Diameter base RFC -- The Session-Id includes a mandatory portion and an implementation-defined portion; a recommended format for the implementation-defined portion is outlined below ..."

Steve

Ulrich

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

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

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

On Feb 5, 2014, at 9:53 AM, <[email-masked]><mailto:[email-masked]> <[email-masked]><mailto:[email-masked]> wrote:

-----Message d'origine-----

Cc : Steve Donovan; [email-masked]<mailto:[email-masked]>

On Feb 5, 2014, at 9:37 AM, [email-masked]<mailto:[email-masked]> wrote:

Lionel

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

Steve

I also agree.

Regards,

Nirav.

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

Lionel

-----Message d'origine-----

   related or correlated.

Thank you.

DiME mailing list

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

Thank you.

DiME mailing list

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

DiME mailing list

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

DiME mailing list

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

---

From: Jouni Korhonen <[email-masked]>
Date: Sat, 8 Feb 2014 12:33:27 +0200

Sounds acceptable. Would the following then work for all:

o clarify that once the overload report expires there is no
  reason to remember anything about it
o the sequence number would be similar to session-id.. based 
  on the NTP time + any vendor specific data to make it 
  "globally and eternally unique".

- Jouni

---

From: <[email-masked]>
Date: Mon, 10 Feb 2014 13:47:47 +0000

I would add, maybe even before the format (NTP time based), that the real requirements for the sequence-number are:

- Globally/eternally unique
- increase monotonically over time, including over a reboot (as remind by Steve) 

The NTP time based type is just a guidance provided by the draft on how to generate sequence numbers with such properties.

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Jouni Korhonen
Envoyé : samedi 8 février 2014 11:33
À : Wiehe, Ulrich (NSN - DE/Munich)
Cc : [email-masked]
Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR

- Jouni

---

From: Steve Donovan <[email-masked]>
Date: Mon, 10 Feb 2014 07:58:36 -0600

+1

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 11 Feb 2014 21:59:25 +0000

It sounds reasonable to me as well.
/MCruz

From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: lunes, 10 de febrero de 2014 14:59
To: [email-masked]
Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR

+1
On 2/10/14 7:47 AM, [email-masked]<mailto:[email-masked]> wrote:

Lionel

-----Message d'origine-----

- Jouni

On Feb 7, 2014, at 1:00 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]><mailto:[email-masked]> wrote:

Steve,

Ulrich

A couple of things -

Steve

Ulrich

-----Message d'origine-----

Lionel

Steve

I also agree.

Regards,

Nirav.

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

Lionel

-----Message d'origine-----

   related or correlated.

Thank you.

DiME mailing list

Thank you.

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 12 Feb 2014 00:42:59 +0200

If the NTP is only going to be guidance when building the globally
and eternally unique sequence number, IMHO better not mention NTP
then at all. Just include the required properties below. One less
mandatory reference..

- Jouni

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 12 Feb 2014 13:28:08 +0000

Maybe its worth to explicitly say that "... there is no reason to remember anything about it" includes "no need for reacting nodes to remember sequence numbers of expired OLRs" or even mandate that sequence numbers of expired OLRs must not be remembered by reacting nodes.
Ulrich

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 10, 2014 2:48 PM
To: Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: RE: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR

Lionel

-----Message d'origine-----

- Jouni

---

From: Steve Donovan <[email-masked]>
Date: Thu, 13 Feb 2014 06:25:58 -0600

Jouni,

The important thing is to define the properties.  There should be no
harm in giving one suggested implementation.

Steve

---

From: Steve Donovan <[email-masked]>
Date: Thu, 13 Feb 2014 06:26:55 -0600

Ulrich,

I agree, we should say must not remember.  Otherwise it will be more
difficult to get back into syncronization.

Steve

---

From: <[email-masked]>
Date: Fri, 14 Feb 2014 15:59:04 +0000

I agree.

De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : jeudi 13 février 2014 13:26
À : [email-masked]
Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR

Jouni,

The important thing is to define the properties.  There should be no harm in giving one suggested implementation.

Steve

mandatory reference..

- Jouni

On Feb 11, 2014, at 11:59 PM, Maria Cruz Bartolome <[email-masked]><mailto:[email-masked]> wrote:

/MCruz

+1

Lionel

-----Message d'origine-----

- Jouni

Steve,

Ulrich

A couple of things -

Steve

Ulrich

-----Message d'origine-----

Lionel

Steve

I also agree.

Regards,

Nirav.

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

Lionel

-----Message d'origine-----

   related or correlated.

Thank you.

DiME mailing list

Thank you.

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

DiME mailing list

DiME mailing list

---

From: <[email-masked]>
Date: Fri, 14 Feb 2014 15:59:24 +0000

And I agree too.

De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : jeudi 13 février 2014 13:27
À : [email-masked]
Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR

Ulrich,

I agree, we should say must not remember.  Otherwise it will be more difficult to get back into syncronization.

Steve

Ulrich

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

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

Lionel

-----Message d'origine-----

- Jouni

Steve,

Ulrich

A couple of things -

Steve

Ulrich

-----Message d'origine-----

Lionel

Steve

I also agree.

Regards,

Nirav.

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

Lionel

-----Message d'origine-----

   related or correlated.

Thank you.

DiME mailing list

Thank you.

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

DiME mailing list

Thank you.

DiME mailing list

---

From: Ben Campbell <[email-masked]>
Date: Fri, 14 Feb 2014 15:28:06 -0600

+1. It doesn't even have to be "suggested" in the since of a (non-normative) recommendation. It can merely be an example of an approach which meets the stated requirements.

On Feb 13, 2014, at 6:25 AM, Steve Donovan <[email-masked]> wrote:

>> On Feb 11, 2014, at 11:59 PM, Maria Cruz Bartolome 
>> <[email-masked]>
>>  wrote:
>> 
>> 
>>> From: DiME [
>>> mailto:[email-masked]
>>> ] On Behalf Of Steve Donovan
>>> To: 
>>> [email-masked]
>>> On 2/10/14 7:47 AM, 
>>> [email-masked]
>>>  wrote:
>>> De : DiME [
>>> mailto:[email-masked]
>>> ] De la part de Jouni Korhonen
>>> Cc : 
>>> [email-masked]
>>> On Feb 7, 2014, at 1:00 PM, "Wiehe, Ulrich (NSN - DE/Munich)" 
>>> <[email-masked]>
>>>  wrote:
>>>  
>>> Steve,
>>>  
>>> From: DiME [
>>> mailto:[email-masked]
>>> ] On Behalf Of ext Steve Donovan
>>> To: 
>>> [email-masked]
>>> From: DiME [
>>> mailto:[email-masked]
>>> ] On Behalf Of ext Ben Campbell
>>> Cc: 
>>> [email-masked]
>>> On Feb 5, 2014, at 9:53 AM, 
>>> <[email-masked]> <[email-masked]>
>>>  wrote:
>>>  
>>> De : Ben Campbell [
>>> mailto:[email-masked]
>>> ] 
>>> On Feb 5, 2014, at 9:37 AM, 
>>> [email-masked]
>>>  wrote:
>>>  
>>> De : DiME [
>>> mailto:[email-masked]
>>> ] De la part de Steve Donovan
>>> À : 
>>> [email-masked]
>>> From: DiME [
>>> mailto:[email-masked]] On Behalf Of [email-masked]
>>> 
>>> To: 
>>> [email-masked]
>>> De : dime issue tracker [
>>> mailto:[email-masked]
>>> ]
>>> Cc : 
>>> [email-masked]

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 28 Feb 2014 16:01:21 +0200

<as a chair>

It seems we reached a conclusion here. So summarizing:

o Document that the sequence number is:
 - Globally/eternally unique.
 - increase monotonically over time, including over a reboot.
o Write a non-normative recommendation/suggestion how to create
  sequence numbers fulfilling the above requirements (e.g. using
  NTP as one component).

@Ulrich or Lionel could you update the above into the ticket
 and close it?

- JOuni

---

From: <[email-masked]>
Date: Fri, 28 Feb 2014 14:02:05 +0000

I will

-----Message d'origine-----
De : Jouni Korhonen [mailto:[email-masked]] 
Envoyé : vendredi 28 février 2014 15:01
À : [email-masked] list; Ulrich (NSN - DE/Munich) Wiehe; MORAND Lionel IMT/OLN
Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR

<as a chair>

- JOuni

---

From: "dime issue tracker" <[email-masked]>
Date: Fri, 28 Feb 2014 14:05:48 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

Comment:

-- 
--------------------------------------+---------------------------
 Reporter:  [email-masked]  |       Owner:  Ulrich Wiehe
     Type:  defect                    |      Status:  closed
 Priority:  major                     |   Milestone:
Component:  draft-docdt-dime-ovli     |     Version:
 Severity:  Active WG Document        |  Resolution:  fixed
 Keywords:                            |
--------------------------------------+---------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/32#comment:1>
dime <http://tools.ietf.org/wg/dime/>

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 28 Feb 2014 15:07:53 +0000

Dear Jouni,
My understanding is that #32 is RESOLVED as follows:

Agreed - Sequence-Number is of type Unsigned64.
 
Agreed - 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 (where "initial occurrence means something like "moving from no overload to overload after a sufficiently long periode of no overload"). 
When received, a sequence number is used to detect outdates/replays/freshness.
 
Sequence numbers of expired OLRs MUST NOT be remembered by reacting nodes.

Can be CLOSED when the next version of the draft correctly reflects this agreement.

Ulrich

-----Original Message-----
From: ext Jouni Korhonen [mailto:[email-masked]] 
Sent: Friday, February 28, 2014 3:01 PM
To: [email-masked] list; Wiehe, Ulrich (NSN - DE/Munich); [email-masked] Morand
Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR

<as a chair>

- JOuni

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 28 Feb 2014 17:14:13 +0200

Uhh.. there was continuum to this thread. Sorry ;-) Let me come back to
this in a sec.

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 28 Feb 2014 17:43:58 +0200

First.. sorry for missing the continuum of the thread. My _bad_ mistake.

> Agreed - Sequence-Number is of type Unsigned64.

This is/was ok, since time did not really fit anymore what was concluded even earlier.
 
> Agreed - 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).

Ok.

> Sequence numbers of expired OLRs MUST NOT be remembered by reacting nodes.

Ok.

> Can be CLOSED when the next version of the draft correctly reflects this agreement.

Different practises. In some groups we did close tickets once the proposed
change & conclusion was documented in the issue tracker.

One should still update the ticket to contain the conclusion even before
closing it. There is a place for comments. Makes it much easier to track
down the conclusions. (as seen here how easily one misses even a thread
of mails..)

- Jouni