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

Lester Caine <lester@lsces.co.uk> Sun, 01 February 2015 17:30 UTC

Return-Path: <lester@lsces.co.uk>
X-Original-To: ietf-privacy@ietfa.amsl.com
Delivered-To: ietf-privacy@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38421A1A36 for <ietf-privacy@ietfa.amsl.com>; Sun, 1 Feb 2015 09:30:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level:
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyIlRNoJSEco for <ietf-privacy@ietfa.amsl.com>; Sun, 1 Feb 2015 09:30:39 -0800 (PST)
Received: from mail4.serversure.net (mail4-2.serversure.net [217.147.176.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D48CD1A89E0 for <ietf-privacy@ietf.org>; Sun, 1 Feb 2015 09:30:38 -0800 (PST)
Received: (qmail 32206 invoked by uid 89); 1 Feb 2015 17:30:36 -0000
Received: by simscan 1.3.1 ppid: 32198, pid: 32202, t: 0.1010s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677
Received: from unknown (HELO ?10.0.0.8?) (lester@rainbowdigitalmedia.org.uk@86.189.147.37) by mail4.serversure.net with ESMTPA; 1 Feb 2015 17:30:36 -0000
Message-ID: <54CE62BB.9070308@lsces.co.uk>
Date: Sun, 01 Feb 2015 17:30:35 +0000
From: Lester Caine <lester@lsces.co.uk>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: saag@ietf.org, ietf-privacy@ietf.org, Time Zone Data Distribution Service <tzdist@ietf.org>
References: <CADZyTkkLu6qQ9LCqDkTHA9o+-YVvQuaUp33kqkAt=PRaQS-Jew@mail.gmail.com> <CADZyTkkCrvTam_ba7Tq6A-cHAVZn+ktKqwWsr_PNQaz2jyTkUQ@mail.gmail.com> <874mr9aucv.fsf@alice.fifthhorseman.net> <54CBC609.4010309@lsces.co.uk> <87egqcq827.fsf@alice.fifthhorseman.net> <54CC8F13.6060808@cs.ucla.edu> <54CC9DB3.6040500@lsces.co.uk> <54CD5886.7020409@cs.ucla.edu> <04F56E6866304E628CA1C45B@cyrus.local>
In-Reply-To: <04F56E6866304E628CA1C45B@cyrus.local>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf-privacy/1E1HHMbrWHc6yNEs8SahGUNUJDw>
Subject: Re: [ietf-privacy] [Tzdist] [saag] Fwd: WGLC for draft-ietf-tzdist-service-05
X-BeenThere: ietf-privacy@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Internet Privacy Discussion List <ietf-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-privacy>, <mailto:ietf-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-privacy/>
List-Post: <mailto:ietf-privacy@ietf.org>
List-Help: <mailto:ietf-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-privacy>, <mailto:ietf-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Feb 2015 17:30:42 -0000

On 01/02/15 20:03, Cyrus Daboo wrote:
>>> some devices such as central heating controllers
>>> would not need a processor capable of the sort of processing power
>>> needed to handle that
>>
>> Even the lowliest central heating controller can easily handle the entire
>> tz database, if only to discard unneeded parts as they're received.
>> We're talking kilobytes here, not gigabytes or even megabytes.
> 
> Well in this day and age the IETF really ought to also require an
> "Environmental Considerations" section in specs too, alongside
> "Security" and "Privacy". If that were a factor here (and I don't see
> why it would not be) then clearly sending all the data (and throwing
> away all but one) vs sending just one tz is an added impact on power
> usage for all devices involved (servers, clients, network hardware). Yes
> we are talking about kilobytes per device but you have to multiply that
> by the number of devices (which with internet of things is only going to
> increase beyond what we have now).
> 
> As with everything there are trade offs involved here. For a personal
> device, yes I do want strong privacy for key aspects of data that device
> might use (the obvious one being location information). However, for
> "fixed" devices, like a wall-clock in an office building, in all
> likelihood the exposure of revealing what time zone it is configure to
> use is likely small.

This is actually a good point. One of the 'cost cutting' exercises IS to
eliminate the need for a mains power supply since modern devices need so
little power so while power over the network cable is a more recent
'development', many current central heating controllers have a couple of
AA batteries and a not to 'replace every few years'. So adding paper
displays, they can go to sleep for most of the time and any unnecessary
software cycles are a drain :)

> At this point I do think it worthwhile to give clients the option to
> chose what is appropriate for them given the trade offs. So it does make
> sense to provide a "full set of tz data" option in the protocol to allow
> clients to get the entire set of current data without exposing which
> specific time zone(s) they are actually interested in (which would also
> remove the need for them to use etags). How about a "getall" action
> using a /allzones URI to retrieve all the data. The only tricky part
> might be explaining how the data is returned. For iCalendar-based
> formats that is easy as multiple VTIMEZONEs would be included in a
> single VCALENDAR calendar object. For the binary tz data format, I am
> not sure whether simply concatenating the binary data for all tzs is
> valid - that is something that that format will need to be clear about.

One thing that I have only just twigged is that what we are  talking
about here is just sending the one data package with everything in! If
something is not spelt out it is often missed. I still see the 'power
saving' capabilities of a 'changed since' data package flagging
centrally just which TZis's need to be looked at, and a complete diff
package rather than a full dump again would reduce packet size, but
there is no security risk from that either way?

I still see the major advantage of tzdist in it's ability to flag that
something needs looking at. If I'm not following the affected TZid's
then it's up to me if I even update, but I only really see that being
necessary if there are several competing publishers each using their own
set of data for some 'political or commercial' reason so while we select
a default local one, third party material may well need our accessing
other services :(

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