Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)

Brian Dickson <brian.peter.dickson@gmail.com> Tue, 27 November 2018 07:56 UTC

Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 405FA130E6B for <dnsop@ietfa.amsl.com>; Mon, 26 Nov 2018 23:56:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level:
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 ZcPXCgc1q-EB for <dnsop@ietfa.amsl.com>; Mon, 26 Nov 2018 23:56:47 -0800 (PST)
Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3576312008A for <dnsop@ietf.org>; Mon, 26 Nov 2018 23:56:47 -0800 (PST)
Received: by mail-qt1-x842.google.com with SMTP id t13so20743322qtn.3 for <dnsop@ietf.org>; Mon, 26 Nov 2018 23:56:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc; bh=zLfpkfruFNvq8rT4hmdChAcmmMrpwT6JTG8BZ5XCUys=; b=S3N/Usinf3kCXkdeZTUJawZuVcqq69LzWtvvG72DrWZsC0kJIuHUsg7cy8qbfPdIxV C4Nahf+l0mu1T53Y/VbR3OofKyc5meFkiOBYT9CRiy0TkUEvo7nQAFfCYSTgTx5Zm5Rr DqJ0Ql6eZS0VAWgnJEokQMGDp8najmJwLIMD2Z3u6MLgIsz8wR3PLYS3ETLHdiiDuYrp DsGbUlp5gG2hSg9B/oa8wq7ePpZurkTDLIbajUjQ8wawVMuiyIwd4Zl/m3eFxbqOVxdW h/n+w7PIVFWGBHHbjqqIebX/8EB/K/9x6tMsRg0Vaq+z2CnY6VBgEX4fB1BX2DJqjqVM OYdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:cc; bh=zLfpkfruFNvq8rT4hmdChAcmmMrpwT6JTG8BZ5XCUys=; b=CrQyregMaU+jX1DkfUDsaLbpUSpJWJKx2jAOUexVdMvYP0pYrjGV+RK2OMk0+ao2yh PKu/sJvUpTG6WwJP3zKUVo9UU7gYQwN7im4QDy5zeQwPKuV8B5tUnJPUQfwNQnsPk0tn 9Q5WCnllluY/VvNKEcrfj+FqDzPSyB2UPK/c7OjksBrfZQWaxL6Mr6eL9pPedXUHWbZT EFCXsA1REzMgftRJqvN8XIiwufvP30PKI8xy6g9xLtYlvfr8ybut78OCgoO6jm6gyo8g RhM35uevxOI9mOvVJ3XlAEe3IsedAN5g5JYJ2m8BzaA0smYIvRSKPxiC0TMWkgQJIQN+ I9EQ==
X-Gm-Message-State: AA+aEWabd5sne/OAyKJOE6X5g/tKMonbqCr9c+2mYL7qvxD2mDrew9WQ 4PgUKxquobMGnxtDfI//mzFg4/91EiqW50X6MgM=
X-Received: by 2002:aed:3802:: with SMTP id j2mt31947331qte.146.1543305406282; Mon, 26 Nov 2018 23:56:46 -0800 (PST)
MIME-Version: 1.0
References: <154258729961.2478.12875770828573692533.idtracker@ietfa.amsl.com> <8538EA17-143F-4855-A658-B78701D9B37C@sinodun.com> <8dcbfb75-cee9-99a4-3d9d-817c30efe33b@oracle.com> <alpine.DEB.2.20.1811261403030.3596@grey.csi.cam.ac.uk> <9012B3C7-32BE-4932-A927-8222641C677E@isc.org>
In-Reply-To: <9012B3C7-32BE-4932-A927-8222641C677E@isc.org>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Mon, 26 Nov 2018 23:56:34 -0800
Message-ID: <CAH1iCiqN7B1oS6PPZG2Zt5LJfaVrG06ZKrn1xDFZrD+g8C_bnQ@mail.gmail.com>
Cc: Tony Finch <dot@dotat.at>, Tim Wicinski <tjw.ietf@gmail.com>, dnsop-chairs@ietf.org, draft-ietf-dnsop-dns-capture-format@ietf.org, "dnsop@ietf.org WG" <dnsop@ietf.org>, sara@sinodun.com, kaduk@mit.edu, richard.j.gibson@oracle.com, iesg@ietf.org
Content-Type: multipart/alternative; boundary="00000000000085a203057ba0ca9e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/jEKxOpd_ZOOpseyDHQRbldIKeFg>
Subject: Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Nov 2018 07:56:49 -0000

>
>
> On 27 Nov 2018, at 1:54 am, Tony Finch <dot@dotat.at>; wrote:

> >

> > Richard Gibson <richard.j.gibson@oracle.com>; wrote:

> >>

> >> I am currently going through a similar exercise in another context, and
the

> >> best current text there explicitly characterizes the non-obvious
day-based

> >> accounting of POSIX time.

> >

> > In general I think it's best to just refer to POSIX on this matter, and

> > not try to restate the definition. POSIX is very clear and explicit about

> > the day-based accounting of seconds.

> >

> >
http://pubs.opengroup.org/onlinepubs/9699919799.2016edition/basedefs/V1_chap04.html#tag_04_16

> >

> >> However, there may be C-DNS purposes that cannot tolerate such

> >> discontinuities, and they would presumably want to use a continuous
monotonic

> >> timescale with a fixed offset from TAI (as is the case for e.g. GPS
time).

> >

> > That's practically unobtanium on most systems :-) Even if you have PTP

> > there isn't a fixed PTP epoch, though the SMPTE profile defines it to be

> > equivalent to POSIX time plus the TAI-UTC value from the IERS / NIST

> > leapsecond tables.

>
IMHO, this (the SMTPE profile) makes the most sense.
The most important aspect is that it is continuous, and the second most
important is that it relates predictably to UTC.

Honestly, the whole "leap second" thing... don't get me started.

But, I think it would be fair to have "this thing" (what the formula
describes) be its own "time zone", i.e. that it be given a proper
representation everywhere that anything that uses some notion of "local
time", can refer to time using that as a TZ.

I'd suggest that C-DNS start using it, and parallel to that, propose the
reference timeframe be adopted by whatever WG or standards body manages
timezones and/or UTC.

Besides, isn't it kind of backwards?
Doesn't UTC actually derive its time from TAI plus/minus leap seconds?
Why isn't it already available to use as a time zone?
(Consults wikipedia on unix time, sees there is an IANA database. Curses
POSIX.)

Brian


> Tony.

> > --

> > f.anthony.n.finch  <dot@dotat.at>;  http://dotat.at/
> disperse power, foster diversity, and nurture creativity