Re: [dtn] [EXTERNAL] Re: [Last-Call] Genart last call review of draft-ietf-dtn-bpbis-17

"Burleigh, Scott C (US 312B)" <scott.c.burleigh@jpl.nasa.gov> Fri, 08 November 2019 15:34 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 82E77120812; Fri, 8 Nov 2019 07:34:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 NQs0vCsyLmV2; Fri, 8 Nov 2019 07:34:07 -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 F0B3112080E; Fri, 8 Nov 2019 07:34:06 -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 xA8FUFbX050939; Fri, 8 Nov 2019 07:34:02 -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=GOSpMOWzIZh22/XGWX78q29nK0EylfKfF5JxabyY11Y=; b=vAJvEMOvsM6beDLhsyiN1Ek8nUwgutQdZ5toCh+3lJ1YP4gp7KS22D2H6ptjxxVhBGi7 oa1W/W7v26S/CqBFK96HK0KkjmdCJ8kCiAh4DFL4lE8t2htriF+rIHM4gXz45d1qMFgl 2Ek1sFieX2GerxeawjvsY0/9iHQGBZodVPVBfA+uAYcKEmSMQEXOrpSRJiTP/g/lOgLs xCTEvSr/XaNe3aJr+JNWvvlULPjbKAcdvBxoDls40yx0p4uDvJI57av7EcOHudKbMmWl HXKqsfUOTTrWYUUNder2RmeEaKXOHg+plwWTnu2f9oueT3t+A4ATJc9Sbz+4VkV7Dnj0 lQ==
Received: from mail.jpl.nasa.gov (altphysenclup02.jpl.nasa.gov [128.149.137.53]) by ppa01.jpl.nasa.gov with ESMTP id 2w41uht2ma-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 08 Nov 2019 07:34:02 -0800
Received: from ap-embx16-sp60.RES.AD.JPL (ap-embx16-sp60.jpl.nasa.gov [128.149.137.141]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id xA8FY0M8016263 (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128 bits) verified FAIL); Fri, 8 Nov 2019 07:34:00 -0800
Received: from ap-embx16-sp10.RES.AD.JPL (2002:8095:8953::8095:8953) by ap-embx16-sp60.RES.AD.JPL (2002:8095:898d::8095:898d) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Fri, 8 Nov 2019 07:34:00 -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.1591.008; Fri, 8 Nov 2019 07:34:00 -0800
From: "Burleigh, Scott C (US 312B)" <scott.c.burleigh@jpl.nasa.gov>
To: Stewart Bryant <stewart.bryant@gmail.com>, "lloyd.wood@yahoo.co.uk" <lloyd.wood@yahoo.co.uk>
CC: Magnus Westerlund <magnus.westerlund@ericsson.com>, "last-call@ietf.org" <last-call@ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>, "draft-ietf-dtn-bpbis.all@ietf.org" <draft-ietf-dtn-bpbis.all@ietf.org>, "dtn@ietf.org" <dtn@ietf.org>
Thread-Topic: [EXTERNAL] Re: [Last-Call] Genart last call review of draft-ietf-dtn-bpbis-17
Thread-Index: AQHVljTsVQnJrJRlrE224GbltiEk4aeB3JUA//+AThA=
Date: Fri, 8 Nov 2019 15:34:00 +0000
Message-ID: <17ed0ca2fddc42c5bec46925d10a0458@jpl.nasa.gov>
References: <157306815414.27362.18239257168598208900@ietfa.amsl.com> <65cb92a64e5e6d5010392ad33d70be44c8abc962.camel@ericsson.com> <A75165E4-126B-4791-9A6D-7CDF555A431C@gmail.com> <430992730.1235576.1573218197349@mail.yahoo.com> <EFC9E9F1-D43C-46B4-A38B-53EB76E1D3AD@gmail.com>
In-Reply-To: <EFC9E9F1-D43C-46B4-A38B-53EB76E1D3AD@gmail.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_17ed0ca2fddc42c5bec46925d10a0458jplnasagov_"
MIME-Version: 1.0
X-Source-IP: ap-embx16-sp60.jpl.nasa.gov [128.149.137.141]
X-Source-Sender: scott.c.burleigh@jpl.nasa.gov
X-AUTH: Authorized
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-08_05:, , 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=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911080154
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/h7Ivg3sK12zduLlzrPuS1kPKBLM>
Subject: Re: [dtn] [EXTERNAL] Re: [Last-Call] Genart last call review of draft-ietf-dtn-bpbis-17
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, 08 Nov 2019 15:34:10 -0000

