From nobody Thu Jan 11 08:54:06 2018 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 B16BB12D858 for ; Thu, 11 Jan 2018 08:54:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=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 DaL8NGbyVzjG for ; Thu, 11 Jan 2018 08:54:01 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 A367212D7F5 for ; Thu, 11 Jan 2018 08:54:01 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id u76so5060337qku.11 for ; Thu, 11 Jan 2018 08:54:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=hc/Tn1fAhm11zH/eTS6B940RZBRVgxDXy9jrBsEl8Q4=; b=sdSoumV3DwiTpvftq+IPhLvfVCKGoHEY8aJRaF8P9s+ybWVc9qnLk0Z2b7MPCHDQUW WtFyVyRk1Q66iBdLcFDuP6hpkLWGMxchvZK9TXqVXrH7NdbhB/SCgp1O+SrGU9uIV6w4 11Pn0i6A8VQHnVvpkeWlBRUrhQdU/ef0OycgUWnAea8kV0cbcxk4d3MloDPvbTnflzaN a85APWUqC4tKdTJQ+wNNFMuIpF9EbHT8KxodXevvj48j3NYZ7M4ToenPR/4dlg59PsnM fQt04vZ3r0KIsS2ZAs3hFGyTWbWQN0h2tfCLwdfzk2pHdwKRWD2GuPW6IpJl5HTxTwEd pkUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=hc/Tn1fAhm11zH/eTS6B940RZBRVgxDXy9jrBsEl8Q4=; b=LgeJWLQHKMCprVUgL6MUr+6uHiYBR9hRe27ZSccnmj0mwcSYK4ehRM3CsJ+hzdUNHH 7zaZdZrBaBzxRZ6SjrU/iBojSqdX4XmOxjbp4DL6/mNOpDVUDzgvoQvHv4YUPNF0p3vT 0kiY19A1MR622y/uxfUG+0WbpJMWvZsjReXeMK6Vty+hFvPFk2BnjmaAi/GmOf9iNzXh x9yc1b8oHUKSIyWKgih51XvlksscIGO1Wmv92oGRHJNXiusigsgaz3cOGEuY4NMXm/wo OcOiyecbcXlDxX4UJhqdvEfogaL6n0lrEAmGLDl0FBB5zos/rz39Ym53dMj9RdkQEylr C53A== X-Gm-Message-State: AKwxytcYzdYVvZWLPd8QujXEK7zZjBwGqhXSl4BSAN9xFE6RL1fVxCQ2 J3v55xe4EKXtloXriFjnDxPEfbpMryOUuOaF3fM= X-Google-Smtp-Source: ACJfBouhCKzIQ3rg6tBOhI+mOFh/sw/GbhksUc5yY6n7yr25YOJAtmU/y0eRDd3VLfZr4TQK7DkgXUROnSlalmo88sc= X-Received: by 10.55.192.202 with SMTP id v71mr30470602qkv.294.1515689640466; Thu, 11 Jan 2018 08:54:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.36.169 with HTTP; Thu, 11 Jan 2018 08:53:30 -0800 (PST) In-Reply-To: <151562210589.15919.5331266765571305256.idtracker@ietfa.amsl.com> References: <151562210589.15919.5331266765571305256.idtracker@ietfa.amsl.com> From: Ted Hardie Date: Thu, 11 Jan 2018 08:53:30 -0800 Message-ID: To: art@ietf.org Content-Type: multipart/alternative; boundary="001a1147a26c9c1fea056282fe5a" Archived-At: Subject: [art] Fwd: New Version Notification for draft-hardie-iris-arpa-00.txt 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, 11 Jan 2018 16:54:04 -0000 --001a1147a26c9c1fea056282fe5a Content-Type: text/plain; charset="UTF-8" Greetings, If there are folks on this list who are interested in the deployment of IRIS and who are not on the mailing list of the concluded CRISP working group, I would like to draw your attention to this draft. Its summary is brief, and the draft itself almost equally so. AREG didn't deploy, and we'd like to clean up the arpa domain to recognize that fact. Comments to me or the list, please. regards, Ted ---------- Forwarded message ---------- From: Date: Wed, Jan 10, 2018 at 2:08 PM Subject: New Version Notification for draft-hardie-iris-arpa-00.txt To: Ted Hardie A new version of I-D, draft-hardie-iris-arpa-00.txt has been successfully submitted by Ted Hardie and posted to the IETF repository. Name: draft-hardie-iris-arpa Revision: 00 Title: Iris.arpa is Deprecated Document date: 2018-01-10 Group: Individual Submission Pages: 3 URL: https://www.ietf.org/internet-drafts/draft-hardie-iris-arpa- 00.txt Status: https://datatracker.ietf.org/doc/draft-hardie-iris-arpa/ Htmlized: https://tools.ietf.org/html/draft-hardie-iris-arpa-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-hardie-iris- arpa-00 Abstract: This document requests that iris.arpa and areg.iris.arpa be removed from the arpa zone. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --001a1147a26c9c1fea056282fe5a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings,

If there are f= olks on this list who are interested in the deployment of IRIS and who are = not on the mailing list of the concluded CRISP working group, I would like = to draw your attention to this draft.=C2=A0 Its summary is brief, and the d= raft itself almost equally so.=C2=A0 AREG didn't deploy, and we'd l= ike to clean up the arpa domain to recognize that fact.

Commen= ts to me or the list, please.

regards,

Ted



---------- For= warded message ----------
From: <internet-draft= s@ietf.org>
Date: Wed, Jan 10, 2018 at 2:08 PM
Subject:= New Version Notification for draft-hardie-iris-arpa-00.txt
To: Ted Hard= ie <ted.ietf@gmail.com>
=


A new version of I-D, draft-hardie-iris-arpa-00.txt
has been successfully submitted by Ted Hardie and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hardie-iris-arpa
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Iris.arpa is Deprecated
Document date:=C2=A0 2018-01-10
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-hardie-iris-arp= a-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0htt= ps://datatracker.ietf.org/doc/draft-hardie-iris-arpa/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://too= ls.ietf.org/html/draft-hardie-iris-arpa-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttps://datatracker.ietf.org/doc/html/draft-hardie-iris-arpa-00


