Re: [dtn] DTN time and RFC8877

"Burleigh, Scott C (US 312B)" <scott.c.burleigh@jpl.nasa.gov> Fri, 04 December 2020 18:13 UTC

Return-Path: <scott.c.burleigh@jpl.nasa.gov>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2BB3A0E78 for <dtn@ietfa.amsl.com>; Fri, 4 Dec 2020 10:13:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.42
X-Spam-Level:
X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_GOV_DKIM_AU=-0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_NOVOWEL=0.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jpl.nasa.gov
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 MRKdpyrWlpeq for <dtn@ietfa.amsl.com>; Fri, 4 Dec 2020 10:13:32 -0800 (PST)
Received: from ppa01.jpl.nasa.gov (ppa01.jpl.nasa.gov [128.149.137.112]) (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 99C5C3A0E65 for <dtn@ietf.org>; Fri, 4 Dec 2020 10:13:32 -0800 (PST)
Received: from pps.filterd (ppa01.jpl.nasa.gov [127.0.0.1]) by ppa01.jpl.nasa.gov (8.16.0.27/8.16.0.27) with SMTP id 0B4IDT4G182659; Fri, 4 Dec 2020 10:13:29 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jpl.nasa.gov; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=InSight1906; bh=VgirdR+Di8jwQSbOfirA8GhJhG3kLjlMQyYC1hwaXoc=; b=rE5dITjNNinR3ddcMKtVRPv/WEzbbNFGS28a00XHcMH2niFfCFqAlZJWScvn0lEAgg7l qBcVRx5137IKR/osEcdSHSAJbcCNVKXLVHNlxVou69uD5H/mNraXtlFtdRmqN2dIy0zU yN5L0Kq1ToKS871M+UaAvaR00F6NvfhMupESZQB0X9XZBc6wMJtYnTUbv/IWhdndFXO1 i+i9GmBLoLh2QzVMuEoHuVXbs6nainvkR1il2XFUSw1QrzZWgcwSBB6ZUWRcOXQCrUmp 5Ltieuc2m8JGNpqWL6jS4nthvDJSGkSin06nKMqa+bzph2qhi3rtKZcqCngWSy3izwAZ rQ==
Received: from mail.jpl.nasa.gov (av-senagnt-sp01.jpl.nasa.gov [128.149.137.102]) by ppa01.jpl.nasa.gov with ESMTP id 356pk29sbx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 04 Dec 2020 10:13:29 -0800
Received: from ap-embx16-sp30.RES.AD.JPL (ap-embx16-sp30.jpl.nasa.gov [128.149.137.85]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.5.3/Sentrion-MTA-4.5.3) with ESMTPS id 0B4ICgng045138 (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128 bits) verified FAIL); Fri, 4 Dec 2020 18:12:43 GMT
Received: from ap-embx16-sp10.RES.AD.JPL (2002:8095:8953::8095:8953) by ap-embx16-sp30.RES.AD.JPL (2002:8095:8955::8095:8955) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Fri, 4 Dec 2020 10:13:28 -0800
Received: from ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b]) by ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b%17]) with mapi id 15.01.1979.006; Fri, 4 Dec 2020 10:13:27 -0800
From: "Burleigh, Scott C (US 312B)" <scott.c.burleigh@jpl.nasa.gov>
To: Brian Sipos <BSipos@rkf-eng.com>, Carsten Bormann <cabo@tzi.org>, "R. Atkinson" <rja.lists@gmail.com>
CC: "dtn@ietf.org" <dtn@ietf.org>
Thread-Topic: [dtn] DTN time and RFC8877
Thread-Index: AQHWymBhK77KrRbeI0C/NcvU9OSB1qnnLGIQgACTgAD//3zX0A==
Date: Fri, 04 Dec 2020 18:13:27 +0000
Message-ID: <b0635a10c8e84765839d1323f77a7e5e@jpl.nasa.gov>
References: <MN2PR13MB3567AB6566B5B2C8F3DBB4A59FF10@MN2PR13MB3567.namprd13.prod.outlook.com> <79AB2C3F-D470-4381-9DDA-A3A3045140B6@gmail.com>, <79172DA3-C10C-439F-A31D-40F21ED9F503@tzi.org> <MN2PR13MB3567FC3F22BCF58531A709329FF10@MN2PR13MB3567.namprd13.prod.outlook.com>, <f99ddda56ee646a9bbc74514b91a4615@jpl.nasa.gov> <MN2PR13MB3567EFBED8E8524EDA6D97D39FF10@MN2PR13MB3567.namprd13.prod.outlook.com>
In-Reply-To: <MN2PR13MB3567EFBED8E8524EDA6D97D39FF10@MN2PR13MB3567.namprd13.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [207.151.104.72]
Content-Type: multipart/alternative; boundary="_000_b0635a10c8e84765839d1323f77a7e5ejplnasagov_"
MIME-Version: 1.0
X-Source-IP: ap-embx16-sp30.jpl.nasa.gov [128.149.137.85]
X-Source-Sender: scott.c.burleigh@jpl.nasa.gov
X-AUTH: Authorized
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-12-04_07:2020-12-04, 2020-12-04 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2009150000 definitions=main-2012040105
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/JHY8E7qOR5GN_nbZfejnGBsw5vo>
Subject: Re: [dtn] DTN time and RFC8877
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Dec 2020 18:13:36 -0000

Sure, I'm happy to remove "which is exactly 946684800 seconds after the Unix Epoch" from the proposed revised text.

Scott

