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

Stewart Bryant <> Fri, 08 November 2019 12:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0813A12007C; Fri, 8 Nov 2019 04:36:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xgpTNgQEw4RD; Fri, 8 Nov 2019 04:36:27 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D7930120041; Fri, 8 Nov 2019 04:36:26 -0800 (PST)
Received: by with SMTP id f2so6829701wrs.11; Fri, 08 Nov 2019 04:36:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xTY5KSSkvQyh5ENzjG+Sdgqs/nPz5leVMn+9kbtJcM0=; b=OjnMuaBfiiFMNFYrlbGUrSDBi8UBeUQmqxoCkLsYvnv3PItZ81yauVEkFLpWx03pw+ QWx8bLDN8f9O41WlMcoL32JQWYLOuaFpB0wAEeEXZ66qGeflxi9+lustmvbV0etj/9Tt LCXfWYvApCcejxloQGeUZzH1ebKhz1h12qYP7i0p00khqsRAdRvX0BkIrXskkRfQxz/E afswPfCh8POgvNizBLpE1T93wHKuW3d2UTNzHhC0WWdiO5W7f+FCYb5t7un9FwKqaV/d 7XckvYWbHCBb1kCM0mbSKC7QRSHTkdUfAJoRckg6rDfuh5f+BlwxEFPWHWxeRBp8IIal lJtw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xTY5KSSkvQyh5ENzjG+Sdgqs/nPz5leVMn+9kbtJcM0=; b=IFIwN8n8Qscnn0YnklHEZzGKCiEVHkAz/9a4HEbtGukdsCuG6Xd07RwwjehfXhqEdQ QS92L2UjvKYH06y32sTWayrLel+swUXmDEbT4GD4uTolvLE6X/JheD8HQqnPojN+ikf8 Ui/pNAk5Yr2QqWd3OeurgcpMoPEu4BZgYoHeNN8wUbpyRf1cKLW8xMBezUiH2+mO707P rJMXINm/xbrlO+Cwv+NZ2rt/+DXT43fckt2rPR9UaaEX92UREM26YYu7SV8w/HVLqBvK wFsFU7QxpXHdMhO/54jzia7IPKtstn92B6KbwpQMqlmrg+btLDGcgZtswCW3Fg9y84Ux +Wxg==
X-Gm-Message-State: APjAAAX/Ymaxp4zyXp+ocMPC496DQ3HQt83+3irvEnRbmUnVmWxPek+9 TcTwRaWaYzXfuIyR+PZcUgQ=
X-Google-Smtp-Source: APXvYqz5FoS7UCiXsn265OoplwlE0CGEHzdcWZOL5ZQQUzn192PxtF5l+gMhao9QVZ2GEytYbX8/DA==
X-Received: by 2002:adf:9f52:: with SMTP id f18mr7894615wrg.51.1573216585279; Fri, 08 Nov 2019 04:36:25 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id t24sm9116565wra.55.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Nov 2019 04:36:24 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
From: Stewart Bryant <>
In-Reply-To: <>
Date: Fri, 8 Nov 2019 12:35:52 +0000
Cc: "" <>, "" <>, "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Magnus Westerlund <>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <>
Subject: Re: [dtn] Genart last call review of draft-ietf-dtn-bpbis-17
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Nov 2019 12:36:29 -0000

>> SB> I think you are saying that you use Unix time, but Unix time
>> includes leap seconds by double increment, so I don’t think
>> you are using that because that would give you the measurement
>> error you are concerned about. I think that what you are using is
>> a monotonically increasing time based on the Unix epoch. I think
>> that is what PTP (IEEE1588) is using and PTP might be a better
>> reference. PTP is likely to become more available in spacecraft
>> anyway, since it is finding deployment in precision measurement
>> applications. Thus I am not sure I understand why UET is more
>> accessible on spacecraft than TAI. Presumably the spacecraft are using
>> free-running clocks and so will drift, although I understand that
>> work is in progress to provide time sync to spacecraft for
>> navigation purposes.
>> The argument in this section seems long and will become dated.
>> Surely all you need to say is that you need a monotonically
>> increasing time system such as TAI or UNIX time(), and out of
>> software convenience you choose the latter. However I don’t
>> think that is what you are actually doing. What I think you are doing
>> is using TAI with a free running clock that you accept will drift.
> So, when I did the AD review I did raise similar concerns, and the note was
> really intended to answer these questions of why the chosen clock rather than
> TAI or other clock definitions that would avoid some other issues. I got enough
> good answers to progress, but apparently the motivation part isn't clear enough
> to make you comfortable over the choices. 

Hi Magnus

I will address the other points in a later email, but on this I am concerned that WG have a misunderstanding of the timebase they are using. UNIX/POSIX time does have leap seconds it just handles them silently so you will get double increments. However since my follow-up note yesterday, I was wondering how the remote remote system knew to add a leap second in order to keep in track with the local system? Isn’t there a risk that the two systems will drift apart as leap seconds are added locally? Also there is the rollover problem to worry about.

I think the section needs to go to a specialist group for review such as TicToc/NTP to verify that it works exactly as the WG expect.

Best regards