From nobody Mon Mar 13 08:06:08 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4211293E8 for ; Sun, 5 Mar 2017 10:02:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 5xfD26p_mqXM for ; Sun, 5 Mar 2017 10:02:08 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 B28D51289C4 for ; Sun, 5 Mar 2017 10:02:08 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id 90so100965652ios.1 for ; Sun, 05 Mar 2017 10:02:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=3noelF5yFj7WbXiRdCUKxZELlGJhfmVTGtmSlXGzDj4=; b=WgelHQNYEj0o4cIIdupBvJP2dnd9jGzB+QfsDtq24tvYvRCqkojmYjKO9au3P5Ekpr XWBbB3UGywKJTj52AU3HvVsqRz6QBbFFrko8j2+dsG0Z4Uo8dpI1qUTZkczS0jydoG0E 5ttCM2QVW/IAB1pAZ2NjjkCEeXEUKfwJCE9gdSROlZVmtVchpODcdCOjaSkrHbR4dT0D cA78pAYz4PzQ/09AU+AhxJN4mo3mvp3KUfb942eLvRC71WCcYYcPDqLUC/BDs48sF6ZH HSdT1JyqYju/gyAan5jkVgBMUM8BvjvJh+kT0JA7pKMhVpdxzjyoXu/7xd3JLx07FuMv RwhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=3noelF5yFj7WbXiRdCUKxZELlGJhfmVTGtmSlXGzDj4=; b=f/GryEhI6Z/KRliiPe5ZSIWEjc8LHI3rh8XhuiRKThR2sTh1PhL4iATNzAIBld382Q sHowTpTtd1dzSS2cq5oAm7b3hZrK4/ZaIfhM2lFVnzSqlEn8ww95xG+emXhyOs6c8p30 fTCu4o5/DIxEvnNT7FR7CdgxKHdDUVyIB4nsCw3NXSFfCka5/OMlcS6zdk6i8T3fIGww 6m1UWU+JnT+yTbqdlqNEzxfvSL4zYIIvduCYa3eVU2UTa9+jGZbzHIngXc4XxIsfvkfU +yNllfa01g+j2HimBNN38uPWnnYD5DlseRDsFLTwA1fz00QYvWn3+THlxeg3lx+7uhYJ sV5A== X-Gm-Message-State: AMke39ki+YMZDoH1QMyfqPWRIkm8MCyRMv7/VhgBdoG/16cF9gDKn9X4N5w++sYdsaGuxQIIV4BFyV8L8JAZPQ== X-Received: by 10.107.142.88 with SMTP id q85mr11412234iod.56.1488736927965; Sun, 05 Mar 2017 10:02:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.46.162 with HTTP; Sun, 5 Mar 2017 10:02:07 -0800 (PST) From: Melvin Carvalho Date: Sun, 5 Mar 2017 19:02:07 +0100 Message-ID: To: Apps Discuss Content-Type: multipart/alternative; boundary=94eb2c05a2b6c16dd00549ff9399 Archived-At: X-Mailman-Approved-At: Mon, 13 Mar 2017 08:06:07 -0700 Subject: [art] reverse lookup of named instances X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 18:02:10 -0000 --94eb2c05a2b6c16dd00549ff9399 Content-Type: text/plain; charset=UTF-8 I've been looking lately at the excellent RFC 6920, Naming things with hashes. It allows you to systematically translate a hash into a URI, and as another excellent feature, provides a standard for doing a "forward" lookup. In particular, if you lookup, say https://some-domain/.well-known/ni/sha-1/ It will return some information about that hash, which is really useful. It could have a name, a description, the algorithm details, and hashtage etc. This leads to a question / problem. Let's say I have a tag, and I want to find a list of hashes that contain that tag. Does anyone know of a systematic way to solve this problem? I was thinking something like https://some-domain/.well-known/lookup/ Which would return a list of hashes. Is this a solved problem, or does something need to be invented? Thanks in advance --94eb2c05a2b6c16dd00549ff9399 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've been= looking lately at the excellent RFC 6920, Naming things with hashes.
It allows you to systematically translate a hash into a URI, and as= another excellent feature, provides a standard for doing a "forward&q= uot; lookup.=C2=A0

In particular, if you lookup, say

https://some-domain/.well-kn= own/ni/sha-1/<hash>

It will return some information = about that hash, which is really useful.=C2=A0 It could have a name, a desc= ription, the algorithm details, and hashtage etc.

This leads t= o a question / problem.=C2=A0 Let's say I have a tag, and I want to fin= d a list of hashes that contain that tag.

Does anyone know of = a systematic way to solve this problem?

I was thinking somethi= ng like

ht= tps://some-domain/.well-known/lookup/<term>

Which wo= uld return a list of hashes.

Is this a solved problem, or does= something need to be invented?

