Re: Issues with LastModified

The reason LastModified was removed from the download request was just to
simplify - conditional downloads weren't thought of as needed since the
use of a fingerprint/timestamp would not save any roundtrips. After
thinking about this some more, I would argue that it is useful when
bandwidth is low and/or expensive, e.g. in a GPRS network, especially if
multiple sets of credentials are supported. I propose, therefore, that it
is re-instated in the download request.

Regarding the time value - the server should not attempt to interpret this
value or compare it with current time, it should just treat it as opaque
data and compare it for equality. But without conditional uploads, the
server could not detect the version mismatch problem described in Section
2.2.1 of the I-D (sacred-protocol-bss-02). It would only have
unconditional uploads and it would not know what version the client's
credentials that are being uploaded were based upon. It seems, therefore,
as if the upload request also should allow the client to specify the
LastModified time of the credentials it's upload are based on. Likewise, a
LastModified value in an upload response would allow a client to later on
do a conditional download request, similar to its usage in a download
response. I therefore propose that a LastModified element be added to the
schema - both for upload requests and responses.

With this functionality, it does not matter if the clock is changed on the
server - all that matters is equality with the timestamp associated with a
credential.  If a server, upon receiving a conditional download request
discovers that the credentials already in place at the client side have the
same version as those stored at the server's end (same LastModified) it
does not have to download anything. If a server, upon receiving a
conditional upload request discovers that the credentials being uploaded
are based on a previous version compared to the version stored at the
server (LastModified in upload differs from LastModified stored) it will
be able to act accordingly, without doing anything but comparing the
LastModified values for equality.

As I see it, a problem would only arise if the server is basing the
LastModified value on its current clock and this clock was reset such that
when an upload occured, the newly uploaded credentials would be assigned
the same LastModified value as some previous version. A version mismatch
would then potentially not be detected. Servers can protect against this
(remote) possibility however, without us having to specify the
exact procedure in the protocol. I.e. by appending a sequence number to
the LastModified value itself.

-- Magnus

On Mon, 13 May 2002, Dale Gustafson wrote:

> 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/
>
>

-- Magnus