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

From: Eliot Lear <[email-masked]>
Date: Fri, 30 Jan 2015 15:32:09 +0100

Major issues:

Security & privacy considerations must be addressed.  That doesn't mean
we have to accept every aspect of Daniel's review, but we certainly do
need to address them.

Section 8:
>
>    Clients that support transport layer security as defined by [RFC2818]
>    SHOULD try the "_timezones" service first before trying the
>    "_timezone" service.  Clients MUST follow the certificate
>    verification process specified in [RFC6125].

This poses a downgrade attack.  What I thought we had agreed was that we
wanted was that servers MUST implement timezones, and MAY implement
both; clients SHOULD use timezones, but MAY instead query timezone.  But
they should choose one and use it, processing an error if no service is
available.

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.

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

Section 4.2.1.2 & 4.2.1.3

Is there a need for both of these mechanisms?

Nits:

In the next version the following text should either have its tense
changed or be removed:

>    Discussion of this document should take place on the tzdist working
>    group mailing list <[email-masked]>.

Section 2:
>    (a) Contributors:  Individuals, governments or organizations which
>       provide information about time zones to the publishing process.
>       There can be many contributors.

Note that this spec does not address contributors as that is an internal
matter for the publisher.

Eliot

---

From: Lester Caine <[email-masked]>
Date: Fri, 30 Jan 2015 17:37:32 +0000

> Providers?  If not, we should should say so.  I'm tempted to suggest

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?

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

> 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