On Mon, May 23, 2011 at 10:32 AM, Marc Petit-Huguenin <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 04/26/2011 01:38 PM, Cullen Jennings wrote:
>>
>> On Mar 15, 2011, at 6:41 PM, Marc Petit-Huguenin wrote:
>>
>>> http://www.ietf.org/mail-archive/web/p2psip/current/msg05792.html
>>
>> Covered in section 6.4.1.1.
>>
>> Search for para starting with
>> "When a peer stores data previously stored by another node"
>>
>
> The confusion here (well, at least for me) is that it is not really clear in
> the
> spec that there is no relationship between the storage_time and lifetime field
> in StoredData. I initially thought that the expiration date/time for a value
> was storage_time + lifetime. The formula in 6.4.1.1 makes clear that it is
> the
> real date/time of storage that is used (like for most I-D/RFCs, the initial
> intent of the authors is generally lost, and implementers have to do detective
> work to find out what to do).
>
> I think that some of the confusion could be prevented. For example
> "storage_time: The time when the data was stored..." is obviously not true
> (it's
> at best the time the StoreReq was signed, and even that is not always true,
> see
> "... the node MAY elect to perform its store using a storage_time that
> increments..." - BTW the whole sentence looks wrong, probably an "If" is
> missing
> at the beginning of it)
>
now reads:
<t>The time when the data was stored represented as the number of
milliseconds elapsed since midnight Jan 1, 1970 UTC not counting
leap seconds. This will have the same values for seconds as standard
UNIX time or POSIX time. More information can be found at <xref
target="UnixTime"></xref>. Any attempt to store a data value with a
storage time before that of a value already stored at this location
MUST generate a Error_Data_Too_Old error. This prevents rollback
attacks. The node SHOULD make a best-effort attempt to use a
correct clock to determine this number, however, the protocol does not
require synchronized clocks: the
receiving peer uses the storage time in the previous store, not its
own clock. Clock values are used so that when clocks are
generally synchronized, data may be stored in a single transaction,
rather than querying for the value of a counter before performing the
actual store.</t>
<t>If a node attempting to store new data in response to a user
request (rather than as an overlay maintenance operation such as
occurs during unpartitioning) is rejected with an Error_Data_Too_Old
error, the node MAY elect to perform its store using a storage_time
that increments the value used with the previous store. This
situation may occur when the clocks of nodes storing to this
location are not properly synchronized.</t>
> Also in "lifetime: the validity ... starting from the time of store", "time of
> store" is ambiguous. Saying "from the time the peer receives the StoreReq"
> matches with 6.4.1.1 and removes the ambiguity.
>
done
> - --
> Marc Petit-Huguenin
> Personal email: [email protected]
> Professional email: [email protected]
> Blog: http://blog.marc.petit-huguenin.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iEYEARECAAYFAk3acA8ACgkQ9RoMZyVa61dQ8wCgoSxght2bE6tfN7/qvgw1L8Ws
> h7gAnAx/x81QFazFYlvMZYHW/6vhL+Om
> =Sqdc
> -----END PGP SIGNATURE-----
> _______________________________________________
> P2PSIP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/p2psip
>
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