Thanks in advance
--94eb2c05a2b6c16dd00549ff9399-- From nobody Mon Mar 13 08:06:12 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4240C1295DA for ; Mon, 13 Mar 2017 06:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.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 Sy5HgNKFRQmZ for ; Mon, 13 Mar 2017 06:02:46 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0131.outbound.protection.outlook.com [104.47.34.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C64631295D8 for ; Mon, 13 Mar 2017 06:02:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=h/DK4/acJQbjC9kF61N5Ix4zmGe2OUmvZNFh0OV4mSM=; b=Fnw7gP9MYF0GMlBUaDWpS3hRFywvEZqjtRbQizHKyMKp+ROeOce4U18G+pBb/eZmygseIz2/UXNNpAyZDvooAXHpB7sTzlASxhMzJQHyxsJCBNK97ke+6Zvq+x2er/hYC9tm0A6Jrnj+PhoLOAcnFU36d55UrafMggODUXZfUzY= Received: from BY2PR0501MB1703.namprd05.prod.outlook.com (10.163.154.156) by BY2PR0501MB1702.namprd05.prod.outlook.com (10.163.154.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Mon, 13 Mar 2017 13:02:44 +0000 Received: from BY2PR0501MB1703.namprd05.prod.outlook.com ([10.163.154.156]) by BY2PR0501MB1703.namprd05.prod.outlook.com ([10.163.154.156]) with mapi id 15.01.0977.010; Mon, 13 Mar 2017 13:02:44 +0000 From: Stuart Mackie To: Matt Miller , "bess@ietf.com" , "apps-discuss@ietf.org" Thread-Topic: [bess] APPDIR Review of draft-ietf-l3vpn-end-system-05 Thread-Index: AQHSOTors9evukLEtUK6ZExvAWx8JqDNtxKAgD2OCYCAh/maAA== Date: Mon, 13 Mar 2017 13:02:44 +0000 Message-ID: <8667BCED-2930-4655-BEC8-2E116FE26AD4@juniper.net> References: <9B279855-F523-4650-A1E3-2428AF30FA30@juniper.net> <823aa4f5-fc64-a8ae-ecc1-1bc95b50bec9@cisco.com> In-Reply-To: <823aa4f5-fc64-a8ae-ecc1-1bc95b50bec9@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.15] x-microsoft-exchange-diagnostics: 1; BY2PR0501MB1702; 7:q1w01eefze2kTEluFcDzKG9KtdHe5YWaa/86SWKKKRJwc2Bov4pGKU20DhCyT+Jx0/k687ddAL/h9BTFRhotYBrw8pg6T5r/ci3qPNqE6IjTJahY6PEV6f7XggYLfLJZQ1ckm1BOoc4We4haU0Ndi7mqfoy3XvBzmFF+6eGk+RlyyaHzYfebBSWopo1z+GLpfoiiXeg7Q1JFVmNE/sFeF3c7uMi/akVrr/Jrxb7YFBCElg4d/bUh6NnceoUMlCxC0OaJtKWewOpufE0zBOshOPWzQGBMnvcztyErQAhxgU58ZVCRw7IVKRYfJIizzknKDFDXMjuoUGTv1EOHS4c7bw== x-ms-office365-filtering-correlation-id: 9426f092-b136-447f-dd5b-08d46a113d7b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BY2PR0501MB1702; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(60795455431006)(158342451672863)(278428928389397)(150554046322364)(95692535739014)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123558025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:BY2PR0501MB1702; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0501MB1702; x-forefront-prvs: 0245702D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39450400003)(39860400002)(39410400002)(39850400002)(24454002)(51914003)(377424004)(377454003)(36756003)(106116001)(2906002)(31430400001)(230783001)(3280700002)(3660700001)(2501003)(3846002)(2900100001)(33656002)(102836003)(1720100001)(66066001)(6116002)(305945005)(7736002)(86362001)(2201001)(53546006)(38730400002)(53376002)(77096006)(82746002)(6486002)(229853002)(19273905006)(83506001)(6506006)(6512007)(6306002)(83716003)(25786008)(5660300001)(122556002)(189998001)(6436002)(8936002)(81166006)(50986999)(8676002)(4001150100001)(4001350100001)(54356999)(76176999)(6246003)(966004)(2950100002)(53936002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0501MB1702; H:BY2PR0501MB1703.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2017 13:02:44.3661 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0501MB1702 Archived-At: X-Mailman-Approved-At: Mon, 13 Mar 2017 08:06:03 -0700 Subject: Re: [art] [bess] APPDIR Review of draft-ietf-l3vpn-end-system-05 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 13:02:53 -0000 TWF0dA0KDQpEaWQgeW91IGdldCBhIGNoYW5jZSB0byBsb29rIGF0IHRoZSB1cGRhdGVzPw0KDQpU aGFua3MNCg0KU3R1YXJ0DQotOTE0IDg4NiAyNTM0DQoNCk9uIDEyLzE2LzE2LCAzOjM0IFBNLCAi TWF0dCBNaWxsZXIiIDxtYW1pbGxlMkBjaXNjby5jb20+IHdyb3RlOg0KDQogICAgVGhhbmtzIGZv ciB0aGUgdXBkYXRlLCBTdHVhcnQuICBJJ2xsIHRha2UgYSByZWFkIHRocm91Z2ggYW5kIGxldCB5 b3Uga25vdy4NCiAgICANCiAgICANCiAgICAtIG0mbQ0KICAgIA0KICAgIE1hdHQgTWlsbGVyDQog ICAgQ2lzY28gU3lzdGVtcywgSW5jLg0KICAgIA0KICAgIE9uIDIwMTYtMTItMTUgMTU6MTMsIFN0 dWFydCBNYWNraWUgd3JvdGU6DQogICAgPiBNYXR0LA0KICAgID4gDQogICAgPiAgDQogICAgPiAN CiAgICA+IEFzIHlvdSBoYXZlIHByb2JhYmx5IHJlYWxpemVkIGZyb20gdGhlIGxhY2sgb2YgYWN0 aXZpdHkgb24gdGhpcyBkcmFmdCwNCiAgICA+IFBlZHJvIE1hcnF1ZXMgaGFzIG1vdmVkIG9uIGFu ZCBpcyBubyBsb25nZXIgYWN0aXZlIGluIHRoaXMgYXJlYS4gSSBoYXZlDQogICAgPiBiZWVuIGFz a2VkIHRvIHRha2Ugb3duZXJzaGlwIGFuZCBtb3ZlIHRoZSBkcmFmdCB0aHJvdWdoIHRoZSBJRVRG IHByb2Nlc3MuDQogICAgPiANCiAgICA+ICANCiAgICA+IA0KICAgID4gSSBqdXN0IHBvc3RlZCBh IG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdCB3aGljaCBhZGRyZXNzZXMgdGhlIGNvbmNlcm5zDQog ICAgPiByYWlzZWQgaW4geW91ciBlbWFpbC4NCiAgICA+IA0KICAgID4gIA0KICAgID4gDQogICAg PiBJIGhhdmUgbWFkZSBxdWl0ZSBhIGZldyBjaGFuZ2VzIGZvciBjbGFyaXR5IGluIHRoZSBkcmFm dCwgc28gSSBoYXZlDQogICAgPiBkZXNjcmliZWQgdGhlIGNoYW5nZXMgdGhhdCBzcGVjaWZpY2Fs bHkgYWRkcmVzcyB5b3VyIGlzc3VlcyBpbiB0aGlzIG5vdGUuDQogICAgPiANCiAgICA+ICANCiAg ICA+IA0KICAgID4gUGxlYXNlIGxldCBtZSBrbm93IGlmIHlvdSBoYXZlIGFueSBmdXJ0aGVyIGNv bmNlcm5zLg0KICAgID4gDQogICAgPiAgDQogICAgPiANCiAgICA+IFRoYW5rcw0KICAgID4gDQog ICAgPiAgDQogICAgPiANCiAgICA+IFN0dWFydA0KICAgID4gDQogICAgPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICA+IA0KICAgID4gIA0KICAgID4gDQogICAg PiBJIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgQXBwbGljYXRpb25zIGluIEFSVCBEaXJlY3Rv cmF0ZSByZXZpZXdlciBmb3INCiAgICA+IA0KICAgID4gdGhpcyBkcmFmdCAoZm9yIGJhY2tncm91 bmQgb24gYXBwc2RpciwgcGxlYXNlIHNlZQ0KICAgID4gDQogICAgPiDigIsNCiAgICA+IGh0dHA6 Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvYXBwL3RyYWMvd2lraS9BcHBsaWNhdGlvbnNBcmVh RGlyZWN0b3JhdGUgKS4NCiAgICA+IA0KICAgID4gIA0KICAgID4gDQogICAgPiBQbGVhc2UgcmVz b2x2ZSB0aGVzZSBjb21tZW50cyBhbG9uZyB3aXRoIGFueSBvdGhlciBMYXN0IENhbGwgY29tbWVu dHMNCiAgICA+IA0KICAgID4geW91IG1heSByZWNlaXZlLiBQbGVhc2Ugd2FpdCBmb3IgZGlyZWN0 aW9uIGZyb20geW91ciBkb2N1bWVudCBzaGVwaGVyZA0KICAgID4gDQogICAgPiBvciBBRCBiZWZv cmUgcG9zdGluZyBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4NCiAgICA+IA0KICAgID4gIA0K ICAgID4gDQogICAgPiAgDQogICAgPiANCiAgICA+IERvY3VtZW50OiBkcmFmdC1pZXRmLWwzdnBu LWVuZC1zeXN0ZW0tMDUNCiAgICA+IA0KICAgID4gVGl0bGU6IEJHUC1zaWduYWxlZCBlbmQtc3lz dGVtIElQL1ZQTnMNCiAgICA+IA0KICAgID4gUmV2aWV3ZXI6IE1hdHQgTWlsbGVyDQogICAgPiAN CiAgICA+IFJldmlldyBEYXRlOiAyMDE2LTAxLTE4DQogICAgPiANCiAgICA+IElFVEYgTGFzdCBD YWxsIERhdGU6IE4vQQ0KICAgID4gDQogICAgPiBJRVNHIFRlbGVjaGF0IERhdGU6IE4vQQ0KICAg ID4gDQogICAgPiAgDQogICAgPiANCiAgICA+IFN1bW1hcnk6IFRoaXMgZHJhZnQgaXMgbm90IHJl YWR5IGZvciBwdWJsaWNhdGlvbiBhcyBhIFByb3Bvc2VkDQogICAgPiANCiAgICA+IFN0YW5kYXJk Lg0KICAgID4gDQogICAgPiAgDQogICAgPiANCiAgICA+IENvbW1lbnRzOg0KICAgID4gDQogICAg PiAgDQogICAgPiANCiAgICA+IFRoaXMgZHJhZnQgaXMgbWFraW5nIGFzc3VtcHRpb25zIGFuZCBk ZXNpZ24gZGVjaXNpb25zIHRoYXQgYXJlIG5vdCByZWFsbHkNCiAgICA+IA0KICAgID4gY29tcGF0 aWJsZSB3aXRoIFhNUFAsIGFuZCB0aGVzZSBzaG91bGQgYmUgcmVzb2x2ZWQgYmVmb3JlIHB1Ymxp c2hpbmcuDQogICAgPiANCiAgICA+ICANCiAgICA+IA0KICAgID4gSXQncyBpbXBvcnRhbnQgdG8g bm90ZSBYTVBQIGlzIGFuIGVuZC10by1lbmQgYXBwbGljYXRpb24gcm91dGluZw0KICAgID4gDQog ICAgPiBwcm90b2NvbC4gQ2xpZW50cyBhcmUgY2FwYWJsZSBvZiBzZW5kaW5nIGRhdGEgdG8gb3Ro ZXIgY2xpZW50cywNCiAgICA+IA0KICAgID4gcG9zc2libHkgY3Jvc3NpbmcgbXVsdGlwbGUgc2Vy dmVyIGJvdW5kYXJpZXMuICBGb3IgZXhhbXBsZToNCiAgICA+IA0KICAgID4gIA0KICAgID4gDQog ICAgPiAxKSBjbGllbnQtYUBzZXJ2ZXItMS5leGFtcGxlIC0tPg0KICAgID4gDQogICAgPiAyKSBz ZXJ2ZXItMS5leGFtcGxlIC0tPg0KICAgID4gDQogICAgPiAzKSBtdWMuZXhhbXBsZSAtLT4NCiAg ICA+IA0KICAgID4gNCkgc2VydmVyLTIuZXhhbXBsZSAtLT4NCiAgICA+IA0KICAgID4gNSkgY2xp ZW50LWJAc2VydmVyLTIuZXhhbXBsZQ0KICAgID4gDQogICAgPiAgDQogICAgPiANCiAgICA+IFRo aXMgZG9jdW1lbnQgc2VlbXMgdG8gbWFrZSB0aGUgYXNzdW1wdGlvbiB0aGF0IHJvdXRpbmcgaXMg cHVyZWx5DQogICAgPiANCiAgICA+IGJldHdlZW4gYSBjbGllbnQgYW5kIGl0cyBzZXZlciwgd2hp Y2ggSSBiZWxpZXZlIGhhcyBsZWFkIHRvIGRlc2lnbg0KICAgID4gDQogICAgPiBkZWNpc2lvbnMg dGhhdCBhcmUgdmVyeSBwcm9ibGVtYXRpYy4NCiAgICA+IA0KICAgID4gIA0KICAgID4gDQogICAg PiBNYWpvciBJc3N1ZXM6IChBbGwgb2Ygd2hpY2ggYXBwbHkgdG8gU2VjdGlvbiA2LiBYTVBQIFNp Z25hbGluZw0KICAgID4gDQogICAgPiBQcm90b2NvbCkNCiAgICA+IA0KICAgID4gIA0KICAgID4g DQogICAgPiAqIFRoZSBhZGRyZXNzaW5nIHNjaGVtZSBmb3IgRW5kIFN5c3RlbXMgY29ubmVjdGlu ZyB0byB0aGUgZXh0ZXJuYWwgVlBODQogICAgPiANCiAgICA+IEZvcndhcmRlciBpcyBub3QgZXhw bGljaXRseSBkb2N1bWVudGVkIGFueXdoZXJlIC0tIHRoZSBvbmx5IGluc3RhbmNlIEkNCiAgICA+ IA0KICAgID4gY2FuIGRlZHVjZSBpcyBmcm9tIHRoZSBleHRlcm5hbCBWUE4gZm9yd2FyZGVkIHN1 YnNjcmlwdGlvbiBleGFtcGxlLA0KICAgID4gDQogICAgPiB3aGljaCBzZWVtcyB0byB1c2UgYSBk b21haW4gSklEIGZvciB0aGUgRW5kIFN5c3RlbS4gIFdpdGhvdXQgYSBjbGVhcg0KICAgID4gDQog ICAgPiBYTVBQIGFkZHJlc3Npbmcgc2NoZW1lLCBwcm9wZXJseSByb3V0aW5nIHN0YW56YXMgYWNy b3NzIHRoZSBYTVBQDQogICAgPiANCiAgICA+IG5ldHdvcmsgYW5kIG11dHVhbGx5IGF1dGhlbnRp Y2F0aW5nIFRMUyBhY2NvcmRpbmcgdG8gUkZDIDYxMjUgKGFuZA0KICAgID4gDQogICAgPiBwb3Nz aWJseSBbWEVQLTAxNzhdKSBzZWVtIHByb2JsZW1hdGljIHRvIG1lLg0KICAgID4gDQogICAgPiAg DQogICAgPiANCiAgICA+IC9TTT4gIE1vZGlmaWVkIGFzIGZvbGxvd3M6Lw0KICAgID4gDQogICAg PiAvVGhlIFZQTiBGb3J3YXJkZXIgU0hPVUxEIHVzZSBpdHMgaG9zdG5hbWUgYXMgSklELCB3aGVu IGF2YWlsYWJsZSwgb3IgYQ0KICAgID4gdW5pcXVlIElQIGFkZHJlc3Mgd2l0aGluIHRoZSBpbmZy YXN0cnVjdHVyZSBuZXR3b3JrIHVzaW5nIGl0cyBzdHJpbmcNCiAgICA+IHJlcHJlc2VudGF0aW9u LiBUaGUgc2FtZSBuYW1pbmcgY29udmVudGlvbiBTSE9VTEQgYmUgdXNlZCBmb3IgYW4gRW5kDQog ICAgPiBTeXN0ZW0gd2hpY2ggaGFzIGFuIFhNUFAgc2Vzc2lvbiB3aXRoIGFuIGV4dGVybmFsIFZQ TiBGb3J3YXJkZXIuLw0KICAgID4gDQogICAgPiAgDQogICAgPiANCiAgICA+IElmIEVuZCBTeXN0 ZW1zIGFyZSBleHBlY3RlZCB0byBjb21tdW5pY2F0ZSBkaXJlY3RseSB3aXRoIHRoZSBSb3V0ZQ0K ICAgID4gDQogICAgPiBTZXJ2ZXIgKGUuZy4sIEVuZCBTeXN0ZW0gYWRkcmVzc2VzIHN0YW56YXMg dG8gdGhlIFJvdXRlIFNlcnZlciwgd2hpY2gNCiAgICA+IA0KICAgID4gdGhlIFZQTiBGb3J3YXJk ZXIgaXMgZXhwZWN0ZWQgdG8gcmVsYXkpLCB0aGUgYWRkcmVzc2luZyBzY2hlbWUgZm9yIGFsbA0K ICAgID4gDQogICAgPiBjb21wb25lbnRzIG5lZWRzIHRvIGJlIGJldHRlciBkZWZpbmVkLiAgRm9y IGluc3RhbmNlLCB0aGUgVlBOIEZvcndhcmRlcg0KICAgID4gDQogICAgPiBhZGRyZXNzIGluIFhN UFAgY291bGQgYmUgYSBkb21haW4gSklEIGFzIGl0IGlzLCB3aGlsZSB0aGUgRW5kIFN5c3RlbQ0K ICAgID4gDQogICAgPiBhZGRyZXNzIGNvdWxkIGJlIGEgYmFyZSBKSUQgZGVyaXZlZCBmcm9tIHRo YXQgVlBOIEZvcndhcmRlcidzIEpJRA0KICAgID4gDQogICAgPiAoZS5nLiwgImVuZC1zeXN0ZW1A Zm9yd2FyZGVyLmV4YW1wbGUiKS4gIFRoaXMgd291bGQgZGlzYW1iaWd1YXRlIHRoZQ0KICAgID4g DQogICAgPiBYTVBQIHJvdXRpbmcgYWNyb3NzIHRoZSBYTVBQIG5ldHdvcmsuDQogICAgPiANCiAg ICA+ICANCiAgICA+IA0KICAgID4gL1NNPiBJdCBpcyBub3QsIGluIGZhY3QsIGludGVuZGVkIHRo YXQgRW5kIFN5c3RlbXMgY29tbXVuaWNhdGUgd2l0aCB0aGUNCiAgICA+IFJvdXRlIFNlcnZlciBk aXJlY3RseS4gVGhlcmUgd2VyZSBzb21lIHR5cG9zIHRoYXQgaW5kaWNhdGVkIHRvIHRoZQ0KICAg ID4gY29udHJhcnkuIEZpZ3VyZSAxIGluIHRoZSAtMDUgZHJhZnQgd2FzIG1pc2xlYWRpbmcgc2lu Y2UgaXQgaW5kaWNhdGVkDQogICAgPiB0aGF0IEVuZCBTeXN0ZW1zIGhhdmUgYW4gWE1QUCBzZXNz aW9uIHdpdGggUm91dGUgU2VydmVycy4gVGhlIGRpYWdyYW0NCiAgICA+IGhhcyBiZWVuIHVwZGF0 ZWQgYXMgZm9sbG93cy8NCiAgICA+IA0KICAgID4gIA0KICAgID4gDQogICAgPiAgICAgICAgICAg ICAgICAgICAgICAgICArLS0tLS0tLS0tKyAgICAgICAgKy0tLS0tLS0tKw0KICAgID4gDQogICAg PiAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgIFJTICAgfC0tLS0tLS0tfCAgQkdQICAgfA0K ICAgID4gDQogICAgPiAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tKyAgICAgICAg Ky0tLS0tLS0tKw0KICAgID4gDQogICAgPiAgICAgICAgICAgICAgICAgICAgICAgICAvICAgICAg ICAgXCAgICAgICAgLw0KICAgID4gDQogICAgPiAgICAgICAgICAgICAgICAgICAgICAgWE1QUCAg ICAgICAgIFwgICAgICAvDQogICAgPiANCiAgICA+ICAgICAgICAgICAgICAgICAgICAgICAvICAg ICAgICAgICAgIFwgICAgLw0KICAgID4gDQogICAgPiAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0r ICAgICAgICAgICAgXCAgLw0KICAgID4gDQogICAgPiAgICB8ICBFbmQgICB8ICAgVlBOICAgICB8 ICAgICAgICAgICAgIFwvDQogICAgPiANCiAgICA+ICAgIHwgU3lzdGVtIHwgRm9yd2FyZGVyIHwg ICAgICAgICAgICAgL1wNCiAgICA+IA0KICAgID4gICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tKyAg ICAgICAgICAgIC8gIFwNCiAgICA+IA0KICAgID4gICAgICAgICAgICAgICAgICAgICAgIFwgICAg ICAgICAgICAgLyAgICBcDQogICAgPiANCiAgICA+ICAgICAgICAgICAgICAgICAgICAgICBYTVBQ ICAgICAgICAgLyAgICAgIFwNCiAgICA+IA0KICAgID4gICAgICAgICAgICAgICAgICAgICAgICAg XCAgICAgICAgIC8gICAgICAgIFwNCiAgICA+IA0KICAgID4gICAgICAgICAgICAgICAgICAgICAg ICAgKy0tLS0tLS0tLSsgICAgICAgICstLS0tLS0tLSsNCiAgICA+IA0KICAgID4gICAgICAgICAg ICAgICAgICAgICAgICAgfCAgICBSUyAgIHwtLS0tLS0tLXwgIEJHUCAgIHwNCiAgICA+IA0KICAg ID4gICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLSsgICAgICAgICstLS0tLS0tLSsN CiAgICA+IA0KICAgID4gIA0KICAgID4gDQogICAgPiAgDQogICAgPiANCiAgICA+ICANCiAgICA+ IA0KICAgID4gSG93ZXZlciwgaWYgVlBOIEZvcndhcmRlcnMgYXJlIHRvIGFjdCBhcyBwcm94aWVz IGZvciBFbmQgU3lzdGVtcywgdGhlbg0KICAgID4gDQogICAgPiBpdCBzaG91bGQgYWN0IGFzIGEg cHJveHkgaW4gYWxsIGNhc2VzIC0tIEVuZCBTeXN0ZW1zIHN1YnNjcmliZSB0bw0KICAgID4gDQog ICAgPiBwdWJzdWIgbm9kZXMgb24gdGhlIGV4dGVybmFsIFZQTiBGb3J3YXJkZXIgKHdoaWNoIGNv dWxkIGluIHR1cm4gdHJpZ2dlcg0KICAgID4gDQogICAgPiBhIHN1YnNjcmliZSBvZiB0aGUgVlBO IGZvcndhcmRlciB0byB0aGUgUm91dGUgU2VydmVyKSwgYW5kIHJlY2VpdmUNCiAgICA+IA0KICAg ID4gbm90aWZpY2F0aW9ucyBmcm9tIHRoZSBWUE4gRm9yd2FyZGVyICh3aGljaCBpbiB0dXJuIGFy ZSBmaXJzdCByZWNlaXZlZA0KICAgID4gDQogICAgPiBieSB0aGUgVlBOIEZvcndhcmRlciBmcm9t IHRoZSBSb3V0ZSBTZXJ2ZXIpLg0KICAgID4gDQogICAgPiAgDQogICAgPiANCiAgICA+IC9TTT4g VGhlIHRleHQgbm93IHJlYWRzOi8NCiAgICA+IA0KICAgID4gLyAgIFdoZW4gYW4gZXh0ZXJuYWwg Rm9yd2FyZGVyIGlzIHVzZWQsIGl0cyBjb250cm9sIHNvZnR3YXJlIE1BWSBvcGVyYXRlLw0KICAg ID4gDQogICAgPiAvICAgYXMgYW4gWE1QUCBzZXJ2ZXIgd2hpY2ggcHJvY2Vzc2VzIHJlcXVlc3Rz IGZyb20gZW5kLXN5c3RlbXMgYW5kIFNIQUxMLw0KICAgID4gDQogICAgPiAvICAgb3BlcmF0ZSBh cyBhIGNsaWVudCBvZiBvbmUgb3IgbW9yZSBFbmQtU3lzdGVtIFJvdXRlIFNlcnZlcnMuICBUaGUv DQogICAgPiANCiAgICA+IC8gICBjb250cm9sIHNvZnR3YXJlIHJlbGF5cyB0byB0aGUgRW5kLVN5 c3RlbSBSb3V0ZSBTZXJ2ZXIocykgVlBOLw0KICAgID4gDQogICAgPiAvICAgbWVtYmVyc2hpcCBz dGFuemFzIGl0IHJlY2VpdmVzIGZyb20gdGhlIGVuZC1zeXN0ZW0uICBWUE4gcm91dGluZy8NCiAg ICA+IA0KICAgID4gLyAgIGluZm9ybWF0aW9uIHJlY2VpdmVkIGZyb20gdGhlIFJvdXRlIFNlcnZl cihzKSBTSE9VTEQgTk9UIGJlLw0KICAgID4gDQogICAgPiAvICAgcHJvcGFnYXRlZCB0byB0aGUg ZW5kLXN5c3RlbSB1bmxlc3MgaXQgc3BlY2lmaWNhbGx5IHJlcXVlc3RzIHN1Y2gvDQogICAgPiAN CiAgICA+IC8gICBpbmZvcm1hdGlvbi4gIEVuZCBzeXN0ZW1zIE1BWSBoYXZlIHNlc3Npb25zIGRp cmVjdGx5IHdpdGggdGhlIEVuZC0vDQogICAgPiANCiAgICA+IC8gICBTeXN0ZW0gUm91dGUgU2Vy dmVycywgYW5kIGluIHRoaXMgY2FzZSBubyBYTVBQIHNlc3Npb25zIGFyZSByZXF1aXJlZC8NCiAg ICA+IA0KICAgID4gLyAgIHdpdGggVlBOIEZvcndhcmRlcnMuLw0KICAgID4gDQogICAgPiAgDQog ICAgPiANCiAgICA+ICogVXNpbmcgYSBoYXJkLWNvZGVkIEpJRCBmb3IgdGhlIFJvdXRlIFNlcnZl ciBjYW4gYmUgYSBzZXJpb3VzIHByb2JsZW0gaWYNCiAgICA+IA0KICAgID4gdGhlcmUgaXMgZXZl ciBhIGNhc2Ugd2hlcmUgaW5kaXZpZHVhbCBSb3V0ZSBTZXJ2ZXJzIG92ZXJzZWUgZGlmZmVyZW50 DQogICAgPiANCiAgICA+IHJvdXRpbmcgaW5mb3JtYXRpb24uICBJZiB0aGlzIGlzIG5ldmVyIHRo ZSBjYXNlLCB0aGVuIGEgc2luZ2xlIEpJRCBmb3INCiAgICA+IA0KICAgID4gYWxsIFJvdXRlIFNl cnZlcnMgaXMgcHJvYmFibHkgT0ssIGJ1dCBJIHRoaW5rIHRoZXJlIGNvdWxkIGJlIHByb2JsZW1z DQogICAgPiANCiAgICA+IHdpdGggcHJvcGVybHkgYXV0aGVudGljYXRpbmcgdGhlIFRMUyBzZXNz aW9uLiAgVXNpbmcgYSBkaWZmZXJlbnQgSklEDQogICAgPiANCiAgICA+IGZvciBlYWNoIFJvdXRl IFNlcnZlciBjYW4gaW50cm9kdWNlIHNvbWUgZGlmZmljdWx0aWVzIGZvciBFbmQgU3lzdGVtcw0K ICAgID4gDQogICAgPiB1dGlsaXppbmcgZXh0ZXJuYWwgVlBOIEZvcndhcmRlcnMsIGJ1dCBJIHRo aW5rIG9ubHkgaW4gdGhlIGNhc2Ugd2hlcmUNCiAgICA+IA0KICAgID4gdGhlIEVuZCBTeXN0ZW0g aXMgZXhwZWN0ZWQgdG8gc3Vic2NyaWJlIHRvIHRoZSBSb3V0ZSBTZXJ2ZXIgZGlyZWN0bHkgLS0N CiAgICA+IA0KICAgID4gaWYgdGhlIEVuZCBTeXN0ZW0gYWN0dWFsbHkgc3Vic2NyaWJlcyB0byB0 aGUgVlBOIEZvcndhcmRlciwgdGhlbiB0aGUNCiAgICA+IA0KICAgID4gRW5kIFN5c3RlbSBhbHJl YWR5IGtub3dzIHRoZSBWUE4gRm9yd2FyZGVyJ3MgSklEIGFuZCB3b3VsZCBub3QgbmVlZCB0bw0K ICAgID4gDQogICAgPiBkZXRlcm1pbmUgdGhlIFJvdXRlIFNlcnZlcicgSklELg0KICAgID4gDQog ICAgPiAgDQogICAgPiANCiAgICA+IC9TTT4gSXQgaXMgYXNzdW1lZCB0aGF0IFJvdXRlIFNlcnZl cnMgY29udGFpbiBpZGVudGljYWwgcm91dGluZw0KICAgID4gaW5mb3JtYXRpb24sIC8NCiAgICA+ IA0KICAgID4gL29yIHRoYXQgUm91dGluZyBTZXJ2ZXJzIGNvbnRhaW4ganVzdCB0aGUgcm91dGlu ZyBpbmZvcm1hdGlvbiByZXF1aXJlZA0KICAgID4gZm9yIHRoZSAvDQogICAgPiANCiAgICA+IC9W UE4gRm9yd2FyZGVycyB0aGF0IGNvbm5lY3QgdG8gdGhlbS4gSW4gdGhpcyBzZWNvbmQgY2FzZSwg YSBSb3V0aW5nDQogICAgPiBTZXJ2ZXIgLw0KICAgID4gDQogICAgPiAvY2FuIHN1YnNjcmliZSBm b3Igcm91dGluZyBpbmZvcm1hdGlvbiBtYW5hZ2VkIGluIGEgaGlnaGVyLW9yZGVyDQogICAgPiBt YW5hZ2VtZW50IC8NCiAgICA+IA0KICAgID4gL3N5c3RlbSB0aGF0IG1hbmFnZXMgYWxsIHRoZSBy b3V0aW5nIGluZm9ybWF0aW9uIGZvciBhIGRvbWFpbiBvZiBWUE4gLw0KICAgID4gDQogICAgPiAv Rm9yd2FyZGVycy4gVGhlIHByb3RvY29sIGJldHdlZW4gUm91dGUgU2VydmVycyBhbmQgc3VjaCBh IGhpZ2hlci1sZXZlbCAvDQogICAgPiANCiAgICA+IC9tYW5hZ2VtZW50IGNvdWxkIGJlIFhNUFAg b3IgYW5vdGhlciBjb252ZW5pZW50IHByb3RvY29sIHRoYXQgc3VwcG9ydHMgYSAvDQogICAgPiAN CiAgICA+IC9wdWJsaXNoIGFuZCBzdWJzY3JpYmUgY2FwYWJpbGl0eS4vDQogICAgPiANCiAgICA+ ICANCiAgICA+IA0KICAgID4gIA0KICAgID4gDQogICAgPiBNaW5vciBJc3N1ZXM6IChhbGwgYXBw bHkgdG8gU2VjdGlvbiA2LiBYTVBQIFNpZ25hbGluZyBQcm90b2NvbCkNCiAgICA+IA0KICAgID4g IA0KICAgID4gDQogICAgPiAqIFRoZSBYRVAtMDA2MCBQdWJTdWIgc3Vic2NyaXB0aW9uIGFuZCB1 bnN1YnNjcmlwdGlvbiBleGFtcGxlcyBhcmUNCiAgICA+IA0KICAgID4gaW5jb3JyZWN0LiAgU3Bl Y2lmaWNhbGx5LCB0aGUgJ2ppZCcgYXR0cmlidXRlIG9mIHRoZSA8c3Vic2NyaWJlLz4NCiAgICA+ IA0KICAgID4gZWxlbWVudCBpcyB0aGUgc3Vic2NyaWJlcidzIEpJRCBub3QgdGhlIHB1YnN1YiBz ZXJ2aWNlLCBhbmQNCiAgICA+IA0KICAgID4gc3Vic2NyaXB0aW9uIG9wdGlvbnMgYXJlIGVuY29k ZWQgdXNpbmcgRGF0YSBGb3JtcyBbWEVQLTAwMDRdLg0KICAgID4gDQogICAgPiAgDQogICAgPiAN CiAgICA+IFRoZSBjby1sb2NhdGVkIGV4YW1wbGUgdGhlbiBpczoNCiAgICA+IA0KICAgID4gIA0K ICAgID4gDQogICAgPiA8aXEgdHlwZT0nc2V0Jw0KICAgID4gDQogICAgPiAgICAgZnJvbT0nZm9y d2FyZGVyLmV4YW1wbGUnDQogICAgPiANCiAgICA+ICAgICB0bz0ncm91dGUtc2VydmVyJw0KICAg ID4gDQogICAgPiAgICAgaWQ9J3N1YjEnPg0KICAgID4gDQogICAgPiAgIDxwdWJzdWIgeG1sbnM9 J2h0dHA6Ly9qYWJiZXIub3JnL3Byb3RvY29sL3B1YnN1Yic+DQogICAgPiANCiAgICA+ICAgICA8 c3Vic2NyaWJlIG5vZGU9J3Zwbi1jdXN0b21lci1uYW1lJyBqaWQ9J2ZvcndhcmRlci5leGFtcGxl Jy8+DQogICAgPiANCiAgICA+ICAgICA8b3B0aW9ucyBub2RlPSd2cG4tY3VzdG9tZXItbmFtZScg amlkPSdmb3J3YXJkZXIuZXhhbXBsZSc+DQogICAgPiANCiAgICA+ICAgICAgIDx4IHhtbG5zPSdq YWJiZXI6eDpkYXRhJyB0eXBlPSdzdWJtaXQnPg0KICAgID4gDQogICAgPiAgICAgICAgIDxmaWVs ZCB2YXI9J3ZwbiNpbnN0YW5jZS1pZCc+DQogICAgPiANCiAgICA+ICAgICAgICAgICA8dmFsdWU+ MTwvdmFsdWU+DQogICAgPiANCiAgICA+ICAgICAgICAgPC9maWVsZD4NCiAgICA+IA0KICAgID4g ICAgICAgPC94Pg0KICAgID4gDQogICAgPiAgICAgPC9vcHRpb25zPg0KICAgID4gDQogICAgPiAg IDwvcHVic3ViPg0KICAgID4gDQogICAgPiA8L2lxPg0KICAgID4gDQogICAgPiAgDQogICAgPiAN CiAgICA+IC9TTT4gVGhpcyBoYXMgYmVlbiBjb3JyZWN0ZWQvDQogICAgPiANCiAgICA+ICANCiAg ICA+IA0KICAgID4gVGhlIGV4dGVybmFsIGV4YW1wbGUgY291bGQgYmUgdGhlIGZvbGxvd2luZyAo aWYgdGhlcmUgaXMgYSBzaW5nbGUNCiAgICA+IA0KICAgID4gYWRkcmVzc2luZyBzY2hlbWUpOg0K ICAgID4gDQogICAgPiAgDQogICAgPiANCiAgICA+IDxpcSB0eXBlPSdzZXQnDQogICAgPiANCiAg ICA+ICAgICBmcm9tPSdlbmQtc3lzdGVtQGZvcndhcmRlci5leGFtcGxlJw0KICAgID4gDQogICAg PiAgICAgdG89J3JvdXRlLXNlcnZlcicNCiAgICA+IA0KICAgID4gICAgIGlkPSdzdWIxJz4NCiAg ICA+IA0KICAgID4gICA8cHVic3ViIHhtbG5zPSdodHRwOi8vamFiYmVyLm9yZy9wcm90b2NvbC9w dWJzdWInPg0KICAgID4gDQogICAgPiAgICAgPHN1YnNjcmliZSBub2RlPSd2cG4tY3VzdG9tZXIt bmFtZScgamlkPSdlbmQtc3lzdGVtQGZvcndhcmRlci5leGFtcGxlJy8+DQogICAgPiANCiAgICA+ ICAgICA8b3B0aW9ucyBub2RlPSd2cG4tY3VzdG9tZXItbmFtZScgamlkPSdlbmQtc3lzdGVtQGZv cndhcmRlci5leGFtcGxlJz4NCiAgICA+IA0KICAgID4gICAgICAgPHggeG1sbnM9J2phYmJlcjp4 OmRhdGEnIHR5cGU9J3N1Ym1pdCc+DQogICAgPiANCiAgICA+ICAgICAgICAgPGZpZWxkIHZhcj0n dnBuI3ZsYW5faWQnPjx2YWx1ZT4xMDA8L3ZhbHVlPjwvZmllbGQ+DQogICAgPiANCiAgICA+ICAg ICAgIDwveD4NCiAgICA+IA0KICAgID4gICAgIDwvb3B0aW9ucz4NCiAgICA+IA0KICAgID4gICA8 L3B1YnN1Yj4NCiAgICA+IA0KICAgID4gPC9pcT4NCiAgICA+IA0KICAgID4gIA0KICAgID4gDQog ICAgPiAgDQogICAgPiANCiAgICA+IFRoZSB1bnN1YnNjcmliZSBleGFtcGxlIGlzIHRoZW46DQog ICAgPiANCiAgICA+ICANCiAgICA+IA0KICAgID4gPGlxIHR5cGU9J3NldCcNCiAgICA+IA0KICAg ID4gICAgIGZyb209J2ZvcndhcmRlci5leGFtcGxlJw0KICAgID4gDQogICAgPiAgICAgdG89J3Jv dXRlLXNlcnZlcicNCiAgICA+IA0KICAgID4gICAgIGlkPSd1bnN1YjEnPg0KICAgID4gDQogICAg PiAgIDxwdWJzdWIgeG1sbnM9J2h0dHA6Ly9qYWJiZXIub3JnL3Byb3RvY29sL3B1YnN1Yic+DQog ICAgPiANCiAgICA+ICAgICA8dW5zdWJzY3JpYmUgbm9kZT0ndnBuLWN1c3RvbWVyLW5hbWUnDQog ICAgPiANCiAgICA+ICAgICAgICAgICAgICAgICAgamlkPSdmb3J3YXJkZXIuZXhhbXBsZScgLz4N CiAgICA+IA0KICAgID4gICA8L3B1YnN1Yj4NCiAgICA+IA0KICAgID4gPC9pcT4NCiAgICA+IA0K ICAgID4gIA0KICAgID4gDQogICAgPiAvU00+ICBJbiB0aGUgZXh0ZXJuYWwgY2FzZSwgdGhlIFZQ TiBGb3J3YXJkZXIgaGFzIHRoZSBzZXNzaW9uIHdpdGggdGhlDQogICAgPiBSb3V0ZSBTZXJ2ZXIs IG5vdCAvDQogICAgPiANCiAgICA+IC90aGUgRW5kLVN5c3RlbSwgYW5kIHRoZSB0ZXh0IGhhcyBi ZWVuIGNoYW5nZWQgdG8gcmVmbGVjdCB0aGlzLiAvDQogICAgPiANCiAgICA+IC8gLw0KICAgID4g DQogICAgPiAgDQogICAgPiANCiAgICA+ICogUmVxdWlyaW5nIHB1YnN1YiBub3RpZmljYXRpb25z IHRvIGFsd2F5cyBnbyBmcm9tIHRoZSBSb3V0ZSBTZXJ2ZXIgdG8NCiAgICA+IA0KICAgID4gdGhl IFZQTiBGb3J3YXJkZXIgcmVnYXJkbGVzcyBvZiB3aGF0IGVudGl0eSBzdWJzY3JpYmVkIHRvIHRo ZSBwdWJzdWINCiAgICA+IA0KICAgID4gbm9kZSBpcyBjb3VudGVyIHRvIGhvdyBYRVAtMDA2MCB3 b3Jrcy4gIFRoZSBwdWJzdWIgc3Vic2NyaWJlIHJlcXVlc3QNCiAgICA+IA0KICAgID4gc3BlY2lm aWVzIHdoZXJlIHRoZSBub3RpZmljYXRpb25zIGFyZSBzdXBwb3NlZCB0byBnbywgYW5kIHRoZSBw dWJzdWINCiAgICA+IA0KICAgID4gc2VydmljZSBpcyBleHBlY3RlZCB0byBob25vciB0aGF0LiAg U2VlIGFib3ZlIGluIHRoZSBhZGRyZXNzaW5nDQogICAgPiANCiAgICA+IGRpc2N1c3Npb24gZm9y IHNvbWUgaWRlYXMgb2YgaG93IHRvIGRlYWwgd2l0aCB0aGlzLg0KICAgID4gDQogICAgPiAgDQog ICAgPiANCiAgICA+IC9TTT4gV2l0aGluIHRoZSBjb250ZXh0IG9mIHRoaXMgZG9jdW1lbnQsIG9u bHkgVlBOIEZvcndhcmRlcnMgYXJlDQogICAgPiBzdWJzY3JpYmluZyAvDQogICAgPiANCiAgICA+ IC90byBSb3V0ZSBTZXJ2ZXJzLi8NCiAgICA+IA0KICAgID4gIA0KICAgID4gDQogICAgPiAgDQog ICAgPiANCiAgICA+IE5pdHM6DQogICAgPiANCiAgICA+ICANCiAgICA+IA0KICAgID4gKiAoTW9z dGx5IGluIFNlY3Rpb24gNi4gWE1QUCBTaWduYWxpbmcgUHJvdG9jb2wpIFRoZSBkb2N1bWVudCBv ZnRlbg0KICAgID4gDQogICAgPiB1c2VzIHRoZSB0ZXJtICJtZXNzYWdlIiB3aGVuIGRpc2N1c3Np bmcgWE1QUCBjb21tdW5pY2F0aW9ucy4gVGhlIFhNUFANCiAgICA+IA0KICAgID4gdGVybSBvZiBh cnQgaXMgInN0YW56YSIgbm90ICJtZXNzYWdlIjsgIm1lc3NhZ2UiIGhhcyBhIHNwZWNpZmljDQog ICAgPiANCiAgICA+IG1lYW5pbmcgaW4gWE1QUCB0aGF0IGlzIG5vdCBpbiB1c2UgaGVyZSwgYW5k IGNhbiBsZWFkIHRvIGNvbmZ1c2lvbg0KICAgID4gDQogICAgPiBmb3IgcmVhZGVycyBvZiB0aGlz IGRvY3VtZW50IG9uY2UgdGhleSBmb2xsb3cgdGhlIHJlZmVyZW5jZXMgdG8NCiAgICA+IA0KICAg ID4gUkZDIDYxMjAgYW5kIHRoZSB2YXJpb3VzIFhFUHMuDQogICAgPiANCiAgICA+IC9TTT4gQ2hh bmdlZCDigJxtZXNzYWdl4oCdIHRvIOKAnHN0YW56YeKAnSwgZXhjZXB0IGluIHRoZSBzZWN0aW9u IHRoYXQgZGVhbHMgd2l0aCAvDQogICAgPiANCiAgICA+IC9ub3RpZmljYXRpb25zLw0KICAgID4g DQogICAgPiAgDQogICAgPiANCiAgICA+ICogSW4gU2VjdGlvbiAxLiBJbnRyb2R1Y3Rpb24sIHRo ZSB1c2Ugb2YgdGhlIHRlcm0gWE1QUCBzaG91bGQgYmUNCiAgICA+IA0KICAgID4gZm9sbG93ZWQg YnkgYSByZWZlcmVuY2UgdG8gUkZDIDYxMjAuDQogICAgPiANCiAgICA+ICANCiAgICA+IA0KICAg ID4gL1NNPiBDaGFuZ2UgbWFkZS8NCiAgICA+IA0KICAgID4gIA0KICAgID4gDQogICAgPiAqIElu IFNlY3Rpb24gNi4gWE1QUCBTaWduYWxpbmcgUHJvdG9jb2wsIHRoZSBzZXZlbnRoIHBhcmFncmFw aA0KICAgID4gDQogICAgPiAoaW1tZWRpYXRlbHkgcHJlY2VkaW5nIEZpZ3VyZSAxKSBoYXMgYW4g ZXh0cmFuZW91cyBwZXJpb2QgKC4pIGF0IHRoZQ0KICAgID4gDQogICAgPiBlbmQgb2YgdGhlIGxh c3Qgc2VudGVuY2UuDQogICAgPiANCiAgICA+ICANCiAgICA+IA0KICAgID4gU00+IEZpeGVkDQog ICAgPiANCiAgICA+ICANCiAgICA+IA0KICAgID4gKiBJbiBTZWN0aW9uIDYuIFhNUFAgU2lnbmFs aW5nIFByb3RvY29sLCBJIHVuZGVyc3Rvb2QgdGhlIG1lYW5pbmcgb2YNCiAgICA+IA0KICAgID4g dGhlIGZvbGxvd2luZyBzZW50ZW5jZToNCiAgICA+IA0KICAgID4gIA0KICAgID4gDQogICAgPiAg ICAgVGhlIFZQTiBGb3J3YXJkZXIgU0hPVUxEIHVzZSBhcyBKSUQgaXRzIGhvc3RuYW1lLCB3aGVu IGF2YWlsYWJsZSwNCiAgICA+IA0KICAgID4gICAgIG9yIGFuIHVuaXF1ZSBJUCBhZGRyZXNzIHdp dGhpbiB0aGUgaW5mcmFzdHJ1Y3R1cmUgbmV0d29yayB3aW4gaXRzDQogICAgPiANCiAgICA+ICAg ICBzdHJpbmcgcmVwcmVzZW50YXRpb24uDQogICAgPiANCiAgICA+ICANCiAgICA+IA0KICAgID4g UmVnYXJkbGVzcyBvZiBob3cgbXkgWE1QUCBhZGRyZXNzaW5nIGNvbmNlcm5zIGFyZSBmaW5hbGx5 IHJlc29sdmVkLA0KICAgID4gDQogICAgPiBwbGVhc2UgcmV2aXNpdCB0aGlzIHNlbnRlbmNlLg0K ICAgID4gDQogICAgPiAgDQogICAgPiANCiAgICA+IC9TTT4gQ2hhbmdlZCB0bzovDQogICAgPiAN CiAgICA+IC9UaGUgVlBOIEZvcndhcmRlciBTSE9VTEQgdXNlIGFzIEpJRCBpdHMgaG9zdG5hbWUs IHdoZW4gYXZhaWxhYmxlLCBvciBhDQogICAgPiB1bmlxdWUgLw0KICAgID4gDQogICAgPiAvSVAg YWRkcmVzcyB3aXRoaW4gdGhlIGluZnJhc3RydWN0dXJlIG5ldHdvcmsgdXNpbmcgaXQgc3RyaW5n DQogICAgPiByZXByZXNlbnRhdGlvbi4vDQogICAgPiANCiAgICA+ICANCiAgICA+IA0KICAgID4g IA0KICAgID4gDQogICAgPiAgDQogICAgPiANCiAgICA+IFJlZmVyZW5jZXM6DQogICAgPiANCiAg ICA+ICANCiAgICA+IA0KICAgID4gW1hFUC0wMDA0XTogRGF0YSBGb3JtcyA8IGh0dHA6Ly94bXBw Lm9yZy9leHRlbnNpb25zL3hlcC0wMDA0Lmh0bWwgPg0KICAgID4gDQogICAgPiBbWEVQLTAwMzBd OiBTZXJ2aWNlIERpc2NvdmVyeSA8IGh0dHA6Ly94bXBwLm9yZy9leHRlbnNpb25zL3hlcC0wMDMw Lmh0bWwgPg0KICAgID4gDQogICAgPiBbWEVQLTAxNzhdOiBCZXN0IFByYWN0aWNlcyBmb3IgVXNl IG9mIFNBU0wgRVhURVJOQUwgd2l0aCBDZXJ0aWZpY2F0ZXMgPA0KICAgID4gaHR0cDovL3htcHAu b3JnL2V4dGVuc2lvbnMveGVwLTAxNzguaHRtbCA+DQogICAgPiANCiAgICA+ICANCiAgICA+IA0K ICAgID4gIA0KICAgID4gDQogICAgPiAtLQ0KICAgID4gDQogICAgPiAtIG0mbQ0KICAgID4gDQog ICAgPiAgDQogICAgPiANCiAgICA+IE1hdHQgTWlsbGVyDQogICAgPiANCiAgICA+IENpc2NvIFN5 c3RlbXMsIEluYy4NCiAgICA+IA0KICAgID4gIA0KICAgID4gDQogICAgPiAgDQogICAgPiANCiAg ICA+ICrigKbigKbigKbigKbigKbigKbigKbigKbigKbigKYuLioNCiAgICA+IA0KICAgID4gIA0K ICAgID4gDQogICAgPiAqU3R1YXJ0IE1hY2tpZSoNCiAgICA+IA0KICAgID4gL1NETi9ORlYgQXJj aGl0ZWN0Lw0KICAgID4gDQogICAgPiAvIC8NCiAgICA+IA0KICAgID4gKzEgOTE0IDg4NiAyNTM0 DQogICAgPiANCiAgICA+ICANCiAgICA+IA0KICAgID4gY2lkOmltYWdlMDAxLnBuZ0AwMUQyMzkx NC5DNDFBQjcyMA0KICAgID4gDQogICAgDQogICAgDQoNCg== From nobody Sun Mar 19 02:16:35 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37D8129481 for ; Sun, 19 Mar 2017 02:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.717 X-Spam-Level: X-Spam-Status: No, score=-2.717 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=M6ZckuQ+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mqxLXqwZ 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 MWHwPFTe_qvN for ; Sun, 19 Mar 2017 02:16:32 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FCB112947F for ; Sun, 19 Mar 2017 02:16:32 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id BE78C20511; Sun, 19 Mar 2017 05:16:31 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Sun, 19 Mar 2017 05:16:31 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=OyKKFwdE0Uyw3+4cw8kjzOktWg8=; b=M6ZckuQ+F 23az3Bhv3f7t6RPUa5EXFqDKnBap4tpwmEkB/aS4cuRyeWPQKpRCpaaTMgK07RNy qrPC6d9WHck9e7MEDaX8x/jXhnT13+nWXc4zkqIyhOC7tq6HIsL2agP59pseYztW yiZOmkiY2c1wX9vs8Mbbox+9bqb2C9D5BMGXFdTUwYMXuBYy2CcVhvSI258pcs4x UpWeTT7Zn6EUo5Hkv7jeAK8RrtyCax09VubjtX0o3Qd3v7Ewi7HAhoUpKXhVx75j bvTeYNQE8uyjlla6B67bwNh3i1KmiZThwajKujmYXi4nvcCKqkhR+JIUmPGjFs63 e2NApe/gTxCtg== DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=OyKKFwdE0Uyw3+4cw8 kjzOktWg8=; b=mqxLXqwZMgZ4KoshNlWPrPvYtDiCCoZIGAxBjZidgMsUbliG4c HUjrG0liRu2vdv4SBoQDeiTuS0cf2fGuwRxh7GpmYWhDSplkjsH9cp5ktahUTXuX l6VdmcB94HhN2B3M7v6gLOAqPh1djtt/r4QKweVS1taLCtUa3y9dcSTHvhfPT4QE 8IubaG2MOkZOOUDWUnm0S+laKMFsHGPpH0YxKCgz7aJuO9pI7dxaSL8NxZQ8UQ3h MxLUwoIUrz87pUP+GyOyI9AfTeYXRvHmzoyk6VpUQmSYyKctZkYvYt4tSFNPuxRS fl+TiHMDSBokGlA6VwMs8nj/2iqB/oJX4XPw== X-ME-Sender: X-Sasl-enc: 8eqlyo27r+392WeAYx8GXevgx6x1dpsTrkTC+Y6kWrSs 1489914991 Received: from [192.168.0.6] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by mail.messagingengine.com (Postfix) with ESMTPA id 6E2317E46B; Sun, 19 Mar 2017 05:16:31 -0400 (EDT) From: Alexey Melnikov Content-Type: multipart/alternative; boundary=Apple-Mail-C854E0FA-33DC-4F37-B99B-4A350D3DFE19 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Sun, 19 Mar 2017 09:36:27 +0000 Message-Id: To: art@ietf.org X-Mailer: iPad Mail (14A456) Archived-At: Subject: [art] ART ADs open hour X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 09:16:34 -0000 --Apple-Mail-C854E0FA-33DC-4F37-B99B-4A350D3DFE19 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear ART Area participants, Sorry for the late notice, but hopefully you will find this information useful. ART AD are planning to have ART AD open hour session in Chicago. You can come and talk to us about general ART Area topics or specific WGs or documents. The session will be on Monday, March 27, in the afternoon session II slot (15:20-16:50). Location is to be announced, but it is most likely will be the IESG meeting room. If after reading this message you decide to definitely come, please email art-ads@ietf.org. This will help us with planning. However turning up unannounced is fine as well. Best Regards, Alexey, on behalf of ART ADs --Apple-Mail-C854E0FA-33DC-4F37-B99B-4A350D3DFE19 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear ART Area participants,
Sorry for the late notice, but h= opefully you will find this information
useful.

ART AD are plannin= g to have ART AD open hour session in Chicago. You can
come and talk to u= s about general ART Area topics or specific WGs or
documents.

The s= ession will be on Monday, March 27, in the afternoon sessi= on II
slot (15:20-16:50). Location is to be announced, but it is m= ost likely
will be the IESG meeting room.

If after reading this me= ssage you decide to definitely come, please
email art-ads@ietf.org<= /a>. This will help us with planning. However turning
up unannounced is f= ine as well.

Best Regards,
Alexey, on behalf of ART ADs= --Apple-Mail-C854E0FA-33DC-4F37-B99B-4A350D3DFE19-- From nobody Thu Mar 23 08:03:00 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697771293FF for ; Tue, 14 Mar 2017 22:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ss0fKekBAyKf for ; Tue, 14 Mar 2017 22:17:16 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9106B1293F4 for ; Tue, 14 Mar 2017 22:17:16 -0700 (PDT) Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id EAE3022E1F3 for ; Wed, 15 Mar 2017 01:17:09 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <5CB15D9F-D50F-4A78-8AC0-21B835534D23@mnot.net> Date: Wed, 15 Mar 2017 16:17:07 +1100 To: IETF Apps Discuss X-Mailer: Apple Mail (2.3259) Archived-At: X-Mailman-Approved-At: Thu, 23 Mar 2017 08:02:58 -0700 Subject: [art] "Home" documents for HTTP APIs X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 05:17:18 -0000 Hi art[-discuss], I've had a document on the back burner for a while about a "home = document" for non-brower uses of HTTP. https://datatracker.ietf.org/doc/draft-nottingham-json-home/ https://mnot.github.io/I-D/json-home/ The idea is to promote good practice, especially regarding allowing the = server to control its own URLs (as per RFC7320) -- especially in the = case where there are likely to be multiple implementations, multiple = servers and multiple clients deployed (i.e., standards). This differentiates it from other "HTTP API description formats" that = you might have come across. See the Introduction for a more full = explanation. It's come to a point where there's a non-trival (but not huge) community = of folks interested in it and implementing it; e.g., see:=20 https://github.com/mnot/I-D/wiki/json-home https://github.com/mnot/I-D/issues?utf8=3D=E2=9C=93&q=3Dlabel%3Ajson-hom= e%20 However, I'm not sure about next steps. What I'd like to hear from folks = here is whether people think defining this would help IETF protocols = that use HTTP (of which there seem to be more every day). Any thoughts? Thanks, -- Mark Nottingham https://www.mnot.net/ From nobody Thu Mar 23 09:44:15 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE30129A48 for ; Thu, 23 Mar 2017 09:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 TuKKvPmdEjJ7 for ; Thu, 23 Mar 2017 09:44:11 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C05F129A45 for ; Thu, 23 Mar 2017 09:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2NGhrfC026425 for ; Thu, 23 Mar 2017 17:43:53 +0100 (CET) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vpsnj3ZxtzDJ9q for ; Thu, 23 Mar 2017 17:43:53 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <5CB15D9F-D50F-4A78-8AC0-21B835534D23@mnot.net> Date: Thu, 23 Mar 2017 17:43:53 +0100 X-Mao-Original-Outgoing-Id: 511980232.904076-a7e1c4a00d64d31d09f617de29acd8f6 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5CB15D9F-D50F-4A78-8AC0-21B835534D23@mnot.net> To: art@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [art] "Home" documents for HTTP APIs X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 16:44:13 -0000 draft-ietf-core-links-json just finished second WGLC in core. That is clearly solving a different problem (making RFC 6690 available = in JSON/CBOR), but I can=E2=80=99t help noticing that there are some = commonalities. RFC 6690, of course, is the =E2=80=9Chome document=E2=80=9D for CoRE. Also, OCF has /oic/res, which is in the same mold. No idea whether this semblance should have any impact on either = document, but maybe food for thought. (Yes, I have read Appendix D. Maybe I should point to = draft-hartke-t2trg-coral as one take on the =E2=80=9Cform=E2=80=9D gap. = Input on this is very welcome over in T2TRG.) Gr=C3=BC=C3=9Fe, Carsten [resent this because of "Message has implicit destination=E2=80=9D = breakage.] From nobody Sun Mar 26 06:08:38 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0861C12955D for ; Sun, 26 Mar 2017 06:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=JHqMRwpS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fEPm7xpH 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 BCGSVNFLCS7X for ; Sun, 26 Mar 2017 06:08:35 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C286B129415 for ; Sun, 26 Mar 2017 06:08:35 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id D3EA1209C2 for ; Sun, 26 Mar 2017 09:08:34 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Sun, 26 Mar 2017 09:08:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=Vq2bdb6dsDlqyFZjUIdg4W56gDKyJUzA4J+PfOZgQ C4=; b=JHqMRwpSpQySqOdLIx2Hpc2+HM+5ciFo8akxRi+DK64J0L8NMWGys7F9K TPu7jAYz2QIrTugoFb1P2dv5W2BVO2ialrrOrgcyW/XSyaq9KZTqy/fzF+TmAAKW X/PNl2djEBC83BcpHps3HD9Wp9Pc2RqgiNTxCEVkq/+f0DT3xd5U0hXN476Mw/aL +kTDFGAgkD7MuejXpG8h03Dg1YZqToNUX4lXUGko1HfDdEa+8/VZj/nQPhnoH2gA lfo48aRWsOob97q+bcH4/51ZerPf1dJJ1AePKrl+b2k8parLm8e4pX2NyZSTsdz7 BlWRV4g0RmfYw5m2GaQ0v5QWT0ejA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=Vq2bdb6dsDlqyFZjUI dg4W56gDKyJUzA4J+PfOZgQC4=; b=fEPm7xpHZRyubMMnAQXuuZXUA71M1Oclq4 77KMCf/umJ6HA4XtmLcX2xY1eU9XxLLhtKvDy7A+Ec8g+cBWG3jnEC+x5GqXKvF1 3RjSXUlGOHr63XbJ3hSvlIPQblAIq6mwfb6qfle8oYJ2CxGulmUheoiQaAwNPpR1 KO1SlNgZkk6EvGtvm5PjmXrMP3Pgx6wYCj3K5QNvOkUgXBgbj6nggUim++EJmP5p SxZJcNJi22lEDLq5NLmuyE0wLLZGBsrI/gXW3CFMVoHtODf10pCOq4AsJ4pvqEUG FG2AO8oatDSDwMLi+WJOM4TNrHqAr7M/BvQasEPgvYYtbE7H+laQ== X-ME-Sender: X-Sasl-enc: V9gsoD+l4hwJ3yXEOarMzA+igfrI8xeHmcxiIwDd23eM 1490533714 Received: from [172.20.1.223] (swissotel07.s.subnet.rcn.com [216.80.61.6]) by mail.messagingengine.com (Postfix) with ESMTPA id 86A4124614 for ; Sun, 26 Mar 2017 09:08:34 -0400 (EDT) From: Alissa Cooper Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <26AEF735-09EF-4B9F-A7D4-DC29965F9DE6@cooperw.in> Date: Sun, 26 Mar 2017 08:08:33 -0500 To: art@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [art] Transition of ART WGs X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 13:08:37 -0000 With Adam coming in as the new ART AD, we wanted to share the plans for = which ADs will be responsible for which WGs once he officially joins the = IESG on Wednesday: - Adam will become responsible for BFCPBIS, CAPPORT, CLUE, ECRIT, = GEOJSON, MODERN, NETVC, REGEXT, RTCWEB, STIR, and WEBPUSH - Ben will become responsible for XRBLOCK - All other ART groups will remain as-is for now The ADs are working on finding chair replacements for groups that Adam = was chairing. From nobody Mon Mar 27 12:34:44 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5CBA129440 for ; Mon, 27 Mar 2017 12:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 RVFD6nslVHDf for ; Mon, 27 Mar 2017 12:34:41 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 598D41274D2 for ; Mon, 27 Mar 2017 12:34:41 -0700 (PDT) Received: from [128.9.184.151] ([128.9.184.151]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v2RJYGoX001785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 27 Mar 2017 12:34:16 -0700 (PDT) To: art@ietf.org From: Joe Touch Message-ID: Date: Mon, 27 Mar 2017 12:34:16 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------CA0EB7FAAA3A8C1FDDF4AE80" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: [art] resolving time frames X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 19:34:43 -0000 This is a multi-part message in MIME format. --------------CA0EB7FAAA3A8C1FDDF4AE80 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, all, I've participated in discussions on issues with differences in time frames twice in the past year on the main IETF list and on HTTPBIS WG: https://mailarchive.ietf.org/arch/msg/ietf/To8dZTn9uBJLnzqIvEDPpNnA1rc https://lists.w3.org/Archives/Public/ietf-http-wg/2017JanMar/0406.html This suggested the need for documenting the issue for clarification, so that we can avoid such protracted debates in the future. As a result, I wrote document indicated below for discussion here. Feedback welcome. Joe ---------- A new version of I-D, draft-touch-time-01.txt has been successfully submitted by Joe Touch and posted to the IETF repository. Name: draft-touch-time Revision: 01 Title: Resolving Multiple Time Scales in the Internet Document date: 2017-03-27 Group: Individual Submission Pages: 17 URL: https://www.ietf.org/internet-drafts/draft-touch-time-01.txt Status: https://datatracker.ietf.org/doc/draft-touch-time/ Htmlized: https://tools.ietf.org/html/draft-touch-time-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-touch-time-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-touch-time-01 Abstract: Internet systems use a variety of time scales, which can complicate time comparisons and calculations. This document explains these various ways of indicating time and explains how they can be used together safely. This document is intended as a companion to Internet time as discussed in RFC 3339. --------------CA0EB7FAAA3A8C1FDDF4AE80 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, all,

I've participated in discussions on issues with differences in time
frames twice in the past year on the main IETF list and on HTTPBIS WG:

https://mailarchive.ietf.org/arch/msg/ietf/To8dZTn9uBJLnzqIvEDPpNnA1rc

https://lists.w3.org/Archives/Public/ietf-http-wg/2017JanMar/0406.html

This suggested the need for documenting the issue for clarification, so that we can avoid such protracted debates in the future. As a result, I wrote document indicated below for discussion here.

Feedback welcome.

Joe

----------
A new version of I-D, draft-touch-time-01.txt
has been successfully submitted by Joe Touch and posted to the
IETF repository.

Name:		draft-touch-time
Revision:	01
Title:		Resolving Multiple Time Scales in the Internet
Document date:	2017-03-27
Group:		Individual Submission
Pages:		17
URL:            https://www.ietf.org/internet-drafts/draft-touch-time-01.txt
Status:         https://datatracker.ietf.org/doc/draft-touch-time/
Htmlized:       https://tools.ietf.org/html/draft-touch-time-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-touch-time-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-touch-time-01

Abstract:
   Internet systems use a variety of time scales, which can complicate
   time comparisons and calculations. This document explains these
   various ways of indicating time and explains how they can be used
   together safely. This document is intended as a companion to
   Internet time as discussed in RFC 3339.

--------------CA0EB7FAAA3A8C1FDDF4AE80-- From nobody Tue Mar 28 07:05:45 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B13129528 for ; Tue, 28 Mar 2017 07:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 4DfR40zeCjn4 for ; Tue, 28 Mar 2017 07:05:41 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 967CF128ACA for ; Tue, 28 Mar 2017 07:05:40 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1csrkh-0000GYC; Tue, 28 Mar 2017 16:05:39 +0200 Message-Id: To: art@ietf.org Cc: Joe Touch From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com In-reply-to: Your message of "Mon, 27 Mar 2017 12:34:10 -0700 ." <869e1c74-2e6e-f4cd-4830-50985bab6be8@isi.edu> Date: Tue, 28 Mar 2017 16:05:37 +0200 Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 14:05:43 -0000 In your letter dated Mon, 27 Mar 2017 12:34:10 -0700 you wrote: >I've submitted the time frame discussion intended to resolve this issue, >which also recently arouse on another mailing list. Further discussion >on this draft will occur on the ART mailing list (art@ietf.org). A few random comments. I think a document like this is useful, though it might hard to strike the right balance between providing enough and too much detail. - There are two types of solar time. The actual solar time where the sun is at the highest point at noon, and mean solar time. Section 4 does not make that distinction, but it is mentioned in a later section. After far as I know, actual solar time is extremely rare (only sundials). Solar time is almost always mean solar time. I.e UT0 is already mean solar time. - UTC (and TAI) doesn't really exist. They are realized at various labs all over the world. The real value of UTC is coordinated only after the fact. This makes a statement that GPS time differs 25 ns from TAI a bit weird. Maybe this is too much detail. - It is not clear to me why NTP would differ 100ms from TAI. - The epoch for NTP is 1900-01-01. - It is not clear to me what 'Unix time' is in this context. Typically POSIX time is linked to UTC, i.e. every value of time_t corresponds to a specific UTC timestamp. The inverse is not true, leapseconds cannot be represented in time_t. - I can't find any reference where the epoch of TAI is defined as 1977-01-01. - Section 5.1.3 says 'Similarly, the earth's orbit around the sun varies and is slowing over time, resulting in an increasing stretching of a solar second.' It is the rotation of the earth around it's own axis that causes the solar second to become longer over time, not the rotation of the earth around the sun. - One thing I'd like to add is 'uptime' or more general, monotonic time. Many network protocols need timers and timeout. There is however no need to reference these to UTC, or TAI, etc. So computing time intervals using uptime is in many cases better because that also works if an external time reference doesn't become available until long after booting. - Another thing worth mentioning explictly is that for the distant future, there is no way to convert between TAI and UTC because future leapsecond are not yet defined. So TAI is good for computing intervals, except if it involves timestamps more than a few months in the future. From nobody Tue Mar 28 08:14:16 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95AB128B88 for ; Tue, 28 Mar 2017 08:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no 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 tDdpdgYXi4p4 for ; Tue, 28 Mar 2017 08:14:12 -0700 (PDT) Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [131.111.8.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CD71129437 for ; Tue, 28 Mar 2017 08:13:53 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:50575) by ppsw-33.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.137]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1cssof-000mKE-i5 (Exim 4.89) (return-path ); Tue, 28 Mar 2017 16:13:49 +0100 Date: Tue, 28 Mar 2017 16:13:49 +0100 From: Tony Finch To: Philip Homburg cc: art@ietf.org, Joe Touch In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 15:14:15 -0000 Philip Homburg wrote: > > A few random comments. Good comments :-) > - There are two types of solar time. The actual solar time where the sun is > at the highest point at noon, and mean solar time. The usual term for the former is "apparent solar time". If you are talking about both then it's worth saying the difference between apparent and mean solar time is called the equation of time. > - One thing I'd like to add is 'uptime' or more general, monotonic time. An interesting discussion re. compatible APIs for elapsed time: https://github.com/golang/proposal/blob/master/design/12914-monotonic.md > - Another thing worth mentioning explictly is that for the distant future, > there is no way to convert between TAI and UTC because future leapsecond are > not yet defined. So TAI is good for computing intervals, except if it involves > timestamps more than a few months in the future. I think "distant future" isn't a very good description for "a few months" :-) The actual horizon is about 5 - 11 months, just before and just after bulletin C is published in January or July. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode North Hebrides, Bailey, Fair Isle, Faeroes, Southeast Iceland: Easterly 5 to 7, occasionally gale 8 in western Southeast Iceland. Moderate or rough. Occasional drizzle. Good, occasionally poor. From nobody Tue Mar 28 11:12:34 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED1312944B for ; Tue, 28 Mar 2017 11:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 7uVg3xxIdu0z for ; Tue, 28 Mar 2017 11:12:30 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 DDD76129471 for ; Tue, 28 Mar 2017 11:12:29 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v2SIBxIj021706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Mar 2017 11:11:59 -0700 (PDT) To: Philip Homburg , art@ietf.org References: From: Joe Touch Message-ID: <1cb57d13-4145-eb74-7d6a-954fe3a1059c@isi.edu> Date: Tue, 28 Mar 2017 11:11:59 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 18:12:33 -0000 Hi, Philip, On 3/28/2017 7:05 AM, Philip Homburg wrote: > In your letter dated Mon, 27 Mar 2017 12:34:10 -0700 you wrote: >> I've submitted the time frame discussion intended to resolve this issue, >> which also recently arouse on another mailing list. Further discussion >> on this draft will occur on the ART mailing list (art@ietf.org). > A few random comments. I think a document like this is useful, though it > might hard to strike the right balance between providing enough and too much > detail. Yeah - I struggled with that. I don't think everyone will be happy with any particular boundary... > - There are two types of solar time. The actual solar time where the sun is > at the highest point at noon, and mean solar time. Section 4 does not make > that distinction, but it is mentioned in a later section. After far as I know, > actual solar time is extremely rare (only sundials). Solar time is almost > always mean solar time. I.e UT0 is already mean solar time. Section 3 states that in the definition of a solar day. Section 4.2 explains that UT0 is one of many different "means", and that UT0 is the most common in current use. > - UTC (and TAI) doesn't really exist. They are realized at various labs all > over the world. The real value of UTC is coordinated only after the fact. Although that's strictly true, there are also UTC and TAI sources that provide the current time as close to UTC and TAI as known. I can add that. > This makes a statement that GPS time differs 25 ns from TAI a bit weird. > Maybe this is too much detail. See above - even in retrospect, GPS can differ from TAI by 25 ns (it's in the spec for GPS). GPS isn't one of the clocks averaged into TAI (AFAICT); it's a separate source that's sync'd to TAI to ensure the 25 ns max delta. > - It is not clear to me why NTP would differ 100ms from TAI. It's in the spec. > - The epoch for NTP is 1900-01-01. Yup - my error. WIll fix. > - It is not clear to me what 'Unix time' is in this context. Typically POSIX > time is linked to UTC, That is incorrect. POSIX time is defined as 1/86400 of a day, which does not take into account leap seconds at all (UTC does) and "day" is not defined as related to SI units (UTC is). AFAICT, a POSIX "day" is at best a rough approximation of UT0. > i.e. every value of time_t corresponds to a specific > UTC timestamp. The inverse is not true, leapseconds cannot be represented in > time_t. See above, I think. > - I can't find any reference where the epoch of TAI is defined as 1977-01-01. It's from the updated definition of TAI, the one that started to take account for time dilation and gravitational influences. I'll see if I can find a citable ref for that. > - Section 5.1.3 says 'Similarly, the earth's orbit around the sun varies and > is slowing over time, resulting in an increasing stretching of a solar second.' > It is the rotation of the earth around it's own axis that causes the > solar second to become longer over time, not the rotation of the earth > around the sun. I'll fix that... > - One thing I'd like to add is 'uptime' or more general, monotonic time. Uptime is just a printout of the delta of the POSIX time when a computer started and the current POSIX time. It might be useful to indicate that some computers just start their clocks at boot as zero. > Many network protocols need timers and timeout. There is however no need > to reference these to UTC, or TAI, etc. So computing time intervals using > uptime is in many cases better because that also works if an external time > reference doesn't become available until long after booting. How/when to sync a "clock" to a time scale is important to note, but the details are implementation issues. "uptime" isn't used for timers; internal clocks are, e.g., the POSIX time scale. > - Another thing worth mentioning explictly is that for the distant future, > there is no way to convert between TAI and UTC because future leapsecond are > not yet defined. So TAI is good for computing intervals, except if it involves > timestamps more than a few months in the future. The doc mentions in various places that updated leapsecond information is required to maintain UTC or derive TAI from UTC. I can mention that we don't *expect* leapseconds to be added without at least a few months' notice, and that this affects indicating future dates accurately. Joe From nobody Tue Mar 28 11:21:37 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6551294AB for ; Tue, 28 Mar 2017 11:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 RSvKPP7XTQik for ; Tue, 28 Mar 2017 11:21:34 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 58CAA1293F8 for ; Tue, 28 Mar 2017 11:21:34 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v2SIL2BK024853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Mar 2017 11:21:02 -0700 (PDT) To: Tony Finch , Philip Homburg References: Cc: art@ietf.org From: Joe Touch Message-ID: <809d2f85-0421-026b-f81d-6725e0548b6a@isi.edu> Date: Tue, 28 Mar 2017 11:21:02 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 18:21:36 -0000 On 3/28/2017 8:13 AM, Tony Finch wrote: > Philip Homburg wrote: >> A few random comments. > Good comments :-) > >> - There are two types of solar time. The actual solar time where the sun is >> at the highest point at noon, and mean solar time. > The usual term for the former is "apparent solar time". If you are talking > about both then it's worth saying the difference between apparent and mean > solar time is called the equation of time. Will do. > >> - One thing I'd like to add is 'uptime' or more general, monotonic time. > An interesting discussion re. compatible APIs for elapsed time: > https://github.com/golang/proposal/blob/master/design/12914-monotonic.md This is another example of the confusion that results when the time scale is not clearly indicated or defined. Having Go read the "system wall clock" is the source of the problem, and this doc explains a variety of solutions. I can add a new "monotonic clock" definition that uses an arbitrary "tick" that is guaranteed to increase between reads and across reboots, but is not comparable across machines. > >> - Another thing worth mentioning explictly is that for the distant future, >> there is no way to convert between TAI and UTC because future leapsecond are >> not yet defined. So TAI is good for computing intervals, except if it involves >> timestamps more than a few months in the future. > I think "distant future" isn't a very good description for "a few months" :-) > > The actual horizon is about 5 - 11 months, just before and just after > bulletin C is published in January or July Agreed, but not sure we need that level of detail. Joe From nobody Tue Mar 28 11:41:19 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6819F129556 for ; Tue, 28 Mar 2017 11:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.798 X-Spam-Level: X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adobe.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 kWThpjDGbc0S for ; Tue, 28 Mar 2017 11:41:15 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0071.outbound.protection.outlook.com [104.47.41.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEAE21292CE for ; Tue, 28 Mar 2017 11:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adobe.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yNuIBvKDSwUMfBWpdx1Yvptish/umnnyltRI7eYU9GE=; b=SKf/0+ioSYolHF9yP1b9ThWCVBCUE7eHMMzjr80AB+bucpQGadny6wz8Q5SLuJ96Jua2RaUHvdP9SpFqm5uCIq0rJ/IxsKJlsWsHMb+pR5s+r9LLFuMQ/TIgxiEvQp+hqkwra0BwSNFB64IU0Te+/r+wjizJQ+/ivYWaug7OmT8= Received: from BN6PR02MB2323.namprd02.prod.outlook.com (10.168.254.13) by BN6PR02MB2323.namprd02.prod.outlook.com (10.168.254.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Tue, 28 Mar 2017 18:41:12 +0000 Received: from BN6PR02MB2323.namprd02.prod.outlook.com ([10.168.254.13]) by BN6PR02MB2323.namprd02.prod.outlook.com ([10.168.254.13]) with mapi id 15.01.0991.021; Tue, 28 Mar 2017 18:41:12 +0000 From: Michael Thornburgh To: Philip Homburg , "art@ietf.org" Thread-Topic: [art] Predictable Internet Time Thread-Index: AQHSp8xoOjtVatoOPkKRROl2zZ5L86GqiOrX Date: Tue, 28 Mar 2017 18:41:12 +0000 Message-ID: References: Your message of "Mon, 27 Mar 2017 12:34:10 -0700 ." <869e1c74-2e6e-f4cd-4830-50985bab6be8@isi.edu> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: u-1.phicoh.com; dkim=none (message not signed) header.d=none;u-1.phicoh.com; dmarc=none action=none header.from=adobe.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [25.172.48.132] x-microsoft-exchange-diagnostics: 1; BN6PR02MB2323; 7:tult8y0XDotoFgcoP8vlJ1YK3yVUjpM8whPzK4kF9Xb9PyJm+gbE60YdqomzGytDlV7hHtEtde6tpehoMpwq7yNXDoZRVW4e5qCTGEIrZDYa0RK59j6RO1JiPkSCC9LlHuib/BtJ9RVUD3TRW6xzl6RCyLYx/QndaUjlJSBLnqvLp+Uhn/t0lQ7E1yXeLoxwv2LKfDlNU1+HnDzrk72o6wgyy/N/fgt/NlicJBzSj+yrY046MIjPU3hoxHJDaYG6xlG1xPdP6kO6nZrRF0PEDDT24I6vuCpFgxGqhSgi3T99u5ifkjTnt+6McUdfgId3NTtSqJAi5mR61NWbhaXPrw==; 20:/fymwrsdeA/8Xjtft2VEkJYo7GBuJNlQt/nUIkzzsPOZWaG3SwCfhRx8JLaJ4BVZCItwduYUfo+12iamBvAYOYzcsrYMLoDzWMIjSzzIRj4iUT7pJtpBJD8UkN/FDZrPJu6WpC9zxfrZqN7RhAHIiow87UkksZ1yynFX3KFr8h4= x-ms-office365-filtering-correlation-id: 8b22e0f9-a26a-41a2-b378-08d4760a0230 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:BN6PR02MB2323; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(20161123558025)(6072148); SRVR:BN6PR02MB2323; BCL:0; PCL:0; RULEID:; SRVR:BN6PR02MB2323; x-forefront-prvs: 0260457E99 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39450400003)(39840400002)(39850400002)(39860400002)(377454003)(377424004)(6246003)(25786009)(229853002)(38730400002)(189998001)(5660300001)(6436002)(8990500004)(33656002)(10090500001)(66066001)(122556002)(77096006)(2501003)(6116002)(3846002)(102836003)(74316002)(7736002)(305945005)(99286003)(6306002)(8936002)(81166006)(2950100002)(3660700001)(8676002)(2900100001)(9686003)(6506006)(55016002)(86362001)(2906002)(7696004)(3280700002)(54356999)(50986999)(53936002)(76176999); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR02MB2323; H:BN6PR02MB2323.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2017 18:41:12.2267 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR02MB2323 Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 18:41:17 -0000 > From: art [art-bounces@ietf.org] on behalf of Philip Homburg [pch-ietf-ar= t@u-1.phicoh.com] > Sent: Tuesday, March 28, 2017 7:05 AM [...] > - It is not clear to me what 'Unix time' is in this context. Typically PO= SIX > time is linked to UTC, i.e. every value of time_t corresponds to a specif= ic > UTC timestamp. The inverse is not true, leapseconds cannot be represented= in > time_t. [...] while this has been the case so far, this is not true in general. there ca= n be negative leap seconds, for which there will be values of time_t with no corresponding UTC= time. fortunately there have not been any negative leap seconds yet. as i mentioned on a different mailing list [0], unix/posix time is a (defic= ient) time representation form, but people use it as a time keeping form (as if it's actually the "uptime" = since the unix epoch). i'm sure it was initially envisioned as both, even though that's w= rong. really unfortunately (or at least annoyingly) for timekeeping, "1970-01-01 = 00:00:00 UTC" isn't a whole number of seconds offset from TAI. UTC's ticks weren't synchronize= d to TAI ticks until 1972-01-01 00:00:10 TAI / 1972-01-01 00:00:00 UTC. so having 1970-01-01 00= :00:00 UTC as a timekeeping epoch is the wrong choice anyway. as i indicated in [0], = i think the right choice is 1970-01-01 00:00:10 TAI as the timekeeping epoch. because solar time is variable, the standardized second is useful, and it i= s useful for civil time to be in close agreement with solar time, there will need to be = leap seconds or at least periodic civil time steps. therefore, the representation of civil= /human time in something like a time_t or a struct timeval is wrong, especially for future times. t= he correct choice should represent civil/human time in something like a struct tm or ISO 8601 or som= ething. [0] https://lists.w3.org/Archives/Public/ietf-http-wg/2017JanMar/0424.html= From nobody Tue Mar 28 11:43:09 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50691292CE for ; Tue, 28 Mar 2017 11:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 ogK9SJlIQEzs for ; Tue, 28 Mar 2017 11:43:07 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A91D124BFA for ; Tue, 28 Mar 2017 11:43:07 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 271D81406B20; Tue, 28 Mar 2017 11:43:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=74x4MtdjA3qR/S wPBrqknsljGG8=; b=RSZ98gA4Ws/knuZUxvSMRMD2GyxOAhO4fKQTB9GovHlObp gWbszj7N8RtkT9UwwNm0VCIZOZTtCVRLXR/tnlqRSft73OCNB2qK6kgsI6A6fuQV ByrcYnYZWjoaCta/5N8im22hkaDT2bNbxrdVWOMFtTKQM7ikQHTMorBhpWqRE= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 063851406B0A; Tue, 28 Mar 2017 11:43:04 -0700 (PDT) Date: Tue, 28 Mar 2017 13:43:02 -0500 From: Nico Williams To: Joe Touch Cc: Tony Finch , Philip Homburg , art@ietf.org Message-ID: <20170328184301.GF7490@localhost> References: <809d2f85-0421-026b-f81d-6725e0548b6a@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <809d2f85-0421-026b-f81d-6725e0548b6a@isi.edu> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 18:43:09 -0000 On Tue, Mar 28, 2017 at 11:21:02AM -0700, Joe Touch wrote: > On 3/28/2017 8:13 AM, Tony Finch wrote: > >> - One thing I'd like to add is 'uptime' or more general, monotonic time. > > An interesting discussion re. compatible APIs for elapsed time: > > https://github.com/golang/proposal/blob/master/design/12914-monotonic.md > This is another example of the confusion that results when the time > scale is not clearly indicated or defined. Having Go read the "system > wall clock" is the source of the problem, and this doc explains a > variety of solutions. Better data types -and strong typing- are needed: - Unix-like TAI (seconds since epoch, admitting not leap seconds) - Unix-like UTC (seconds since epoch, with leap seconds) - both with variations like real versus integer, or seconds + microseconds, etc.. - broken-down time without leap seconds - broken-down time with leap seconds - formatted time (with a zone indicator to indicate whether UTC or TAI) - perhaps other forms Then there's intervals. Having variations on intervals based on whether or not they admit leaps seems silly though, so intervals are a bit easier. Nico -- From nobody Tue Mar 28 11:48:26 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7251012943B for ; Tue, 28 Mar 2017 11:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 BLstBEstzm1y for ; Tue, 28 Mar 2017 11:48:22 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 C6D531299F7 for ; Tue, 28 Mar 2017 11:48:22 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v2SIlKgk003683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Mar 2017 11:47:20 -0700 (PDT) To: Nico Williams References: <809d2f85-0421-026b-f81d-6725e0548b6a@isi.edu> <20170328184301.GF7490@localhost> Cc: Tony Finch , Philip Homburg , art@ietf.org From: Joe Touch Message-ID: <8df1b619-d2c4-9830-a02f-372afa0077b3@isi.edu> Date: Tue, 28 Mar 2017 11:47:20 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170328184301.GF7490@localhost> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 18:48:24 -0000 Hi, Nico, On 3/28/2017 11:43 AM, Nico Williams wrote: > On Tue, Mar 28, 2017 at 11:21:02AM -0700, Joe Touch wrote: >> On 3/28/2017 8:13 AM, Tony Finch wrote: >>>> - One thing I'd like to add is 'uptime' or more general, monotonic time. >>> An interesting discussion re. compatible APIs for elapsed time: >>> https://github.com/golang/proposal/blob/master/design/12914-monotonic.md >> This is another example of the confusion that results when the time >> scale is not clearly indicated or defined. Having Go read the "system >> wall clock" is the source of the problem, and this doc explains a >> variety of solutions. > Better data types -and strong typing- are needed: Unix defines only POSIX time right now, FWIW. AFAICT, wouldn't specing Unix interfaces to the different times below be out of scope for the IETF? > - Unix-like TAI (seconds since epoch, admitting not leap seconds) > - Unix-like UTC (seconds since epoch, with leap seconds) > - both with variations like real versus integer, or seconds + > microseconds, etc.. > - broken-down time without leap seconds > - broken-down time with leap seconds > - formatted time (with a zone indicator to indicate whether UTC or TAI) > - perhaps other forms > > Then there's intervals. Having variations on intervals based on whether > or not they admit leaps seems silly though, so intervals are a bit > easier. > > Nico From nobody Tue Mar 28 12:01:07 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357981297ED for ; Tue, 28 Mar 2017 12:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 wjHeLjIsSydK for ; Tue, 28 Mar 2017 12:01:04 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8466129A74 for ; Tue, 28 Mar 2017 12:00:49 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 498791406B20; Tue, 28 Mar 2017 12:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=aXvWkEWmUrFpGy MXs3jW5IBm9+g=; b=Uuj+eSm/dxf3OXHH0+ALMWqdrQEu2x/0hpq03G7TXGySod IAowjECQCUSQsItlPZPydEEE+TGTu+ixnEvN1QDrknSL9sjZO10JTn3PCTlJQyUs 5BSe1umx4ExF/wLnfs0rBGz2FKtyH6fcnhGjdamSn26Rhj0eYF07Pz1EqF3Eo= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id A6BFE1406B1A; Tue, 28 Mar 2017 12:00:48 -0700 (PDT) Date: Tue, 28 Mar 2017 14:00:46 -0500 From: Nico Williams To: Joe Touch Cc: Tony Finch , Philip Homburg , art@ietf.org Message-ID: <20170328190045.GG7490@localhost> References: <809d2f85-0421-026b-f81d-6725e0548b6a@isi.edu> <20170328184301.GF7490@localhost> <8df1b619-d2c4-9830-a02f-372afa0077b3@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8df1b619-d2c4-9830-a02f-372afa0077b3@isi.edu> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 19:01:06 -0000 On Tue, Mar 28, 2017 at 11:47:20AM -0700, Joe Touch wrote: > On 3/28/2017 11:43 AM, Nico Williams wrote: > > On Tue, Mar 28, 2017 at 11:21:02AM -0700, Joe Touch wrote: > >> On 3/28/2017 8:13 AM, Tony Finch wrote: > >>>> - One thing I'd like to add is 'uptime' or more general, monotonic time. > >>> An interesting discussion re. compatible APIs for elapsed time: > >>> https://github.com/golang/proposal/blob/master/design/12914-monotonic.md > >> This is another example of the confusion that results when the time > >> scale is not clearly indicated or defined. Having Go read the "system > >> wall clock" is the source of the problem, and this doc explains a > >> variety of solutions. > > Better data types -and strong typing- are needed: > > Unix defines only POSIX time right now, FWIW. POSIX defines POSIX time. Unix and Unix-like systems use it. (Nothing stops any Unix-like OS from including extensions.) > AFAICT, wouldn't specing Unix interfaces to the different times below be > out of scope for the IETF? Yes and no. First, the IETF has and does specify some APIs. (BSD sockets bindings for IPv6, GSS-API, and various others.) Second, the IETF could define abstract APIs but refrain from specifying C bindings for APIs and recommend to the Open Group and others that they standardize those based on the abstract APIs. (GSS-API, for example, defines both, abstract and programming-language-specific bindings.) Regardless, how could we address our time issues without specifying what amounts to.. type conversions? That's an API by whatever name you wish to call it. Best call it an API, define "types" and "type conversions" or "functions" that do the same. Obviously, for leap second smearing, besides an API there is also behavior (smearing). There's some difficulty with typing smeared time in that a smeared time would be closer to UTC than POSIX time, but *pretending to be POSIX time*. Which makes it difficult to have strong typing (which you get becomes a run-time matter!), but makes it easy to inject the new type in existing object code. But it may still be necessary to convert smeared time (when you know that's what it is) to other time forms, and there has to be a canonical, reproduceable, non-host-dependent way to do it, else you end up with a synchronization problem. Nico -- From nobody Tue Mar 28 12:08:59 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9AF129574 for ; Tue, 28 Mar 2017 12:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 UjtVYmU8CULW for ; Tue, 28 Mar 2017 12:08:49 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 C5589129486 for ; Tue, 28 Mar 2017 12:08:49 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v2SJ7cPr011346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Mar 2017 12:07:39 -0700 (PDT) To: Nico Williams References: <809d2f85-0421-026b-f81d-6725e0548b6a@isi.edu> <20170328184301.GF7490@localhost> <8df1b619-d2c4-9830-a02f-372afa0077b3@isi.edu> <20170328190045.GG7490@localhost> Cc: Tony Finch , Philip Homburg , art@ietf.org From: Joe Touch Message-ID: <7096194a-aa8d-fb5a-dc9f-51670248bb88@isi.edu> Date: Tue, 28 Mar 2017 12:07:38 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170328190045.GG7490@localhost> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 19:08:52 -0000 Hi, Nico, On 3/28/2017 12:00 PM, Nico Williams wrote: > ... >> Unix defines only POSIX time right now, FWIW. > POSIX defines POSIX time. Unix and Unix-like systems use it. > > (Nothing stops any Unix-like OS from including extensions.) Agreed. > >> AFAICT, wouldn't specing Unix interfaces to the different times below be >> out of scope for the IETF? > Yes and no. > > First, the IETF has and does specify some APIs. (BSD sockets bindings > for IPv6, GSS-API, and various others.) Only network APIs, AFAICT> > Second, the IETF could define abstract APIs but refrain from specifying > C bindings for APIs and recommend to the Open Group and others that they > standardize those based on the abstract APIs. (GSS-API, for example, > defines both, abstract and programming-language-specific bindings.) > > Regardless, how could we address our time issues without specifying what > amounts to.. type conversions? *our* time issues are mostly that we need to know the time frame being used, and to appreciate that there's no single solution that can be used to calculate intervals AND correspond to civil time that avoids the need for constantly-updated external information. No closed system is sufficient for that. > ... > > Obviously, for leap second smearing, besides an API there is also > behavior (smearing). I sincerely hope we can stop referring to this nonstandard technique. We certainly cannot even consider standardizing a conversion (even if that were our purview) between time scales that include smearing until there are smearing standards. A key point in this doc is that smearing makes things horribly worse, not better in any way, except to delude users into thinking otherwise. Joe From nobody Tue Mar 28 12:19:28 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59918129486 for ; Tue, 28 Mar 2017 12:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 r_Amag59wJ5v for ; Tue, 28 Mar 2017 12:19:19 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0301D12956C for ; Tue, 28 Mar 2017 12:19:19 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 566971406B1F; Tue, 28 Mar 2017 12:19:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=GKCr+takFV1C4b mhD0vsQdBa/fE=; b=IoF2tnGVCkw56Rup2V4lPN2HJOYrgilwOZBRsaogi5vm9T CyC7EKjqT0hyn56W3UTbYVsxocKq+dBCrNlzJOq5V1jPHxuua2oeKxZ/XPyGTRqz ync3vsvjR9pOQoqpi69qjhmUT+mBpePYt7WBk44nADRaDlml/YI6XrXN9d//o= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 96E311406B0A; Tue, 28 Mar 2017 12:19:17 -0700 (PDT) Date: Tue, 28 Mar 2017 14:19:15 -0500 From: Nico Williams To: Joe Touch Cc: Tony Finch , Philip Homburg , art@ietf.org Message-ID: <20170328191914.GI7490@localhost> References: <809d2f85-0421-026b-f81d-6725e0548b6a@isi.edu> <20170328184301.GF7490@localhost> <8df1b619-d2c4-9830-a02f-372afa0077b3@isi.edu> <20170328190045.GG7490@localhost> <7096194a-aa8d-fb5a-dc9f-51670248bb88@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7096194a-aa8d-fb5a-dc9f-51670248bb88@isi.edu> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 19:19:21 -0000 On Tue, Mar 28, 2017 at 12:07:38PM -0700, Joe Touch wrote: > On 3/28/2017 12:00 PM, Nico Williams wrote: > >> AFAICT, wouldn't specing Unix interfaces to the different times below be > >> out of scope for the IETF? > > Yes and no. > > > > First, the IETF has and does specify some APIs. (BSD sockets bindings > > for IPv6, GSS-API, and various others.) > > Only network APIs, AFAICT> Network protocols often depend on or relate to time, thus there's a nexus. > > Regardless, how could we address our time issues without specifying what > > amounts to.. type conversions? > > *our* time issues are mostly that we need to know the time frame being > used, and to appreciate that there's no single solution that can be used > to calculate intervals AND correspond to civil time that avoids the need > for constantly-updated external information. No closed system is > sufficient for that. If you can keep track of who needs time in what form... And if you can't... then what's the point of adding PIT? > > ... > > > > Obviously, for leap second smearing, besides an API there is also > > behavior (smearing). > > I sincerely hope we can stop referring to this nonstandard technique. We > certainly cannot even consider standardizing a conversion (even if that > were our purview) between time scales that include smearing until there > are smearing standards. Agreed. > A key point in this doc is that smearing makes things horribly worse, > not better in any way, except to delude users into thinking otherwise. Agreed! Nico -- From nobody Tue Mar 28 12:42:08 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B84A129A07 for ; Tue, 28 Mar 2017 12:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 fVK0U8Mzd2ku for ; Tue, 28 Mar 2017 12:42:05 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 A565E129573 for ; Tue, 28 Mar 2017 12:42:02 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v2SJfgXE020547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Mar 2017 12:41:42 -0700 (PDT) To: Nico Williams References: <809d2f85-0421-026b-f81d-6725e0548b6a@isi.edu> <20170328184301.GF7490@localhost> <8df1b619-d2c4-9830-a02f-372afa0077b3@isi.edu> <20170328190045.GG7490@localhost> <7096194a-aa8d-fb5a-dc9f-51670248bb88@isi.edu> <20170328191914.GI7490@localhost> Cc: Tony Finch , Philip Homburg , art@ietf.org From: Joe Touch Message-ID: <470f9a23-ecbb-4c87-d96d-124690f05419@isi.edu> Date: Tue, 28 Mar 2017 12:41:42 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170328191914.GI7490@localhost> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 19:42:06 -0000 On 3/28/2017 12:19 PM, Nico Williams wrote: > On Tue, Mar 28, 2017 at 12:07:38PM -0700, Joe Touch wrote: >> On 3/28/2017 12:00 PM, Nico Williams wrote: >>>> AFAICT, wouldn't specing Unix interfaces to the different times below be >>>> out of scope for the IETF? >>> Yes and no. >>> >>> First, the IETF has and does specify some APIs. (BSD sockets bindings >>> for IPv6, GSS-API, and various others.) >> Only network APIs, AFAICT> > Network protocols often depend on or relate to time, thus there's a > nexus. Mostly they depend on continuous time, which is already pointed out. > >>> Regardless, how could we address our time issues without specifying what >>> amounts to.. type conversions? >> *our* time issues are mostly that we need to know the time frame being >> used, and to appreciate that there's no single solution that can be used >> to calculate intervals AND correspond to civil time that avoids the need >> for constantly-updated external information. No closed system is >> sufficient for that. > If you can keep track of who needs time in what form... > > And if you can't... then what's the point of adding PIT? I don't think there is. Managing time across systems requires some sort of coordination, either to unify time units or entire time scales. Once you recognize that, it's sufficient to use UTC + locale. Joe From nobody Tue Mar 28 13:12:12 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4EA1294E7 for ; Tue, 28 Mar 2017 13:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no 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 KTlqejWtcqqi for ; Tue, 28 Mar 2017 13:12:09 -0700 (PDT) Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [131.111.8.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E8C51295EE for ; Tue, 28 Mar 2017 13:12:09 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:49196) by ppsw-42.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1csxTI-000mV4-8h (Exim 4.89) (return-path ); Tue, 28 Mar 2017 21:12:04 +0100 Date: Tue, 28 Mar 2017 21:12:04 +0100 From: Tony Finch To: Joe Touch cc: Philip Homburg , art@ietf.org In-Reply-To: <1cb57d13-4145-eb74-7d6a-954fe3a1059c@isi.edu> Message-ID: References: <1cb57d13-4145-eb74-7d6a-954fe3a1059c@isi.edu> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 20:12:12 -0000 Joe Touch wrote: > Section 3 states that in the definition of a solar day. Section 4.2 > explains that UT0 is one of many different "means", and that UT0 is the > most common in current use. No, UT1 is the most common form of mean solar time. (UT0 is basically mean solar time at a particular observatory; UT1 is corrected for polar motion so it is globally consistent.) > GPS isn't one of the clocks averaged into TAI (AFAICT); it's a separate > source that's sync'd to TAI to ensure the 25 ns max delta. Well, GPS is an ensemble clock (each sat has its own clock) which is steered with reference to UTC(USNO). UTC(USNO) feeds into the BIPM paper clocks. The USNO says that GPS's maximum deviation from UTC(USNO) is 1us though in practice it is within a few hundred nanoseconds. The NAV message has additional information that allows GPS receivers to get the UTC(USNO) time to within 40ns. http://www.usno.navy.mil/USNO/time/gps/usno-gps-time-transfer > > - It is not clear to me why NTP would differ 100ms from TAI. > > It's in the spec. Where in which spec? > Uptime is just a printout of the delta of the POSIX time when a computer > started and the current POSIX time. CLOCK_MONOTONIC cannot be reset, so it is more reliable than that. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Trafalgar: In southeast, variable 3 or 4. In northwest, southerly 5 to 7. In southeast, slight or moderate. in northwest, moderate or rough. In southeast, fair. In northwest, rain or showers. Good, occasionally poor. From nobody Tue Mar 28 14:40:36 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9234129637 for ; Tue, 28 Mar 2017 14:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 LOUWJf5BCtTh for ; Tue, 28 Mar 2017 14:40:33 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 6E814129535 for ; Tue, 28 Mar 2017 14:40:31 -0700 (PDT) Received: from [128.9.184.151] ([128.9.184.151]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v2SLe7we028062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Mar 2017 14:40:07 -0700 (PDT) To: Nico Williams , Stewart Bryant References: <504e2cea0d1668c31486b05fec0a967a4446aefe@webmail.weijax.net> <20170328173916.GE7490@localhost> Cc: art@ietf.org From: Joe Touch Message-ID: Date: Tue, 28 Mar 2017 14:40:07 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170328173916.GE7490@localhost> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: v2SLe7we028062 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 21:40:35 -0000 Moving this to ART... On 3/28/2017 10:39 AM, Nico Williams wrote: > On Tue, Jan 03, 2017 at 06:35:03PM +0000, Stewart Bryant wrote: >> Yes, the system should use a leap-second-free constant-duration-seconds time >> for everything. It is only humans that need the variable jumpy version of >> time presented to them, and that is a UI issue. > I don't think that's quite right. > > Unix time is canonically a count of seconds since an epoch and admits no > leap seconds. Unix time also uses a completely different definition of a "second" than UTC. There is no simple conversion between Unix time and UTC. Conversion requires accurate assessment of the local Unix clock vs SI to determine a rate conversion as well as knowing the table of leap seconds since the Unix epoch. > ... > It's all about data typing. That is certainly one problem, but not the only one. Joe From nobody Tue Mar 28 14:43:57 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32B0129686 for ; Tue, 28 Mar 2017 14:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 OHBvtOqD0C1m for ; Tue, 28 Mar 2017 14:43:54 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 3E755129A1C for ; Tue, 28 Mar 2017 14:43:51 -0700 (PDT) Received: from [128.9.184.151] ([128.9.184.151]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v2SLhVmq028643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Mar 2017 14:43:32 -0700 (PDT) To: Nico Williams , Phillip Hallam-Baker References: <20170328191654.GH7490@localhost> Cc: art@ietf.org From: Joe Touch Message-ID: Date: Tue, 28 Mar 2017 14:43:31 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170328191654.GH7490@localhost> Content-Type: multipart/alternative; boundary="------------7AD8A46539DC22E85D167285" X-MailScanner-ID: v2SLhVmq028643 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 21:43:56 -0000 This is a multi-part message in MIME format. --------------7AD8A46539DC22E85D167285 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 3/28/2017 12:16 PM, Nico Williams wrote: >> With a suitable definition, PIT could create a condition in which it would >> only take a decision by one major government to force a change on the >> astronomers. The commercial advantages of PIT over UTC are obvious - fewer >> things are going to break for no good reason. That is an argument that >> every politician is willing to listen to. > Do we have this much influence? If we do, why not just... lobby for > fixing UTC and creating an TAC (tempt astronomique coordiné) to serve, > for astronomers, the function that UTC serves today. We don't need TAC; we already have UT. IERS already broadcasts the UTC-UT1 delta. Joe --------------7AD8A46539DC22E85D167285 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 3/28/2017 12:16 PM, Nico Williams wrote:
With a suitable definition, PIT could create a condition in which it would
only take a decision by one major government to force a change on the
astronomers. The commercial advantages of PIT over UTC are obvious - fewer
things are going to break for no good reason. That is an argument that
every politician is willing to listen to.

Do we have this much influence?  If we do, why not just... lobby for
fixing UTC and creating an TAC (tempt astronomique coordiné) to serve,
for astronomers, the function that UTC serves today.
We don't need TAC; we already have UT. IERS already broadcasts the UTC-UT1 delta.

Joe
--------------7AD8A46539DC22E85D167285-- From nobody Tue Mar 28 15:40:50 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E735C12708C for ; Tue, 28 Mar 2017 15:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 HvKq1k3d9lhe for ; Tue, 28 Mar 2017 15:40:47 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 358A4126BF0 for ; Tue, 28 Mar 2017 15:40:45 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id AC2491406B20; Tue, 28 Mar 2017 15:40:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=tLdVeXGDxhSITD XaLcuNBhcTZQs=; b=sPB9tghqMhc7GkuiPYxPDm78N8wxpCR1RrjuJtIqVwu8Td q7aH/VrwIQCpPWE8gySTwEfS64lope0dtHoI/sqYi6nOTuzm6WowHwWoVKGKZkl3 0g+ijCH6k0SSYv15dhlgaTzfOfiSfsmuUoylz70myHkDRSIRBw8WWVF8NbJfE= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 576A51406B0A; Tue, 28 Mar 2017 15:40:44 -0700 (PDT) Date: Tue, 28 Mar 2017 17:40:42 -0500 From: Nico Williams To: Joe Touch Cc: Stewart Bryant , art@ietf.org Message-ID: <20170328224041.GJ7490@localhost> References: <504e2cea0d1668c31486b05fec0a967a4446aefe@webmail.weijax.net> <20170328173916.GE7490@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 22:40:49 -0000 On Tue, Mar 28, 2017 at 02:40:07PM -0700, Joe Touch wrote: > On 3/28/2017 10:39 AM, Nico Williams wrote: > > On Tue, Jan 03, 2017 at 06:35:03PM +0000, Stewart Bryant wrote: > >> Yes, the system should use a leap-second-free constant-duration-seconds time > >> for everything. It is only humans that need the variable jumpy version of > >> time presented to them, and that is a UI issue. > > I don't think that's quite right. > > > > Unix time is canonically a count of seconds since an epoch and admits no > > leap seconds. > > Unix time also uses a completely different definition of a "second" than > UTC. Did I.. say otherwise? > There is no simple conversion between Unix time and UTC. Conversion > requires accurate assessment of the local Unix clock vs SI to determine > a rate conversion as well as knowing the table of leap seconds since the > Unix epoch. You're complicating things. Forget the local clock. To convert a time_t value to UTC requires just a list of leap seconds (and some arithmetic). There's no need to assess the quality of the local clock or anything of the sort. > > ... > > It's all about data typing. > > That is certainly one problem, but not the only one. It's really the main one, IMO. In any case, smearing seems very wrong: you end up with more problems because you go from roughly two kinds of time (UTC vs TAI-ish) to three kinds of time (UTC vs TAI-ish vs the new thing). If people had a hard time interoperating with two kinds of time, imagine how it would be with THREE kinds of time. And if the smearing formula ever needs updating, then we'd be in trouble. (Earth's rotation normally _slows_ over time, but the 2004 earthquake _sped up_ Earth's rotation. A few big ones and we might need negative leap seconds. PIT's formula can't predict these events.) Just specify, in each protocol, the use of TAI (x)or UTC. Done. Nico -- From nobody Tue Mar 28 15:56:21 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F803124D68 for ; Tue, 28 Mar 2017 15:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=teamtelstra.onmicrosoft.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 Q3RTUip4IYxo for ; Tue, 28 Mar 2017 15:56:17 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DC9E124234 for ; Tue, 28 Mar 2017 15:56:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.36,238,1486386000"; d="scan'208";a="31816277" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipocni.tcif.telstra.com.au with ESMTP; 29 Mar 2017 09:56:14 +1100 X-IronPort-AV: E=McAfee;i="5800,7501,8481"; a="332857357" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcbni.tcif.telstra.com.au with ESMTP; 29 Mar 2017 09:56:14 +1100 Received: from wsapp5585.srv.dir.telstra.com (10.75.3.67) by wsmsg3704.srv.dir.telstra.com (172.49.40.197) with Microsoft SMTP Server (TLS) id 8.3.485.1; Wed, 29 Mar 2017 09:56:14 +1100 Received: from wsapp5584.srv.dir.telstra.com (10.75.131.20) by wsapp5585.srv.dir.telstra.com (10.75.3.67) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 29 Mar 2017 09:56:13 +1100 Received: from AUS01-SY3-obe.outbound.protection.outlook.com (10.172.101.126) by wsapp5584.srv.dir.telstra.com (10.75.131.20) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Wed, 29 Mar 2017 09:56:13 +1100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=teamtelstra.onmicrosoft.com; s=selector1-team-telstra-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=d3Lm8/9zC1Cl48WZFg7YsZdVXQ9ZZEaoh2v6Crz5Fr4=; b=R37gdUhMKISmbMh1pak4JJ0kG6UIR6OFj9c3l5oS1+EFC5yN4qkr+wAHnLFXUY+/21cr512TCYgR/+7RgqjV+q5BmMhzN5sIZMGWqcTgjb6nstGwWccBTGmLM1qoNzFGUqrKHj6BXttq9Xo2iv15VJ53t55pyZrl/H2nGjgy0RU= Received: from SYXPR01MB1615.ausprd01.prod.outlook.com (10.175.209.15) by SYXPR01MB1613.ausprd01.prod.outlook.com (10.175.209.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Tue, 28 Mar 2017 22:56:11 +0000 Received: from SYXPR01MB1615.ausprd01.prod.outlook.com ([10.175.209.15]) by SYXPR01MB1615.ausprd01.prod.outlook.com ([10.175.209.15]) with mapi id 15.01.0991.021; Tue, 28 Mar 2017 22:56:12 +0000 From: "Manger, James" To: "art@ietf.org" , Joe Touch , Nico Williams CC: Tony Finch , Philip Homburg Thread-Topic: [art] Predictable Internet Time Thread-Index: AQHSp8x4+eWaPRFif0Gk8+C8dDs/KqGqXDSAgAA0TwCAAAYmAIAAATMAgAADwQCAAAHrAIAANdkg Date: Tue, 28 Mar 2017 22:56:12 +0000 Message-ID: References: <809d2f85-0421-026b-f81d-6725e0548b6a@isi.edu> <20170328184301.GF7490@localhost> <8df1b619-d2c4-9830-a02f-372afa0077b3@isi.edu> <20170328190045.GG7490@localhost> <7096194a-aa8d-fb5a-dc9f-51670248bb88@isi.edu> In-Reply-To: <7096194a-aa8d-fb5a-dc9f-51670248bb88@isi.edu> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=team.telstra.com; x-originating-ip: [203.35.185.244] x-microsoft-exchange-diagnostics: 1; SYXPR01MB1613; 7:mr+zHeX5eSdw7JxtR6KruVm1q0hwprDGy5P66Jfd7LwYQyTSyHEw5E/KNSYzzFlrykRVJIfqxexZ370g6o7n7uDroTGfsGqaektAilD3FnwPeue3Yez+iamwZ3QIOoVcmCFo84gMwyBGo8glarNb4CxPWAPhW3ciTvhkdT6WwlOm3hk5BC7eZ1/4dETuqr6TFf73CcaNBjihz4bsutRpdz8qZQIPzOQYxLgiAz3oIA/bIyXBID1eJ5DQJgiUuog65arTSO08QxtnM61p3C/JYPGqo6dr+MdyY0CiMTuiUHgE7JvqUEiHrA9oU1c+rBL7cUv3GGKEmlzFowG+AujVKA==; 20:pAEnfzS8zpQkA7vdnP8uGw9362WlcOrj3bAHagcA0IfxKFE7EpnsHCuoPVOpMxORZVKAy2PVTuKT+Lidy7fG1Y6G5E6H0UdZ94CpQO1YloZ+rCQPtiXCHaevD0u9cvxsERX8DU7CZ3jd52E7G+lq3c3BviC3Cl8/l0EPkbp3QJgNrKMPmBLj5dqPiOG5SPEbQIrjERbdXOE5GrQssTTcUqzDPs44RYBOTr+h+OMQflgv3OWAIocDUs/KDCnlTr04TUJ5xRsj+U+cKxgzUc4HfQVtCca/uvr+/ixax5aOnlWcbAi02OThUg0lKgZ6ME1n74nwzqZKHsc0Bbi0Gu+ePEbFIehemRG6ekOpgdDyrDH7h4NgS3GMyJmrfDROb8HHFcKBJPdAa47v+7pNIcqog5P4V9dNnsrYL2Vanc7B5u9QOtTP7R+EuBdy4e7A2bUrD2C4FqpsgLRoNVhD4bBl95dW3zmC896D2SlWt35grizlnp8uLWk+gVlFXo1DPAgA x-ms-office365-filtering-correlation-id: de00051f-585d-4b6e-9205-08d4762da19b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423067)(201703031133073); SRVR:SYXPR01MB1613; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040442)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123564025)(20161123560025)(201703131423067)(201702281528067)(201703061421067)(201703061406067)(20161123558025)(20161123555025)(6072148); SRVR:SYXPR01MB1613; BCL:0; PCL:0; RULEID:; SRVR:SYXPR01MB1613; x-forefront-prvs: 0260457E99 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39410400002)(39850400002)(39400400002)(39840400002)(6436002)(5660300001)(189998001)(6506006)(33656002)(38730400002)(4326008)(229853002)(6246003)(3846002)(6116002)(2950100002)(42882006)(7696004)(102836003)(54356999)(25786009)(7736002)(76176999)(50986999)(77096006)(122556002)(2900100001)(305945005)(74316002)(53936002)(9686003)(8676002)(2501003)(3660700001)(93886004)(66066001)(2906002)(8936002)(86362001)(3280700002)(99286003)(55016002)(54906002); DIR:OUT; SFP:1102; SCL:1; SRVR:SYXPR01MB1613; H:SYXPR01MB1615.ausprd01.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2017 22:56:12.2194 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYXPR01MB1613 X-OriginatorOrg: team.telstra.com Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 22:56:19 -0000 >> leap second smearing > We certainly cannot even consider standardizing a conversion (even if tha= t > were our purview) between time scales that include smearing until there > are smearing standards. It looks like the most valuable IETF contribution would be standardizing on= e smearing scheme (& getting Google, Java, ... to agree to it). > A key point in this doc is that smearing makes things horribly worse, > not better in any way, except to delude users into thinking otherwise. Given that a well-defined smearing scheme allows a simple and precise mappi= ng to UTC, it is hard to see how that can be "horribly worse". Smearing moves the complexity of solar-vs-atomic-vs-civic time and the resu= ltant leap seconds to a place where a huge number of systems can correctly = handle that complexity by "doing nothing", while systems that care if time = intervals can be 0.001% wrong (if 24hr is the smear standard) can still be = more precise by making well-defined adjustments. -- James Manger From nobody Tue Mar 28 16:03:04 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5456412773A for ; Tue, 28 Mar 2017 16:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 9oDj6b4LsH-v for ; Tue, 28 Mar 2017 16:03:01 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 DEFB41271DF for ; Tue, 28 Mar 2017 16:03:00 -0700 (PDT) Received: from [128.9.184.151] ([128.9.184.151]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v2SN2khD014396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Mar 2017 16:02:46 -0700 (PDT) To: Nico Williams References: <504e2cea0d1668c31486b05fec0a967a4446aefe@webmail.weijax.net> <20170328173916.GE7490@localhost> <20170328224041.GJ7490@localhost> Cc: Stewart Bryant , art@ietf.org From: Joe Touch Message-ID: <9ddcde60-a915-a03d-dfc3-2c2c451c398c@isi.edu> Date: Tue, 28 Mar 2017 16:02:46 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170328224041.GJ7490@localhost> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: v2SN2khD014396 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 23:03:02 -0000 On 3/28/2017 3:40 PM, Nico Williams wrote: > On Tue, Mar 28, 2017 at 02:40:07PM -0700, Joe Touch wrote: >> On 3/28/2017 10:39 AM, Nico Williams wrote: >>> On Tue, Jan 03, 2017 at 06:35:03PM +0000, Stewart Bryant wrote: >>>> Yes, the system should use a leap-second-free constant-duration-seconds time >>>> for everything. It is only humans that need the variable jumpy version of >>>> time presented to them, and that is a UI issue. >>> I don't think that's quite right. >>> >>> Unix time is canonically a count of seconds since an epoch and admits no >>> leap seconds. >> Unix time also uses a completely different definition of a "second" than >> UTC. > Did I.. say otherwise? Yes, below.... > >> There is no simple conversion between Unix time and UTC. Conversion >> requires accurate assessment of the local Unix clock vs SI to determine >> a rate conversion as well as knowing the table of leap seconds since the >> Unix epoch. > You're complicating things. Forget the local clock. To convert a time_t > value to UTC requires just a list of leap seconds (and some arithmetic). time_t does not access a SI reference or frankly any other stable reference. If you don't have a stable time unit, accurate conversion isn't possible. If you do have a stable time unit, you need the ratio of that time unit to SI. > There's no need to assess the quality of the local clock or anything of > the sort. > >>> ... >>> It's all about data typing. >> That is certainly one problem, but not the only one. > It's really the main one, IMO. In any case, smearing seems very wrong: > you end up with more problems because you go from roughly two kinds of > time (UTC vs TAI-ish) to three kinds of time (UTC vs TAI-ish vs the new > thing). If people had a hard time interoperating with two kinds of > time, imagine how it would be with THREE kinds of time. And if the > smearing formula ever needs updating, then we'd be in trouble. (Earth's > rotation normally _slows_ over time, but the 2004 earthquake _sped up_ > Earth's rotation. A few big ones and we might need negative leap > seconds. PIT's formula can't predict these events.) > > Just specify, in each protocol, the use of TAI (x)or UTC. Done. I agree. Joe From nobody Tue Mar 28 16:11:45 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3AF71294E0 for ; Tue, 28 Mar 2017 16:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 oYwACm8FHfzB for ; Tue, 28 Mar 2017 16:11:43 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 3AE4A126D05 for ; Tue, 28 Mar 2017 16:11:43 -0700 (PDT) Received: from [128.9.184.151] ([128.9.184.151]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v2SNBR4a016066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Mar 2017 16:11:27 -0700 (PDT) To: "Manger, James" , "art@ietf.org" , Nico Williams References: <809d2f85-0421-026b-f81d-6725e0548b6a@isi.edu> <20170328184301.GF7490@localhost> <8df1b619-d2c4-9830-a02f-372afa0077b3@isi.edu> <20170328190045.GG7490@localhost> <7096194a-aa8d-fb5a-dc9f-51670248bb88@isi.edu> Cc: Tony Finch , Philip Homburg From: Joe Touch Message-ID: <38391306-8da7-b29c-45f8-517a2f207965@isi.edu> Date: Tue, 28 Mar 2017 16:11:27 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: v2SNBR4a016066 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 23:11:45 -0000 On 3/28/2017 3:56 PM, Manger, James wrote: >>> leap second smearing >> We certainly cannot even consider standardizing a conversion (even if that >> were our purview) between time scales that include smearing until there >> are smearing standards. > It looks like the most valuable IETF contribution would be standardizing one smearing scheme (& getting Google, Java, ... to agree to it). Ick. IMO, the most valuable contribution is to recommend the use of TAI or UTC, IMO. > >> A key point in this doc is that smearing makes things horribly worse, >> not better in any way, except to delude users into thinking otherwise. > Given that a well-defined smearing scheme allows a simple and precise mapping to UTC, it is hard to see how that can be "horribly worse". Even if we say that all interval calculations and conversions are equally messy or not, why introduce yet another standard when we already have TAI and UTC? > Smearing moves the complexity of solar-vs-atomic-vs-civic time and the resultant leap seconds to a place where a huge number of systems can correctly handle that complexity by "doing nothing", while systems that care if time intervals can be 0.001% wrong (if 24hr is the smear standard) can still be more precise by making well-defined adjustments. Doing nothing means smeared times are always wrong. When that smeared time corresponds to a day or year change in another time zone, you've really messed things up. That means doing nothing either means your wrong or you're really wrong. The only solution is to convert out of the smear back to UTC, but then why bother smearing at all? Joe From nobody Tue Mar 28 17:06:12 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCCB126E3A for ; Tue, 28 Mar 2017 17:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 jSqQA9QuM01s for ; Tue, 28 Mar 2017 17:06:08 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 719F2128B44 for ; Tue, 28 Mar 2017 17:06:06 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 615E01406B1F; Tue, 28 Mar 2017 17:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=ms+p0gHO3zxNHw 1PpZeL+K3kp2I=; b=ihLQEOXOSY8Z0bA7mLPGJuw8NLGyWNoOiH9EHfdlQ4DiFR 0qtl8BGAVmvjMGeRI9llK5GwiEiqnYfEW+c7kFvvL+Musfg25VOwUz6xDMgddwUQ iALt7cwpX+o9Z7LHpaaSJJwVmhkOJInLK8Amoj/RGE/zRDcMon5qhqgRY60ek= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id C05FB1406B21; Tue, 28 Mar 2017 17:06:04 -0700 (PDT) Date: Tue, 28 Mar 2017 19:06:02 -0500 From: Nico Williams To: Joe Touch Cc: Stewart Bryant , art@ietf.org Message-ID: <20170329000601.GK7490@localhost> References: <504e2cea0d1668c31486b05fec0a967a4446aefe@webmail.weijax.net> <20170328173916.GE7490@localhost> <20170328224041.GJ7490@localhost> <9ddcde60-a915-a03d-dfc3-2c2c451c398c@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9ddcde60-a915-a03d-dfc3-2c2c451c398c@isi.edu> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 00:06:11 -0000 On Tue, Mar 28, 2017 at 04:02:46PM -0700, Joe Touch wrote: > On 3/28/2017 3:40 PM, Nico Williams wrote: > > Did I.. say otherwise? > Yes, below.... You're picking non-nits. > >> There is no simple conversion between Unix time and UTC. Conversion > >> requires accurate assessment of the local Unix clock vs SI to determine > >> a rate conversion as well as knowing the table of leap seconds since the > >> Unix epoch. > > You're complicating things. Forget the local clock. To convert a time_t > > value to UTC requires just a list of leap seconds (and some arithmetic). > > time_t does not access a SI reference or frankly any other stable reference. The Open Group man pages I'm looking at don't reference SI, but so bloody what. If it says "seconds", it means "seconds". > If you don't have a stable time unit, accurate conversion isn't possible. Sure, but POSIX time clearly uses the only definition of seconds that matters. Also, time is relative. These seconds are seconds at mean sea level on Earth, but they might vary nonetheless. At some point precision is not so interesting, but knowing 1490745768 is 2017-03-29T00:02:48Z, that's kinda important, and that will be true in any local frame of reference, even in space, far from Earth, and under large accelerations. Sure, two such observers won't agree as to current time because of relativistic effects, but they will agree that 1490745768 is 2017-03-29T00:02:48Z. > If you do have a stable time unit, you need the ratio of that time unit > to SI. It's very safe to assume it's 1. Anything else would be insane. > > It's really the main one, IMO. In any case, smearing seems very wrong: > > you end up with more problems because you go from roughly two kinds of > > time (UTC vs TAI-ish) to three kinds of time (UTC vs TAI-ish vs the new > > thing). If people had a hard time interoperating with two kinds of > > time, imagine how it would be with THREE kinds of time. And if the > > smearing formula ever needs updating, then we'd be in trouble. (Earth's > > rotation normally _slows_ over time, but the 2004 earthquake _sped up_ > > Earth's rotation. A few big ones and we might need negative leap > > seconds. PIT's formula can't predict these events.) > > > > Just specify, in each protocol, the use of TAI (x)or UTC. Done. > > I agree. Isn't that the important bit of information here? Nico -- From nobody Tue Mar 28 17:16:28 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94FD4127871 for ; Tue, 28 Mar 2017 17:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 qZjPSBpN8uGn for ; Tue, 28 Mar 2017 17:16:26 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 ED487126BFD for ; Tue, 28 Mar 2017 17:16:25 -0700 (PDT) Received: from [128.9.184.151] ([128.9.184.151]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v2T0FwrE027194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Mar 2017 17:15:59 -0700 (PDT) To: Nico Williams References: <504e2cea0d1668c31486b05fec0a967a4446aefe@webmail.weijax.net> <20170328173916.GE7490@localhost> <20170328224041.GJ7490@localhost> <9ddcde60-a915-a03d-dfc3-2c2c451c398c@isi.edu> <20170329000601.GK7490@localhost> Cc: Stewart Bryant , art@ietf.org From: Joe Touch Message-ID: <96ad09b7-7dc2-20e8-2aa4-793310d184f6@isi.edu> Date: Tue, 28 Mar 2017 17:15:58 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170329000601.GK7490@localhost> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: v2T0FwrE027194 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 00:16:27 -0000 On 3/28/2017 5:06 PM, Nico Williams wrote: > ... >> time_t does not access a SI reference or frankly any other stable reference. > The Open Group man pages I'm looking at don't reference SI, but so > bloody what. If it says "seconds", it means "seconds". That's the trouble - seconds in SI are not seconds defined as 86400/day. If the units don't match, then a conversion needs to be included. If the units aren't known, you can't convert accurately. > >> If you don't have a stable time unit, accurate conversion isn't possible. > Sure, but POSIX time clearly uses the only definition of seconds that > matters. > > Also, time is relative. These seconds are seconds at mean sea level on > Earth, but they might vary nonetheless. At some point precision is not > so interesting, but knowing 1490745768 is 2017-03-29T00:02:48Z, that's > kinda important, and that will be true in any local frame of reference, > even in space, far from Earth, and under large accelerations. Sure, two > such observers won't agree as to current time because of relativistic > effects, but they will agree that 1490745768 is 2017-03-29T00:02:48Z. 2017 is 1.4e9 seconds after the Unix epoch. If the Unix and SI "seconds" unit is off by one part in a (US) billion, then you're off by 1.5 seconds. > >> If you do have a stable time unit, you need the ratio of that time unit >> to SI. > It's very safe to assume it's 1. Anything else would be insane. s/insane/undefined/ That's the problem. I appreciate it would be nice if there were a definition (as a start), and if the defined unit were SI, but it isn't, AFAICT. If you have a ref to the contrary, I'd be more than glad to include it and correct the doc accordingly. > >>> It's really the main one, IMO. In any case, smearing seems very wrong: >>> you end up with more problems because you go from roughly two kinds of >>> time (UTC vs TAI-ish) to three kinds of time (UTC vs TAI-ish vs the new >>> thing). If people had a hard time interoperating with two kinds of >>> time, imagine how it would be with THREE kinds of time. And if the >>> smearing formula ever needs updating, then we'd be in trouble. (Earth's >>> rotation normally _slows_ over time, but the 2004 earthquake _sped up_ >>> Earth's rotation. A few big ones and we might need negative leap >>> seconds. PIT's formula can't predict these events.) >>> >>> Just specify, in each protocol, the use of TAI (x)or UTC. Done. >> I agree. > Isn't that the important bit of information here? To you and me, perhaps, but there are others on this thread that are misled by what POSIX is and how easy/hard it is to convert to TAI/UTC... Joe From nobody Tue Mar 28 18:58:21 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921D91295B3 for ; Tue, 28 Mar 2017 18:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 t8Bpc-AZedXr for ; Tue, 28 Mar 2017 18:58:17 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4DCE1273B1 for ; Tue, 28 Mar 2017 18:58:16 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 22F8F1406B1A; Tue, 28 Mar 2017 18:58:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=IkiJEAOjOyYoBg idm9ND9+ibnec=; b=TPDiZimvt/cdxgywQBqQ5iB55wNqSnkL+3OcdgKTMDcR6U wdQqWlol54SJGs/GhVoG5ypBcue9kfpFf5QK1e19Urk4P4CCtCR6Z6WnxOG9l90J 0RkTqTuGk4Y5hNyQs866wDbBRFun3CWPe+mBwDZpFTsiCx9qMuEqMxLwHqKTg= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id D40401406B0A; Tue, 28 Mar 2017 18:58:14 -0700 (PDT) Date: Tue, 28 Mar 2017 20:58:12 -0500 From: Nico Williams To: Joe Touch Cc: art@ietf.org Message-ID: <20170329015811.GL7490@localhost> References: <20170328173916.GE7490@localhost> <20170328224041.GJ7490@localhost> <9ddcde60-a915-a03d-dfc3-2c2c451c398c@isi.edu> <20170329000601.GK7490@localhost> <96ad09b7-7dc2-20e8-2aa4-793310d184f6@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <96ad09b7-7dc2-20e8-2aa4-793310d184f6@isi.edu> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 01:58:20 -0000 On Tue, Mar 28, 2017 at 05:15:58PM -0700, Joe Touch wrote: > >> time_t does not access a SI reference or frankly any other stable reference. > > The Open Group man pages I'm looking at don't reference SI, but so > > bloody what. If it says "seconds", it means "seconds". > That's the trouble - seconds in SI are not seconds defined as 86400/day. > If the units don't match, then a conversion needs to be included. If > the units aren't known, you can't convert accurately. POSIX does NOT define seconds in terms of days! It does the opposite: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16 How any changes to the value of seconds since the Epoch are made to align to a desired relationship with the current actual time is implementation-defined. As represented in seconds since the Epoch, each and every day shall be accounted for by exactly 86400 seconds. There is NO reference to solar or sidereal days or any other astronomical definition of day. Unlike as with days, there is no multiplicity of generally accepted definitions of seconds, so there is no support for the idea that this text defines seconds in terms of days. The second sentence defines days in terms of seconds, not the other way around. The first sentence is a bit abstruse, but no matter, because in _practice_ on all systems I know of that claim to implement POSIX, or which don't but which are Unix or Unix-like systems, seconds since the epoch differs from UTC *only* by leap seconds -- just like TAI. Also, POSIX does refer to UTC: A value that approximates the number of seconds that have elapsed since the Epoch. A Coordinated Universal Time name (specified in terms of seconds (tm_sec), minutes (tm_min), hours (tm_hour), days since January 1 of the year (tm_yday), and calendar year minus 1900 (tm_year)) is related to a time represented as seconds since the Epoch, according to the expression below. But as others have pointed out, that is either a lie or an error: POSIX simply does not and cannot account for leap seconds in a numeric type representing seconds since an epoch. Perhaps we can say that the reference to UTC was meant to be to TAI. Either way the definition of seconds can only plausibly be SI. The text is sufficiently ambiguous (because of its errors, for example) that you could remotely plausibly make these claims that you do, but practice does not bear them out. > > It's very safe to assume it's 1. Anything else would be insane. > > s/insane/undefined/ > > That's the problem. I appreciate it would be nice if there were a > definition (as a start), and if the defined unit were SI, but it isn't, > AFAICT. If you have a ref to the contrary, I'd be more than glad to > include it and correct the doc accordingly. POSIX seconds are not defined, indeed, but they can only be taken to be SI seconds -- anything else would be sheer madness and, anyways, not supported by actual practice. I know of no POSIX or POSIX-ish system where this is not true. Running code, _running code_. > > Isn't that the important bit of information here? > > To you and me, perhaps, but there are others on this thread that are > misled by what POSIX is and how easy/hard it is to convert to TAI/UTC... Maybe, but so are you. Not that that is particularly important to making a successful argument against smearing, but that such errors are distracting. The obvious argument against smeared time is that we already have _two_ time standards, and we don't need a third. All we need is to carefully pick one or the other in each specification, and preferably TAI time in all cases. Nico -- From nobody Tue Mar 28 19:58:34 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1CB7128896 for ; Tue, 28 Mar 2017 19:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 afTwdymXscYH for ; Tue, 28 Mar 2017 19:58:32 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B5A6127F0E for ; Tue, 28 Mar 2017 19:58:32 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 684AC1406B1A; Tue, 28 Mar 2017 19:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=zK3RkTBaSK/Q+L 2CLEcUNqJ+Hdw=; b=mXkckAFzHOTDee+h31LP1Tj8Z59KK5LGZ974Z2Xh9ylPMO 59bXu4sGB1k/arNIAHzHEzb6CQh69LYC2uBAnvEGSkeunnaFqHulgXib/HSrQH0H 4smVUVmmymwsNsoPAeheVDO9O0uehT5/Tb1LWethIqI4BQqDd5cggSRa4PXWc= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 9AEED1406B0A; Tue, 28 Mar 2017 19:58:15 -0700 (PDT) Date: Tue, 28 Mar 2017 21:58:13 -0500 From: Nico Williams To: Joe Touch Cc: art@ietf.org Message-ID: <20170329025808.GM7490@localhost> References: <20170328173916.GE7490@localhost> <20170328224041.GJ7490@localhost> <9ddcde60-a915-a03d-dfc3-2c2c451c398c@isi.edu> <20170329000601.GK7490@localhost> <96ad09b7-7dc2-20e8-2aa4-793310d184f6@isi.edu> <20170329015811.GL7490@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170329015811.GL7490@localhost> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 02:58:34 -0000 On Tue, Mar 28, 2017 at 08:58:12PM -0500, Nico Williams wrote: > On Tue, Mar 28, 2017 at 05:15:58PM -0700, Joe Touch wrote: > > >> time_t does not access a SI reference or frankly any other stable reference. > > > The Open Group man pages I'm looking at don't reference SI, but so > > > bloody what. If it says "seconds", it means "seconds". > > That's the trouble - seconds in SI are not seconds defined as 86400/day. > > If the units don't match, then a conversion needs to be included. If > > the units aren't known, you can't convert accurately. > > POSIX does NOT define seconds in terms of days! It does the opposite: Although I can see how to waterboard the spec to get either answer. If it were right about POSIX time being UTC (which it's not in practice), then you'd be quite right about it defining seconds in terms of days... Would that make POSIX a smeared time standard? Sure seems that way! From nobody Wed Mar 29 04:36:55 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F621296A6 for ; Wed, 29 Mar 2017 04:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 kPVF4LB11ZMe for ; Wed, 29 Mar 2017 04:36:52 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 7507C1296A4 for ; Wed, 29 Mar 2017 04:36:51 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1ctBuE-0000G3C; Wed, 29 Mar 2017 13:36:50 +0200 Message-Id: To: art@ietf.org From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <1cb57d13-4145-eb74-7d6a-954fe3a1059c@isi.edu> In-reply-to: Your message of "Tue, 28 Mar 2017 11:11:59 -0700 ." <1cb57d13-4145-eb74-7d6a-954fe3a1059c@isi.edu> Date: Wed, 29 Mar 2017 13:36:49 +0200 Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 11:36:55 -0000 [Just responding to text in many different e-mails] >> actual solar time is extremely rare (only sundials). Solar time is almost >> always mean solar time. I.e UT0 is already mean solar time. >Section 3 states that in the definition of a solar day. Section 4.2 >explains that UT0 is one of many different "means", and that UT0 is the >most common in current use. Very confusing to have two completely different definitions of Solar day in one item. Later you use solar time sometimes as mean, sometimes as 'apparent'. >> This makes a statement that GPS time differs 25 ns from TAI a bit weird. >> Maybe this is too much detail. > >See above - even in retrospect, GPS can differ from TAI by 25 ns (it's >in the spec for GPS). GPS isn't one of the clocks averaged into TAI >(AFAICT); it's a separate source that's sync'd to TAI to ensure the 25 >ns max delta. Given the complexities of dealing with time at the nanosecond level, maybe it is better to ignore those issues in this document. I.e, GPS and Galilelo are synced to TAI (with some fixed offset). GLONASS tracks UTC. And leave it at that. >> - It is not clear to me why NTP would differ 100ms from TAI. >It's in the spec. Can you be more specific. >> - It is not clear to me what 'Unix time' is in this context. Typically POSIX >> time is linked to UTC, > >That is incorrect. POSIX time is defined as 1/86400 of a day, which does >not take into account leap seconds at all (UTC does) and "day" is not >defined as related to SI units (UTC is). AFAICT, a POSIX "day" is at >best a rough approximation of UT0. I was going to propose that for this document we treat POSIX time as NTP time minus 2208988800. Unfortunately, the latest NTP RFC (5905) doesn't seem to actually define NTP time. So that doesn't help. >But as others have pointed out, that is either a lie or an error: POSIX >simply does not and cannot account for leap seconds in a numeric type >representing seconds since an epoch. Perhaps we can say that the >reference to UTC was meant to be to TAI. Either way the definition of >seconds can only plausibly be SI. The way I read it, the following formula tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400 converts between a time_t value and a broken down UTC time. Just about every piece of software assume this to be true. I.e, if you run ls then the times shown by ls are based on this formula. Of course this implies that time_t is horribly broken in many different ways, but we already know that. So if you subtract two time_t values, you don't get the real number of seconds between the two points of time they represent because leapseconds are ignored. If tm_sec == 60, i.e. during a leap second, you get the same time_t value as the first second of the next minute. >> - One thing I'd like to add is 'uptime' or more general, monotonic time. > >Uptime is just a printout of the delta of the POSIX time when a computer >started and the current POSIX time. > >It might be useful to indicate that some computers just start their >clocks at boot as zero. The main thing is that monotonic time can never go backward. Ntpd will hapily step the (POSIX) time backwards. So you need a separate clock, which POSIX calls CLOCK_MONOTONIC (see clock_settime). >I can add a new "monotonic clock" definition that uses an arbitrary >"tick" that is guaranteed to increase between reads and across reboots, >but is not comparable across machines. Note that monotonic time is typically not maintained across reboots. >Better data types -and strong typing- are needed: > > - Unix-like TAI (seconds since epoch, admitting not leap seconds) If we can get the opengroup to add CLOCK_TAI then we can have this. One problem is that there doesn't seem to be a sensible epoch for TAI. > - Unix-like UTC (seconds since epoch, with leap seconds) > - both with variations like real versus integer, or seconds + > microseconds, etc.. I'd like to treat time_t as something that is synchronized with UTC and behaves rather weird around a leap second. > - broken-down time without leap seconds Not sure why that would be desirable, but that's what have now. > - broken-down time with leap seconds A 'tai_gmtime' could do that. >Then there's intervals. Having variations on intervals based on whether >or not they admit leaps seems silly though, so intervals are a bit >easier. If you want to set a timer based on an interval, then it may make sense to know if leap seconds need to be counted or not. >The obvious argument against smeared time is that we already have _two_ >time standards, and we don't need a third. All we need is to carefully >pick one or the other in each specification, and preferably TAI time in >all cases. There is (right now) no meaningful way to convert 2020-01-01 00:00:00 UTC to a TAI time value. From nobody Wed Mar 29 07:35:48 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A7B1242EA for ; Wed, 29 Mar 2017 07:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 LJooWk7V4M2d for ; Wed, 29 Mar 2017 07:35:45 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 0B153124D37 for ; Wed, 29 Mar 2017 07:35:44 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v2TEZ7Jv015474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Mar 2017 07:35:08 -0700 (PDT) To: Nico Williams References: <20170328173916.GE7490@localhost> <20170328224041.GJ7490@localhost> <9ddcde60-a915-a03d-dfc3-2c2c451c398c@isi.edu> <20170329000601.GK7490@localhost> <96ad09b7-7dc2-20e8-2aa4-793310d184f6@isi.edu> <20170329015811.GL7490@localhost> Cc: art@ietf.org From: Joe Touch Message-ID: <111c86bc-c2c5-5050-edc0-82e40d36c570@isi.edu> Date: Wed, 29 Mar 2017 07:35:06 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170329015811.GL7490@localhost> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 14:35:47 -0000 Hi, Nico, On 3/28/2017 6:58 PM, Nico Williams wrote: > On Tue, Mar 28, 2017 at 05:15:58PM -0700, Joe Touch wrote: >>>> time_t does not access a SI reference or frankly any other stable reference. >>> The Open Group man pages I'm looking at don't reference SI, but so >>> bloody what. If it says "seconds", it means "seconds". >> That's the trouble - seconds in SI are not seconds defined as 86400/day. >> If the units don't match, then a conversion needs to be included. If >> the units aren't known, you can't convert accurately. > POSIX does NOT define seconds in terms of days! It does the opposite: > > http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16 > > How any changes to the value of seconds since the Epoch are made to > align to a desired relationship with the current actual time is > implementation-defined. As represented in seconds since the Epoch, > each and every day shall be accounted for by exactly 86400 seconds. > > There is NO reference to solar or sidereal days or any other > astronomical definition of day. OK - we agree that it defines "day" = 86400 "seconds". It should be clear that it also never defines either "day" or "seconds". "Seconds" can't be SI units unless there's a tiny cesium clock inside my PC. "day" can't be apparent or mean solar time because it doesn't have a sextant either. > Unlike as with days, there is no multiplicity of generally accepted > definitions of seconds, so there is no support for the idea that this > text defines seconds in terms of days. > > The second sentence defines days in terms of seconds, not the other way > around. > > The first sentence is a bit abstruse, but no matter, because in > _practice_ on all systems I know of that claim to implement POSIX, or > which don't but which are Unix or Unix-like systems, seconds since the > epoch differs from UTC *only* by leap seconds -- just like TAI. The text only states that the POSIX clock *started* with a known offset to TAI and that the POSIX clock won't jump with leap seconds. It never states anything else... > ... > POSIX seconds are not defined, indeed, but they can only be taken to be > SI seconds -- anything else would be sheer madness and, anyways, not > supported by actual practice. I know of no POSIX or POSIX-ish system > where this is not true. I know of no POSIX system with a cesium atomic clock. The issue is that POSIX really runs off of whatever local source of time passage is available, and can (and does) drift from TAI on *each* system. That drift can't be determined until your system tries to sync with an external source (e.g., via NTP). Joe From nobody Wed Mar 29 07:36:47 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983941242EA for ; Wed, 29 Mar 2017 07:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 B58var9dlcPA for ; Wed, 29 Mar 2017 07:36:45 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 4A9F2124D37 for ; Wed, 29 Mar 2017 07:36:45 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v2TEa091015639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Mar 2017 07:36:01 -0700 (PDT) To: Nico Williams References: <20170328173916.GE7490@localhost> <20170328224041.GJ7490@localhost> <9ddcde60-a915-a03d-dfc3-2c2c451c398c@isi.edu> <20170329000601.GK7490@localhost> <96ad09b7-7dc2-20e8-2aa4-793310d184f6@isi.edu> <20170329015811.GL7490@localhost> <20170329025808.GM7490@localhost> Cc: art@ietf.org From: Joe Touch Message-ID: <9440a2e3-3415-335f-10b0-ae7d5f42f1a9@isi.edu> Date: Wed, 29 Mar 2017 07:35:59 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170329025808.GM7490@localhost> Content-Type: multipart/alternative; boundary="------------D5B2CE16C54F2026B4170BA8" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 14:36:47 -0000 This is a multi-part message in MIME format. --------------D5B2CE16C54F2026B4170BA8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 3/28/2017 7:58 PM, Nico Williams wrote: >> POSIX does NOT define seconds in terms of days! It does the opposite: > Although I can see how to waterboard the spec to get either answer. If > it were right about POSIX time being UTC (which it's not in practice), > then you'd be quite right about it defining seconds in terms of days... > > Would that make POSIX a smeared time standard? Sure seems that way! POSIX never claims that its "days" sync to UTC, UT, or TAI days. As such, there's no smearing assumed. Joe --------------D5B2CE16C54F2026B4170BA8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit



On 3/28/2017 7:58 PM, Nico Williams wrote:
POSIX does NOT define seconds in terms of days!  It does the opposite:

Although I can see how to waterboard the spec to get either answer.  If
it were right about POSIX time being UTC (which it's not in practice),
then you'd be quite right about it defining seconds in terms of days...

Would that make POSIX a smeared time standard?  Sure seems that way!
POSIX never claims that its "days" sync to UTC, UT, or TAI days. As such, there's no smearing assumed.

Joe
--------------D5B2CE16C54F2026B4170BA8-- From nobody Wed Mar 29 07:53:07 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7424128656 for ; Wed, 29 Mar 2017 07:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 f-zgC6HHCxrq for ; Wed, 29 Mar 2017 07:53:04 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id AFF37129474 for ; Wed, 29 Mar 2017 07:53:03 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1ctEy7-0000G9C; Wed, 29 Mar 2017 16:53:03 +0200 Message-Id: To: art@ietf.org Cc: Joe Touch From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <20170328173916.GE7490@localhost> <20170328224041.GJ7490@localhost> <9ddcde60-a915-a03d-dfc3-2c2c451c398c@isi.edu> <20170329000601.GK7490@localhost> <96ad09b7-7dc2-20e8-2aa4-793310d184f6@isi.edu> <20170329015811.GL7490@localhost> <111c86bc-c2c5-5050-edc0-82e40d36c570@isi.edu> In-reply-to: Your message of "Wed, 29 Mar 2017 07:35:06 -0700 ." <111c86bc-c2c5-5050-edc0-82e40d36c570@isi.edu> Date: Wed, 29 Mar 2017 16:53:01 +0200 Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 14:53:06 -0000 >I know of no POSIX system with a cesium atomic clock. > >The issue is that POSIX really runs off of whatever local source of time >passage is available, and can (and does) drift from TAI on *each* >system. That drift can't be determined until your system tries to sync >with an external source (e.g., via NTP). To be completely pedantic, a single cesium clock will also drift from TAI/UTC. There is no such concept as being in sync with TAI without external corrections. To be even more pedantic, of course that depends on the desired accuracy. A cesium clock could easily stay within one hour from TAI for a period of a 100 years. A random PC with a quarz crystal at room temperature would have a hard time doing that. From nobody Wed Mar 29 07:57:47 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970D2129435 for ; Wed, 29 Mar 2017 07:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 cmxEvfSwKASX for ; Wed, 29 Mar 2017 07:57:45 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 32C2A1287A5 for ; Wed, 29 Mar 2017 07:57:45 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v2TEvVkU019042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Mar 2017 07:57:33 -0700 (PDT) To: Philip Homburg , art@ietf.org References: <20170328173916.GE7490@localhost> <20170328224041.GJ7490@localhost> <9ddcde60-a915-a03d-dfc3-2c2c451c398c@isi.edu> <20170329000601.GK7490@localhost> <96ad09b7-7dc2-20e8-2aa4-793310d184f6@isi.edu> <20170329015811.GL7490@localhost> <111c86bc-c2c5-5050-edc0-82e40d36c570@isi.edu> From: Joe Touch Message-ID: <70bae467-8636-379c-7452-21cacf03215f@isi.edu> Date: Wed, 29 Mar 2017 07:57:30 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 14:57:47 -0000 On 3/29/2017 7:53 AM, Philip Homburg wrote: >> I know of no POSIX system with a cesium atomic clock. >> >> The issue is that POSIX really runs off of whatever local source of time >> passage is available, and can (and does) drift from TAI on *each* >> system. That drift can't be determined until your system tries to sync >> with an external source (e.g., via NTP). > To be completely pedantic, a single cesium clock will also drift from TAI/UTC. > > There is no such concept as being in sync with TAI without external > corrections. Yes - I got email off-list about this and need to update the doc to remind us that TAI is actually determined post-facto, though its current value is approximated. > To be even more pedantic, of course that depends on the desired accuracy. > A cesium clock could easily stay within one hour from TAI for a period of a 100 > years. A random PC with a quarz crystal at room temperature would have a hard > time doing that. Right - I will update the doc accordingly. AFAICT, POSIX time implies (but never states) that it uses a local reference clock to emulate TAI. Joe From nobody Wed Mar 29 08:13:16 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6041296CB for ; Wed, 29 Mar 2017 08:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 EgcE9bLsXz36 for ; Wed, 29 Mar 2017 08:13:10 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id B65941296B5 for ; Wed, 29 Mar 2017 08:13:08 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1ctFHX-0000HSC; Wed, 29 Mar 2017 17:13:07 +0200 Message-Id: To: art@ietf.org Cc: Joe Touch From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <20170328173916.GE7490@localhost> <20170328224041.GJ7490@localhost> <9ddcde60-a915-a03d-dfc3-2c2c451c398c@isi.edu> <20170329000601.GK7490@localhost> <96ad09b7-7dc2-20e8-2aa4-793310d184f6@isi.edu> <20170329015811.GL7490@localhost> <111c86bc-c2c5-5050-edc0-82e40d36c570@isi.edu> <70bae467-8636-379c-7452-21cacf03215f@isi.edu> In-reply-to: Your message of "Wed, 29 Mar 2017 07:57:30 -0700 ." <70bae467-8636-379c-7452-21cacf03215f@isi.edu> Date: Wed, 29 Mar 2017 17:13:07 +0200 Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 15:13:12 -0000 >Right - I will update the doc accordingly. AFAICT, POSIX time implies >(but never states) that it uses a local reference clock to emulate TAI. Not TAI, UTC. Every time_t value has a specific interpretation as a UTC timestamp. Obviously, without correction a free running clock will go wrong with leap seconds. But that doesn't change that it is some approximation of UTC and not TAI. By and large, current Unix systems have no idea about TAI. There are no (commonly available) APIs that give you TAI. From nobody Wed Mar 29 08:22:05 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D52212709D for ; Wed, 29 Mar 2017 08:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 N3RfXpFXz4Jh for ; Wed, 29 Mar 2017 08:22:02 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 F2529126DC2 for ; Wed, 29 Mar 2017 08:22:01 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v2TFLGcM023005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Mar 2017 08:21:17 -0700 (PDT) To: Philip Homburg , art@ietf.org References: <20170328173916.GE7490@localhost> <20170328224041.GJ7490@localhost> <9ddcde60-a915-a03d-dfc3-2c2c451c398c@isi.edu> <20170329000601.GK7490@localhost> <96ad09b7-7dc2-20e8-2aa4-793310d184f6@isi.edu> <20170329015811.GL7490@localhost> <111c86bc-c2c5-5050-edc0-82e40d36c570@isi.edu> <70bae467-8636-379c-7452-21cacf03215f@isi.edu> From: Joe Touch Message-ID: <37dae716-fb6b-a933-d1fa-0a875ab66408@isi.edu> Date: Wed, 29 Mar 2017 08:21:15 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 15:22:03 -0000 On 3/29/2017 8:13 AM, Philip Homburg wrote: >> Right - I will update the doc accordingly. AFAICT, POSIX time implies >> (but never states) that it uses a local reference clock to emulate TAI. > Not TAI, UTC. POSIX doesn't include leaps. It can't track UTC. Maybe we're talking across things - POSIX defines only one internal clock - the Unix one that starts at the Unix epoch and counts up. time_t is supposed to return an integer of this count If you're referring to a time_t structure that indicates days, weeks, months, etc., you're talking about a *conversion* that *approximates* UTC, but really basically converts the Unix clock as close as it can to TAI and ignores the leaps. > Every time_t value has a specific interpretation as a UTC timestamp. There is an intended correlation between Unix dates and UTC dates, but it isn't exact - the equation is indicated as approximate. > Obviously, > without correction a free running clock will go wrong with leap seconds. But > that doesn't change that it is some approximation of UTC and not TAI. POSIX says it doesn't track leaps, which means (at best) it emulates TAI, not UTC. Even if the documentation of the time_t structure and commands indicate otherwise... > By and large, current Unix systems have no idea about TAI. There are no > (commonly available) APIs that give you TAI. The time_t struct is a conversion of the Unix count since epoch into a "UTC-like" format, but it really is much more an emulation of TAI than UTC. But it *is* really neither, because it isn't sync'd to anything. Joe From nobody Wed Mar 29 08:30:52 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3691296E7 for ; Wed, 29 Mar 2017 08:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 HfDgL6JzU0Xa for ; Wed, 29 Mar 2017 08:30:48 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 274931296F4 for ; Wed, 29 Mar 2017 08:30:38 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 886F51406B21; Wed, 29 Mar 2017 08:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=OShKMJH6sX3HZe vr5FYgMWNCxoI=; b=ncO5urs5nmB4/weOOI42+plLGPNXhUc452OcIbVYf3zF6d ijGMT5k1hC6OwoMLTwpnf4l1UMP6l9ScPtknaH4nN5q5ZgPKATk4t+524+KNZI4j i2zBE4DC4B8ViM5uU9z5LMFjBadKyZ3ToBFl5UFiMxeOzvl3OHjLZLabIj/QQ= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 0DDCB1406B0A; Wed, 29 Mar 2017 08:30:36 -0700 (PDT) Date: Wed, 29 Mar 2017 10:30:34 -0500 From: Nico Williams To: Philip Homburg Cc: art@ietf.org, Joe Touch Message-ID: <20170329153033.GO7490@localhost> References: <20170328173916.GE7490@localhost> <20170328224041.GJ7490@localhost> <9ddcde60-a915-a03d-dfc3-2c2c451c398c@isi.edu> <20170329000601.GK7490@localhost> <96ad09b7-7dc2-20e8-2aa4-793310d184f6@isi.edu> <20170329015811.GL7490@localhost> <111c86bc-c2c5-5050-edc0-82e40d36c570@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 15:30:50 -0000 On Wed, Mar 29, 2017 at 04:53:01PM +0200, Philip Homburg wrote: > >I know of no POSIX system with a cesium atomic clock. The preceding bit about POSIX seconds being unable to be SI seconds without an atomic clock speaks for itself. Joe may be the only one who believes that. > >The issue is that POSIX really runs off of whatever local source of time > >passage is available, and can (and does) drift from TAI on *each* > >system. That drift can't be determined until your system tries to sync > >with an external source (e.g., via NTP). Which... most do. > To be completely pedantic, a single cesium clock will also drift from TAI/UTC. > > There is no such concept as being in sync with TAI without external > corrections. To be even more pedantic that may not be meaningfully possible or useful or desirable due to being in an irregular orbit around Earth (e.g., frequently using thrusters to adjust it) or not in orbit around Earth, and not on Earth. This is not a helpful distraction. It's wasting everyone else's time. Also yours and mine. Nico -- From nobody Wed Mar 29 08:34:54 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAE5A129411 for ; Wed, 29 Mar 2017 08:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 4eNLzHqnJ8Ey for ; Wed, 29 Mar 2017 08:34:51 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 B02BD128D19 for ; Wed, 29 Mar 2017 08:34:46 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v2TFYJ2R024700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Mar 2017 08:34:20 -0700 (PDT) To: Nico Williams , Philip Homburg References: <20170328173916.GE7490@localhost> <20170328224041.GJ7490@localhost> <9ddcde60-a915-a03d-dfc3-2c2c451c398c@isi.edu> <20170329000601.GK7490@localhost> <96ad09b7-7dc2-20e8-2aa4-793310d184f6@isi.edu> <20170329015811.GL7490@localhost> <111c86bc-c2c5-5050-edc0-82e40d36c570@isi.edu> <20170329153033.GO7490@localhost> Cc: art@ietf.org From: Joe Touch Message-ID: Date: Wed, 29 Mar 2017 08:34:18 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170329153033.GO7490@localhost> Content-Type: multipart/alternative; boundary="------------63661D7387DEC3EBDE662C4E" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 15:34:53 -0000 This is a multi-part message in MIME format. --------------63661D7387DEC3EBDE662C4E Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 3/29/2017 8:30 AM, Nico Williams wrote: >>> The issue is that POSIX really runs off of whatever local source of time >>> passage is available, and can (and does) drift from TAI on *each* >>> system. That drift can't be determined until your system tries to sync >>> with an external source (e.g., via NTP). > Which... most do. Then you're reporting NTP time, not Unix time. And that's when you're clock jumps - because you're looking at UTC, not the Unix clock anymore. Joe --------------63661D7387DEC3EBDE662C4E Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit



On 3/29/2017 8:30 AM, Nico Williams wrote:
The issue is that POSIX really runs off of whatever local source of time
passage is available, and can (and does) drift from TAI on *each*
system. That drift can't be determined until your system tries to sync
with an external source (e.g., via NTP).

Which... most do.
Then you're reporting NTP time, not Unix time.

And that's when you're clock jumps - because you're looking at UTC, not the Unix clock anymore.

Joe
--------------63661D7387DEC3EBDE662C4E-- From nobody Wed Mar 29 08:46:30 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A3F129422 for ; Wed, 29 Mar 2017 08:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Kx6V3-Qp8q7O for ; Wed, 29 Mar 2017 08:46:25 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 4BDC112942F for ; Wed, 29 Mar 2017 08:46:18 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v2TFjnIV026245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Mar 2017 08:45:50 -0700 (PDT) To: Tony Finch References: <1cb57d13-4145-eb74-7d6a-954fe3a1059c@isi.edu> Cc: Philip Homburg , art@ietf.org From: Joe Touch Message-ID: <2c04440a-11e4-4c7f-1e63-7151794ec90d@isi.edu> Date: Wed, 29 Mar 2017 08:45:48 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 15:46:28 -0000 On 3/28/2017 1:12 PM, Tony Finch wrote: > Joe Touch wrote: > >> Section 3 states that in the definition of a solar day. Section 4.2 >> explains that UT0 is one of many different "means", and that UT0 is the >> most common in current use. > No, UT1 is the most common form of mean solar time. (UT0 is basically > mean solar time at a particular observatory; UT1 is corrected for polar > motion so it is globally consistent.) Yes - mistyped (the doc is correct on that - it says UT1 is the particular mean that is in common use). > >> GPS isn't one of the clocks averaged into TAI (AFAICT); it's a separate >> source that's sync'd to TAI to ensure the 25 ns max delta. > Well, GPS is an ensemble clock (each sat has its own clock) which is > steered with reference to UTC(USNO). UTC(USNO) feeds into the BIPM paper > clocks. > > The USNO says that GPS's maximum deviation from UTC(USNO) is 1us though > in practice it is within a few hundred nanoseconds. The NAV message has > additional information that allows GPS receivers to get the UTC(USNO) time > to within 40ns. > > http://www.usno.navy.mil/USNO/time/gps/usno-gps-time-transfer The GPS spec guarantees that its max deviation is 25 ns AFAICT (see the cited ref in the doc). > >>> - It is not clear to me why NTP would differ 100ms from TAI. >> It's in the spec. > Where in which spec? It's in the definition of NTP strata. Stratum 0 is the a reference clock itself; stratum 1 is connected to the clock directly, stratum 2 is connected to stratum 1 over the net. I'll dig up a specific citation for that... > >> Uptime is just a printout of the delta of the POSIX time when a computer >> started and the current POSIX time. > CLOCK_MONOTONIC cannot be reset, so it is more reliable than that. It is guaranteed monotonic only while the system is running. I don't know what "reliable" means, but it isn't guaranteed to be preserved across a boot. http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_getres.html Joe From nobody Wed Mar 29 09:11:42 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F80129851 for ; Wed, 29 Mar 2017 09:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 35bgbamJ_htS for ; Wed, 29 Mar 2017 09:11:34 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id E2023129562 for ; Wed, 29 Mar 2017 09:11:33 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1ctGC5-0000HWC; Wed, 29 Mar 2017 18:11:33 +0200 Message-Id: To: art@ietf.org Cc: Joe Touch From: Philip Homburg Sender: pch-bF054DD66@u-1.phicoh.com References: <20170328173916.GE7490@localhost> <20170328224041.GJ7490@localhost> <9ddcde60-a915-a03d-dfc3-2c2c451c398c@isi.edu> <20170329000601.GK7490@localhost> <96ad09b7-7dc2-20e8-2aa4-793310d184f6@isi.edu> <20170329015811.GL7490@localhost> <111c86bc-c2c5-5050-edc0-82e40d36c570@isi.edu> <70bae467-8636-379c-7452-21cacf03215f@isi.edu> <37dae716-fb6b-a933-d1fa-0a875ab66408@isi.edu> In-reply-to: Your message of "Wed, 29 Mar 2017 08:21:15 -0700 ." <37dae716-fb6b-a933-d1fa-0a875ab66408@isi.edu> Date: Wed, 29 Mar 2017 18:11:32 +0200 Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 16:11:37 -0000 >> Every time_t value has a specific interpretation as a UTC timestamp. >There is an intended correlation between Unix dates and UTC dates, but >it isn't exact - the equation is indicated as approximate. Quoting the opengroup docs, and this is the last thing I will say about POSIX time: "4.16 Seconds Since the Epoch " "A value that approximates the number of seconds that have elapsed since the Epoch. A Coordinated Universal Time name (specified in terms of seconds (tm_sec), minutes (tm_min), hours (tm_hour), days since January 1 of the year (tm_yday), and calendar year minus 1900 (tm_year)) is related to a time represented as seconds since the Epoch, according to the expression below. " "If the year is <1970 or the value is negative, the relationship is undefined. If the year is >=1970 and the value is non-negative, the value is related to a Coordinated Universal Time name according to the C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, and tm_year are all integer types: " "tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + " (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - " ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400 Feel free to define POSIX time as you wish. This what the opengroup says about it. From nobody Wed Mar 29 09:16:53 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A33011243F3 for ; Wed, 29 Mar 2017 09:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 ONbkhjjfdJQo for ; Wed, 29 Mar 2017 09:16:49 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 0FFB612778E for ; Wed, 29 Mar 2017 09:16:47 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v2TGGMf0029797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Mar 2017 09:16:23 -0700 (PDT) To: Philip Homburg , art@ietf.org References: <20170328173916.GE7490@localhost> <20170328224041.GJ7490@localhost> <9ddcde60-a915-a03d-dfc3-2c2c451c398c@isi.edu> <20170329000601.GK7490@localhost> <96ad09b7-7dc2-20e8-2aa4-793310d184f6@isi.edu> <20170329015811.GL7490@localhost> <111c86bc-c2c5-5050-edc0-82e40d36c570@isi.edu> <70bae467-8636-379c-7452-21cacf03215f@isi.edu> <37dae716-fb6b-a933-d1fa-0a875ab66408@isi.edu> From: Joe Touch Message-ID: <3182b82f-66e6-26c9-026f-af008e3080e0@isi.edu> Date: Wed, 29 Mar 2017 09:16:21 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 16:16:51 -0000 On 3/29/2017 9:11 AM, Philip Homburg wrote: >>> Every time_t value has a specific interpretation as a UTC timestamp. >> There is an intended correlation between Unix dates and UTC dates, but >> it isn't exact - the equation is indicated as approximate. > Quoting the opengroup docs, and this is the last thing I will say > about POSIX time: We've all been referring to this. The problem is that POSIX never defines second, and that this entire paragraph starts with "a value that approximates". It also refers to "a Coordinated Universal Time name", that's a data structure, not an assurance that seconds since epoch actually synchronizes to UTC. Joe > "4.16 Seconds Since the Epoch > " > "A value that approximates the number of seconds that have elapsed since the Epoch. A Coordinated Universal Time name (specified in terms of seconds (tm_sec), minutes (tm_min), hours (tm_hour), days since January 1 of the year (tm_yday), and calendar year minus 1900 (tm_year)) is related to a time represented as seconds since the Epoch, according to the expression below. > " > "If the year is <1970 or the value is negative, the relationship is undefined. If the year is >=1970 and the value is non-negative, the value is related to a Coordinated Universal Time name according to the C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, and tm_year are all integer types: > " > "tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + > " (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - > " ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400 > > Feel free to define POSIX time as you wish. This what the opengroup says > about it. > From nobody Wed Mar 29 09:25:18 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35689126D74 for ; Wed, 29 Mar 2017 09:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 Rj-2E7uAf_W1 for ; Wed, 29 Mar 2017 09:25:15 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 F32351294CA for ; Wed, 29 Mar 2017 09:25:14 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v2TGOs4a000955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Mar 2017 09:24:55 -0700 (PDT) To: Philip Homburg , art@ietf.org References: <1cb57d13-4145-eb74-7d6a-954fe3a1059c@isi.edu> From: Joe Touch Message-ID: <984a122d-6998-3590-8165-4479b8500a49@isi.edu> Date: Wed, 29 Mar 2017 09:24:52 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [art] Predictable Internet Time X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 16:25:17 -0000 On 3/29/2017 4:36 AM, Philip Homburg wrote: > [Just responding to text in many different e-mails] > >>> actual solar time is extremely rare (only sundials). Solar time is almost >>> always mean solar time. I.e UT0 is already mean solar time. >> Section 3 states that in the definition of a solar day. Section 4.2 >> explains that UT0 is one of many different "means", and that UT0 is the >> most common in current use. > Very confusing to have two completely different definitions of Solar day in one > item. Later you use solar time sometimes as mean, sometimes as 'apparent'. That's on my list to fix (I'm typing that summary to post to the list in a minute or two)... > >>> This makes a statement that GPS time differs 25 ns from TAI a bit weird. >>> Maybe this is too much detail. >> See above - even in retrospect, GPS can differ from TAI by 25 ns (it's >> in the spec for GPS). GPS isn't one of the clocks averaged into TAI >> (AFAICT); it's a separate source that's sync'd to TAI to ensure the 25 >> ns max delta. > Given the complexities of dealing with time at the nanosecond level, maybe > it is better to ignore those issues in this document. I.e, GPS and Galilelo > are synced to TAI (with some fixed offset). GLONASS tracks UTC. And leave it > at that. > >>> - It is not clear to me why NTP would differ 100ms from TAI. >> It's in the spec. > Can you be more specific. I'm tracking that down - it's because of the strata. > >>> - It is not clear to me what 'Unix time' is in this context. Typically POSIX >>> time is linked to UTC, >> That is incorrect. POSIX time is defined as 1/86400 of a day, which does >> not take into account leap seconds at all (UTC does) and "day" is not >> defined as related to SI units (UTC is). AFAICT, a POSIX "day" is at >> best a rough approximation of UT0. > I was going to propose that for this document we treat POSIX time as > NTP time minus 2208988800. Unfortunately, the latest NTP RFC (5905) doesn't > seem to actually define NTP time. So that doesn't help. I think I see the issue here. Unix time is a count since epoch, but never defines second or day. It emulates TAI, but there's no definition of how it drifts (or not) from TAI. POSIX *time* is this Unix time. The POSIX time API allows access to two different clocks: a local realtime clock and a local monotonic clock. The API *approximates* UTC by trying to convert its internal time to what it thinks is UTC. When that realtime clock is updated by NTP, the API can present an accurate UTC value. When not, it likely presents something that is TAI+offset, because it doesn't track leaps. It's important to differentiate these; I've been talking almost exclusively about POSIX *time*, not the POSIX time API. > >> But as others have pointed out, that is either a lie or an error: POSIX >> simply does not and cannot account for leap seconds in a numeric type >> representing seconds since an epoch. Perhaps we can say that the >> reference to UTC was meant to be to TAI. Either way the definition of >> seconds can only plausibly be SI. > The way I read it, the following formula > > tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + > (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - > ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400 > > converts between a time_t value and a broken down UTC time. See above. This is just an *approximation* that tries to convert Unix time to something close to UTC, but because it doesn't track leaps, it really emulates TAI. > Just about > every piece of software assume this to be true. I.e, if you run ls then > the times shown by ls are based on this formula. > > Of course this implies that time_t is horribly broken in many different ways, > but we already know that. If time_t is an integer (i.e., you're not referring to the struct tm or some other API), then it is supposed to be the Unix time... > So if you subtract two time_t values, you don't get the real number of > seconds between the two points of time they represent because leapseconds > are ignored. You do (or should) get the real seconds. You can't subtract two struct tm's that way, though. > >>> - One thing I'd like to add is 'uptime' or more general, monotonic time. >> Uptime is just a printout of the delta of the POSIX time when a computer >> started and the current POSIX time. >> >> It might be useful to indicate that some computers just start their >> clocks at boot as zero. > The main thing is that monotonic time can never go backward. It can on reboot. > Ntpd will hapily > step the (POSIX) time backwards. So you need a separate clock, which POSIX > calls CLOCK_MONOTONIC (see clock_settime). We really need to differentiate between the POSIX time scale and the POSIX time API. You're talking about the POSIX time API. POSIX time itself should never go backwards... > >> I can add a new "monotonic clock" definition that uses an arbitrary >> "tick" that is guaranteed to increase between reads and across reboots, >> but is not comparable across machines. > Note that monotonic time is typically not maintained across reboots. I'll point that out too.. > >> Better data types -and strong typing- are needed: >> >> - Unix-like TAI (seconds since epoch, admitting not leap seconds) > If we can get the opengroup to add CLOCK_TAI then we can have this. One > problem is that there doesn't seem to be a sensible epoch for TAI. TAI defines its epoch as 1977-01-01 When you say "sensible", is the problem in representing times before that epoch? They can be denoted as negatives... > >> - Unix-like UTC (seconds since epoch, with leap seconds) >> - both with variations like real versus integer, or seconds + >> microseconds, etc.. > I'd like to treat time_t as something that is synchronized with UTC and behaves > rather weird around a leap second. time_t should be the Unix time, which can't sync to a time scale with leaps like UTC the POSIX time API does have a struct tm, which might derive a UTC approximation. > >> - broken-down time with leap seconds > A 'tai_gmtime' could do that. > >> Then there's intervals. Having variations on intervals based on whether >> or not they admit leaps seems silly though, so intervals are a bit >> easier. > If you want to set a timer based on an interval, then it may make sense to > know if leap seconds need to be counted or not. That would depend IMO on whether the timer is supposed to trigger on an exact date or at the end of an exact interval. That's worth noting. > >> The obvious argument against smeared time is that we already have _two_ >> time standards, and we don't need a third. All we need is to carefully >> pick one or the other in each specification, and preferably TAI time in >> all cases. > There is (right now) no meaningful way to convert 2020-01-01 00:00:00 UTC > to a TAI time value. True, but that's also because that UTC date is indeterminate. Until you know the leaps between now and then, you don't know when that date will actually occur. Joe From nobody Wed Mar 29 09:43:59 2017 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22393129422 for ; Wed, 29 Mar 2017 09:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 yAUtSGQwZK1O for ; Wed, 29 Mar 2017 09:43:56 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 7F2FE128C83 for ; Wed, 29 Mar 2017 09:43:56 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v2TGhE6D003411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Mar 2017 09:43:15 -0700 (PDT) To: art@ietf.org References: <20170328173916.GE7490@localhost> <20170328224041.GJ7490@localhost> <9ddcde60-a915-a03d-dfc3-2c2c451c398c@isi.edu> <20170329000601.GK7490@localhost> <96ad09b7-7dc2-20e8-2aa4-793310d184f6@isi.edu> <20170329015811.GL7490@localhost> <111c86bc-c2c5-5050-edc0-82e40d36c570@isi.edu> <70bae467-8636-379c-7452-21cacf03215f@isi.edu> <37dae716-fb6b-a933-d1fa-0a875ab66408@isi.edu> From: Joe Touch Message-ID: <236d8d65-71b2-cebf-b7eb-54b0c5464399@isi.edu> Date: Wed, 29 Mar 2017 09:43:13 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <37dae716-fb6b-a933-d1fa-0a875ab66408@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: [art] summary of updates - draft-time-touch X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 16:43:58 -0000 Hi, all, So I have a set of things to update so far. Please let me know if I missed something. I will have an update out by the end of this week. I'm hoping this update can help us converge... Joe --------- - clarify TAI as a post-facto average - clarify prev definition of astronomical second as instantaneous: 1/31556925.9747 of the tropical year as of the instant 1900 January 0 at 12:00:00 Ephemeris Time. - clarify UT1 as a a measure of the orientation angle of the earth upon which international agreement bases the notion of calendar days. - consider cleaning up the UT definitions, noting mostly that UT1 is the only one in use (and not getting into the detail of UT0 and UT2) - clean up the POSIX definition (it's not solar; more like a local clock) - this is all at mean sea level (we're ignoring relativistic effects) - reminder that the POSIX "equation" is approximate - a light discussion about implementation issues (e.g., struct timeval vs struct tm vs. ISO 8601) - fix NTP epoch to 1900-01-01 - clarify the two solar times as "apparent" vs "mean" - reminder that timers either end on a date or specify an interval - reminder that future times in UTC are indeterminate - UTC is known only into some future (e.g., a few months) that you know about scheduled leaps - earth rotation, not orbit, causes most of solar time variation One other thing that came up is the difference between "POSIX time" (previously called Unix time) and the POSIX time API. The API can access a variety of time scales, including UTC (e.g., when NTP is running), an emulation of UTC, an emulation of Unix time, or direct access to a monotonic counter (which may or may not be reset on reboot). I think this is Nico's issue with data types, and it's worth clarifying. -----