Re: [Tzdist] WGLC for draft-ietf-tzdist-service-05

[Daniel Migault <[e-mail]>]

I have read the document and it mostly look fine to me. In addition to
Lester's comments here are my personal comments:

comment 1:

Introduction section 1

"""In the case of operating systems, often those changes only get
propagated to client machines when there is an operating system update,
which can be infrequent, resulting in inaccurate time zone data being
present for significant amounts of time."""

One could also add that relying on OS updates are more risky operations
than TZ updates, as such, we should not rely on OS upgrade for TZ updates.

comment 2:

Figure 1. Maybe  "Provider" could be replaced by "Root
Providers"/"Secondary Providers"

comment 3:

"""3.5. Observance
   Data that defines a portion of a time zone where the UTC offset is a
constant.
"""
The offset is always a constant, so I am wondering if it would not be
better to say:

Data that defines a portion of a time zone where the UTC offset is constant
during the observance.

comment 4:

"""To support conditional time zone requests, based on whether the
underlying time zone data or meta-data has changed, the server supports two
options:"""

I would prefer to make clear these two options are necessary to cover all
cases. Maybe removing "the server supports two options" could leverage the
idea that the two options are simply two ways to do the same thing. The
next paragraph however clarify this.

comment 5:


"""4.2.2.1. Initial Synchronization of All Time Zones

   When a secondary service or a client wishing to cache all time zone data
first starts, or wishes to do a full refresh, it synchronizes with another
server by first issuing a "list" action.  """

maybe it would help the reader ti briefly indicate what a list action
results in.

Note that this is done in section
4.2.2.3. "[...]"list" action to retrieve all the time zone meta-data [...]"


comment 6:
4.2.2.2. Subsequent Synchronization of All Time Zones

s/etag/ETag/ ?

OK, I got it. Personaly, I would prefer another keyword for etag,
(tz_version?) and then saying its value equals ETag. But that is only a
personal opinion.


comment 7:


"""4.2.2.2. Subsequent Synchronization of All Time Zones

   A secondary service or a client caching all time zones needs to
periodically synchronize with a server.  To do so it would issue a "list"
action with the "changedsince" URI query parameter set to the
   value of the opaque token returned by the last synchronization."""

Maybe it would ease if the response returned by the server is a bit more
detailed.


comment 8:

I would like to make sure the Json description will not cause any issue.


On Sun, Jan 18, 2015 at 10:49 PM, Daniel Migault <[e-mail]>
wrote:

> Dear Friends an Colleagues,
>
> This is the Working Group Last Call (WGLC) for draft-ietf-tzdist-service-05
> [1] <http://tools.ietf.org/html/draft-ietf-tzdist-service-05>. Please
> provide all comments by February 2.
>
> Best Regards,
>
> Daniel and Eliot
>
>
> [1] http://tools.ietf.org/html/draft-ietf-tzdist-service-05
>
> On Sat, Jan 17, 2015 at 6:52 PM, Lester Caine <[e-mail]> wrote:
>
>> Looking good!
>>
>> Question ... Any reason why 'opaque token' would not be simply the
>> version? Since the data is locked to it's version number nothing else
>> should exist.
>>
>> Only problem ...
>> I'm still unconvinced by the attempt to create "monolithic" and
>> "incremental" models! If I am publishing an historic snapshot, I need a
>> complete set of timezones for that version ... even if my publication
>> method is only supplying the incremental changes. It is an
>> implementation detail of the storage process and asking for an
>> 'incremental' version just seems wrong. One needs the 'monolithic'
>> version at that point. If my data source is TZ, then the only version
>> numbers are those provided by the 'monolithic' view, but I only notify
>> the incremental changes.
>>
>> --
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tzdist
>>
>
>
>
> --
> Daniel Migault
> Orange Labs -- Security
> [phone]
>



-- 
Daniel Migault
Orange Labs -- Security
[phone]