Abstract:
=C2=A0 =C2=A0This document requests that iris.arpa and areg.iris.arpa be re= moved
=C2=A0 =C2=A0from the arpa zone.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--001a1147a26c9c1fea056282fe5a-- From nobody Fri Jan 19 06:49:23 2018 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 754B312D953 for ; Fri, 19 Jan 2018 06:49:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 bH1mBNeIsCB9 for ; Fri, 19 Jan 2018 06:49:20 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C50C120726 for ; Fri, 19 Jan 2018 06:49:20 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 13589B80EB2; Fri, 19 Jan 2018 06:49:12 -0800 (PST) To: pbryan@anode.ca, mnot@mnot.net, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, superuser@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: grzesiek.olszewski@orange.com, art@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180119144912.13589B80EB2@rfc-editor.org> Date: Fri, 19 Jan 2018 06:49:12 -0800 (PST) Archived-At: Subject: [art] [Technical Errata Reported] RFC6902 (5239) 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: Fri, 19 Jan 2018 14:49:21 -0000 The following errata report has been submitted for RFC6902, "JavaScript Object Notation (JSON) Patch". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5239 -------------------------------------- Type: Technical Reported by: Grzegorz Olszewski Section: A.16 Original Text ------------- An example target JSON document: { "foo": ["bar"] } A JSON Patch document: [ { "op": "add", "path": "/foo/-", "value": ["abc", "def"] } ] The resulting JSON document: { "foo": ["bar", ["abc", "def"]] } Corrected Text -------------- An example target JSON document: { "foo": ["bar"] } A JSON Patch document: [ { "op": "add", "path": "/foo/-", "value": ["abc", "def"] } ] The resulting JSON document: { "foo": ["bar", "abc", "def"] } Notes ----- surplus square brackets in resulting JSON document Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6902 (draft-ietf-appsawg-json-patch-10) -------------------------------------- Title : JavaScript Object Notation (JSON) Patch Publication Date : April 2013 Author(s) : P. Bryan, Ed., M. Nottingham, Ed. Category : PROPOSED STANDARD Source : Applications Area Working Group APP Area : Applications Stream : IETF Verifying Party : IESG From nobody Fri Jan 19 07:04:53 2018 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 582C0120727 for ; Fri, 19 Jan 2018 07:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=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 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 w6QFnBMB54GO for ; Fri, 19 Jan 2018 07:04:50 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 83356120726 for ; Fri, 19 Jan 2018 07:04:49 -0800 (PST) Received: from [192.168.1.38] ([217.91.35.233]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lo2EO-1fIUkS2sO0-00g1Pa; Fri, 19 Jan 2018 16:04:33 +0100 To: RFC Errata System , pbryan@anode.ca, mnot@mnot.net, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, superuser@gmail.com Cc: art@ietf.org, grzesiek.olszewski@orange.com References: <20180119144912.13589B80EB2@rfc-editor.org> From: Julian Reschke Message-ID: <90d55ced-9035-4dcc-49da-bd381469d44a@gmx.de> Date: Fri, 19 Jan 2018 16:04:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180119144912.13589B80EB2@rfc-editor.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:p1ZFG5sffqNLAOQT/K8132SZYhXDNu1uuAlagbLRAxhAZWR274a dKdK23CyHo0od2QdjKe39cGUHkHrgef7ir0PmU+z54cQFfbnJcApg3f1BbQk2meZ89wKQzK vFQqICvEtqyB3ofg3EiDHLNz7+fQbCmUJjix14Wn60iLTQBBlNjUs8jneBQzlHJAHOE99hC y0swcdQrDL8fd9rYaVpoQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:Y8UaYG7nQuY=:9Rt6ym0voqxuGmiQzyPta5 0umImwI2YpN5pZ+ZGwLFtMsMzgBuMRIwENgGaRYXiEk2SpAsTLJnXyVfrI2bSm3q5mUNf7aPb RMqHnJzyJ9b8cx1eP/jjMD3HaHcyN8OhdaCiq35lg3j/Qkr6KDtC8gqaJ0h9inkGAYi70+iBW HZuk25xsuTXk7o1c15dWP8Ma82cv/YTMe5vS88ySmnTx07+r+GisfpnyDrWe+aJcgx9fy1tBd 83U+J30XCYmZSJ+YxeWGbysq15Hvjhj7XXk1aUxv60ZRs7+r0DqKvJ6TS0CE5NUrBY5rW23i5 ZHXGS618lCzNzqo3smLslIukEyuQarM2/i9gtlkkuN9dmRAvDT4y2RUnveM055F6O/VmwKM4t 0OG0oqYJpfbX4edNRDu5Z8DOw/YHbAbjlDCyIBNqObnPVjgoGn5woy/klyMfC7DHeUaeon+Xh KJlzPSBwLRsgHKtC5GFSbcmrqNDh0ixT79yNC2v3VfmWqxDFGVj9GYtHVHWVs/f/XXpX8cBSM 7lMC7FadKvlpxu/RoGoyYLwQxrZJUXvi7lwQl2mNSWDAonLWk5UJuu6DL3VLSKkgfJ0TCealw 274Laa7pJXFvnQlQF6uaWs1N/tt8KObM3/lOPMybpOrph98xtQ8E1cY6y/seOCEdmblAYpgoL yTE/uBWzRNTyWIo6OywNmQJbaxT7L4ai0MAjNW4Nt+v9sWGWJncOwipguxBGJY5h8impHonjT z+J8G/GN6Tkg9McAAPdBJq+CPsLMDmKqtzajKuPJvqDuUuqwG0WXDuY3DUkRKkq6LQxlgzUZm u+UpV9suEVL8swl63lRi+f+Qiu8LM5KlwVovOou6hiY0Jaligc= Archived-At: Subject: Re: [art] [Technical Errata Reported] RFC6902 (5239) 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: Fri, 19 Jan 2018 15:04:52 -0000 On 2018-01-19 15:49, RFC Errata System wrote: > The following errata report has been submitted for RFC6902, > "JavaScript Object Notation (JSON) Patch". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5239 > > -------------------------------------- > Type: Technical > Reported by: Grzegorz Olszewski > > Section: A.16 > > Original Text > ------------- > An example target JSON document: > > { "foo": ["bar"] } > > A JSON Patch document: > > [ > { "op": "add", "path": "/foo/-", "value": ["abc", "def"] } > ] > > The resulting JSON document: > > { "foo": ["bar", ["abc", "def"]] } > > Corrected Text > -------------- > An example target JSON document: > > { "foo": ["bar"] } > > A JSON Patch document: > > [ > { "op": "add", "path": "/foo/-", "value": ["abc", "def"] } > ] > > The resulting JSON document: > > { "foo": ["bar", "abc", "def"] } > > Notes > ----- > surplus square brackets in resulting JSON document > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > ... The original text looks correct to me. ["abc", "def"] is inserted at the end of ["bar"] yielding ["bar", ["abc", "def"]] Best regards, Julian From nobody Sun Jan 21 20:20:22 2018 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 CFB01127601 for ; Sun, 21 Jan 2018 20:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=ppel5Uas; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=G/SouMi0 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 juPHqtGyLb8j for ; Sun, 21 Jan 2018 20:20:17 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6498F1275C5 for ; Sun, 21 Jan 2018 20:20:02 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 2F83520A78; Sun, 21 Jan 2018 23:20:01 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Sun, 21 Jan 2018 23:20:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=E0oWmvVl1eQuluWhSC/VaTJ3YZX35 zAFjDo4Qv/8Aws=; b=ppel5UasF9HiVsH/zyzDRxHqz7XFeeQRKDfG8/Gabo3Pg aFH7EPNQXga1GMQvBzFkkPKp/JkLrxNLNfvMPKVwrxWhL6b08gMJHv/0z3deBDLU s7zCwA+UDQ+jtaL4kDXHV8+GGa1eNtI3gILJn2aG98larIe0h36Kgy9S3vNJiWC/ 3yoXmPVVTu8c+zZPcuIPSHg7EHwkYyGk3vv2tl5kaNd/wj2sgzaDj+b2yeSQxZuq hZAMQqOTSZ912cQTL7R0rv+dlL7JGzJzjOBIveDFqKqaMrAoph/pfc6OkzuDl4sc 3EMsA53OxEeM/VNJ6DynZK7j0jRJ9UKIly3IwcnqA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=E0oWmv Vl1eQuluWhSC/VaTJ3YZX35zAFjDo4Qv/8Aws=; b=G/SouMi0xpcc73JjYrIDoH OcQ5+k0YbckgHGKAWQXISMK+6ApKLmirBm6WFGFDGgI8E1TfidDFLb+ZmvTpR5jR 5X4icdR1jXiJKlgqCWuh4uWbqzae/iWF6I0y3zCiWecr4MFCWA10ulikMVodZwXU zfzL4preEYpiESiZYzSscbf7MTxNU/kdANaw72cPysJjChuN57sPiLJ0CDqsr1y9 EgrB1mcU/QrfexXMwY/Yf2jVIwLx5RAr7m056DTdG9eD/hJaCW+cnm5obBy7E2Yl Vf8XUNEEPx8TjRSwLB97QB/JeeRQaWQFcXaDzQRAby3DmDyTbJlOpBt5zUyhPWAw == X-ME-Sender: Received: from attitudadjuster.home (unknown [1.152.140.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 7438A7E354; Sun, 21 Jan 2018 23:19:57 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Mark Nottingham In-Reply-To: <90d55ced-9035-4dcc-49da-bd381469d44a@gmx.de> Date: Mon, 22 Jan 2018 15:19:54 +1100 Cc: RFC Errata System , pbryan@anode.ca, Ben Campbell , Alexey Melnikov , adam@nostrum.com, superuser@gmail.com, art@ietf.org, grzesiek.olszewski@orange.com Content-Transfer-Encoding: 7bit Message-Id: References: <20180119144912.13589B80EB2@rfc-editor.org> <90d55ced-9035-4dcc-49da-bd381469d44a@gmx.de> To: "Julian F. Reschke" X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [art] [Technical Errata Reported] RFC6902 (5239) 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, 22 Jan 2018 04:20:20 -0000 Concur with Julian; this is REJECT. > On 20 Jan 2018, at 2:04 am, Julian Reschke wrote: > > On 2018-01-19 15:49, RFC Errata System wrote: >> The following errata report has been submitted for RFC6902, >> "JavaScript Object Notation (JSON) Patch". >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata/eid5239 >> -------------------------------------- >> Type: Technical >> Reported by: Grzegorz Olszewski >> Section: A.16 >> Original Text >> ------------- >> An example target JSON document: >> { "foo": ["bar"] } >> A JSON Patch document: >> [ >> { "op": "add", "path": "/foo/-", "value": ["abc", "def"] } >> ] >> The resulting JSON document: >> { "foo": ["bar", ["abc", "def"]] } >> Corrected Text >> -------------- >> An example target JSON document: >> { "foo": ["bar"] } >> A JSON Patch document: >> [ >> { "op": "add", "path": "/foo/-", "value": ["abc", "def"] } >> ] >> The resulting JSON document: >> { "foo": ["bar", "abc", "def"] } >> Notes >> ----- >> surplus square brackets in resulting JSON document >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >> ... > > The original text looks correct to me. > > ["abc", "def"] > > is inserted at the end of > > ["bar"] > > yielding > > ["bar", ["abc", "def"]] > > Best regards, Julian -- Mark Nottingham https://www.mnot.net/ From nobody Mon Jan 22 17:45:26 2018 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 B371412D86E for ; Mon, 22 Jan 2018 17:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 QJLXhXrfKfiR for ; Mon, 22 Jan 2018 17:45:22 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 11E4C12D86C for ; Mon, 22 Jan 2018 17:45:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Date:To:References:Message-Id:Subject: Mime-Version:Content-Type:From:Sender:Reply-To:Cc:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8118IQhWNSvLA1KYaG8AO+HKTHMpL2DtFZD1CZwmnuo=; b=wu6y4Igmj54uaRdJUXVikkSRfP wgOhMn0RiE+RLhrwZesvatIt1Y0xs8V/CoVNHP6xWxbjgLDS0QTTXAyz8XzTGfWJY4E15ruyRkNeK qwH7k+9PHLoElgkqPktnPSfLxnZ+GuUFrqrbzZsGItX2lRMaDwvN1mKWGWgPv8dbkJ49iNS+a9klJ 2OMLMycTNWkzQOfCs8OM4+FMzFCaVC0u8+3tfaEEosEmnVPqkkiYfXFD+Zg9cMvJ2saeIVW39adPM EBCwORW1CktZYdSRprNEz/Vgfz1ijFvzJnP7l0xdvucxz8sjNlzIysxFuM+NrqEKsy9eLHEDDreVh MVSq/kmQ==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:53463 helo=[192.168.1.87]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1edneE-0004Pm-V5 for art@ietf.org; Mon, 22 Jan 2018 20:45:16 -0500 From: Joe Touch Content-Type: multipart/alternative; boundary="Apple-Mail=_53F8D157-FC9E-4185-8527-F367937DB4C9" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: References: <151641287464.3257.11011391661979125459.idtracker@ietfa.amsl.com> To: art@ietf.org Date: Mon, 22 Jan 2018 17:45:06 -0800 X-Mailer: Apple Mail (2.3273) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [art] Fwd: Confirm submission of I-D draft-touch-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, 23 Jan 2018 01:45:25 -0000 --Apple-Mail=_53F8D157-FC9E-4185-8527-F367937DB4C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 HI, all, I=E2=80=99ve updated draft-touch-time. Note that there may be pending edits not yet incorporated - I=E2=80=99ll = post more on that shortly. Joe > Begin forwarded message: >=20 > From: IETF I-D Submission Tool > Subject: Confirm submission of I-D draft-touch-time > Date: January 19, 2018 at 5:47:54 PM PST > To: "Joseph Touch" , , = , >=20 >=20 > Hi, >=20 > The IETF datatracker draft submission service has received your draft > draft-touch-time-03, and requires a > confirmation step in order to be able to complete the posting of > the draft. > Please follow this link to the page where you can confirm the posting: >=20 > = https://datatracker.ietf.org/submit/status/92363/confirm/6323bcc3041c402c7= 7999b95e5f00510/ >=20 >=20 > Best regards, >=20 > The IETF Secretariat > through the draft submission service >=20 >=20 --Apple-Mail=_53F8D157-FC9E-4185-8527-F367937DB4C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 HI, all,

I=E2=80=99ve updated draft-touch-time.
Note that there may be pending edits = not yet incorporated - I=E2=80=99ll post more on that shortly.

Joe
Begin = forwarded message:

From: = IETF I-D Submission Tool <idsubmission@ietf.org>
Subject: = Confirm = submission of I-D draft-touch-time
Date: = January 19, 2018 at 5:47:54 PM = PST
To: = "Joseph Touch" <touch@isi.edu>, <ben@nostrum.com>, = <adam@nostrum.com>, <aamelnikov@fastmail.fm>


Hi,

The IETF datatracker draft submission service = has received your draft
draft-touch-time-03, and requires = a
confirmation step in order to be able to complete the = posting of
the draft.
Please follow this = link to the page where you can confirm the posting:

https://datatracker.ietf.org/submit/status/92363/confirm/6323bc= c3041c402c77999b95e5f00510/


Best regards,

The IETF = Secretariat
through the draft submission = service



= --Apple-Mail=_53F8D157-FC9E-4185-8527-F367937DB4C9-- From nobody Mon Jan 22 17:48:24 2018 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 3991512D871 for ; Mon, 22 Jan 2018 17:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 Dr_aConvdy6t for ; Mon, 22 Jan 2018 17:48:14 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 C95AD12D866 for ; Mon, 22 Jan 2018 17:47:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-Id:In-Reply-To:To:References:Date: Subject:Mime-Version:Content-Type:From:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1zDkE7c9yz0bIV5sGo87tspsndvmzB+Ak1u8R3UlSXg=; b=TcNHJXSf3t0ZRhqeaV84hv9z1 vVUS24qSZD6FEpTIoskAhjXQQ0YEkRzDqflITPDCPkkwk1x8XIern/e1ywWoKkhfDCOGnqjsB5O+M +JpaAQiKMXoGQ6e9s6EyUEW9SRa7P0bk/YU7wyEEyU5jQmK6pfOxxooZlMaGaFmCCdF57oE7aSv3K 3BCV2Ok0YJR/W96UQ/G6I2xvqdo1zmFwLilVztEfmeYWpWtrIhsbejQVN5mbeisLALx7RcSS9puCu 9ooxqlAV20heTx06oYLYP5whQ7T1KIoIHDWbkj8K2BRchdPyt4B1LTFntDYspzc2JfF1nkBOc9zG+ JPny7TTDg==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:53484 helo=[192.168.1.87]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1edngk-0006CT-1r for art@ietf.org; Mon, 22 Jan 2018 20:47:54 -0500 From: Joe Touch Content-Type: multipart/alternative; boundary="Apple-Mail=_FD457A3E-645E-4C65-81D6-1010A85DD06D" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 22 Jan 2018 17:47:36 -0800 References: <151641287464.3257.11011391661979125459.idtracker@ietfa.amsl.com> To: art@ietf.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3273) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [art] New version of I-D draft-touch-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, 23 Jan 2018 01:48:23 -0000 --Apple-Mail=_FD457A3E-645E-4C65-81D6-1010A85DD06D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 22, 2018, at 5:45 PM, Joe Touch wrote: >=20 > HI, all, >=20 > I=E2=80=99ve updated draft-touch-time. >=20 > Note that there may be pending edits not yet incorporated - I=E2=80=99ll= post more on that shortly. FYI - here=E2=80=99s the correct link and context: A new version of I-D, draft-touch-time-03.txt has been successfully submitted by Joe Touch and posted to the IETF repository. Name: draft-touch-time Revision: 03 Title: Resolving Multiple Time Scales in the Internet Document date: 2018-01-19 Group: Individual Submission Pages: 19 URL: = https://www.ietf.org/internet-drafts/draft-touch-time-03.txt = Status: https://datatracker.ietf.org/doc/draft-touch-time/ = Htmlized: https://tools.ietf.org/html/draft-touch-time-03 = Htmlized: = https://datatracker.ietf.org/doc/html/draft-touch-time-03 = Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-touch-time-03 = 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. --Apple-Mail=_FD457A3E-645E-4C65-81D6-1010A85DD06D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jan = 22, 2018, at 5:45 PM, Joe Touch <touch@strayalpha.com> wrote:

HI, all,

I=E2=80=99ve updated = draft-touch-time.

Note that there may be pending edits not yet incorporated - = I=E2=80=99ll post more on that = shortly.

FYI - here=E2=80=99s the correct link = and context:

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

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

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.

= --Apple-Mail=_FD457A3E-645E-4C65-81D6-1010A85DD06D-- From nobody Thu Jan 25 05:57:13 2018 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 486F1120726; Thu, 25 Jan 2018 05:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 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, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 qKwX96NOBI_k; Thu, 25 Jan 2018 05:57:10 -0800 (PST) Received: from mail-vk0-f45.google.com (mail-vk0-f45.google.com [209.85.213.45]) (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 C2CCF120227; Thu, 25 Jan 2018 05:57:09 -0800 (PST) Received: by mail-vk0-f45.google.com with SMTP id f186so4863763vkc.1; Thu, 25 Jan 2018 05:57:09 -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:cc; bh=9R6bk2EvlnwkKl7CPHkgmHjU7S1YkXUA0yrb9q2txC0=; b=CGk54hMaY2ctoPShRNkqVPM26lJOKXUmulyAVcaP3ygknDBQepD80ATLHL4PRDHPmN uqyzmRpLcKXM4xeZCnbnYIdG9f5aQbKN5MVZ4y8Mts3hdWZBrjjL4xoot/W2DkWeNhYm nNPo20+RCVWPr30dOaBnoUgBfgPXUhynA8LJsLaM7tGDzeQ9x7DKvpyqfnspIom27sJb I34MomB3KQ9yhsOnr7C6sdPnR0Zq8I15/LZME5WSS1YYn1S5pxgmos3o+kKsjNkHEn8o EBbLlBFIo8qRnM2saAmoZ6FN63HwUlkfKMTko0MpHezXIq8FdrFehKEELyBUEd04MSNa q9dA== 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:cc; bh=9R6bk2EvlnwkKl7CPHkgmHjU7S1YkXUA0yrb9q2txC0=; b=MsP5JWCtB9ibWWecFwAtGhBapJipo4DzMLSWdIs+6WWDKxnY0LJw/aX66FcTAX4uba U+duLD7bY5w9hOg9Yb/fkTvsKwAnQEn/Tnw4JDyyrMnpBK5S0LOM1Hr47buaAtGoDqat 2+tFV4B1+t+pHXSRFZLFf00BQRQFJpgihnVCWjIyZlYM/8Njt1ieQIhgOfezQhFNuM47 +VemsGvZlNg90VV7f/TIFffMayUztJk5c2FoUbVy+vLEUohw3vKrfQ3Chxu1G7/HnmIc O3YTs1ndkTW9QOhXP2einLpb7RD0i42hA7Z5Hauwm878aYTPw07L/YP69lawiHwOB88F DNRA== X-Gm-Message-State: AKwxytf9Z5/ScoAa/2PeHmu68pNPKGQLIB5YFyGXAhIO7yWHNtYeq5lf cQi1/yH9El7llTsPLJ7yOG1/fXgjUrx0zOhCEo5d6Nw= X-Google-Smtp-Source: AH8x224g8oto+P9+hGjRznzv8F7Vd6v2/mplZYvc+gTSBPQPTMf8+5ZwarbnchX9vMFvC0rGmqMm8J5OQmhNt8BbzdM= X-Received: by 10.31.56.209 with SMTP id f200mr7212855vka.50.1516888568682; Thu, 25 Jan 2018 05:56:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.10.27 with HTTP; Thu, 25 Jan 2018 05:55:27 -0800 (PST) From: Frank Ellermann Date: Thu, 25 Jan 2018 14:55:27 +0100 Message-ID: To: Ted Hardie Cc: regext@ietf.org, art@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [art] New Version Notification for draft-hardie-iris-arpa-00.txt 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, 25 Jan 2018 13:57:11 -0000 On 22 January 2018, Ted Hardie wrote: > If you have thoughts Maybe "obsoletes 4698" instead of only "updates 4698" would be clearer for readers of RFC 4698. From nobody Thu Jan 25 07:13:49 2018 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 CB215124BE8; Thu, 25 Jan 2018 07:13:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 HAPqpVXpPrwG; Thu, 25 Jan 2018 07:13:40 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 594141243F3; Thu, 25 Jan 2018 07:13:40 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1eejDf-000EnG-4R; Thu, 25 Jan 2018 10:13:39 -0500 Date: Thu, 25 Jan 2018 10:13:32 -0500 From: John C Klensin To: Frank Ellermann , Ted Hardie cc: art@ietf.org, regext@ietf.org Message-ID: <221F1CDD2609C43811D017C3@PSB> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [art] New Version Notification for draft-hardie-iris-arpa-00.txt 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, 25 Jan 2018 15:13:43 -0000 --On Thursday, January 25, 2018 14:55 +0100 Frank Ellermann wrote: > On 22 January 2018, Ted Hardie wrote: >> If you have thoughts > > Maybe "obsoletes 4698" instead of only "updates 4698" would be > clearer for readers of RFC 4698. Ted, Unless there are considerations that I don't understand, I agree with Frank and would go a step further. While the document indicates that IRIS was not actually deployed for address registry usage, as far as I know it has not been deployed for anything else either and has become part of the wreckage along the path to try to replace Whois for registry database use. If the intent here is to say "we have given up on IRIS" (probably just recognizing what has happened historically), then we should be formally obsoleting all of the IRIS documents at the same time (and/or moving them to Historic) so they are no longer listed as Proposed Standards and implicitly recommended. That means at least RFC 4698 but also 4414 and the original protocol specifications (3982-3983). That would require broadening the scope of this document somewhat and adjusting its title but, having skimmed through it, would not require significant work. By contrast, if you believe that the ISOS protocols and the other registries and identifiers are still relevant for implementation and use, I think it would be helpful if this document said that explicitly. For example, you might explicitly indicate that IRIS had additional applications (with a reference or two) and that, unlike the address registries, those are still in use and Recommended. best, john From nobody Thu Jan 25 07:20:42 2018 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 B9C651243FE for ; Thu, 25 Jan 2018 07:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hxr-us.20150623.gappssmtp.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 fwZt-4OiHJ_f for ; Thu, 25 Jan 2018 07:20:39 -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 1592B124BE8 for ; Thu, 25 Jan 2018 07:20:39 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id b198so8991721iof.6 for ; Thu, 25 Jan 2018 07:20:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr-us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sB/pAevwOtIBZCz4am4BRLa0d9vX4fQCNoMdtqtkc1E=; b=WYi9XDcsBNlSMskBkT6GbjLsjBZbXT3RDpDpqmrNFboZ4qVHUFgr6OUvPxe1Sgby1Y syqShWUj78RQgJloFHQbikCXJ7w5VsoN8IDVkwWpHq9UK+YlJWQngJ7Y8t7rQ43n7Aq4 Mgz6Hpps5ipN3HVywr17y1Ft+kJaADTNAw6F9cKVw9+f3DrC9TscrLYki0QkbPUSbq44 UT87swpz1tHk6tiSp3Am5Qssezb6VYa0cbpz4FhR0U6wIngLUN23LgjI10iN0vvwnv5B rOy2YR+YqwLgcpCb0ekVQEWiT1xtz25iiVsFX8PQHJC6SAs4yWUpkKTPaT71Fjg6ByHk yh/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sB/pAevwOtIBZCz4am4BRLa0d9vX4fQCNoMdtqtkc1E=; b=LQiZETIDLtPrq0IzZXZ4jIc0e2Ea2EqF9GBRpclyE54Y3h6gdrxnlEbV9YOsSpU0Lu qTD2Op+ru8kH/bwZHapngGI/XbTPMvkjiqd2ApL88Ipfkx06wPGBo1Zj9qQKczK+Qi+A i5VbMOfYWPmkY4qSJDrCq1dc/1pkGcSa2Y+0JiGkvbBPmZWhXsgoug5t8XTCVSmpCcrW vd5jBTINVavDlHlgIX2K3+toxJ1Q68tUIPfTUv/r3UByh1duc8DvXelIvipbG4BROiQ3 cTPKhkspfB8ZIQFw56OxenyY39qoAev5wiDI4N9j98yzATtb/ti20Z2KFtCa4dFd5vb/ 9oMw== X-Gm-Message-State: AKwxytfiZGCiYzaki6GbZPZcwB354sY45l7eD3FEi2qcAkd6gGq5L/2m h2uFQIT8PopSnSU9hqv+vH72heLUwX5e7nf5CCMRMQ== X-Google-Smtp-Source: AH8x225dWBs6C50gqYRjJjCC497JFrZ+/n/hML5RmNjdQfT65Al6K1zKT6feKfhwekcrdWAmZZi63ta8wKFZWvjD27g= X-Received: by 10.107.48.68 with SMTP id w65mr12997759iow.84.1516893638438; Thu, 25 Jan 2018 07:20:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.132.165 with HTTP; Thu, 25 Jan 2018 07:20:37 -0800 (PST) X-Originating-IP: [192.136.136.238] In-Reply-To: <221F1CDD2609C43811D017C3@PSB> References: <221F1CDD2609C43811D017C3@PSB> From: Andrew Newton Date: Thu, 25 Jan 2018 10:20:37 -0500 Message-ID: To: John C Klensin Cc: Frank Ellermann , Ted Hardie , art@ietf.org, Registration Protocols Extensions Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [art] [regext] New Version Notification for draft-hardie-iris-arpa-00.txt 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, 25 Jan 2018 15:20:41 -0000 On Thu, Jan 25, 2018 at 10:13 AM, John C Klensin wrote: > > Unless there are considerations that I don't understand, I agree > with Frank and would go a step further. While the document > indicates that IRIS was not actually deployed for address > registry usage, as far as I know it has not been deployed for > anything else either and has become part of the wreckage along > the path to try to replace Whois for registry database use. My understanding is that DCHK did get deployed by two domain registries. I do not know if they still use it though. > > If the intent here is to say "we have given up on IRIS" > (probably just recognizing what has happened historically), then > we should be formally obsoleting all of the IRIS documents at > the same time (and/or moving them to Historic) so they are no > longer listed as Proposed Standards and implicitly recommended. > That means at least RFC 4698 but also 4414 and the original > protocol specifications (3982-3983). That would require > broadening the scope of this document somewhat and adjusting its > title but, having skimmed through it, would not require > significant work. In my opinion, "we have given up on IRIS" is the proper thing to say. -andy From nobody Thu Jan 25 07:42:30 2018 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 92D9612E883; Thu, 25 Jan 2018 07:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, 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 sWykofCQDB_e; Thu, 25 Jan 2018 07:42:23 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9C3612DA2C; Thu, 25 Jan 2018 07:42:22 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1eejfR-000Epf-81; Thu, 25 Jan 2018 10:42:21 -0500 Date: Thu, 25 Jan 2018 10:42:15 -0500 From: John C Klensin To: Andrew Newton cc: Frank Ellermann , Ted Hardie , art@ietf.org, Registration Protocols Extensions Message-ID: <41864C6DD0500389F14534C3@PSB> In-Reply-To: References: <221F1CDD2609C43811D017C3@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [art] [regext] New Version Notification for draft-hardie-iris-arpa-00.txt 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, 25 Jan 2018 15:42:24 -0000 --On Thursday, January 25, 2018 10:20 -0500 Andrew Newton wrote: > On Thu, Jan 25, 2018 at 10:13 AM, John C Klensin > wrote: >> >> Unless there are considerations that I don't understand, I >> agree with Frank and would go a step further. While the >> document indicates that IRIS was not actually deployed for >> address registry usage, as far as I know it has not been >> deployed for anything else either and has become part of the >> wreckage along the path to try to replace Whois for registry >> database use. > > My understanding is that DCHK did get deployed by two domain > registries. I do not know if they still use it though. Even if they do, a move to Historic and/or Obsolete doesn't change their situation, it is just an implicit recommendation that others should not rush out to deploy this or even actively consider it as a option. If something more nuanced is needed, it is probably time to write an A/S and have this particular registry/ subdomain removal be part of that. >> If the intent here is to say "we have given up on IRIS" >> (probably just recognizing what has happened historically), >> then we should be formally obsoleting all of the IRIS >> documents at the same time (and/or moving them to Historic) >> so they are no longer listed as Proposed Standards and >> implicitly recommended. That means at least RFC 4698 but also >> 4414 and the original protocol specifications (3982-3983). >> That would require broadening the scope of this document >> somewhat and adjusting its title but, having skimmed through >> it, would not require significant work. > > In my opinion, "we have given up on IRIS" is the proper thing > to say. Sad although probably right. It was and remains, at least in my opinion, a nice piece of work. That actually leads to another commend, which is that I'd much rather see a document like this say something equivalent to "overtaken by events" or "use no longer recommended" rather than "deprecated". best, john From nobody Sat Jan 27 11:08:11 2018 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 6D655126C22 for ; Sat, 27 Jan 2018 11:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 KJ28Ls3IELL7 for ; Sat, 27 Jan 2018 11:08:07 -0800 (PST) Received: from smtp.ucolick.org (zilan.ucolick.org [128.114.23.234]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BB0E12421A for ; Sat, 27 Jan 2018 11:08:07 -0800 (PST) Received: from smtp.ucolick.org (localhost [127.0.0.1]) by smtp.ucolick.org (Postfix) with ESMTP id E8902293B; Sat, 27 Jan 2018 11:08:06 -0800 (PST) Received: from geneva.ucolick.org (geneva.ucolick.org [128.114.23.183]) by smtp.ucolick.org (Postfix) with ESMTP id E4F4328F8; Sat, 27 Jan 2018 11:08:06 -0800 (PST) Received: from geneva.ucolick.org (localhost [127.0.0.1]) by geneva.ucolick.org (Postfix) with ESMTP id D5709372; Sat, 27 Jan 2018 11:08:06 -0800 (PST) Received: (from sla@localhost) by geneva.ucolick.org (8.14.7/8.14.7/Submit) id w0RJ861M023809; Sat, 27 Jan 2018 11:08:06 -0800 Date: Sat, 27 Jan 2018 11:08:06 -0800 From: Steve Allen To: Joe Touch Cc: Applications and Real-Time Area Discussion Message-ID: <20180127190806.GA23684@ucolick.org> References: <151641287464.3257.11011391661979125459.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [art] Fwd: Confirm submission of I-D draft-touch-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: Sat, 27 Jan 2018 19:08:09 -0000 On Mon 2018-01-22T17:45:06-0800 Joe Touch hath writ: > I’ve updated draft-touch-time. > > Note that there may be pending edits not yet incorporated - I’ll post more on that shortly. I offer the following toward improvements in the document. > 1. Introduction This section has a numbered list of recommendations. List point 3 is about UTC, and reasons to use UTC are broader than given in the current text. They include the following: UTC is the time scale that the ITU-R recommends for use in radio broadcast time signals ITU-R TF.460 UTC is the time scale that the ITU-R recommends for use in communications of time and date ITU-R Radio Regulations 2.6 UTC is the time scale that the ITU-T recommends for use in communications of time and date 7th Plenary Assembly of the CCITT in 1980-11 UTC is the time scale that the CGPM strongly endorsed as the basis for civil time Resolution 5 of the 15th meeting of the CGPM in 1975-05/06 http://www.bipm.org/en/CGPM/db/15/5/ UTC is the time scale that members of the BIPM routinely intercompare to compute TAI as seen in BIPM Circular T https://www.bipm.org/en/bipm-services/timescales/time-ftp/Circular-T.html and its explanatory supplement ftp://ftp2.bipm.org/pub/tai/publication/notes/explanatory_supplement_v0.1.pdf UTC is the legal or official time scale in many countries whose national metrology agencies are members of the BIPM and which provide the radio broadcast time signals as that legal time. > Section 3. Terminology This section defines terms, and those terms are used differently in the older language of some of the citations. In older documents the term "epoch" meant what we now generally call a "date". In particular "epoch" was any instant which could be unambiguously recognized and generally agreed upon, thus an epoch could be any "date and time" within a calendar based on the rotation of the earth which all parties had the ability to observe and measure. "Solar day" The final sentence should read "A given apparent solar day can vary by as much as 30 seconds vs. the mean." Except that really that should be omitted altogether because ... The notion of apparent solar day is irrelevant to this document. There is no service which provides values of apparent solar time. Other than observers looking at the shadow of a stick in the ground there are no consumers of values of apparent solar time. Starting in 1833 the UK Nautical Almanac abandoned the tabulation of apparent solar time in favor of mean solar time because by then the Admiralty allowed that the navigator of any ship had a chronometer. Only the mean solar day is relevant to this document, and all discussionsof variation in the apparent solar day should be omitted. "Tropical Year" Replace the current text with the following: Tropical Year: a unit of time defined by the interval of one revolution of the earth around the sun in its mean orbit as measured with respect to the mean equinox. "Leap seconds" replace "based on solar days" with "based on mean solar days as measured using UT1". > Section 4.2 Time Scales This section includes a definition of TAI and reference. That definition is currently being reworked to harmonize with the IAU definition of Terrestrial Time (TT). In the redefinition there will be no reference to a geoid CCTF has produced draft of new definition of TAI for BIPM http://www.iaufs.org/CCTF%20Recommendation-DRAFT.pdf this has been approved by 2017 Oct CIPM for inclusion into the resolutions for the draft resolutions of the 2018 Nov CGPM. https://www.bipm.org/cc/PARTNERS/Allowed/2017_October/Plans-for-the-26th-CGPM-M-MILTON.pdf TAI is irrelevant to this document because no service can provide it to an operational system. TAI is only available after the fact in the publication of BIH Circular T. See the current BIPM circular T ftp://ftp2.bipm.org/pub/tai//Circular-T/cirthtm/cirt.360.html Note that the time labs intercompare their values of UTC(k). Note that no value of TAI is given other than as an offset from UTC. Only versions of UTC(k) exist in real time. UTC does not exist until Circular T is published the next month, and that will also define TAI as an offset from UTC. A system can only use TAI if it had realtime access to a value of UTC(k) and then after the publication of Circular T applies the corrections to the recorded values of UTC(k). This section also contains a definition of Universal Time that deserves better treatment. UT (Universal Time) is a time scale based on measuring the rotation of the earth. UT is a subdivision of the Universal Day which was agreed as the basis for civil time at International Meridian Conference in 1884. ref https://en.wikipedia.org/wiki/International_Meridian_Conference Since 1928 UT has been synonymous with Greenwich Mean Time. ref text from IAU Commission 4 at the 1928 GA in https://www.iau.org/static/resolutions/IAU1928_French.pdf UT has several variants which have during various intervals been the basis for civil time. ref Bulletin Horaire, series 4, numbers 3 and 4 in 1955 https://www.ucolick.org/~sla/leapsecs/BH1955.html Originally UT was a subdivision of the mean solar day measured using a specific meridian on earth (Greenwich) and a specific celestial reference point (the mean equinox). Most common in recent usage is UT1 which since 2003 measures earth rotation using fully relativistic transformations, models for plate tectonics, and motions of fluids in core, oceans, and atmosphere. ref IAU 2000 resolution B1.8 https://www.iau.org/static/resolutions/IAU2000_French.pdf Proceeding onward to the other time scales ... Ephemeris Time is only tangentially relevant to this document. No source provides Ephemeris Time. No consumers use Ephemeris Time. The current variation of Ephemeris Time most relevant to this document is Terrestrial Time (TT) which is the ideal time scale that TAI strives to realize. GPS is not defined as tracking TAI. GPS is defined by IS-GPS-200H plus subsequent IRNs https://www.gps.gov/technical/icwg/ The term TAI and the words International Atomic Time exist nowhere in the defining documents for GPS. In particular see IS-GPS-200H paragraph 3.3.4 GPS Time and SV Z-Count. where the first line is "GPS time is established by the Control Segment and is referenced to Coordinated Universal Time (UTC) as maintained by the U.S. Naval Observatory (UTC (USNO))" So GPS time is defined as UTC(USNO) + (numleaps - 9) seconds. Why is PTP aka IEEE 1588-2002 aka ITU-T Recommendation G.8265.1 not mentioned in this document? %%%%%%%%%%%%% > 4.3 Comparison of Properties Uniform should end its definition more like "all intervals of the same size represent the same amount of time in the specific reference frame of that time scale." Missing from this list of properties is: Availability more specifically, availability in real time. TAI is not available in real time, and neither is UTC. UTC(k) can be available in real time. For example, a good GPS receiver which follows IS-GPS-200H by applying the SV clock correction polynomial, the GPS time polynomial, the general relativity, and the ionosperic correction can give a good real time estimate of UTC(USNO). For details of that the references are in IS-GPS-200H 20.3.3.5.2.4 Coordinated Universal Time (UTC). 20.3.3.5.2.3 Almanac Time Parameters. A financial exchange whose regulators require that transactions be accurately timestamped can contract to lease a fiber to a national metrology institute to get access to that version of UTC(k). A rather old publication may yet be a good reference here. HP Application Note 1289 http://www.allanstime.com/Publications/DWA/Science_Timekeeping/TheScienceOfTimekeeping.pdf See Table C1 for the technologies and costs and precision tradeoffs. Also note that nowhere does it indicate that TAI is available. > 5 Systems that report time This section must reference BIPM Circular T and its explanatory supplement. This section should distinguish between reports of time (as in Circular T for TAI, and IERS publications for UT1) and systems which provide time in real time. > 6.1.1 Continuous and uniform As noted above, strike the equation relating GPS and TAI. Again, the current length of day in SI seconds of TT (or TAI) should reference IERS. > 6.1.3 Not uniform Strike the sentence about Solar days varying by as much as 50 seconds because that should read "Apparent Solar Days" and because there are no sources nor consumers of apparent solar time. Strike the entire sentence about variations in the earth orbit over time. Those variations are small by comparison to earth rotation, but more importantly, there are no sources nor consumers of earth orbit time and this document gains nothing by veering that far off into celestial mechanics. Strike the entire sentence about GPS using its own clocks rather than TAI. TAI does not exist in real time, so it is not possible for an operational system to refer to it. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From nobody Sun Jan 28 20:50:11 2018 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 EA4081315EA for ; Sun, 28 Jan 2018 20:50:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] 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 lJZuOGbYvRwY for ; Sun, 28 Jan 2018 20:50:07 -0800 (PST) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) (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 E323A1315EC for ; Sun, 28 Jan 2018 20:50:05 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.46,429,1511787600"; d="scan'208";a="208771866" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 29 Jan 2018 15:50:02 +1100 X-IronPort-AV: E=McAfee;i="5900,7806,8788"; a="838565934" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcavi.tcif.telstra.com.au with ESMTP; 29 Jan 2018 15:50:02 +1100 Received: from wsapp5584.srv.dir.telstra.com (10.75.131.20) by WSMSG3707.srv.dir.telstra.com (172.49.40.81) with Microsoft SMTP Server (TLS) id 8.3.485.1; Mon, 29 Jan 2018 15:50:01 +1100 Received: from wsapp5585.srv.dir.telstra.com (10.75.3.67) by wsapp5584.srv.dir.telstra.com (10.75.131.20) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 29 Jan 2018 15:50:00 +1100 Received: from AUS01-SY3-obe.outbound.protection.outlook.com (10.172.101.126) by wsapp5585.srv.dir.telstra.com (10.75.3.67) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Mon, 29 Jan 2018 15:50:00 +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=npiEMT5qh176KorTKQNFnGGkBaWbQGuYWbThSQnmjYI=; b=XEE2W2dTbIBkS52Bf+Bkj72Y36SI2FuJ+WiOgb5z0fMYKwJ+gWcowdhgQXTyxRMtTiSZbO4K4Yx7NfWOuA+7gV99+1kOKBLdIoYKmHd7RQhBgKgfUP/sj82QTN14Aojsbfw7I/9rQt+GQSVL2syjb/QpajOb7YNGLmmAqd0IS7E= Received: from ME1PR01MB1076.ausprd01.prod.outlook.com (10.169.167.15) by ME1PR01MB0211.ausprd01.prod.outlook.com (10.162.66.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.14; Mon, 29 Jan 2018 04:49:59 +0000 Received: from ME1PR01MB1076.ausprd01.prod.outlook.com ([fe80::5ee:c0f:e19b:9ff8]) by ME1PR01MB1076.ausprd01.prod.outlook.com ([fe80::5ee:c0f:e19b:9ff8%18]) with mapi id 15.20.0444.016; Mon, 29 Jan 2018 04:49:59 +0000 From: "Manger, James" To: Joe Touch , "Applications and Real-Time Area Discussion" Thread-Topic: [art] Fwd: Confirm submission of I-D draft-touch-time Thread-Index: AQHTk+vhectROW+ThkqgekqjKPGTO6OIHHsAgAIujeA= Date: Mon, 29 Jan 2018 04:49:59 +0000 Message-ID: References: <151641287464.3257.11011391661979125459.idtracker@ietfa.amsl.com> <20180127190806.GA23684@ucolick.org> In-Reply-To: <20180127190806.GA23684@ucolick.org> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=James.H.Manger@team.telstra.com; x-originating-ip: [203.41.142.254] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; ME1PR01MB0211; 7:H4BfYnYfTQ/NKAmuMSCDDAq/izGGH1SiOgT21cQmyyhVLHdYPKJtEHJibycqK/kKx7iLlkccLBkrcw8HN+evC+KYvJnJuYS0FTcYJkN8NgHYhfWeZIdIh6aKSXqbolkCnzJdOy+QHjbGhcT0kS5uqDiD+GGjD5eMl+fdmWwfKrz1dru9jBbE+5EMcE4i5PFk+WsJJ8LP50pBnoPNJuPsthw6/iV5EUhOP0nTjR07MUVe72raSfwzCOUSMDX3ZtME x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 51beb0d2-4cc7-4bba-9b52-08d566d3c093 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:ME1PR01MB0211; x-ms-traffictypediagnostic: ME1PR01MB0211: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(168375693250761); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(10201501046)(3231101)(944501161)(93006095)(93001095)(3002001)(6041288)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:ME1PR01MB0211; BCL:0; PCL:0; RULEID:; SRVR:ME1PR01MB0211; x-forefront-prvs: 0567A15835 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(39860400002)(366004)(396003)(39380400002)(199004)(189003)(25786009)(105586002)(305945005)(74316002)(102836004)(7736002)(478600001)(106356001)(99286004)(33656002)(229853002)(81166006)(81156014)(68736007)(8676002)(2950100002)(42882006)(97736004)(5660300001)(66066001)(72206003)(14454004)(5250100002)(316002)(8936002)(110136005)(3660700001)(2900100001)(3280700002)(53936002)(2906002)(186003)(86362001)(6506007)(7696005)(76176011)(6246003)(6436002)(55016002)(26005)(9686003)(6306002)(6116002)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:ME1PR01MB0211; H:ME1PR01MB1076.ausprd01.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: team.telstra.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: OXJ92COVaNbJuh6QcCjOnNs+4gGLnpVFSqoXJ+fPZt7GJm9Iziszw+LR5/tuxVA4X4DeEG6ma4gljCpTHL5X+A== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 51beb0d2-4cc7-4bba-9b52-08d566d3c093 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2018 04:49:59.7356 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854 X-MS-Exchange-Transport-CrossTenantHeadersStamped: ME1PR01MB0211 X-OriginatorOrg: team.telstra.com Archived-At: Subject: Re: [art] Fwd: Confirm submission of I-D draft-touch-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: Mon, 29 Jan 2018 04:50:10 -0000 Q29tbWVudHMgb24gZHJhZnQtdG91Y2gtdGltZS0wMyAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXRvdWNoLXRpbWUtMDMpOg0KDQpHaXZlbiB0aGF0IHRoZSBtYWluIGFyZ3VtZW50 IGFnYWluc3QgYSB0aW1lIHNjYWxlIHRoYXQgc21lYXJzIG91dCBsZWFwIHNlY29uZHMgaXMgdGhl IGxhY2sgb2YgYSBjdXJyZW50IHN0YW5kYXJkLCB0aGUgYmVzdCBjb250cmlidXRpb24gdGhpcyBk b2N1bWVudCBjb3VsZCBtYWtlIGlzIHRvIGRvY3VtZW50IGFzIGFuIFJGQyB0aGUgIjI0LWhvdXIg bGluZWFyIHNtZWFyIGZyb20gbm9vbiB0byBub29uIFVUQyIgbm93IHVzZWQgYnkgR29vZ2xlICho dHRwczovL2RldmVsb3BlcnMuZ29vZ2xlLmNvbS90aW1lL3NtZWFyKSwgQW1hem9uIGV0Yy4gVGhh dCBtZWFucyBpbnRlcnZhbCBtZWFzdXJlbWVudHMgYXJlIG5vdCBjb21wbGljYXRlZCBhdCBhbGwg dW5sZXNzIHlvdSBuZWVkIHByZWNpc2lvbiBiZXR0ZXIgdGhhdCAxMS42cHBtICgwLjAwMTE2JTsg MSBzZWNvbmQgaW4gMjQgaG91cnMpOyBhbmQgaWYgeW91IGRvIG5lZWQgdGhhdCBwcmVjaXNpb24g aXQgaXMgc3RpbGwgcG9zc2libGUgYXMgdGhlIHNtZWFyaW5nIGlzIHNpbXBsZSAmIGRldGVybWlu aXN0aWMgb25jZSB5b3Uga25vdyB3aGVuIGxlYXAgc2Vjb25kcyBvY2N1ci4NCg0KLS0NCkphbWVz IE1hbmdlcg0K From nobody Sun Jan 28 22:24:41 2018 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 46B16131676 for ; Sun, 28 Jan 2018 22:24:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 b3cVg2wKB1QL for ; Sun, 28 Jan 2018 22:24:38 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 A309A13166E for ; Sun, 28 Jan 2018 22:24:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=K7g9Qd3BGD4edRjptfJT3peO+zZRfSKGYE06EEIqCr8=; b=MB2yKQy8oPobrJnqXAeo+vRkqz YpmaUJbRgAQisZq28xstm9lv+3nkLylTLXInK8ulvUy0LI8WswyuCc/XH3vo0mTbOvZEwt7LFFEV1 wUelS64bXZ2p1Efe92EBjAL/hMmFa8JGoVf03y3cpVtKR1ZnzgUzktLBt9ysthVy5QkQIHOArYpCF Ipg68WlP4JE+q6OivYI1Uh1vHo+LnWazjpfv7bZtOqcYQY7KXjlWoooKv/Kml+2xjFSv93FfiAoRQ ymzxkNimQ+/4dwOTQjQC2qXECv7eGIQx+f4BX10og/d8Nep60viZwpHlllQTkRJ+CijxvprOhX1bC lmM0qmTw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:63256 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1eg2rq-002Eig-ST; Mon, 29 Jan 2018 01:24:35 -0500 To: "Manger, James" , Applications and Real-Time Area Discussion References: <151641287464.3257.11011391661979125459.idtracker@ietfa.amsl.com> <20180127190806.GA23684@ucolick.org> From: Joe Touch Message-ID: Date: Sun, 28 Jan 2018 22:24:27 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [art] Fwd: Confirm submission of I-D draft-touch-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: Mon, 29 Jan 2018 06:24:40 -0000 Hi, James, On 1/28/2018 8:49 PM, Manger, James wrote: > Comments on draft-touch-time-03 (https://tools.ietf.org/html/draft-touch-time-03): > > Given that the main argument against a time scale that smears out leap seconds is the lack of a current standard, Please recheck the draft. That is not the main argument; there are many other reasons, not the least of which is the inability of a method to convert reliably from smeared time to those used in nearly every other context. > the best contribution this document could make is to document as an RFC the "24-hour linear smear from noon to noon UTC" now used by Google (https://developers.google.com/time/smear), Amazon etc. That means interval measurements are not complicated at all unless you need precision better that 11.6ppm (0.00116%; 1 second in 24 hours); and if you do need that precision it is still possible as the smearing is simple & deterministic once you know when leap seconds occur. 11.6 ppm is 11.6 milliseconds. There are many systems that need precision far beyond that, down at 1ms or even lower. Joe From nobody Mon Jan 29 10:11:53 2018 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 35D3E12FAA6; Mon, 29 Jan 2018 10:11:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=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 pn4G-07qjsSq; Mon, 29 Jan 2018 10:11:36 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 BB88A12FAA8; Mon, 29 Jan 2018 10:11:35 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id t134so6705539qke.5; Mon, 29 Jan 2018 10:11:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ydk8DCN0eqdk2sozdku8qAyQ7ElOo+OzA5isX37X/WU=; b=WsVF7I/+yO0Rbz5A0gsyMSqJYsr5AdXLeDTMhwVTzdWAnaeERp+Xw05Qgjzmp45XdT OT9fEH+A4GUd3U52E/9cfx4UkMKLNtYoMq02aIWi8iWv5vAjCoWD8UCbn6vYcB63hHh2 UEH9TX5fFi+2QwYvW0tVwFNC5feiS3DgnKcLfAR4h8GaLea23f6J82TY8aXZP/4tRI9o waAflPd82Nal/K02ofk7WQo+A1S94a4vT1eJwmsRBZ68rJ+Fd6Nrz13lkBTbuY+ht6WI Sjr8cWjb/+F14lc1ddD9Q5U5ikk6Ipg0Bzd9C2siIjloZ2TwDaGNbFkwbSbYt0kbBL4E j0aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ydk8DCN0eqdk2sozdku8qAyQ7ElOo+OzA5isX37X/WU=; b=aNJberwqifRNFxlir5kMSZmS3gJIX1khiepwg3uycjCrXJElJ17jjhcq+P8sSoutpk pYDRqhSC+dWBA7m67R6qZityCp1T9YFBavrB9uTxaLED+A0baABhN2KAclG+MkLwc//S lIDaF0nZtcJdsNew2qTPI7/lqQOlzGq3jOVCoS8eCcIl80+0R0vTtQrluRMVIxBPdJtk KbFU47/v78AMAL9I7uMm0bJa9jhKFXy7LWtvQnvTUOBSNfbG2VCdIUx8XvkWhqvLLz/5 VyFfFNYMhU3MZSD0MNd/ZqTvx1hXOVBtfaG6W5dia5cFnPajoXSwVYT7Nr0xkqI+GPTf BVUw== X-Gm-Message-State: AKwxytfLKsx49YFwXvQHmKmBLth4jAG5wH3QznzLkHhVDULuIOn95Ji5 qoj6yxuEy6OXSorKTLIfEq3zAy5dLAQQANARJvU= X-Google-Smtp-Source: AH8x224+YbNMCX03zderzuZfruLTA7JDBiXUuq9VyKLzCWlh2Xip0b9y5O0bP4Wxt5TGt9o56I+I5NNJVwg0jl1TuOQ= X-Received: by 10.233.232.135 with SMTP id a129mr36243655qkg.347.1517249494570; Mon, 29 Jan 2018 10:11:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.33.213 with HTTP; Mon, 29 Jan 2018 10:11:04 -0800 (PST) In-Reply-To: <221F1CDD2609C43811D017C3@PSB> References: <221F1CDD2609C43811D017C3@PSB> From: Ted Hardie Date: Mon, 29 Jan 2018 10:11:04 -0800 Message-ID: To: John C Klensin Cc: Frank Ellermann , art@ietf.org, regext@ietf.org Content-Type: multipart/alternative; boundary="94eb2c034c8428db5a0563ee2d5a" Archived-At: Subject: Re: [art] New Version Notification for draft-hardie-iris-arpa-00.txt 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, 29 Jan 2018 18:11:38 -0000 --94eb2c034c8428db5a0563ee2d5a Content-Type: text/plain; charset="UTF-8" Sorry for the delay in replying; I was returning from the QUIC meeting in Melbourne. On Thu, Jan 25, 2018 at 7:13 AM, John C Klensin wrote: > > > --On Thursday, January 25, 2018 14:55 +0100 Frank Ellermann > wrote: > > > On 22 January 2018, Ted Hardie wrote: > >> If you have thoughts > > > > Maybe "obsoletes 4698" instead of only "updates 4698" would be > > clearer for readers of RFC 4698. > > Ted, > > Unless there are considerations that I don't understand, I agree > with Frank and would go a step further. While the document > indicates that IRIS was not actually deployed for address > registry usage, as far as I know it has not been deployed for > anything else either and has become part of the wreckage along > the path to try to replace Whois for registry database use. > > If the intent here is to say "we have given up on IRIS" > This came up in the context of the IAB trying to work out how useful some of the existing delegations in .arpa are, and the current draft reflects that. Updating RFC 4698 was, in other words, the simplest thing we could do. Given the feedback, I'm fine with updating that to "obsoletes RFC 4698", since the data support the notion that this is not currently in use. I don't have the data to support a broader statement about IRIS, as I know that there was some deployment at one time. I would be fine seeing a deprecation if one is warranted, in other words, but I'm not sure I can put one forward to the community. Do you object to obsoleting just RFC 4698 by this document? regards, Ted > (probably just recognizing what has happened historically), then > we should be formally obsoleting all of the IRIS documents at > the same time (and/or moving them to Historic) so they are no > longer listed as Proposed Standards and implicitly recommended. > That means at least RFC 4698 but also 4414 and the original > protocol specifications (3982-3983). That would require > broadening the scope of this document somewhat and adjusting its > title but, having skimmed through it, would not require > significant work. > > By contrast, if you believe that the ISOS protocols and the > other registries and identifiers are still relevant for > implementation and use, I think it would be helpful if this > document said that explicitly. For example, you might > explicitly indicate that IRIS had additional applications (with > a reference or two) and that, unlike the address registries, > those are still in use and Recommended. > > best, > john > > > --94eb2c034c8428db5a0563ee2d5a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry for the delay in replying; I was returning from the = QUIC meeting in Melbourne.

On Thu, Jan 25, 2018 at 7:13 AM, John C Klensin <john-ietf@jc= k.com> wrote:


--On Thursday, January 25, 2018 14:55 +0100 Frank Ellermann
<hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com> wrote:
> On 22 January 2018, Ted Hardie wrote:
>> If you have thoughts
>
> Maybe "obsoletes 4698" instead of only "updates 4698&qu= ot; would be
> clearer for readers of RFC 4698.

Ted,

Unless there are considerations that I don't understand, I agree
with Frank and would go a step further.=C2=A0 =C2=A0While the document
indicates that IRIS was not actually deployed for address
registry usage, as far as I know it has not been deployed for
anything else either and has become part of the wreckage along
the path to try to replace Whois for registry database use.

If the intent here is to say "we have given up on IRIS"

This came up in the context of the IAB trying to= work out how useful some of the existing delegations in .arpa are, and the= current draft reflects that.=C2=A0 Updating RFC 4698 was, in other words, = the simplest thing we could do.=C2=A0 Given the feedback, I'm fine with= updating that to "obsoletes RFC 4698", since the data support th= e notion that this is not currently in use.

I don&= #39;t have the data to support a broader statement about IRIS, as I know th= at there was some deployment at one time.=C2=A0 I would be fine seeing a de= precation if one is warranted, in other words, but I'm not sure I can p= ut one forward to the community.

Do you object to obsol= eting just RFC 4698 by this document?

<= /div>
regards,
Ted
=
=C2=A0
(probably just recognizing what has happened historically), then
we should be formally obsoleting all of the IRIS documents at
the same time (and/or moving them to Historic) so they are no
longer listed as Proposed Standards and implicitly recommended.
That means at least RFC 4698 but also 4414 and the original
protocol specifications (3982-3983).=C2=A0 That would require
broadening the scope of this document somewhat and adjusting its
title but, having skimmed through it, would not require
significant work.

By contrast, if you believe that the ISOS protocols and the
other registries and identifiers are still relevant for
implementation and use, I think it would be helpful if this
document said that explicitly.=C2=A0 =C2=A0For example, you might
explicitly indicate that IRIS had additional applications (with
a reference or two) and that, unlike the address registries,
those are still in use and Recommended.

best,
=C2=A0 =C2=A0john



--94eb2c034c8428db5a0563ee2d5a-- From nobody Mon Jan 29 11:27:52 2018 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 1492112FAB1; Mon, 29 Jan 2018 11:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, 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 X-nEqOdZ2ATD; Mon, 29 Jan 2018 11:27:41 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3488612FADB; Mon, 29 Jan 2018 11:27:40 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1egF5f-0001p9-Lg; Mon, 29 Jan 2018 14:27:39 -0500 Date: Mon, 29 Jan 2018 14:27:32 -0500 From: John C Klensin To: Ted Hardie cc: Frank Ellermann , art@ietf.org, regext@ietf.org Message-ID: <9AAAF5E9B148CF62E0EAC41F@PSB> In-Reply-To: References: <221F1CDD2609C43811D017C3@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [art] New Version Notification for draft-hardie-iris-arpa-00.txt 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, 29 Jan 2018 19:27:45 -0000 --On Monday, January 29, 2018 10:11 -0800 Ted Hardie wrote: > Sorry for the delay in replying; I was returning from the QUIC > meeting in Melbourne. > > On Thu, Jan 25, 2018 at 7:13 AM, John C Klensin > wrote: >> --On Thursday, January 25, 2018 14:55 +0100 Frank Ellermann >> wrote: >> >> > On 22 January 2018, Ted Hardie wrote: >> >> If you have thoughts >> > >> > Maybe "obsoletes 4698" instead of only "updates 4698" would >> > be clearer for readers of RFC 4698. >> >> Ted, >> >> Unless there are considerations that I don't understand, I >> agree with Frank and would go a step further. While the >> document indicates that IRIS was not actually deployed for >> address registry usage, as far as I know it has not been >> deployed for anything else either and has become part of the >> wreckage along the path to try to replace Whois for registry >> database use. >> >> If the intent here is to say "we have given up on IRIS" >> > > This came up in the context of the IAB trying to work out how > useful some of the existing delegations in .arpa are, and the > current draft reflects that. Updating RFC 4698 was, in other > words, the simplest thing we could do. Given the feedback, > I'm fine with updating that to "obsoletes RFC 4698", since the > data support the notion that this is not currently in use. > > I don't have the data to support a broader statement about > IRIS, as I know that there was some deployment at one time. I > would be fine seeing a deprecation if one is warranted, in > other words, but I'm not sure I can put one forward to the > community. > > Do you object to obsoleting just RFC 4698 by this document? Object, not really. I do see it as creating something of a silly state in which we leave the protocol apparently active and recommended while eliminating a key facility for utilizing it in a particular way should one decide to do so. The only thing that makes the address registries different in this regard is that the number of possible uses is small and easily identified. One of your comments above helps identify what concerns me about this document, so let me take a step back and address that. So the IAB decides that it should do a review of "how useful some of the existing delegations in .arpa are". Seems worthwhile to me although I might wonder whether the Internet and the various protocol relationships were in such good shape that the IAB should prioritize that work, But then I'd expect an I-D that said that the IAB had conducted that review and was, e.g., elimination all of the subdomains/ registries that were unused or that supported obsolete protocols (or particular applications of protocols) and obsoleted the standards-track documents creating those registries. Perfectly orderly. But, here, the document seems to single out one particular subtree and a single application of a protocol that has gotten little or no traction in it more general form. It that is the topic, I think the IAB is under some obligation to explore that protocol and its present-day utility and active implementations a bit further (especially in the light of Andy's note) or, if that is too burdensome, to include a (very brief) explanation about why IRIS itself is not being retired and/or why the IAB doesn't consider it useful to examine that question. Disclaimer: My position on this issue is conditioned by part of my view of the role of the IAB in current times. That view is that the IAB should be functioning as a sort of architectural think tank and, (at least at the conceptual level), an oversight body. That, in turn, implies that the IAB should be looking at whole-system issues, specifically including how particular protocols and sets of protocols interact with what has recently started being called the "Internet ecosystem". While it isn't my personal highest priority, I think the IAB's taking on a review of RFC 3172 and clean-out of registries that are no longer relevant would be a find idea. Conversely, if the IAB decides at another look --at a system-wide level-- at registry databases of many or all flavors is in order, I'd consider that a worthy task, even if it focused on cleaning up the options that have never taken off, whether you went back to Whois++ (which has been declared obsolete) or Rwhois (which hasn't). But to clean out a single application (and registry) or a single protocol just seems to me like a poor use of time and a likely source of confusion for those who might decide to read and think about the IRIS protocol documents. My vocabulary is somewhat different from that used by Brian and the IAB in 2008, but I believe it is consistent with RFC 2850. If the community no longer believes in that vision of the IAB, my view may be irrelevant, but a revision or replacement for RFC 2850 is probably in order. best, john From nobody Mon Jan 29 11:55:58 2018 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 C777212EAB4; Mon, 29 Jan 2018 11:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=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 pyCrJ9iKTV8M; Mon, 29 Jan 2018 11:55:50 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 BAAA512F9A5; Mon, 29 Jan 2018 11:55:49 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id t134so7137014qke.5; Mon, 29 Jan 2018 11:55:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wXBKViPlJJED1W4QgMgoi0rMqwyw1LfbbNfIyhn+kRU=; b=PvNH1DmH6qd+9QLbIHybtwtOeqUBgf5wWXp4fO0KIGHVfUB+Q82EJ5xBaq6+v69TU1 t7J14qhQgmZFbpF7Kc7q7JUckHf2UCW10dgG4CU9E3uu1ygD5mjgJYq5qfw6c0ShifMK qEjaUBMvpIDSgh0k4EjHt8oQZ6sVJAvopzwPRYxNvX2HcR3Y/OwLX4f/FUq3/3MeXIbU b0U7CPbmSRO9SYBFTorCkxiM+c7mTFpaDsSLp+WDBvyaMEYYJStcs3gQPh7OOW1GYnfO 8C7JFuIB5d1/HAJgTQvn5HjVvtSgJGfm8w7M2d2vhD9YtCax+6SpwKzrEswRMLKRHk1Y wMdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wXBKViPlJJED1W4QgMgoi0rMqwyw1LfbbNfIyhn+kRU=; b=Nvkhr+Omjhinzv6OwnvXXDTW338XWoQN/0W1qPoJxk4angZgkViAIHhMdLiCQiX4aO NbI+4ytJ6YFNocsFTgbZgtG56HGz3Bz7nUjNwUesdfdviFIQTMYFO3aJ1MaoJjK42K5d B9HJh6/gD+MYkZHuE1luTvjku6ctHQhLWegVO+4H/EFOoIeTia6gieiDbs2GlOENtg8o ejMpNBiRrEwNScfqt+ao0TNUdUAHs3++96Tfzo8nTE4N9wOF+kyDSzvA4SAU/LfWIVwg VQ6yXnh8J1wKnk+mW5iiCAFxoiHAAa51IDv8p1LiG1Q4NQqefJfHc0+e+dPIggfaj2XK rB5Q== X-Gm-Message-State: AKwxytcOI963SbLo7UXjGfNqUlGArV0rOQZ3C2fazgNKfk4l4Q0PomPF nr+29cBG/XUMonjw2unuTk/MvzxIANk6GDi24rA= X-Google-Smtp-Source: AH8x2250kfpFwtpLx+sbSQ578uXWMqQ42zAlPBvFioU0fQUe/cMRERtLqq05DzmnePtKnovzINXPisZ8ov1sn90iz5w= X-Received: by 10.55.192.202 with SMTP id v71mr35826957qkv.294.1517255748544; Mon, 29 Jan 2018 11:55:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.33.213 with HTTP; Mon, 29 Jan 2018 11:55:18 -0800 (PST) In-Reply-To: <9AAAF5E9B148CF62E0EAC41F@PSB> References: <221F1CDD2609C43811D017C3@PSB> <9AAAF5E9B148CF62E0EAC41F@PSB> From: Ted Hardie Date: Mon, 29 Jan 2018 11:55:18 -0800 Message-ID: To: John C Klensin Cc: Frank Ellermann , art@ietf.org, regext@ietf.org Content-Type: multipart/alternative; boundary="001a1147a26ceceeb70563efa1a9" Archived-At: Subject: Re: [art] New Version Notification for draft-hardie-iris-arpa-00.txt 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, 29 Jan 2018 19:55:53 -0000 --001a1147a26ceceeb70563efa1a9 Content-Type: text/plain; charset="UTF-8" On Mon, Jan 29, 2018 at 11:27 AM, John C Klensin wrote: > > >> Unless there are considerations that I don't understand, I > >> agree with Frank and would go a step further. While the > >> document indicates that IRIS was not actually deployed for > >> address registry usage, as far as I know it has not been > >> deployed for anything else either and has become part of the > >> wreckage along the path to try to replace Whois for registry > >> database use. > >> > >> If the intent here is to say "we have given up on IRIS" > >> > > > > This came up in the context of the IAB trying to work out how > > useful some of the existing delegations in .arpa are, and the > > current draft reflects that. Updating RFC 4698 was, in other > > words, the simplest thing we could do. Given the feedback, > > I'm fine with updating that to "obsoletes RFC 4698", since the > > data support the notion that this is not currently in use. > > > > I don't have the data to support a broader statement about > > IRIS, as I know that there was some deployment at one time. I > > would be fine seeing a deprecation if one is warranted, in > > other words, but I'm not sure I can put one forward to the > > community. > > > > Do you object to obsoleting just RFC 4698 by this document? > > Object, not really. I do see it as creating something of a > silly state in which we leave the protocol apparently active and > recommended while eliminating a key facility for utilizing it in > a particular way should one decide to do so. This actually reflects how the IRIS documents specified the extension to include address registrations; that facility was separately specified and could have been separately deployed. As far as we can tell, no one has deployed AREG. I've agreed that obsoleting the document, rather than simply updating it, appears to have community support. To put this another way, I personally see the AREG and DREG uses of IRIS as distinct, and I believe that reflects both the document structure and my ability to get data on their use. The data provided by examining the logs shows that there is no current use of RFC 4698 facilities, but there is no parallel data set for DREG available to me. > The only thing > that makes the address registries different in this regard is > that the number of possible uses is small and easily identified. > > One of your comments above helps identify what concerns me about > this document, so let me take a step back and address that. So > the IAB decides that it should do a review of "how useful some > of the existing delegations in .arpa are". Seems worthwhile to > me although I might wonder whether the Internet and the various > protocol relationships were in such good shape that the IAB > should prioritize that work, It originally came up in the context of https://www.iab.org/documents/correspondence-reports-documents/2017-2/iab-statement-on-the-registration-of-special-use-names-in-the-arpa-domain/ but the discussion after that was pretty clear that the IAB couldn't deprecate anything requested in Proposed Standard without an IETF consensus document. That's why this is a personal document going for proposed standard, not an IAB document. > But then I'd expect an I-D that > said that the IAB had conducted that review and was, e.g., > elimination all of the subdomains/ registries that were unused > or that supported obsolete protocols (or particular applications > of protocols) and obsoleted the standards-track documents > creating those registries. Perfectly orderly. > > Each of the others where we might consider deprecation also requires an IETF consensus document, and they represent different communities of use (or did when specified). Putting them all into one document would make this more "the IAB has decided" than "X, who happens to be a member of the IAB, suggests that the IETF should consider deprecation of FOO". The latter seems more in keeping with our practice, at least as far as I see it. Had the community already obsoleted the relevant protocols, then I agree, the IAB could clean up the delegations without further ado. regards, Ted --001a1147a26ceceeb70563efa1a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jan 29, 2018 at 11:27 AM, John C Klensin <john-ie= tf@jck.com> wrote:

>> Unless there are considerations that I don't understand, I
>> agree with Frank and would go a step further.=C2=A0 =C2=A0While th= e
>> document indicates that IRIS was not actually deployed for
>> address registry usage, as far as I know it has not been
>> deployed for anything else either and has become part of the
>> wreckage along the path to try to replace Whois for registry
>> database use.
>>
>> If the intent here is to say "we have given up on IRIS"<= br> >>
>
> This came up in the context of the IAB trying to work out how
> useful some of the existing delegations in .arpa are, and the
> current draft reflects that.=C2=A0 Updating RFC 4698 was, in other
> words, the simplest thing we could do.=C2=A0 Given the feedback,
> I'm fine with updating that to "obsoletes RFC 4698", sin= ce the
> data support the notion that this is not currently in use.
>
> I don't have the data to support a broader statement about
> IRIS, as I know that there was some deployment at one time.=C2=A0 I > would be fine seeing a deprecation if one is warranted, in
> other words, but I'm not sure I can put one forward to the
> community.
>
> Do you object to obsoleting just RFC 4698 by this document?

Object, not really.=C2=A0 I do see it as creating something of = a
silly state in which we leave the protocol apparently active and
recommended while eliminating a key facility for utilizing it in
a particular way should one decide to do so.=C2=A0

This actually reflects how the IRIS documents specified the extens= ion to include address registrations; that facility was separately specifie= d and could have been separately deployed.=C2=A0 As far as we can tell, no = one has deployed AREG.=C2=A0 I've agreed that obsoleting the document, = rather than simply updating it, appears to have community support.=C2=A0 To= put this another way, I personally see the AREG and DREG uses of IRIS as d= istinct, and I believe that reflects both the document structure and my abi= lity to get data on their use.=C2=A0=C2=A0 The data provided by examining t= he logs shows that there is no current use of RFC 4698 facilities, but ther= e is no parallel data set for DREG available to me.
=C2=A0
=C2=A0The only thing that makes the address registries different in this regard is
that the number of possible uses is small and easily identified.

One of your comments above helps identify what concerns me about
this document, so let me take a step back and address that.=C2=A0 So
the IAB decides that it should do a review of "how useful some
of the existing delegations in .arpa are".=C2=A0 Seems worthwhile to me although I might wonder whether the Internet and the various
protocol relationships were in such good shape that the IAB
should prioritize that work,=C2=A0

It orig= inally came up in the context of https://www.iab.org/documents/corre= spondence-reports-documents/2017-2/iab-statement-on-the-registration-of-spe= cial-use-names-in-the-arpa-domain/ but the discussion after that was pr= etty clear that the IAB couldn't deprecate anything requested in Propos= ed Standard without an IETF consensus document.=C2=A0 That's why this i= s a personal document going for proposed standard, not an IAB document.
=

=C2=A0
But then I'd expect an I-D that
said that the IAB had conducted that review and was, e.g.,
elimination all of the subdomains/ registries that were unused
or that supported obsolete protocols (or particular applications
of protocols) and obsoleted the standards-track documents
creating those registries.=C2=A0 Perfectly orderly.


Each of the others where we might cons= ider deprecation also requires an IETF consensus document, and they represe= nt different communities of use (or did when specified).=C2=A0 Putting them= all into one document would make this more "the IAB has decided"= than "X, who happens to be a member of the IAB,=C2=A0 suggests that t= he IETF should consider deprecation of FOO".=C2=A0 The latter seems mo= re in keeping with our practice, at least as far as I see it.

Had the community already obsoleted the relevant protocols,= then I agree, the IAB could clean up the delegations without further ado.<= br>

regards,

Ted


--001a1147a26ceceeb70563efa1a9-- From nobody Mon Jan 29 12:35:44 2018 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 99CEB12EB76; Mon, 29 Jan 2018 12:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, 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 Ewj_GJn-laRA; Mon, 29 Jan 2018 12:35:40 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A8E7126CF9; Mon, 29 Jan 2018 12:35:40 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1egG9S-00033T-JC; Mon, 29 Jan 2018 15:35:38 -0500 Date: Mon, 29 Jan 2018 15:35:31 -0500 From: John C Klensin To: Ted Hardie cc: Frank Ellermann , art@ietf.org, regext@ietf.org Message-ID: In-Reply-To: References: <221F1CDD2609C43811D017C3@PSB> <9AAAF5E9B148CF62E0EAC41F@PSB> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [art] New Version Notification for draft-hardie-iris-arpa-00.txt 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, 29 Jan 2018 20:35:42 -0000 Ok, Ted, I can buy this, albeit somewhat reluctantly and noting that the IAB has passed IAB documents that require community consensus off to the IESG for determination of that consensus in the past. I believe a paragraph of explanation, in your personal capacity and very much along the lines of what you say below, would be desirable, but don't see its absence as a showstopper. thanks for the explanation. john --On Monday, January 29, 2018 11:55 -0800 Ted Hardie wrote: > On Mon, Jan 29, 2018 at 11:27 AM, John C Klensin > wrote: > >> >> >> Unless there are considerations that I don't understand, I >> >> agree with Frank and would go a step further. While the >> >> document indicates that IRIS was not actually deployed for >> >> address registry usage, as far as I know it has not been >> >> deployed for anything else either and has become part of >> >> the wreckage along the path to try to replace Whois for >> >> registry database use. >> >> >> >> If the intent here is to say "we have given up on IRIS" >> >> >> > >> > This came up in the context of the IAB trying to work out >> > how useful some of the existing delegations in .arpa are, >> > and the current draft reflects that. Updating RFC 4698 >> > was, in other words, the simplest thing we could do. Given >> > the feedback, I'm fine with updating that to "obsoletes RFC >> > 4698", since the data support the notion that this is not >> > currently in use. >> > >> > I don't have the data to support a broader statement about >> > IRIS, as I know that there was some deployment at one time. >> > I would be fine seeing a deprecation if one is warranted, in >> > other words, but I'm not sure I can put one forward to the >> > community. >> > >> > Do you object to obsoleting just RFC 4698 by this document? >> >> Object, not really. I do see it as creating something of a >> silly state in which we leave the protocol apparently active >> and recommended while eliminating a key facility for >> utilizing it in a particular way should one decide to do so. > > > This actually reflects how the IRIS documents specified the > extension to include address registrations; that facility was > separately specified and could have been separately deployed. > As far as we can tell, no one has deployed AREG. I've agreed > that obsoleting the document, rather than simply updating it, > appears to have community support. To put this another way, I > personally see the AREG and DREG uses of IRIS as distinct, and > I believe that reflects both the document structure and my > ability to get data on their use. The data provided by > examining the logs shows that there is no current use of RFC > 4698 facilities, but there is no parallel data set for DREG > available to me. > > >> The only thing >> that makes the address registries different in this regard is >> that the number of possible uses is small and easily >> identified. >> >> One of your comments above helps identify what concerns me >> about this document, so let me take a step back and address >> that. So the IAB decides that it should do a review of "how >> useful some of the existing delegations in .arpa are". Seems >> worthwhile to me although I might wonder whether the Internet >> and the various protocol relationships were in such good >> shape that the IAB should prioritize that work, > > > It originally came up in the context of > https://www.iab.org/documents/correspondence-reports-documents > /2017-2/iab-statement-on-the-registration-of-special-use-names > -in-the-arpa-domain/ but the discussion after that was pretty > clear that the IAB couldn't deprecate anything requested in > Proposed Standard without an IETF consensus document. That's > why this is a personal document going for proposed standard, > not an IAB document. > > > >> But then I'd expect an I-D that >> said that the IAB had conducted that review and was, e.g., >> elimination all of the subdomains/ registries that were unused >> or that supported obsolete protocols (or particular >> applications of protocols) and obsoleted the standards-track >> documents creating those registries. Perfectly orderly. >> >> > Each of the others where we might consider deprecation also > requires an IETF consensus document, and they represent > different communities of use (or did when specified). Putting > them all into one document would make this more "the IAB has > decided" than "X, who happens to be a member of the IAB, > suggests that the IETF should consider deprecation of FOO". > The latter seems more in keeping with our practice, at least > as far as I see it. > > Had the community already obsoleted the relevant protocols, > then I agree, the IAB could clean up the delegations without > further ado. > > regards, > > Ted From nobody Mon Jan 29 23:07:05 2018 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 5F393131A23 for ; Mon, 29 Jan 2018 23:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] 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 Jo3zDAxD5alQ for ; Mon, 29 Jan 2018 23:07:02 -0800 (PST) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) (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 D96871315F5 for ; Mon, 29 Jan 2018 23:06:15 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.46,433,1511787600"; d="scan'208";a="201946038" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 30 Jan 2018 18:06:12 +1100 X-IronPort-AV: E=McAfee;i="5900,7806,8769"; a="607826150" Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipcbni.tcif.telstra.com.au with ESMTP; 30 Jan 2018 18:06:12 +1100 Received: from wsapp5584.srv.dir.telstra.com (10.75.131.20) by wsmsg3702.srv.dir.telstra.com (172.49.40.170) with Microsoft SMTP Server (TLS) id 8.3.485.1; Tue, 30 Jan 2018 18:06:09 +1100 Received: from wsapp5584.srv.dir.telstra.com (10.75.131.20) by wsapp5584.srv.dir.telstra.com (10.75.131.20) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 30 Jan 2018 18:06:08 +1100 Received: from AUS01-SY3-obe.outbound.protection.outlook.com (10.172.229.125) by wsapp5584.srv.dir.telstra.com (10.75.131.20) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Tue, 30 Jan 2018 18:06:08 +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=svOeZgyyiHNZilgeIxp2z9uyaB2rJ6pUSg8JTKes42M=; b=K8/T9SnN29pXVRxhNl4pZ2WzVCtGvmVu4qAApeN/zWypQAINNeStaSxxZvDkSJnhTT8d22Yvn9LTVC80IkrSYkQtNSbTZZRMD7rZV4yCXzo5IanEMJxXPbI7/H8+hV30LqpIf4PM5/6UIauyeqd/MJ/uKWD1BdMCTB1wscdhsfI= Received: from ME1PR01MB1076.ausprd01.prod.outlook.com (10.169.167.15) by ME1PR01MB2052.ausprd01.prod.outlook.com (10.171.13.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.14; Tue, 30 Jan 2018 07:06:07 +0000 Received: from ME1PR01MB1076.ausprd01.prod.outlook.com ([fe80::5ee:c0f:e19b:9ff8]) by ME1PR01MB1076.ausprd01.prod.outlook.com ([fe80::5ee:c0f:e19b:9ff8%18]) with mapi id 15.20.0444.016; Tue, 30 Jan 2018 07:06:07 +0000 From: "Manger, James" To: Joe Touch , "Applications and Real-Time Area Discussion" Thread-Topic: [art] Fwd: Confirm submission of I-D draft-touch-time Thread-Index: AQHTk+vhectROW+ThkqgekqjKPGTO6OIHHsAgAIujeCAACDAgIABdqLQ Date: Tue, 30 Jan 2018 07:06:07 +0000 Message-ID: References: <151641287464.3257.11011391661979125459.idtracker@ietfa.amsl.com> <20180127190806.GA23684@ucolick.org> In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=James.H.Manger@team.telstra.com; x-originating-ip: [203.35.9.32] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; ME1PR01MB2052; 7:ANbQjBlDY+ilIqfNsTcORpHeile9ZTuXuSO8PvB0U+Ua8p3IHy3nehDwsaPw8De5VgX8E0FvSOYckzIbEelHV7HyauWGQLVJhRomBaAT9GV55L1xAoXSORFbKlLtnyITPmsKDjxLEsFx4oW/oKcGVQ5GESnNncVzydOtpnTkHqhIdzTztFOR+GM6Zt9my1N64KRYryIor41l3QGZS11SXdrVfiWPg2cxgWhrfUKqYg/Ke00m/2YdI+dj4CWeIlW9 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: edc3b305-e216-4b5f-842c-08d567afef9f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:ME1PR01MB2052; x-ms-traffictypediagnostic: ME1PR01MB2052: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(168375693250761); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231101)(944501161)(6041288)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:ME1PR01MB2052; BCL:0; PCL:0; RULEID:; SRVR:ME1PR01MB2052; x-forefront-prvs: 0568F32D91 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39380400002)(366004)(346002)(376002)(39860400002)(199004)(189003)(6306002)(72206003)(55016002)(229853002)(478600001)(53936002)(66066001)(110136005)(2900100001)(2950100002)(68736007)(76176011)(5660300001)(42882006)(9686003)(7696005)(3280700002)(316002)(99286004)(3660700001)(6436002)(8936002)(81166006)(33656002)(81156014)(8676002)(106356001)(102836004)(14454004)(105586002)(6246003)(5250100002)(2906002)(86362001)(25786009)(97736004)(6506007)(7736002)(26005)(3846002)(93886005)(186003)(74316002)(305945005)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:ME1PR01MB2052; H:ME1PR01MB1076.ausprd01.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: team.telstra.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: LMA7eeISMQJDy/eF+i7QXIy+eEamyDP9mQI+iEpjCffreXxz0qWNh9ju5emma4+Bea/eoUf8gkkSoaVSnebJyw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: edc3b305-e216-4b5f-842c-08d567afef9f X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2018 07:06:07.9470 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854 X-MS-Exchange-Transport-CrossTenantHeadersStamped: ME1PR01MB2052 X-OriginatorOrg: team.telstra.com Archived-At: Subject: Re: [art] Fwd: Confirm submission of I-D draft-touch-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, 30 Jan 2018 07:07:04 -0000 Pj4gQ29tbWVudHMgb24gZHJhZnQtdG91Y2gtdGltZS0wMyAoaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXRvdWNoLXRpbWUtMDMpOg0KPj4NCj4+IEdpdmVuIHRoYXQgdGhlIG1haW4g YXJndW1lbnQgYWdhaW5zdCBhIHRpbWUgc2NhbGUgdGhhdCBzbWVhcnMgb3V0IGxlYXAgc2Vjb25k cyBpcyB0aGUgbGFjayBvZiBhIGN1cnJlbnQgc3RhbmRhcmQsIA0KPiBQbGVhc2UgcmVjaGVjayB0 aGUgZHJhZnQuIFRoYXQgaXMgbm90IHRoZSBtYWluIGFyZ3VtZW50OyB0aGVyZSBhcmUgbWFueQ0K PiBvdGhlciByZWFzb25zLCBub3QgdGhlIGxlYXN0IG9mIHdoaWNoIGlzIHRoZSBpbmFiaWxpdHkg b2YgYSBtZXRob2QgdG8NCj4gY29udmVydCByZWxpYWJseSBmcm9tIHNtZWFyZWQgdGltZSB0byB0 aG9zZSB1c2VkIGluIG5lYXJseSBldmVyeSBvdGhlcg0KPiBjb250ZXh0Lg0KDQoiMjQtaG91ciBs aW5lYXIgc21lYXIgZnJvbSBub29uIHRvIG5vb24gVVRDIiBhbGxvd3MgcHJlY2lzZSBjb252ZXJz aW9uIHRvIFVUQy4NCklmIHlvdSBrbm93IHlvdXIgdGltZSBpcyBzbWVhcmVkLCBidXQgbm90IHdo aWNoIHZhcmlldHkgb2Ygc21lYXIsIHRoZW4geW91IGNhbm5vdCBwcmVjaXNlbHkgY29udmVydCAt LSBidXQgdGhhdCB3YXMgd2h5IDEgc21lYXIgUkZDIHdvdWxkIGJlIGdyZWF0Lg0KRm9yIHJlbGlh YmlsaXR5IHdoZW4geW91IGFyZW4ndCBjZXJ0YWluIGhvdyBzeXN0ZW1zIGhhbmRsZSBsZWFwIHNl Y29uZHMgKFVUQyBvciBzbWVhciBvciBpZ25vcmUgb3IgLi4uKSwgc21lYXJlZCB0aW1lIHdpbGwg YWxtb3N0IGFsd2F5cyBiZSBiZXR0ZXIuIDk5LjklIG9mIHRoZSB0aW1lIChkYXlzIHdpdGhvdXQg YSBsZWFwIHNlY29uZCkgaW50ZXJ2YWxzIGFyZSBwcmVjaXNlLCBpbiB0aGUgcmVtYWluaW5nIGNv cm5lciBjYXNlcyBhIDI0LWhvdXIgbGluZWFyIHNtZWFyIGVuc3VyZXMgYW4gZXJyb3IgaW4gKmFu eSogaW50ZXJ2YWwgZHVyYXRpb24gKHdoZXRoZXIgMW5zIG9yIDFocikgaXMgYWx3YXlzIGxlc3Mg dGhhbiAwLjAwMTE2JSwgd2hpbGUgb3RoZXIgdGltZXNjYWxlcyBtaWdodCBieSBwcmVjaXNlIG9y IG1pZ2h0IGdpdmUgYSArLy0xcyBlcnJvciAod2hpY2ggbWlnaHQgYmUgYSAwLjAwMSUgZXJyb3Ig b3IgYSAxMCUgZXJyb3Igb3IgYSAxMDAwMCUgZXJyb3IgZGVwZW5kaW5nIG9uIHRoZSBkdXJhdGlv biBvZiB0aGUgaW50ZXJ2YWwhKS4NCg0KDQo+PiB0aGUgYmVzdCBjb250cmlidXRpb24gdGhpcyBk b2N1bWVudCBjb3VsZCBtYWtlIGlzIHRvIGRvY3VtZW50IGFzIGFuIFJGQyB0aGUgIjI0LWhvdXIg bGluZWFyIHNtZWFyIGZyb20gbm9vbiB0byBub29uIFVUQyIgbm93IHVzZWQgYnkgR29vZ2xlICho dHRwczovL2RldmVsb3BlcnMuZ29vZ2xlLmNvbS90aW1lL3NtZWFyKSwgQW1hem9uIGV0Yy4gVGhh dCBtZWFucyBpbnRlcnZhbCBtZWFzdXJlbWVudHMgYXJlIG5vdCBjb21wbGljYXRlZCBhdCBhbGwg dW5sZXNzIHlvdSBuZWVkIHByZWNpc2lvbiBiZXR0ZXIgdGhhdCAxMS42cHBtICgwLjAwMTE2JTsg MSBzZWNvbmQgaW4gMjQgaG91cnMpOyBhbmQgaWYgeW91IGRvIG5lZWQgdGhhdCBwcmVjaXNpb24g aXQgaXMgc3RpbGwgcG9zc2libGUgYXMgdGhlIHNtZWFyaW5nIGlzIHNpbXBsZSAmIGRldGVybWlu aXN0aWMgb25jZSB5b3Uga25vdyB3aGVuIGxlYXAgc2Vjb25kcyBvY2N1ci4NCj4xMS42IHBwbSBp cyAxMS42IG1pbGxpc2Vjb25kcy4gVGhlcmUgYXJlIG1hbnkgc3lzdGVtcyB0aGF0IG5lZWQNCj5w cmVjaXNpb24gZmFyIGJleW9uZCB0aGF0LCBkb3duIGF0IDFtcyBvciBldmVuIGxvd2VyLg0KDQox MS42cHBtIGlzIE5PVCAxMS42bXMsIHVubGVzcyB5b3VyIGludGVydmFsIGlzIDEwMDBzLiBHb29n bGUncyBzbWVhciBnaXZlcyBhdCBsZWFzdCAxbXMgcHJlY2lzaW9uIGZvciBhbnkgaW50ZXJ2YWwg YmVsb3cgODYuNHMgaW4gZHVyYXRpb24uDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From nobody Tue Jan 30 06:52:58 2018 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 12B4B131881 for ; Tue, 30 Jan 2018 06:52:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 7JBLWtdjTIB3 for ; Tue, 30 Jan 2018 06:52:54 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 AC1AA12EB94 for ; Tue, 30 Jan 2018 06:48:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=s+Qd4EZchfmPrPSaI3+UM7/rRo7ucPgByHPN1qzdXkQ=; b=r/3pTzrsRaYv4PzdqDDUitU7O lKl6mHGyfIOhNivaJjMwEFdOEjG0mndWLnMzPznGx6THlQ8b8CmgBexdicf4zhfoY04Q97tMBfNLX SvCyBJT633M67ym090PC78YWUZdphFpaBmzUqEnUlhQpy2nXiEL+XQnb9eTVGJi95ZOVmySJXYd2e KS5miE3uzQtIHqYNHBDFZofw0JEXO6GOJhODkRGtEdKcSvbhnEsjgQpgxzNob2wNDQWGdKTTofTcJ Idumer24orpCRRvWIuvCURwqnRRLxxaTofitukwjN6OLseVpZFmbzf1+RecSheKGgu5bvFWARMasl /OLLAteAA==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:52426 helo=[192.168.1.87]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1egXCz-001eHR-RF; Tue, 30 Jan 2018 09:48:31 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Joe Touch In-Reply-To: Date: Tue, 30 Jan 2018 06:48:22 -0800 Cc: Applications and Real-Time Area Discussion Content-Transfer-Encoding: quoted-printable Message-Id: References: <151641287464.3257.11011391661979125459.idtracker@ietfa.amsl.com> <20180127190806.GA23684@ucolick.org> To: "Manger, James" X-Mailer: Apple Mail (2.3445.5.20) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [art] Confirm submission of I-D draft-touch-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, 30 Jan 2018 14:52:57 -0000 > On Jan 29, 2018, at 11:06 PM, Manger, James = wrote: >=20 >>> Comments on draft-touch-time-03 = (https://tools.ietf.org/html/draft-touch-time-03): >>>=20 >>> Given that the main argument against a time scale that smears out = leap seconds is the lack of a current standard,=20 >> Please recheck the draft. That is not the main argument; there are = many >> other reasons, not the least of which is the inability of a method to >> convert reliably from smeared time to those used in nearly every = other >> context. >=20 > "24-hour linear smear from noon to noon UTC" allows precise conversion = to UTC. Only if you know exactly on what day the smear occurred. That means you = need to know the same kind of online information as UTC. > If you know your time is smeared, but not which variety of smear, then = you cannot precisely convert -- but that was why 1 smear RFC would be = great. It is the addition of smear that adds that confusion. We already have a = single, common time frame that is in widespread use, and using that = would avoid all of this. > For reliability when you aren't certain how systems handle leap = seconds (UTC or smear or ignore or ...), smeared time will almost always = be better.=20 A system that doesn=E2=80=99t support UTC is admitting it doesn=E2=80=99t = care about time to with a second anyway. =20 > 99.9% of the time (days without a leap second) intervals are precise, = in the remaining corner cases a 24-hour linear smear ensures an error in = *any* interval duration (whether 1ns or 1hr) is always less than = 0.00116%, while other timescales might by precise or might give a +/-1s = error (which might be a 0.001% error or a 10% error or a 10000% error = depending on the duration of the interval!).\ Smearing means you can no longer compare time intervals directly without = that error. The percentages you=E2=80=99re citing are simply not = acceptable - they could mean the difference of events happening in = different days or even years, given that the smear would happen over a = day within different time zones in different ways. UTC is the only way = to ensure that this isn=E2=80=99t true - all UTC times are directly = comparable and can be directly sequenced. So smearing adds a mess of complication - all just to give people the = incorrect impression that the time didn=E2=80=99t jump. However, time = DID jump - because government time is nearly universally based on UTC.=20= >=20 >=20 >>> the best contribution this document could make is to document as an = RFC the "24-hour linear smear from noon to noon UTC" now used by Google = (https://developers.google.com/time/smear), Amazon etc. That means = interval measurements are not complicated at all unless you need = precision better that 11.6ppm (0.00116%; 1 second in 24 hours); and if = you do need that precision it is still possible as the smearing is = simple & deterministic once you know when leap seconds occur. >> 11.6 ppm is 11.6 milliseconds. There are many systems that need >> precision far beyond that, down at 1ms or even lower. >=20 > 11.6ppm is NOT 11.6ms, unless your interval is 1000s. Google's smear = gives at least 1ms precision for any interval below 86.4s in duration. 1ms of error in a timestamp is more than enough to undermine financial = and government systems.=20 Joe= From nobody Tue Jan 30 22:38:14 2018 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 80CE01315D1 for ; Tue, 30 Jan 2018 22:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] 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 M6k9ydR9HkHe for ; Tue, 30 Jan 2018 22:38:09 -0800 (PST) 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 1CF371315D3 for ; Tue, 30 Jan 2018 22:38:07 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.46,438,1511787600"; d="scan'208";a="87722508" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipocni.tcif.telstra.com.au with ESMTP; 31 Jan 2018 17:38:04 +1100 X-IronPort-AV: E=McAfee;i="5900,7806,8769"; a="579433491" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcani.tcif.telstra.com.au with ESMTP; 31 Jan 2018 17:38:03 +1100 Received: from wsapp5584.srv.dir.telstra.com (10.75.131.20) by wsmsg3757.srv.dir.telstra.com (172.49.40.85) with Microsoft SMTP Server (TLS) id 8.3.485.1; Wed, 31 Jan 2018 17:38:03 +1100 Received: from wsapp5584.srv.dir.telstra.com (10.75.131.20) by wsapp5584.srv.dir.telstra.com (10.75.131.20) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 31 Jan 2018 17:38:02 +1100 Received: from AUS01-SY3-obe.outbound.protection.outlook.com (10.172.229.125) by wsapp5584.srv.dir.telstra.com (10.75.131.20) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Wed, 31 Jan 2018 17:38:02 +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=rr8MEroGbXk8bik1Z7oeK3F9jDNntwP8/yCtTFWZUbI=; b=YxgQAWQRzM0hPudcnL0G302pl4Pa02CGRRXY6IDRbgKrslggALaINolbsHrd/PdKsrZffzfbsz4v5yyAs7bzkv6z6WKrq1boaD/emjdnO+eThO4m9QZoV0odDS8vFa3Ry7Wr0fAFDL4Im5CWU2EbxSF56REznPNc27WPrmgFHUw= Received: from ME1PR01MB1076.ausprd01.prod.outlook.com (10.169.167.15) by ME1PR01MB0788.ausprd01.prod.outlook.com (10.169.165.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.14; Wed, 31 Jan 2018 06:38:01 +0000 Received: from ME1PR01MB1076.ausprd01.prod.outlook.com ([fe80::5ee:c0f:e19b:9ff8]) by ME1PR01MB1076.ausprd01.prod.outlook.com ([fe80::5ee:c0f:e19b:9ff8%18]) with mapi id 15.20.0444.016; Wed, 31 Jan 2018 06:38:01 +0000 From: "Manger, James" To: Joe Touch CC: Applications and Real-Time Area Discussion Thread-Topic: [art] Confirm submission of I-D draft-touch-time Thread-Index: AQHTmdlzxv26ZozYL02Z9YE3c32W9aONAA1w Date: Wed, 31 Jan 2018 06:38:01 +0000 Message-ID: References: <151641287464.3257.11011391661979125459.idtracker@ietfa.amsl.com> <20180127190806.GA23684@ucolick.org> In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.35.9.18] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; ME1PR01MB0788; 7:YZiRpnFDmu4kr5Ac8RE8vn0gdyAHsgvqDfGw7glTNdFh+UYdAq2OXBcLPO46QCgMIFFfCq/aG2gEMzvnrtrxEyHTt/XwftKInrf+KRbVqUnq+/hRMRuZl3mS2FqDyK6QZDN78A5savXI2vrd6/nQCxtMEMLoBKhkeqBeisdEw7fkuGHk6BqenlGWXX2QSs32YNJfrJWO9vcvO3qPO06T5tn70uo8hrhgeaKf9ZRgL/uq45Davt26TbTgCaQOWrHr x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 272045e7-f84d-4f72-f9f4-08d568752cdd x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:ME1PR01MB0788; x-ms-traffictypediagnostic: ME1PR01MB0788: authentication-results: spf=none (sender IP is ) smtp.mailfrom=James.H.Manger@team.telstra.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(209352067349851)(272811157607776)(211936372134217)(211171220733660)(168375693250761)(67441168502697); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231101)(2400082)(944501161)(93006095)(93001095)(6041288)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:ME1PR01MB0788; BCL:0; PCL:0; RULEID:; SRVR:ME1PR01MB0788; x-forefront-prvs: 056929CBB8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(39860400002)(39380400002)(366004)(396003)(346002)(376002)(13464003)(189003)(199004)(66066001)(97736004)(2950100002)(42882006)(3280700002)(186003)(6246003)(3660700001)(68736007)(6916009)(6506007)(86362001)(53546011)(229853002)(33656002)(72206003)(6436002)(106356001)(14454004)(316002)(9686003)(93886005)(6306002)(8676002)(2906002)(5660300001)(7696005)(76176011)(105586002)(5250100002)(102836004)(2900100001)(8936002)(305945005)(4326008)(55016002)(81166006)(59450400001)(478600001)(53936002)(6116002)(74316002)(81156014)(26005)(25786009)(3846002)(7736002)(99286004)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:ME1PR01MB0788; H:ME1PR01MB1076.ausprd01.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: team.telstra.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: zdb4BFrGANeEQ2H2sD0tl/FzIUg14QyOvzcUBbiZY3p60T7iT/gvWDBpOT/COlbAt8eoukT5RZ/GRa5fpguVtw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 272045e7-f84d-4f72-f9f4-08d568752cdd X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2018 06:38:01.5375 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854 X-MS-Exchange-Transport-CrossTenantHeadersStamped: ME1PR01MB0788 X-OriginatorOrg: team.telstra.com Archived-At: Subject: Re: [art] Confirm submission of I-D draft-touch-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, 31 Jan 2018 06:38:12 -0000 V2hlbiB5b3Uga25vdyB0aGUgZGF0ZXMgb2YgbGVhcCBzZWNvbmRzLCB5b3UgY2FuIHByZWNpc2Vs eSBjb252ZXJ0IGJldHdlZW4gVVRDIGFuZCAiMjQtaG91ciBsaW5lYXIgc21lYXIgZnJvbSBub29u IHRvIG5vb24gVVRDIi4gU28gdGhlcmUgY2FuJ3QgYmUgYW55IGVycm9ycyBvciBhbWJpZ3VpdHkg b3IgY29uZnVzaW9uIGluaGVyZW50IHRvIGVpdGhlci4gVGhleSBhcmUgaXNvbW9ycGhpYyENCg0K VGhlIGRpZmZlcmVuY2UgaXMgaW4gd2hhdCBnbGl0Y2hlcy93cmlua2xlcy93YXJ0cyBhcmUgbGlr ZWx5IHRvIG9jY3VyIHdoZW4gdGhlIHRpbWUgc2NhbGUgbWVldHMgYSBtYXNzIG9mIGFwcHMvQVBJ cy9zeXN0ZW1zL3Byb3RvY29scy9kYXRhLXN0cnVjdHVyZXMvZXRjIHRoYXQgY2FuJ3Qgb3IgZG9u J3Qgd2FudCB0byBoYW5kbGUgc3BlY2lhbCBjYXNlcyBzdWNoIGFzIHNlY29uZHM9NjAgKGluc3Rl YWQgb2YgMC01OSkuDQoNCg0KPiB1c2luZyBbVVRDXSB3b3VsZCBhdm9pZCBhbGwgb2YgdGhpcyBb Y29uZnVzaW9uXQ0KDQpUaGF0IGlzIGNsZWFybHkgd3JvbmcgZ2l2ZW4gc3lzdGVtcyB0aGF0IGRv IHdvbmt5IGhhY2tzIGxpa2UgcmVwb3J0aW5nIHRoZSBzYW1lIHRpbWUgdmFsdWUgZHVyaW5nIGEg bGVhcCBzZWNvbmQsIGluY3JlbWVudGVkIGJ5IDEgbnMgb24gZWFjaCByZWFkLg0KDQo+IGFsbCBV VEMgdGltZXMgYXJlIGRpcmVjdGx5IGNvbXBhcmFibGUgYW5kIGNhbiBiZSBkaXJlY3RseSBzZXF1 ZW5jZWQuDQoNClNvIGFyZSBhbGwgc21lYXJlZCB0aW1lcy4gIjI0LWhvdXIgbGluZWFyIHNtZWFy IGZyb20gbm9vbiB0byBub29uIFVUQyIgaXMgYmV0d2VlbiBub29uIFVUQyBzbyBldmVyeXdoZXJl IChyZWdhcmRsZXNzIG9mIHRpbWV6b25lKSBoYXMgdGhlIHNhbWUgc21lYXIgYXQgYW55IGluc3Rh bnQuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogSm9lIFRvdWNoIFttYWlsdG86dG91Y2hAc3RyYXlhbHBoYS5jb21dIA0KU2VudDogV2Vk bmVzZGF5LCAzMSBKYW51YXJ5IDIwMTggMTo0OCBBTQ0KVG86IE1hbmdlciwgSmFtZXMgPEphbWVz LkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20+DQpDYzogQXBwbGljYXRpb25zIGFuZCBSZWFsLVRp bWUgQXJlYSBEaXNjdXNzaW9uIDxhcnRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2FydF0gQ29u ZmlybSBzdWJtaXNzaW9uIG9mIEktRCBkcmFmdC10b3VjaC10aW1lDQoNCg0KDQo+IE9uIEphbiAy OSwgMjAxOCwgYXQgMTE6MDYgUE0sIE1hbmdlciwgSmFtZXMgPEphbWVzLkguTWFuZ2VyQHRlYW0u dGVsc3RyYS5jb20+IHdyb3RlOg0KPiANCj4+PiBDb21tZW50cyBvbiBkcmFmdC10b3VjaC10aW1l LTAzIChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdG91Y2gtdGltZS0wMyk6DQo+ Pj4gDQo+Pj4gR2l2ZW4gdGhhdCB0aGUgbWFpbiBhcmd1bWVudCBhZ2FpbnN0IGEgdGltZSBzY2Fs ZSB0aGF0IHNtZWFycyBvdXQgbGVhcCBzZWNvbmRzIGlzIHRoZSBsYWNrIG9mIGEgY3VycmVudCBz dGFuZGFyZCwgDQo+PiBQbGVhc2UgcmVjaGVjayB0aGUgZHJhZnQuIFRoYXQgaXMgbm90IHRoZSBt YWluIGFyZ3VtZW50OyB0aGVyZSBhcmUgbWFueQ0KPj4gb3RoZXIgcmVhc29ucywgbm90IHRoZSBs ZWFzdCBvZiB3aGljaCBpcyB0aGUgaW5hYmlsaXR5IG9mIGEgbWV0aG9kIHRvDQo+PiBjb252ZXJ0 IHJlbGlhYmx5IGZyb20gc21lYXJlZCB0aW1lIHRvIHRob3NlIHVzZWQgaW4gbmVhcmx5IGV2ZXJ5 IG90aGVyDQo+PiBjb250ZXh0Lg0KPiANCj4gIjI0LWhvdXIgbGluZWFyIHNtZWFyIGZyb20gbm9v biB0byBub29uIFVUQyIgYWxsb3dzIHByZWNpc2UgY29udmVyc2lvbiB0byBVVEMuDQoNCk9ubHkg aWYgeW91IGtub3cgZXhhY3RseSBvbiB3aGF0IGRheSB0aGUgc21lYXIgb2NjdXJyZWQuIFRoYXQg bWVhbnMgeW91IG5lZWQgdG8ga25vdyB0aGUgc2FtZSBraW5kIG9mIG9ubGluZSBpbmZvcm1hdGlv biBhcyBVVEMuDQoNCj4gSWYgeW91IGtub3cgeW91ciB0aW1lIGlzIHNtZWFyZWQsIGJ1dCBub3Qg d2hpY2ggdmFyaWV0eSBvZiBzbWVhciwgdGhlbiB5b3UgY2Fubm90IHByZWNpc2VseSBjb252ZXJ0 IC0tIGJ1dCB0aGF0IHdhcyB3aHkgMSBzbWVhciBSRkMgd291bGQgYmUgZ3JlYXQuDQoNCkl0IGlz IHRoZSBhZGRpdGlvbiBvZiBzbWVhciB0aGF0IGFkZHMgdGhhdCBjb25mdXNpb24uIFdlIGFscmVh ZHkgaGF2ZSBhIHNpbmdsZSwgY29tbW9uIHRpbWUgZnJhbWUgdGhhdCBpcyBpbiB3aWRlc3ByZWFk IHVzZSwgYW5kIHVzaW5nIHRoYXQgd291bGQgYXZvaWQgYWxsIG9mIHRoaXMuDQoNCj4gRm9yIHJl bGlhYmlsaXR5IHdoZW4geW91IGFyZW4ndCBjZXJ0YWluIGhvdyBzeXN0ZW1zIGhhbmRsZSBsZWFw IHNlY29uZHMgKFVUQyBvciBzbWVhciBvciBpZ25vcmUgb3IgLi4uKSwgc21lYXJlZCB0aW1lIHdp bGwgYWxtb3N0IGFsd2F5cyBiZSBiZXR0ZXIuIA0KDQpBIHN5c3RlbSB0aGF0IGRvZXNu4oCZdCBz dXBwb3J0IFVUQyBpcyBhZG1pdHRpbmcgaXQgZG9lc27igJl0IGNhcmUgYWJvdXQgdGltZSB0byB3 aXRoIGEgc2Vjb25kIGFueXdheS4gIA0KDQo+IDk5LjklIG9mIHRoZSB0aW1lIChkYXlzIHdpdGhv dXQgYSBsZWFwIHNlY29uZCkgaW50ZXJ2YWxzIGFyZSBwcmVjaXNlLCBpbiB0aGUgcmVtYWluaW5n IGNvcm5lciBjYXNlcyBhIDI0LWhvdXIgbGluZWFyIHNtZWFyIGVuc3VyZXMgYW4gZXJyb3IgaW4g KmFueSogaW50ZXJ2YWwgZHVyYXRpb24gKHdoZXRoZXIgMW5zIG9yIDFocikgaXMgYWx3YXlzIGxl c3MgdGhhbiAwLjAwMTE2JSwgd2hpbGUgb3RoZXIgdGltZXNjYWxlcyBtaWdodCBieSBwcmVjaXNl IG9yIG1pZ2h0IGdpdmUgYSArLy0xcyBlcnJvciAod2hpY2ggbWlnaHQgYmUgYSAwLjAwMSUgZXJy b3Igb3IgYSAxMCUgZXJyb3Igb3IgYSAxMDAwMCUgZXJyb3IgZGVwZW5kaW5nIG9uIHRoZSBkdXJh dGlvbiBvZiB0aGUgaW50ZXJ2YWwhKS5cDQoNClNtZWFyaW5nIG1lYW5zIHlvdSBjYW4gbm8gbG9u Z2VyIGNvbXBhcmUgdGltZSBpbnRlcnZhbHMgZGlyZWN0bHkgd2l0aG91dCB0aGF0IGVycm9yLiBU aGUgcGVyY2VudGFnZXMgeW914oCZcmUgY2l0aW5nIGFyZSBzaW1wbHkgbm90IGFjY2VwdGFibGUg LSB0aGV5IGNvdWxkIG1lYW4gdGhlIGRpZmZlcmVuY2Ugb2YgZXZlbnRzIGhhcHBlbmluZyBpbiBk aWZmZXJlbnQgZGF5cyBvciBldmVuIHllYXJzLCBnaXZlbiB0aGF0IHRoZSBzbWVhciB3b3VsZCBo YXBwZW4gb3ZlciBhIGRheSB3aXRoaW4gZGlmZmVyZW50IHRpbWUgem9uZXMgaW4gZGlmZmVyZW50 IHdheXMuIFVUQyBpcyB0aGUgb25seSB3YXkgdG8gZW5zdXJlIHRoYXQgdGhpcyBpc27igJl0IHRy dWUgLSBhbGwgVVRDIHRpbWVzIGFyZSBkaXJlY3RseSBjb21wYXJhYmxlIGFuZCBjYW4gYmUgZGly ZWN0bHkgc2VxdWVuY2VkLg0KDQpTbyBzbWVhcmluZyBhZGRzIGEgbWVzcyBvZiBjb21wbGljYXRp b24gLSBhbGwganVzdCB0byBnaXZlIHBlb3BsZSB0aGUgaW5jb3JyZWN0IGltcHJlc3Npb24gdGhh dCB0aGUgdGltZSBkaWRu4oCZdCBqdW1wLiBIb3dldmVyLCB0aW1lIERJRCBqdW1wIC0gYmVjYXVz ZSBnb3Zlcm5tZW50IHRpbWUgaXMgbmVhcmx5IHVuaXZlcnNhbGx5IGJhc2VkIG9uIFVUQy4gDQoN Cj4gDQo+IA0KPj4+IHRoZSBiZXN0IGNvbnRyaWJ1dGlvbiB0aGlzIGRvY3VtZW50IGNvdWxkIG1h a2UgaXMgdG8gZG9jdW1lbnQgYXMgYW4gUkZDIHRoZSAiMjQtaG91ciBsaW5lYXIgc21lYXIgZnJv bSBub29uIHRvIG5vb24gVVRDIiBub3cgdXNlZCBieSBHb29nbGUgKGh0dHBzOi8vZGV2ZWxvcGVy cy5nb29nbGUuY29tL3RpbWUvc21lYXIpLCBBbWF6b24gZXRjLiBUaGF0IG1lYW5zIGludGVydmFs IG1lYXN1cmVtZW50cyBhcmUgbm90IGNvbXBsaWNhdGVkIGF0IGFsbCB1bmxlc3MgeW91IG5lZWQg cHJlY2lzaW9uIGJldHRlciB0aGF0IDExLjZwcG0gKDAuMDAxMTYlOyAxIHNlY29uZCBpbiAyNCBo b3Vycyk7IGFuZCBpZiB5b3UgZG8gbmVlZCB0aGF0IHByZWNpc2lvbiBpdCBpcyBzdGlsbCBwb3Nz aWJsZSBhcyB0aGUgc21lYXJpbmcgaXMgc2ltcGxlICYgZGV0ZXJtaW5pc3RpYyBvbmNlIHlvdSBr bm93IHdoZW4gbGVhcCBzZWNvbmRzIG9jY3VyLg0KPj4gMTEuNiBwcG0gaXMgMTEuNiBtaWxsaXNl Y29uZHMuIFRoZXJlIGFyZSBtYW55IHN5c3RlbXMgdGhhdCBuZWVkDQo+PiBwcmVjaXNpb24gZmFy IGJleW9uZCB0aGF0LCBkb3duIGF0IDFtcyBvciBldmVuIGxvd2VyLg0KPiANCj4gMTEuNnBwbSBp cyBOT1QgMTEuNm1zLCB1bmxlc3MgeW91ciBpbnRlcnZhbCBpcyAxMDAwcy4gR29vZ2xlJ3Mgc21l YXIgZ2l2ZXMgYXQgbGVhc3QgMW1zIHByZWNpc2lvbiBmb3IgYW55IGludGVydmFsIGJlbG93IDg2 LjRzIGluIGR1cmF0aW9uLg0KDQoxbXMgb2YgZXJyb3IgaW4gYSB0aW1lc3RhbXAgaXMgbW9yZSB0 aGFuIGVub3VnaCB0byB1bmRlcm1pbmUgZmluYW5jaWFsIGFuZCBnb3Zlcm5tZW50IHN5c3RlbXMu IA0KDQpKb2UNCg== From nobody Tue Jan 30 22:55:27 2018 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 595381315F4 for ; Tue, 30 Jan 2018 22:55:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 8CzcQ2D_4Bt1 for ; Tue, 30 Jan 2018 22:55:23 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 D1B801200FC for ; Tue, 30 Jan 2018 22:49:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=tKYluhMdIrtniLOKtmZ7vqUa8GBoVTMIWAR4+rmoLGM=; b=OO7HUIqRkC/aZblv3qpLfoXl8 4LoPyAnwe6MSuMdtJQ71OHsz6LgLJT4UVLlxSN5+8wjxRknY/0YBN/eyxLtAVHr7dYfkYiJTxMp3K t3g81mk/+zXRv61apPFhmirSrQ3v2fw0peeoicjoey7mwnkuU/Gj3zexHXJheFoLT9QkTJHl/5TN3 ZEckcQUO2TA6mWVYroBMG0VsOWB274olWCkC8sw9hGM1hQ/z79KOJ8Y/rsRlaIUKvSf7aZ5bIG/Lu IP9hNRLEMP2Huy8w1XNFDnvRLdUSffh+tSAnW0sLcKEoyFQRj5VuhtEjNva0/+mdfyPUEZHH8hjvC 9/3T6CE4A==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:52648 helo=[192.168.1.87]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1egmCb-000nNy-GM; Wed, 31 Jan 2018 01:49:02 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Joe Touch In-Reply-To: Date: Tue, 30 Jan 2018 22:48:54 -0800 Cc: Applications and Real-Time Area Discussion Content-Transfer-Encoding: quoted-printable Message-Id: <83C39F3D-702F-44ED-A9FE-6D8D12C19B0A@strayalpha.com> References: <151641287464.3257.11011391661979125459.idtracker@ietfa.amsl.com> <20180127190806.GA23684@ucolick.org> To: "Manger, James" X-Mailer: Apple Mail (2.3445.5.20) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [art] Confirm submission of I-D draft-touch-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, 31 Jan 2018 06:55:25 -0000 > On Jan 30, 2018, at 10:38 PM, Manger, James = wrote: >=20 > When you know the dates of leap seconds, you can precisely convert = between UTC and "24-hour linear smear from noon to noon UTC". So there = can't be any errors or ambiguity or confusion inherent to either. They = are isomorphic! Except that UTC can be computed in seconds exactly; smear is susceptible = to the limits of the precision of your floating point calculations. > The difference is in what glitches/wrinkles/warts are likely to occur = when the time scale meets a mass of = apps/APIs/systems/protocols/data-structures/etc that can't or don't want = to handle special cases such as seconds=3D60 (instead of 0-59). Apps typically don=E2=80=99t handle this; OSes (already) do this = conversion. Additionally, apps that don=E2=80=99t understand that some minutes have = 60 seconds are incorrect and cannot operate with the time the rest of = the world has already adopted. >> using [UTC] would avoid all of this [confusion] >=20 > That is clearly wrong given systems that do wonky hacks like reporting = the same time value during a leap second, incremented by 1 ns on each = read. Apps that incorrectly use the OS interfaces to time will continue to do = so; adding another time frame invites additional errors rather than = preventing them. >=20 >> all UTC times are directly comparable and can be directly sequenced. >=20 > So are all smeared times. "24-hour linear smear from noon to noon UTC" = is between noon UTC so everywhere (regardless of timezone) has the same = smear at any instant. Except for the resolution of the floating point calculation that could = affect the way in which the smear is continuously applied to = increasingly more precise time intervals. The fundamental issue is that smear doesn=E2=80=99t relieve apps from = needing to have updated info on leap seconds. It only serves to make = interoperation with the time already adopted as universal worldwide more = difficult. If you already need to know about leap seconds, it=E2=80=99s = far simpler to just use them directly and match time to UTC. By avoiding smear, we ensure that =E2=80=9C10 seconds=E2=80=9D means the = same thing at all times, everywhere. Smeared time can be whatever it = wants, but on days when it=E2=80=99s smeared, it shouldn=E2=80=99t ever = use the term =E2=80=98second=E2=80=99. Joe > -----Original Message----- > From: Joe Touch [mailto:touch@strayalpha.com]=20 > Sent: Wednesday, 31 January 2018 1:48 AM > To: Manger, James > Cc: Applications and Real-Time Area Discussion > Subject: Re: [art] Confirm submission of I-D draft-touch-time >=20 >=20 >=20 >> On Jan 29, 2018, at 11:06 PM, Manger, James = wrote: >>=20 >>>> Comments on draft-touch-time-03 = (https://tools.ietf.org/html/draft-touch-time-03): >>>>=20 >>>> Given that the main argument against a time scale that smears out = leap seconds is the lack of a current standard,=20 >>> Please recheck the draft. That is not the main argument; there are = many >>> other reasons, not the least of which is the inability of a method = to >>> convert reliably from smeared time to those used in nearly every = other >>> context. >>=20 >> "24-hour linear smear from noon to noon UTC" allows precise = conversion to UTC. >=20 > Only if you know exactly on what day the smear occurred. That means = you need to know the same kind of online information as UTC. >=20 >> If you know your time is smeared, but not which variety of smear, = then you cannot precisely convert -- but that was why 1 smear RFC would = be great. >=20 > It is the addition of smear that adds that confusion. We already have = a single, common time frame that is in widespread use, and using that = would avoid all of this. >=20 >> For reliability when you aren't certain how systems handle leap = seconds (UTC or smear or ignore or ...), smeared time will almost always = be better.=20 >=20 > A system that doesn=E2=80=99t support UTC is admitting it doesn=E2=80=99= t care about time to with a second anyway. =20 >=20 >> 99.9% of the time (days without a leap second) intervals are precise, = in the remaining corner cases a 24-hour linear smear ensures an error in = *any* interval duration (whether 1ns or 1hr) is always less than = 0.00116%, while other timescales might by precise or might give a +/-1s = error (which might be a 0.001% error or a 10% error or a 10000% error = depending on the duration of the interval!).\ >=20 > Smearing means you can no longer compare time intervals directly = without that error. The percentages you=E2=80=99re citing are simply not = acceptable - they could mean the difference of events happening in = different days or even years, given that the smear would happen over a = day within different time zones in different ways. UTC is the only way = to ensure that this isn=E2=80=99t true - all UTC times are directly = comparable and can be directly sequenced. >=20 > So smearing adds a mess of complication - all just to give people the = incorrect impression that the time didn=E2=80=99t jump. However, time = DID jump - because government time is nearly universally based on UTC.=20= >=20 >>=20 >>=20 >>>> the best contribution this document could make is to document as an = RFC the "24-hour linear smear from noon to noon UTC" now used by Google = (https://developers.google.com/time/smear), Amazon etc. That means = interval measurements are not complicated at all unless you need = precision better that 11.6ppm (0.00116%; 1 second in 24 hours); and if = you do need that precision it is still possible as the smearing is = simple & deterministic once you know when leap seconds occur. >>> 11.6 ppm is 11.6 milliseconds. There are many systems that need >>> precision far beyond that, down at 1ms or even lower. >>=20 >> 11.6ppm is NOT 11.6ms, unless your interval is 1000s. Google's smear = gives at least 1ms precision for any interval below 86.4s in duration. >=20 > 1ms of error in a timestamp is more than enough to undermine financial = and government systems.=20 >=20 > Joe > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art From nobody Tue Jan 30 23:22:48 2018 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 8E319131646 for ; Tue, 30 Jan 2018 23:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 d6Mfk7cR1NWx for ; Tue, 30 Jan 2018 23:22:40 -0800 (PST) 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 DE670131642 for ; Tue, 30 Jan 2018 23:22:38 -0800 (PST) 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 w0V7MP3w001037; Wed, 31 Jan 2018 08:22:25 +0100 (CET) Received: from [192.168.217.102] (p5DC7EAF5.dip0.t-ipconnect.de [93.199.234.245]) (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 3zWZSx5JwyzDWsm; Wed, 31 Jan 2018 08:22:25 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Wed, 31 Jan 2018 08:22:24 +0100 Cc: Joe Touch , Applications and Real-Time Area Discussion X-Mao-Original-Outgoing-Id: 539076143.322834-08af91af8f55f68a8d1c50806b194b8d Content-Transfer-Encoding: quoted-printable Message-Id: <0E386E45-AC4D-413F-9CFF-6E644F2C4311@tzi.org> References: <151641287464.3257.11011391661979125459.idtracker@ietfa.amsl.com> <20180127190806.GA23684@ucolick.org> To: "Manger, James" X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [art] Confirm submission of I-D draft-touch-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, 31 Jan 2018 07:22:47 -0000 On Jan 31, 2018, at 07:38, Manger, James = wrote: >=20 > 24-hour linear smear from noon to noon UTC I propose the name =E2=80=9CSmeared Leapsecond over twentyfour hours" = =E2=80=94 SLOTH. More seriously, I agree with your quest for a standard smear. As Joe correctly says, UTC doesn=E2=80=99t have a problem that needs to = be solved here. But this is not about UTC, it is about the Posix timescale, which is a = corruption of UTC that is not maintaining the monotonous property. = SLOTH is a much better time scale for most systems that have to contend = with the Posix time scale now. (I=E2=80=99m interested in this discussion because of CBOR tags 1 = [RFC7049] and 1001 [draft-bormann-cbor-time-tag].) Gr=C3=BC=C3=9Fe, Carsten PS.: Why couldn't they make it 100000 seconds=E2=80=A6. From nobody Tue Jan 30 23:43:13 2018 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 436E7131645 for ; Tue, 30 Jan 2018 23:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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=mnot.net header.b=GOifX8eA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Jha0J4ke 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 i4QSuw8j7GFd for ; Tue, 30 Jan 2018 23:43:08 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2654B12F4C5 for ; Tue, 30 Jan 2018 23:43:08 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 6C0172090D; Wed, 31 Jan 2018 02:43:07 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 31 Jan 2018 02:43:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=wIZLBboodXLJslsxDcBEHO7EUt9d8 ihGrw8oTJqdivY=; b=GOifX8eAv59qchO40qhbDbKUx9hnUDpF9MK51/YmeJGuR 5UfSZUfDnRyctSpQrU51iiVeotNA3A9LeOMhhTA9fvC6gC+UvJkYzlQ3kisSqJbO pArr+lVJHuQpsJNpRdLkbiHv6K6kmh666qSKLC7CKRl4z/SS285lE2IwOTOe/tG/ Nioh7n2WHg/HD0kzBbR2ELy9NL/jrGOluXy3Xwyg1wfZvEPP01Kr3KHvAjFRdQ6u Vhvr/xvyMfslLcmLy//zhTiI8nCbB5I1AgTOKolBZRfH6/pSdROCIwu9tsuvAvtC ZgURkDqpo0lHq3l/DEEskIU+BqEtQBFO9Cklm8ilw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=wIZLBb oodXLJslsxDcBEHO7EUt9d8ihGrw8oTJqdivY=; b=Jha0J4ke1M6AT5cq4pLuhz SCDoY1PwbicZLOBI/Be5IgcyE3bjAMwyA5Sad2PlKsrA93vW/bCZ4/9PzT4z+GV5 21SF/OUTTXU2OjNY4OlShDigc4uYZRBObc8wccXF2fnA/TJDlPi4kvPgGvQuDWvH 2Z2E86mvpJZiuF8s4otl4c6bL1MdAi4kCoEhhAZGqfXRuf7X+DHza9NiS3Q5ymd1 7A6PVtSsZDb/Z9m5CP7eE6Qwbjdy9dl9zQ1feuJmjUsBz5ZRQVuL7thw24u3Urpj +l/Gs/JY2mKzM/EGhHlYt2i+kg4aeZ7fhDPx3KsE/wJZSU5C+510i5iYJVK5ENPw == X-ME-Sender: Received: from [192.168.1.18] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id AEB527E3D5; Wed, 31 Jan 2018 02:43:05 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Mark Nottingham In-Reply-To: <0E386E45-AC4D-413F-9CFF-6E644F2C4311@tzi.org> Date: Wed, 31 Jan 2018 18:42:58 +1100 Cc: "Manger, James" , Applications and Real-Time Area Discussion , Joe Touch Content-Transfer-Encoding: quoted-printable Message-Id: <4C36ECBF-5AC3-4137-AD75-2EAEEDFF4CDB@mnot.net> References: <151641287464.3257.11011391661979125459.idtracker@ietfa.amsl.com> <20180127190806.GA23684@ucolick.org> <0E386E45-AC4D-413F-9CFF-6E644F2C4311@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [art] Confirm submission of I-D draft-touch-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, 31 Jan 2018 07:43:11 -0000 > On 31 Jan 2018, at 6:22 pm, Carsten Bormann wrote: >=20 > On Jan 31, 2018, at 07:38, Manger, James = wrote: >>=20 >> 24-hour linear smear from noon to noon UTC >=20 > I propose the name =E2=80=9CSmeared Leapsecond over twentyfour hours" = =E2=80=94 SLOTH. That's going to stick... > More seriously, I agree with your quest for a standard smear. +1.=20 > As Joe correctly says, UTC doesn=E2=80=99t have a problem that needs = to be solved here. >=20 > But this is not about UTC, it is about the Posix timescale, which is a = corruption of UTC that is not maintaining the monotonous property. = SLOTH is a much better time scale for most systems that have to contend = with the Posix time scale now. >=20 > (I=E2=80=99m interested in this discussion because of CBOR tags 1 = [RFC7049] and 1001 [draft-bormann-cbor-time-tag].) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > PS.: Why couldn't they make it 100000 seconds=E2=80=A6. >=20 > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art -- Mark Nottingham https://www.mnot.net/ From nobody Tue Jan 30 23:46:18 2018 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 7457C1315F5 for ; Tue, 30 Jan 2018 23:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 eWIcf0XBQJoO for ; Tue, 30 Jan 2018 23:46:14 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 B9AA412F4C5 for ; Tue, 30 Jan 2018 23:46:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=GTowcbVNCQQlGcESlQNvuKSOTWTVnZxIOvVolHwsm9I=; b=5Rr83U5+0Fds+EopjMXfsvhH5 FRk33n0w2OhmXEJQsmR9kiH+01eSWqjAXWJ60RFJ1DMbDVlWnp5DJCHHgHV4vWAvxznrdSzSuJ6wC SE4eGgI5Eo9ML1sewP4q/EJ+ZLcyK66LLEXuuei+9ukji6LtnQGuWOaMdCtp4j7NqquBhVd+cr+NB N8Ughd57o5s9qnOiLyHceRx1HbrWz2iTwqrijyaSig5lFxvLEanwlZR+P+Rls0ELfbNKgx2sfGq5O VAvNP6pFMEFQ8G5l9ZI0yn0OivpieDfooKETGgB19O1oL+eKTVQ9dMf6CnPEP0PmzWKIMVCAaHfzf JLcNkOLOw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:64180 helo=[192.168.1.80]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1egn5g-001nLm-Kc; Wed, 31 Jan 2018 02:46:01 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (15D60) In-Reply-To: <0E386E45-AC4D-413F-9CFF-6E644F2C4311@tzi.org> Date: Tue, 30 Jan 2018 23:45:56 -0800 Cc: "Manger, James" , Applications and Real-Time Area Discussion Content-Transfer-Encoding: quoted-printable Message-Id: References: <151641287464.3257.11011391661979125459.idtracker@ietfa.amsl.com> <20180127190806.GA23684@ucolick.org> <0E386E45-AC4D-413F-9CFF-6E644F2C4311@tzi.org> To: Carsten Bormann X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [art] Confirm submission of I-D draft-touch-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, 31 Jan 2018 07:46:16 -0000 > On Jan 30, 2018, at 11:22 PM, Carsten Bormann wrote: >=20 > SLOTH is a much better time scale for most systems that have to contend w= ith the Posix time scale now. Can you explain why this is better than using UTC? My concern is that is is not only unnecessarily different, but it contaminat= ed the notion of time intervals too - a second on a smear day isn=E2=80=99t a= second on any other.=20 Joe= From nobody Wed Jan 31 01:53:02 2018 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 7E38D131AA4 for ; Wed, 31 Jan 2018 01:53:00 -0800 (PST) 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 vvHialsY8Ype for ; Wed, 31 Jan 2018 01:52:53 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (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 2F773131A24 for ; Wed, 31 Jan 2018 01:49:49 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1egp1W-0000EZC; Wed, 31 Jan 2018 10:49:46 +0100 Message-Id: To: art@ietf.org From: Philip Homburg Sender: pch-bCE2691D2@u-1.phicoh.com References: <151641287464.3257.11011391661979125459.idtracker@ietfa.amsl.com> <20180127190806.GA23684@ucolick.org> <0E386E45-AC4D-413F-9CFF-6E644F2C4311@tzi.org> In-reply-to: Your message of "Wed, 31 Jan 2018 08:22:24 +0100 ." <0E386E45-AC4D-413F-9CFF-6E644F2C4311@tzi.org> Date: Wed, 31 Jan 2018 10:49:46 +0100 Archived-At: Subject: Re: [art] Confirm submission of I-D draft-touch-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, 31 Jan 2018 09:53:00 -0000 > More seriously, I agree with your quest for a standard smear. I'd like to propose a rule that if a system returns a timestamp that is subject to smear, it is tagged as such. So in the context of NTP, there needs to be a flag of some kind that signals that the timestamps in the packet are subject to smear. In the case of an API, ideally the system returns that the time is smeared. Or the application requests that explicitly. For example in the context of the POSIX clock_gettime call, add a CLOCK_REALTIME_SMEARED clock. From nobody Wed Jan 31 06:32:10 2018 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 809DA131880 for ; Wed, 31 Jan 2018 06:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=meinberg.de 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 dkshKicUfHaI for ; Wed, 31 Jan 2018 06:32:02 -0800 (PST) Received: from server1a.meinberg.de (server1a.meinberg.de [176.9.44.212]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E94D012EB53 for ; Wed, 31 Jan 2018 06:30:43 -0800 (PST) Received: from srv-kerioconnect.py.meinberg.de (unknown [217.6.112.194]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server1a.meinberg.de (Postfix) with ESMTPSA id 4815D71C1128 for ; Wed, 31 Jan 2018 15:30:36 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.2 server1a.meinberg.de 4815D71C1128 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=meinberg.de; s=mail201101; t=1517409042; bh=kaTIxDSvGEL7h5BkxfQE2o3i7dBPFPNQLvZ9DaV9RuI=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=YZJSSAlZBgAwOeEtml4NwFvzEMMJkxhOes71Pw8yilso3R5M6tFA+CbzumPDD0eMz hdqJq7potDZpIUz2JyIcAksvr6NsGMAziJS8/lkRPJ06yPCOzoNvWEU00ohhjF6Mgt 404Xu3vpmOmJ4QgZmURe+wpj32qj+0SAub5aDq+4= X-Kerio-Anti-Spam: Build: [Engines: 2.15.8.1142, Stamp: 3], Multi: [Enabled, t: (0.000017,0.101574)], BW: [Enabled, t: (0.000011,0.000001)], RTDA: [Enabled, t: (0.400055), Hit: No, Details: v2.6.16; Id: 15.5f470g.1c3t540ii.h4ek4], total: 0(700) X-Footer: bWVpbmJlcmcuZGU= Received: from localhost ([127.0.0.1]) by srv-kerioconnect.py.meinberg.de with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)) for art@ietf.org; Wed, 31 Jan 2018 15:30:32 +0100 From: Martin Burnicki Organization: Meinberg Funkuhren, Bad Pyrmont, Germany To: art@ietf.org Message-ID: <6a2080c9-1e9b-a683-38fe-b69bcc8a1d0b@meinberg.de> Date: Wed, 31 Jan 2018 15:30:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.3 at server1a X-Virus-Status: Clean Archived-At: Subject: Re: [art] Confirm submission of I-D draft-touch-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, 31 Jan 2018 14:32:09 -0000 Hi all, I just saw a link to this discussion, joined the mailing list and try to reply in the correct thread context, even though I read the previous emails only in the archive. Philip Homburg wrote: > So in the context of NTP, there needs to be a flag of some kind that signals > that the timestamps in the packet are subject to smear. In the case of an API, > ideally the system returns that the time is smeared. Or the application > requests that explicitly. Indeed, leap smearing has been implemented in ntpd. See: https://bugs.ntp.org/show_bug.cgi?id=2855 (The site seems to fail while I'm writing this email) If you are interested, here's a whitepaper that describes the basic concepts of this implementation, and also contains some test results: https://www.meinbergglobal.com/download/burnicki/Leap%20Second%20Smearing%20With%20NTP.pdf Right now this has been implemented as smearing with a cosine shape that is finished at the end of the leap second. While smearing is in progress, the "refid" field in the NTP packets sent to clients has a specific encryption which tells that the NTP server is currently smearing, and it also contains the current smear offset. Also, the command "ntpq -c rv" run on the server is telling if smearing is in progress, and the value of the current smear offset. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy From nobody Wed Jan 31 07:39:17 2018 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 5BF3613148F for ; Wed, 31 Jan 2018 07:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 z1ZW8raWpGMD for ; Wed, 31 Jan 2018 07:39:09 -0800 (PST) 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 1578A12EB8A for ; Wed, 31 Jan 2018 07:38:30 -0800 (PST) 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 w0VFcQsu014677; Wed, 31 Jan 2018 16:38:26 +0100 (CET) Received: from [192.168.217.114] (p5DC7EAF5.dip0.t-ipconnect.de [93.199.234.245]) (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 3zWnTG2YsWzDX1T; Wed, 31 Jan 2018 16:38:26 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Wed, 31 Jan 2018 16:38:25 +0100 Cc: Applications and Real-Time Area Discussion , "Manger, James" X-Mao-Original-Outgoing-Id: 539105904.353488-e2478f271eb12af215c2709cc9e92cca Content-Transfer-Encoding: quoted-printable Message-Id: <681BFFCE-B468-4A10-8F2B-26260E4BB90D@tzi.org> References: <151641287464.3257.11011391661979125459.idtracker@ietfa.amsl.com> <20180127190806.GA23684@ucolick.org> <0E386E45-AC4D-413F-9CFF-6E644F2C4311@tzi.org> To: Joe Touch X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [art] Confirm submission of I-D draft-touch-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, 31 Jan 2018 15:39:15 -0000 On Jan 31, 2018, at 08:45, Joe Touch wrote: >=20 >=20 >=20 >> On Jan 30, 2018, at 11:22 PM, Carsten Bormann wrote: >>=20 >> SLOTH is a much better time scale for most systems that have to = contend with the Posix time scale now. >=20 > Can you explain why this is better than using UTC? It=E2=80=99s not =E2=80=94 it=E2=80=99s just not on the table with most = applications that are running on the Posix time scale. > My concern is that is is not only unnecessarily different, but it = contaminated the notion of time intervals too - a second on a smear day = isn=E2=80=99t a second on any other.=20 The time interval (pair of points in time) doesn=E2=80=99t have a = problem as long as these points are properly identified as SLOTH. = Durations, however, are a different issue =E2=80=94 to compute a = duration from an interval in the presence of smear is more work unless = the application does not care about the 1.2e-5 inaccuracy. (*) The point about smear is that those applications that care about time, = but not about 1.2e-5 accuracy or implement (correct) leapsecond code, = continue to work without breakage over a leapsecond. Most people in = data centers consider that an immense win (as do their customers and = users :-). Gr=C3=BC=C3=9Fe, Carsten (*) Maybe we should, selective-availability style, introduce some smear = even if there is no leapsecond? Might help debugging those smear-sensitive applications :-) From nobody Wed Jan 31 08:28:48 2018 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 BBEC412DDD0 for ; Wed, 31 Jan 2018 08:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 Ggec-D07N1JT for ; Wed, 31 Jan 2018 08:28:44 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 404F512EB8C for ; Wed, 31 Jan 2018 08:28:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=VyzYHDDEQpgJRKssljfNG4eDFfA6qfrpOoBC03CPQzI=; b=ol680C6dc5OwcKJJDPIN0az4yg 1icha2/zOIXIcc1JXvJ+qdSs3C3TBeOm1+bkcmnMrBCp37IuZq2J4b+KzjLWL6+SNFhHG8e9Vg7lE h3DteeuE4qb35ko4625TwPDPh6gIbYn2KNCjVomdy0ra3JHko2vYfzE1eXQS+SCfVC5765a8cwgYa 9F6Qu8VksyU0PKTa4sBzdkC/uDmiLLwO+nw1YkuHVsihaGtTP4D5rOKwaoBk855VJ7uqRI3h6j1fw 4MCIStkJEOLry/8EdC3vaooR/kOdkHSZJsszuppkvLQA5eDxBDYPrJ+FbkEbpL7rIp6QMCruj8SaM rvkRQ0Pg==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:58484 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1egvFQ-003Hjm-N7; Wed, 31 Jan 2018 11:28:34 -0500 To: Martin Burnicki , art@ietf.org References: <6a2080c9-1e9b-a683-38fe-b69bcc8a1d0b@meinberg.de> From: Joe Touch Message-ID: <92593352-ac39-2208-24a3-912fd020caf0@strayalpha.com> Date: Wed, 31 Jan 2018 08:28:31 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <6a2080c9-1e9b-a683-38fe-b69bcc8a1d0b@meinberg.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [art] Confirm submission of I-D draft-touch-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, 31 Jan 2018 16:28:47 -0000 Martin, Can you help clarify whether this is an update to the NTP protocol or merely an update to the user libraries that are provided with it? (i.e., AFAICT, smearing is a local function that doesn't involve synchronization per se, but does rely on NTP-like sync of time outside the smearing period as well as external input on planned leap events) Joe On 1/31/2018 6:30 AM, Martin Burnicki wrote: > Hi all, > > I just saw a link to this discussion, joined the mailing list and try to > reply in the correct thread context, even though I read the previous > emails only in the archive. > > Philip Homburg wrote: >> So in the context of NTP, there needs to be a flag of some kind that signals >> that the timestamps in the packet are subject to smear. In the case of an API, >> ideally the system returns that the time is smeared. Or the application >> requests that explicitly. > Indeed, leap smearing has been implemented in ntpd. See: > https://bugs.ntp.org/show_bug.cgi?id=2855 > (The site seems to fail while I'm writing this email) > > If you are interested, here's a whitepaper that describes the basic > concepts of this implementation, and also contains some test results: > https://www.meinbergglobal.com/download/burnicki/Leap%20Second%20Smearing%20With%20NTP.pdf > > Right now this has been implemented as smearing with a cosine shape that > is finished at the end of the leap second. While smearing is in > progress, the "refid" field in the NTP packets sent to clients has a > specific encryption which tells that the NTP server is currently > smearing, and it also contains the current smear offset. > > Also, the command "ntpq -c rv" run on the server is telling if smearing > is in progress, and the value of the current smear offset. > > > Martin From nobody Wed Jan 31 08:38:17 2018 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 1DA471317C3 for ; Wed, 31 Jan 2018 08:38:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 7aVVGFsbtzA6 for ; Wed, 31 Jan 2018 08:38:12 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 157DC131875 for ; Wed, 31 Jan 2018 08:37:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=KThtZG0u2KwLdg9KenlD4kXKr7s6/rozkS1d5pBNrbw=; b=Mc1KFDLRuyAhzIoD0Mbxgo5Pw U8/JjHlv0llPEKM1c3D/Oxqa1aiIFnM8Oab22p69B+jdxp/odZ3sT8gBamKHoKVWuQmtxQ3bq4yXU 97mx0tAo4R4zGyAw8oq+xxn+FoZO3GPNc7o93BdeUSEjqdqXDewZusy2Mq2Lh6qxodWVmFtGzHTzi X+FuI+M/bi2Ovz5luXYRFc8UfZV1lfYH5Mqm7YR0be7DgQuq261lOq7E1a8212IFYEkGVYayLnlQf Q5UH+9zO/IO0kHbAw1+fBTTCu86oTU6Uumsk9tfYpDup7HoWUjI346tu8xolco25jMT1EQqILg0cg qpw4625fw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:58537 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1egvNm-003SHW-Hx; Wed, 31 Jan 2018 11:37:14 -0500 To: Carsten Bormann Cc: Applications and Real-Time Area Discussion , "Manger, James" References: <151641287464.3257.11011391661979125459.idtracker@ietfa.amsl.com> <20180127190806.GA23684@ucolick.org> <0E386E45-AC4D-413F-9CFF-6E644F2C4311@tzi.org> <681BFFCE-B468-4A10-8F2B-26260E4BB90D@tzi.org> From: Joe Touch Message-ID: Date: Wed, 31 Jan 2018 08:37:09 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <681BFFCE-B468-4A10-8F2B-26260E4BB90D@tzi.org> Content-Type: multipart/alternative; boundary="------------F8B43379C604DDE6EF2C0921" Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [art] Confirm submission of I-D draft-touch-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, 31 Jan 2018 16:38:15 -0000 This is a multi-part message in MIME format. --------------F8B43379C604DDE6EF2C0921 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 1/31/2018 7:38 AM, Carsten Bormann wrote: >>> On Jan 30, 2018, at 11:22 PM, Carsten Bormann wrote: >>> >>> SLOTH is a much better time scale for most systems that have to contend with the Posix time scale now. >> Can you explain why this is better than using UTC? > It’s not — it’s just not on the table with most applications that are running on the Posix time scale. OK, so I'll as "why?" Here's my assumptions: - the primary value in using Posix is for systems without external interactions, e.g., where there is no way to obtain information about newly scheduled leap events and where there is no way to synchronize to an external time frame. - once you add external I/O, I can't see a good reason not to just use UTC because you now have all the information was missing that motivated the use of Posix in the first place, and *every other time reference is just as much work, but much less widely used* (and in some cases, more challenging to compute - e.g., the floating point concerns I raised with smearing). However, I can see why some systems libraries might also support conversion to "Google's time", in much the same way many time libraries support conversion to other calendars, both past and present (Hindu, Jewish, Navjo, Julian, Mayan, Incan, StarDate, etc.). Joe --------------F8B43379C604DDE6EF2C0921 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 1/31/2018 7:38 AM, Carsten Bormann wrote:
On Jan 30, 2018, at 11:22 PM, Carsten Bormann <cabo@tzi.org> wrote:

SLOTH is a much better time scale for most systems that have to contend with the Posix time scale now.

Can you explain why this is better than using UTC?

It’s not — it’s just not on the table with most applications that are running on the Posix time scale.
OK, so I'll as "why?"

Here's my assumptions:

- the primary value in using Posix is for systems without external interactions, e.g., where there is no way to obtain information about newly scheduled leap events and where there is no way to synchronize to an external time frame.

- once you add external I/O, I can't see a good reason not to just use UTC because you now have all the information was missing that motivated the use of Posix in the first place, and *every other time reference is just as much work, but much less widely used* (and in some cases, more challenging to compute - e.g., the floating point concerns I raised with smearing).

However, I can see why some systems libraries might also support conversion to "Google's time", in much the same way many time libraries support conversion to other calendars, both past and present (Hindu, Jewish, Navjo, Julian, Mayan, Incan, StarDate, etc.).

Joe
--------------F8B43379C604DDE6EF2C0921-- From nobody Wed Jan 31 12:49:14 2018 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 D7CBB12FA90 for ; Wed, 31 Jan 2018 12:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 tGbn_ngKGg6Y for ; Wed, 31 Jan 2018 12:49:12 -0800 (PST) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) by ietfa.amsl.com (Postfix) with ESMTP id 8189F12F266 for ; Wed, 31 Jan 2018 12:49:10 -0800 (PST) Received: by sdaoden.eu (Postfix, from userid 1000) id 9F98A16045; Wed, 31 Jan 2018 21:49:09 +0100 (CET) Date: Wed, 31 Jan 2018 21:49:09 +0100 From: Steffen Nurpmeso To: Joe Touch Cc: Martin Burnicki , art@ietf.org Message-ID: <20180131204909.uNHwK%steffen@sdaoden.eu> References: <6a2080c9-1e9b-a683-38fe-b69bcc8a1d0b@meinberg.de> <92593352-ac39-2208-24a3-912fd020caf0@strayalpha.com> In-Reply-To: <92593352-ac39-2208-24a3-912fd020caf0@strayalpha.com> Mail-Followup-To: Joe Touch , Martin Burnicki , art@ietf.org, Steffen Nurpmeso User-Agent: s-nail v14.9.6-48-gd837577b OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. Archived-At: Subject: Re: [art] Confirm submission of I-D draft-touch-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, 31 Jan 2018 20:49:14 -0000 Joe Touch wrote: ... |(i.e., AFAICT, smearing is a local function that doesn't involve |synchronization per se, but does rely on NTP-like sync of time outside |the smearing period as well as external input on planned leap events) As far as i know nothing except the fully-blown and slow RFC 7808 tzdist (untested) and Poul-Henning Kamp's leap DNS record idea as posted on leapsecs@ helps to avoid the downloading and parsing of the IERS leapseconds file on your own if you want to include leapsecond notification in a daily report, on at least systems which were off overnight. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Wed Jan 31 12:57:18 2018 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 2C05D1242F7 for ; Wed, 31 Jan 2018 12:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 BnTM5pAKeY-R for ; Wed, 31 Jan 2018 12:57:15 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 11CE6124217 for ; Wed, 31 Jan 2018 12:57:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=9lPB2hd0lpOzef8pdW1PdkFGA7L6iqGgI6cVhr9eGm8=; b=WreZ4V0O2X2Ncp4g88ZzKQqWP EbPwEvmZXhhPGEgIAGtrRgk4QDH0SdxougD4zjV9+NtuZ+ZYRfgzXGXs+VxtkEIUsG/iAZgiyNhpf 2Ts5EzHUyMvLWqjhNAL8rMYsEUjQPzlNbNlCs7A+/jlkgVYzwU7++IISTktdX8qPfl7qB570P1Vqz Oeg85sR6/RV4UvXyJwYQDPetoZnM1mrYbx7d14w8eICOX6RyJ8ZpzMSVZ4oZuBpageOXcxi0I7lip 6CTX2uwB8GOQOY94ZgDkwRAKL270Srk2iqi6rrpDlwjFbqHaS3T/fGaJuoRO4CKKsjulF9QPTqdLl z09ugWcPA==; Received: from [204.140.240.55] (port=59527 helo=[172.26.51.117]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1egzRG-003qsR-Gr; Wed, 31 Jan 2018 15:57:03 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (15D60) In-Reply-To: <20180131204909.uNHwK%steffen@sdaoden.eu> Date: Wed, 31 Jan 2018 12:56:55 -0800 Cc: art@ietf.org, Martin Burnicki Content-Transfer-Encoding: quoted-printable Message-Id: <8637E113-79F7-46E9-81F1-367F79B6E029@strayalpha.com> References: <6a2080c9-1e9b-a683-38fe-b69bcc8a1d0b@meinberg.de> <92593352-ac39-2208-24a3-912fd020caf0@strayalpha.com> <20180131204909.uNHwK%steffen@sdaoden.eu> To: Steffen Nurpmeso X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [art] Confirm submission of I-D draft-touch-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, 31 Jan 2018 20:57:17 -0000 Hi Steffens, Leap seconds are introduced months in advance. Short of a new boot, there sh= ould not be an urgent need to update that info so rapidly.=20 It would be useful to have more efficient ways to do that update though.=20 Joe > On Jan 31, 2018, at 12:49 PM, Steffen Nurpmeso wrote:= >=20 > Joe Touch wrote: > ... > |(i.e., AFAICT, smearing is a local function that doesn't involve > |synchronization per se, but does rely on NTP-like sync of time outside > |the smearing period as well as external input on planned leap events) >=20 > As far as i know nothing except the fully-blown and slow RFC 7808 > tzdist (untested) and Poul-Henning Kamp's leap DNS record idea as > posted on leapsecs@ helps to avoid the downloading and parsing of > the IERS leapseconds file on your own if you want to include > leapsecond notification in a daily report, on at least systems > which were off overnight. >=20 > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) >=20 > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art From nobody Wed Jan 31 14:31:25 2018 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 B378712426E for ; Wed, 31 Jan 2018 14:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 YUCE5CFv39N0 for ; Wed, 31 Jan 2018 14:31:21 -0800 (PST) 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 477E6124D37 for ; Wed, 31 Jan 2018 14:31:21 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w0VMVHxM023313; Wed, 31 Jan 2018 23:31:17 +0100 (CET) Received: from [192.168.217.114] (p5DC7EAF5.dip0.t-ipconnect.de [93.199.234.245]) (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 3zWydc6hVLzDX4X; Wed, 31 Jan 2018 23:31:16 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Wed, 31 Jan 2018 23:31:16 +0100 Cc: Applications and Real-Time Area Discussion , "Manger, James" X-Mao-Original-Outgoing-Id: 539130675.1209919-3d79126d29b8f6a9e5899de942644a25 Content-Transfer-Encoding: quoted-printable Message-Id: <67A2F04D-9D38-4BF2-A96E-D29992A19F2E@tzi.org> References: <151641287464.3257.11011391661979125459.idtracker@ietfa.amsl.com> <20180127190806.GA23684@ucolick.org> <0E386E45-AC4D-413F-9CFF-6E644F2C4311@tzi.org> <681BFFCE-B468-4A10-8F2B-26260E4BB90D@tzi.org> To: Joe Touch X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [art] Confirm submission of I-D draft-touch-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, 31 Jan 2018 22:31:24 -0000 > On Jan 31, 2018, at 17:37, Joe Touch wrote: >=20 >=20 >=20 > On 1/31/2018 7:38 AM, Carsten Bormann wrote: >>>> On Jan 30, 2018, at 11:22 PM, Carsten Bormann >>>> wrote: >>>>=20 >>>> SLOTH is a much better time scale for most systems that have to = contend with the Posix time scale now. >>>>=20 >>> Can you explain why this is better than using UTC? >>>=20 >> It=E2=80=99s not =E2=80=94 it=E2=80=99s just not on the table with = most applications that are running on the Posix time scale. >>=20 > OK, so I'll as "why?=E2=80=9D Because a ton of legacy applications would have to be rewritten. > Here's my assumptions: >=20 > - the primary value in using Posix is for systems without external = interactions, e.g., where there is no way to obtain information about = newly scheduled leap events and where there is no way to synchronize to = an external time frame. The primary value of using Posix is that it is the interface definition = that governs the dominant operating system of the Web and a lot of = software derived from that. This is not the only place where Posix is broken. It just mainly = codified existing practice that already was broken (i.e., blame Ken = Thompson not thinking about leap seconds in 1969, when the problem of = UTC vs. TAI was still solved by a historical form of [whole-year] = smearing =E2=80=94 at least Unix time is no longer counting in 60ths of = a second :-). > - once you add external I/O, I can't see a good reason not to just use = UTC because you now have all the information was missing that motivated = the use of Posix in the first place, and *every other time reference is = just as much work, but much less widely used* (and in some cases, more = challenging to compute - e.g., the floating point concerns I raised with = smearing). If you are writing everything from scratch. That=E2=80=99s not what = happens. By the way, RFC 7164 is a nice example of the problem becoming visible = on a protocol that actually runs on systems that may implement (or = ignore) leap seconds in different ways. RFC 7164 recommends against basing RTP timestamps on smeared time. = Given that we Europeans are used to a 4 % increase in playback speed of = movies, we are likely to be inclined to accept a 0.0016 % error that = would be introduced by smearing here. > However, I can see why some systems libraries might also support = conversion to "Google's time", in much the same way many time libraries = support conversion to other calendars, both past and present (Hindu, = Jewish, Navjo, Julian, Mayan, Incan, StarDate, etc.). Posix time already is the system time, both for applications that care = about specifics of time (which might even know about the Jewish = calendar) and the much larger class that don=E2=80=99t really but still = have to deal with time somehow. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jan 31 17:28:42 2018 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 E336F12EB14 for ; Wed, 31 Jan 2018 17:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 T4mYj6Fmp-fw for ; Wed, 31 Jan 2018 17:28:39 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 03B6E12420B for ; Wed, 31 Jan 2018 17:28:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=maov4LnaWpuUjVvpDo1qpLS7hJZIpBJQ0wnqdoDY93M=; b=UNTbjhxHpYN8RF2zkSZvl9Ueo PIa24HvJWmauerLOnKLiWCatVopqG/FEhETO0IiRYPL4B3Z2UWZkZjOEHqcC45ykWEgFaaiiROSjG sve+qVgj/rS7zY/r/o1VqVZowgwZmAG/8JtkjwCRBjPN6ZfdX35Vwwwdz1swnx/q7bQ0b0/SnhPqm TrSzVn1NfcPjfreQykAaNLt0Wmb31mcLpPOykykhtiPpM6LmkZ49jen4sNvjlqDRiGju9OysSq6dh 8rbKupkujwtaiJSH9XSlxVUrjZhq2QsSwoDKDH4S+CIovvRn7U2/TwcN9TD4U67YbgY4kdvNQQVGh qRqW/loGg==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:62709 helo=[192.168.1.158]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1eh3fy-004DzE-B1; Wed, 31 Jan 2018 20:28:31 -0500 Content-Type: multipart/alternative; boundary=Apple-Mail-9FD720A5-0ED1-44F9-902C-1CCD5B4FDA0C Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPad Mail (15C202) In-Reply-To: <67A2F04D-9D38-4BF2-A96E-D29992A19F2E@tzi.org> Date: Wed, 31 Jan 2018 17:28:29 -0800 Cc: Applications and Real-Time Area Discussion , "Manger, James" Content-Transfer-Encoding: 7bit Message-Id: <47ABA1B7-E77C-41E9-88AB-8618071B205C@strayalpha.com> References: <151641287464.3257.11011391661979125459.idtracker@ietfa.amsl.com> <20180127190806.GA23684@ucolick.org> <0E386E45-AC4D-413F-9CFF-6E644F2C4311@tzi.org> <681BFFCE-B468-4A10-8F2B-26260E4BB90D@tzi.org> <67A2F04D-9D38-4BF2-A96E-D29992A19F2E@tzi.org> To: Carsten Bormann X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [art] Confirm submission of I-D draft-touch-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: Thu, 01 Feb 2018 01:28:41 -0000 --Apple-Mail-9FD720A5-0ED1-44F9-902C-1CCD5B4FDA0C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten, On Jan 31, 2018, at 2:31 PM, Carsten Bormann wrote: >> OK, so I'll as "why?=E2=80=9D >=20 >=20 > Because a ton of legacy applications would have to be rewritten. If you change this value they hold in what they think is Posix time to somet= hing else, it=E2=80=99ll break them in other unpredictable ways. That helps no one. Joe= --Apple-Mail-9FD720A5-0ED1-44F9-902C-1CCD5B4FDA0C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Carsten,

On J= an 31, 2018, at 2:31 PM, Carsten Bormann <cabo@tzi.org> wrote:

On Jan 31, 2018, at 17:37, Joe Touch <touch@strayalpha.com> wrote:


<= /span>
On 1/31/2018 7:38= AM, Carsten Bormann wrote:
On Jan 30, 2018, at 11:22 PM, Cars= ten Bormann <cabo@tzi.org><= br>
wrote:
<= blockquote type=3D"cite">

SLOTH is a much better time= scale for most systems that have to contend with the Posix time scale now.<= /span>

=
Can you explain why t= his is better than using UTC?
=

It=E2=80=99s not =E2=80=94 it=E2=80=99s just not on the table with m= ost applications that are running on the Posix time scale.

OK, so I'll as "why?=E2=80=9D

Because a ton of legacy applications= would have to be rewritten.

If you change= this value they hold in what they think is Posix time to something else, it= =E2=80=99ll break them in other unpredictable ways.


 That helps no one.

Joe
<= /body>= --Apple-Mail-9FD720A5-0ED1-44F9-902C-1CCD5B4FDA0C-- From nobody Wed Jan 31 22:28:48 2018 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 5B1CF13157D for ; Wed, 31 Jan 2018 22:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 njKtKTH4RlGZ for ; Wed, 31 Jan 2018 22:28:44 -0800 (PST) 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 D271C13157C for ; Wed, 31 Jan 2018 22:28:43 -0800 (PST) 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 w116SdYb006759; Thu, 1 Feb 2018 07:28:39 +0100 (CET) Received: from [192.168.217.102] (p5DC7EAF5.dip0.t-ipconnect.de [93.199.234.245]) (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 3zX9DR0m3LzDX7S; Thu, 1 Feb 2018 07:28:39 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: <47ABA1B7-E77C-41E9-88AB-8618071B205C@strayalpha.com> Date: Thu, 1 Feb 2018 07:28:38 +0100 Cc: Applications and Real-Time Area Discussion , "Manger, James" X-Mao-Original-Outgoing-Id: 539159317.090796-dc0e6fed06d70cc3396ac639f604820f Content-Transfer-Encoding: quoted-printable Message-Id: References: <151641287464.3257.11011391661979125459.idtracker@ietfa.amsl.com> <20180127190806.GA23684@ucolick.org> <0E386E45-AC4D-413F-9CFF-6E644F2C4311@tzi.org> <681BFFCE-B468-4A10-8F2B-26260E4BB90D@tzi.org> <67A2F04D-9D38-4BF2-A96E-D29992A19F2E@tzi.org> <47ABA1B7-E77C-41E9-88AB-8618071B205C@strayalpha.com> To: Joe Touch X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [art] Confirm submission of I-D draft-touch-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: Thu, 01 Feb 2018 06:28:46 -0000 On Feb 1, 2018, at 02:28, Joe Touch wrote: >=20 >> Because a ton of legacy applications would have to be rewritten. >=20 > If you change this value they hold in what they think is Posix time to = something else, it=E2=80=99ll break them in other unpredictable ways. About as much as 1.2e-5 clock drift, which applications already had to = contend with before. Besides, the experiment already has been made in some very large sites, = and site operators/reliability engineers liked the outcome. No doubt, leapsecond smearing is wrong, impure, and a giant hack. But the previous way in which Posix time worked is all these, too, plus = it loses monotonicity and has a step function. We haven=E2=80=99t put an indication of a time scale in = draft-bormann-cbor-time-tag-01 yet (draft-bormann-cbor-time-tag-00 had = one, but it wasn=E2=80=99t fully cooked). Besides UTC, TAI, and = real-time variants of these (UTC(PTB) etc., TAI as approximated towards = UTC(USNO) a.k.a. =E2=80=9CGPS time + 19 s=E2=80=9D, ...), it would be = useful to have a smeared leapsecond time scale in there (and preferably = just one). If the IETF can be instrumental in fostering and documenting = some consensus here, this would be a big win. Gr=C3=BC=C3=9Fe, Carsten