Time Zone Data Distribution Service
charter-ietf-tzdist-01

[Ballot comment]

FWIW I like the privacy text. I suspect that the right approach
would be something like SafeWebBrowsing where the client
downloads not only the set of TZ's in which its interested. But
promising to think about it is good enough for now.

[Ballot comment]
Thanks for raising the question on privacy, Spencer as I was also wondering what scenarios might result in privacy issues.  I was just looking to make sure integrity was covered and it is, so I'm good with this charter, but curious on scenarios you envision for possible privacy issues.

[Ballot comment]
I have a couple of questions you might consider, but I would be fine with this charter the way it is.

Is this text specific enough to be meaningful to the working group?

- The time zone data distribution protocol will initially be targeted at
iCalendar-based clients, but should be flexible enough to deliver
time zone data in other formats.

In this text:

- The time zone data distribution protocol will use current security
protocols to protect the integrity and confidentiality of the data as
it is distributed, and may also address these issues with respect
to retrieval of data from its original source (such as the Time Zone
Database). Even public time zone data can represent a significant
privacy exposure when it is associated with the user or endpoint
that is retrieving it.

After reading it, I realized that I wasn't sure if clients would retrieve all of the time zone data, or would present a time zone and ask for the description associated with that time zone. If querying for a specific time zone is what's being envisioned, that helps me understand why this would be a "significant privacy exposure", but either way, is the expected mode of operation clear to the community?

[Ballot comment]
I was reminded by Dave Crocker on the DMARC charter:

  The first paragraph of a charter is circulated independently of the
  rest, such as when announcing the working group.

  As such, it needs to serve as a kind of abstract.  This is why there
  is a requirement, specified in RFC 2418 (WG Guidelines & Procedures):

  Description of working group
      The focus and intent of the group shall be set forth briefly. By
      reading this section alone, an individual should be able to decide
      whether this group is relevant to their own work. The first
      paragraph must give a brief summary of the problem area, basis,
      goal(s) and approach(es) planned for the working group.  This
      paragraph can be used as an overview of the working group's
      effort.

Perhaps an edit would be useful.

[Ballot comment]

Thanks for the nod to privacy here which is good.

I wondered if a privacy-friendly chunking of the overall TZ data
into more manageable chunks will be part of the effort but that
is definitely something the WG can consider after its up and
running.

[Ballot comment]
This seems likely to be a protocol that people might ask the IANA to implement for the TZ database.  Has anyone talked to them?