Subject: Re: [Tzdist] Ticket #23

From: Daniel Migault <[email-masked]>
Date: Thu, 23 Oct 2014 22:57:10 +0200

Dear Friends and Colleagues,

I would like to know if the WG still consider Issue # 23 [1] as an open
issue. If so how the how setting any change to "substantive" does not solve
this issue.

BR,

Daniel

[1] http://trac.tools.ietf.org/wg/tzdist/trac/ticket/23

On Wed, Aug 27, 2014 at 2:07 PM, Lester Caine <[email-masked]> wrote:

> I think this is may be covered with other tickets?
>
> Some of the material is still optional. The only procedure that I'm
> still concerned about is how we identify the 'version' of VTIMEZONE data
> that goes with the 'list' results.
>
> Turning the problem around and 'passing the buck' I think a process
> where the publisher creates all the new entries and only then updates
> them in a single transaction will work since the list results will match
> the new published data.
>
> The problem comes down stream, where the secondary servers now read the
> new list and start processing their cached copies. I think the same
> sequence can be applied here so while the server has read the new list,
> IT does not publish any new data until it's local copy is totally in
> sync? Continuing to supply the old data. If for some reason even a
> 'client' does not complete the download process initiated by the updated
> list, then they scrap those updates and retain the older stable version.
> Starting the download with a new list call.
>
> Knowing how often I get drop-outs of connection, this is not the most
> efficient way of replicating data, but I'm not sure that the dtstamp
> process can be used with individual VTIMEZONE packets?
>
> --
> Lester Caine - G8HFL
> -----------------------------
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
> _______________________________________________
> Tzdist mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tzdist
>

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Lester Caine <[email-masked]>
Date: Thu, 23 Oct 2014 23:03:43 +0100

On 23/10/14 21:57, Daniel Migault wrote:
> issue. If so how the how setting any change to "substantive" does not
> solve this issue.

Issue 23 has nothing to do with the question of "substantive"? I think
the elements that are within scope have been solved but not but that change.

Other discussions on how the range of data can be truncated partially
address #23, and as long as slave servers do not start announcing
changes until they are fully in sync with the master source any race can
be avoided.

What needs tagging as 'to do later' is identifying how secondary data
may be passed in a VTIMEZONE packet, and I anticipate that any alternate
data format will handle the underlying tz data in a loss-less manor
since it is not practical to modify VTIMEZONE to plug that particular hole.