Re: [Tzdist] eliot review of draft-ietf-tzdist-service

[Lester Caine <[e-mail]>]

On 30/01/15 14:32, Eliot Lear wrote:
> Minor Issues:
> 
> In Section 2, as far as this protocol is concerned, is there any
> architectural difference between Root Providers and Secondary
> Providers?  If not, we should should say so.  I'm tempted to suggest
> combining them, as well.

I would not view a 'publisher' as a provider, but rather someone who
crates a master set of data which is then served up via a root provider.
These providers would be considered master records? While almost
anything that is replicating that data is a secondary provider? There
needs to be a distinction in the absence of any mechanism to indicate
the last time a provider updated from the published source. I would
consider a root provider the first point of update to a published set of
data?

>From a practical point of view, secondary providers may only be
publishing a local subset of material, so one needs to go back up the
chain to a root provider if one needs additional material?

> Section 3.9:
>>    When truncating the start of a "VTIMEZONE" component, the server MUST
>>    include either a "STANDARD" or "DAYLIGHT" sub-component with a
>>    "DTSTART" property value that matches the start point of the
>>    truncation range, and appropriate "TZOFFSETFROM" and "TZOFFSETTO"
>>    properties to indicate the correct offset in effect right before and
>>    after the truncation range start point.
> 
> Very minor: do you mean an OR or an exclusive OR above.  If you mean the
> former, I would suggest replacing the word "either" with "at least one
> of".  If you mean an exclusive or, then I would suggest replacing
> "either" with "exactly one".

The first period of a truncated frame will be either "STANDARD" or
"DAYLIGHT" depending on which period the truncation started. There is
only "exactly one" entry for each period in the data packet but which
type it starts with is an either-or based on what is then active, so to
me the working is correct?

> Section 4.2.1.2 & 4.2.1.3
> 
> Is there a need for both of these mechanisms?

I'm out of my depth here, but ...
A secondary provider may not be in a position to provide a 'Well-Known
URI' but would advertise it's presence via a TXT record?
I think it relates to the first point above? Local embedded devices may
access a local provider that only services the local timezone, while
other devices on the same network need a more capable services. How does
one distinguish between the two ... is this even covered currently?

This is the area where enforcing secure mechanisms may not be
appropriate. As I've indicated previously, I can see situations where
local 'building management' systems may provide a local provision if
only to eliminate every clock providing device having to dial outside of
the building. One just needs a local discovery mechanism for the local
'embedded' tzdist service, which may also provided a relay for a full
tzdist service, or that is provided by an alternate provider.

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