From: Brian Sipos <BSipos@rkf-eng.com>
Sent: Friday, December 4, 2020 10:00 AM
To: Burleigh, Scott C (US 312B) <scott.c.burleigh@jpl.nasa.gov>; Carsten Bormann <cabo@tzi.org>; R. Atkinson <rja.lists@gmail.com>
Cc: dtn@ietf.org
Subject: [EXTERNAL] Re: [dtn] DTN time and RFC8877

Scott,
Your last revised text (in that email) is okay, except that I think it's best to avoid "unix time" or "unix epoch". Both "UTC" and "unix time" have a lot of baggage beyond using them as instant-of-time epoch references. And implementations of unix time seem to do all kinds of funny things that're not strictly in the specs.

Carsten,
The statement "... is not affected by leap seconds." is specifically the recommended language of RFC 8877 for describing this situation. DTN time uses a specific epoch instant as a zero reference and then uses TAI/UTC rate-of-time as its unit scale.
________________________________
From: Burleigh, Scott C (US 312B) <scott.c.burleigh@jpl.nasa.gov<mailto:scott.c.burleigh@jpl.nasa.gov>>
Sent: Friday, December 4, 2020 12:23
To: Brian Sipos <BSipos@rkf-eng.com<mailto:BSipos@rkf-eng.com>>; Carsten Bormann <cabo@tzi.org<mailto:cabo@tzi.org>>; R. Atkinson <rja.lists@gmail.com<mailto:rja.lists@gmail.com>>
Cc: dtn@ietf.org<mailto:dtn@ietf.org> <dtn@ietf.org<mailto:dtn@ietf.org>>
Subject: RE: [dtn] DTN time and RFC8877


Brian, I think it's actually not all that unusual: it's exactly the way the time() system call is defined on the time(2) man page.  Unix calendar time is a simple count of seconds, just as TAI is, and the starting point of the count is a moment in time that we commonly identify as a time value on the UTC time scale.



It's true that TAI and UTC both advance at the same rate, one second per second, but the offset between TAI and UTC changes as new leap second adjustments are made in UTC: as each leap second is declared, the offset between TAI and UTC increases by 1 second - TAI advances by 1 second and UTC does not.  In my proposed revised text I said "DTN time is not affected by leap seconds."  Does that address your concern?



Scott



From: dtn <dtn-bounces@ietf.org<mailto:dtn-bounces@ietf.org>> On Behalf Of Brian Sipos
Sent: Friday, December 4, 2020 9:10 AM
To: Carsten Bormann <cabo@tzi.org<mailto:cabo@tzi.org>>; R. Atkinson <rja.lists@gmail.com<mailto:rja.lists@gmail.com>>
Cc: dtn@ietf.org<mailto:dtn@ietf.org>
Subject: [EXTERNAL] Re: [dtn] DTN time and RFC8877



Scott,

I think the current statement is fine, it's just unusual to mix UTC-the-datum with TAI-the-lack-of-leap-seconds.

Because TAI and UTC only differ by a time-varying offset [1] but use the same rate, these two are identical statements:

  1.  "time elapsed since the start of the year 2000 on the Coordinated Universal Time (UTC) scale" which is what BPbis currently states.
  2.  "time elapsed since 32 seconds after the start of the year 2000 on the TAI scale" which accounts for the TAI-UTC leap second difference of 32 on 1 Jan 2000.

In either case, a statement such as the RFC8877 phrasing of "DTN Time is not affected by leap seconds." would add clarity to the situation without affecting the current agreed requirement text.



[1] https://cdf.gsfc.nasa.gov/html/CDFLeapSeconds.txt<https://urldefense.us/v3/__https:/nam10.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fcdf.gsfc.nasa.gov*2Fhtml*2FCDFLeapSeconds.txt__*3B!!PvBDto6Hs4WbVuu7!au7pNhZH89rogLdZXrVRil2SNQj43GU3wk2GEVPxFbfnbJc0enzoIwG6JJkLTO6LGLz7VB40fAU*24&data=04*7C01*7CBSipos*40rkf-eng.com*7C34669fd5ab7740e52fb108d898794261*7C4ed8b15b911f42bc8524d89148858535*7C1*7C1*7C637426993859020246*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=286lwpqaYG0s9nlF9KZWHdgUWrs2CFPxa0RnxP9P8zA*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!PvBDto6Hs4WbVuu7!b_MQpI1_GEOkrPGC_iJZXUN2j7_sA73Y-zu5PddwK3WKggS523TbFo2eEMhbYWgzzFMbAGEj-Ho$>

________________________________

From: Carsten Bormann <cabo@tzi.org<mailto:cabo@tzi.org>>
Sent: Friday, December 4, 2020 10:40
To: R. Atkinson <rja.lists@gmail.com<mailto:rja.lists@gmail.com>>
Cc: Brian Sipos <BSipos@rkf-eng.com<mailto:BSipos@rkf-eng.com>>; dtn@ietf.org<mailto:dtn@ietf.org> <dtn@ietf.org<mailto:dtn@ietf.org>>
Subject: Re: [dtn] DTN time and RFC8877



On 2020-12-04, at 15:52, R. Atkinson <rja.lists@gmail.com<mailto:rja.lists@gmail.com>> wrote:
>
> (or specify that they are ignored).

You can't say just that, because there are two ways to handle "ignoring" leap seconds, and when you say they are "ignored", you don't say which one.

(One way of "ignoring" leap seconds is to stay in TAI, which has no concept of leap seconds.
The other way is actually being cognizant of them and doing work to "ignore" them, i.e., reset the clock after each of them.  This is what UTC does to be able to "ignore" leap seconds.)

Grüße, Carsten