I disagree.  From Wikipedia:

Unix time (also known as Epoch time, POSIX time,[1]<https://en.wikipedia.org/wiki/Unix_time#cite_note-1> seconds since the Epoch,[2]<https://en.wikipedia.org/wiki/Unix_time#cite_note-single-unix-spec-4.16-2> or UNIX Epoch time[3]<https://en.wikipedia.org/wiki/Unix_time#cite_note-3>;) is a system for describing a point in time<https://en.wikipedia.org/wiki/Timestamp>;. It is the number of seconds<https://en.wikipedia.org/wiki/Second> that have elapsed since the Unix epoch, that is the time 00:00:00 UTC<https://en.wikipedia.org/wiki/Coordinated_Universal_Time> on 1 January 1970, minus leap seconds<https://en.wikipedia.org/wiki/Leap_second>;. Leap seconds are ignored,[4]<https://en.wikipedia.org/wiki/Unix_time#cite_note-single-unix-spec-rationale-4.16-4> with a leap second having the same Unix time as the second before it, and every day is treated as if it contains exactly 86400 seconds.[2]<https://en.wikipedia.org/wiki/Unix_time#cite_note-single-unix-spec-4.16-2> Due to this treatment Unix time is not a true representation of UTC.

Now, of course, this is Wikipedia, which everyone knows to be useless and unreliable.  But the summary is at least concise and clear, and in this particular case it is supported by several source documents, noted at the bottom of the article.

For example, “The Open Group Base Specifications Issue 7, Rationale: Base Definitions”, section A.4 (General Concepts) says “Coordinated Universal Time (UTC) includes leap seconds. However, in POSIX time (seconds since the Epoch), leap seconds are ignored (not applied) to provide an easy and compatible method of computing time differences.”

Going back a bit, page 166 of https://www.tuhs.org/Archive/Distributions/Research/Dennis_v5/v5man.pdf Dennis and Ritchie (who ought to know) say “Time returns the time since 00:00:00 GMT, Jan. 1, 1970, measured in seconds.”

I am happy to agree that an operating system’s implementation of the time() function may typically obtain accurate UTC time (from GPS or NTP) and subtract the leap seconds out of that value to obtain Epoch time, and in this sense the implementation of the time() function is typically dependent on information about leap seconds.

But that is an implementation expedient, which BP does not care about.  What BP cares about is expressing time as a number of seconds that have elapsed since the Epoch (minus an offset, the number of seconds elapsed from the Epoch to midnight 1 January 2000 UTC).  The manner in which that value is generated doesn’t matter to the protocol.

Scott

From: Stewart Bryant <stewart.bryant@gmail.com>;
Sent: Friday, November 8, 2019 6:33 AM
To: lloyd.wood@yahoo.co.uk
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>;; last-call@ietf.org; gen-art@ietf.org; draft-ietf-dtn-bpbis.all@ietf.org; dtn@ietf.org
Subject: [EXTERNAL] Re: [Last-Call] Genart last call review of draft-ietf-dtn-bpbis-17




On 8 Nov 2019, at 13:03, lloyd.wood@yahoo.co.uk<mailto:lloyd.wood@yahoo.co.uk> wrote:

http://lloydwood.users.sourceforge.net/Personal/L.Wood/publications/wood-ieee-aerospace-2009-bundle-problems.pdf

The critical text in that paper is:

"The Bundle Protocol uses Coordinated Universal Time (UTC), where leap seconds are added at irregular, unpredictable, intervals to reflect slowing of the Earth’s rotation. For nodes ‘in the field’ for a long time (decades), some way of communicating newly-decided UTC leap seconds will be required to prevent clock drift over long time scales that would eventually lead to bundles expiring before delivery. This is most likely to be a significant issue for real-time traffic with very short bundle lifetimes."
That says that leap-seconds need to be transmitted to the remote site, but the ID does not say anything about that, indeed it silently implies that this is handled.
The draft text says

Like TAI, Unix epoch time

   is simply a count of seconds elapsed since a standard epoch.  Unlike

   TAI, the current value of Unix epoch time is provided by virtually

   all operating systems on which BP is likely to run.

Which is not quite right. The TAI is a continuous count of the number of seconds since the epoch. The UNIX tine is the continuous count + leap seconds since the epoch. Unix knows how many leap seconds have happened by a background process and adds them in, but for that to work it has to have a method of knowing the current leap second state. BTW leap seconds can be removed as well as added.

- Stewart