Re: Issues with LastModified

Hi Menno,

To control conditional operations, people have expressed interest in:

 - last-modified date/time
 - credential fingerprint
 - one-up sequence count

Last-modified may be preferred because date/time is so much easier for users to work
with.

Fingerprint is interesting because it doesn't change for a given credential.  A
given user credential retains the same fingerprint value no matter which server it's
uploaded to and when.

A sequence count is, I assume, unique to a specific credential server?

I hope we don't need to coordinate time between servers and clients.  Sounds like an
error-prone approach, especially for SACRED environments.

My sense is that a combination of last-modified and/or fingerprint could be
effective in all cases.  The server would match one or both values (both if the
client provides both) then perform or not-perform the conditional operation:

 - upload:  if one or both match, overwrite existing credential with the new one
 - download:  if one or both match, skip the (unnecessary) download
 - delete:  if one or both match, delete the credential

Other ideas?

Best Regards,

Dale Gustafson


Menno Pieters wrote:

> Alexey Melnikov wrote:
> > Hi,
> >
> > I would like to reopen the discussion about LastModified field.
> >
> > Firstly, in draft-ietf-sacred-protocol-bss-01.txt UploadRequest doesn't
> > contain LastModified anymore. I suspect it was removed by mistake from
> > the XML schema. Without LastModified in UploadRequest there are no
> > conditional uploads.
> >
> > Secondly, it wouldn't be uncommon for a machine running a Sacred server
> > also to run a NTP client or similar.
> > Now imagine the following sequence of events:
> > 1). Client A uploads a request and server assigns a LastModified value
> > to it.
> > 2). NTP client running on the same machine adjust current time to be 5
> > minutes to the past from LastModified in 1).
> > 3). Another upload request happens in these 5 minutes, assigned
> > LastModified will be less than in 1).
> >
> > Thus I suggest you change LastModified to be a sequence counter,
> > incremented every time the credential is modified.
>
> Those are two completely different things. A counter could be a nice addition,
> but cannot replace a timestamp. A timestamp shows _when_ a modification took
> place, a counter only _how many_ times.
>
> The problem above can also occur if time is maintained 'manually'. NTP is not
> the problem, it could be the solution. If NTP is running on a machine, it's
> internal clock must me pretty bad, or the machine has been off-line for quite a
> while if it is adjusted by 5 five minutes at once. By the way, if the time on a
> machine is not correct, an NTP daemon usually adjusts the time gradually in
> stead of one big step.
>
> One way to prevent suchs problems might be to compare system times of the server
> and client (based on UTC/GMT). If these differ, say, more than one minute, the
> systems could refuse to communicate any further.
>
> Regards,
>
> Menno Pieters
> --
> Menno Pieters - M&I/STELVIO bv
> Postbus 2171, 3800 CD Amersfoort, the Netherlands
> Zonnehof 41,  3811 ND Amersfoort, the Netherlands
> phone: +31-33-4.697.340 / fax: +31-33-4.697.341
> XOIP: +31-84-8.720.349 / Web: http://www.stelvio.nl/