Re: [Dime] Issue#32 status

Ben,

my preference for Time was based on the assumtion that it implicitly covers the overflow   (see RFC 6733 clause 4.3.1).

I'm ok with Unsigned64, but then we need to address overflow more precisely, e.g.:

For the reacting node: a newly received sequence number Sn must be considered fresher than a stored sequence number Ss if and only if Ss < Sn < Ss+2^63 or Sn < Ss-2^63.
For the reporting node: when Sl is the last generated sequence number and So is the oldest potentially not yet expired sequence number, a newly generated sequence number Sn must comply with ( Sl < Sn < Sl+2^63 or Sn < sl-2^63 )and( So < Sn < So+2^63 or Sn < So-2^63 ).

Ulrich

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
Sent: Thursday, February 20, 2014 11:43 PM
To: Steve Donovan
Cc: dime@ietf.org list
Subject: Re: [Dime] Issue#32 status

On Feb 19, 2014, at 2:11 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:

>>> Sequence-Number is of type Time, however the value need not correspond to the point in time of generation.
>> SRD> I don't agree that the type should be time.  It should be of type Unsigned64.  A time stamp can be inserted into it but we should not prevent simple sequence numbers.  I agree with the remainder of the statement.
> 

+1. Making it type Time implies that the recipient can do something time related with the value. That is not the case here.

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime