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

Stewart Bryant <> Fri, 08 November 2019 14:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BA1AD120807; Fri, 8 Nov 2019 06:34:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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_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 9WJbq-2ixL0K; Fri, 8 Nov 2019 06:34:15 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8A19F12008C; Fri, 8 Nov 2019 06:34:15 -0800 (PST)
Received: by with SMTP id q130so6460917wme.2; Fri, 08 Nov 2019 06:34:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=sJcssbeZOeZLg1snfbp7HAEhVfxbRm9t0nfgxvZAwpI=; b=dt8JlflYFztlpfRYSdAmmjL/+fQRj0uL6YP7F8itlxPFtmW3zNvnMmlySQP9qAodSl T82eRBhcM/7dNVaeeupC6emkyvBBKZ26cwDVrh+KdqSqPSndm+sAswHY5yNia3hJ79Ce XzpUFuwEBDuASeimd+DFvg18yLmfVCWVHd2wvo+YDIEfi3Z2T+yq2u4BFoIlKXFpZwAu He0lz+ru1FcLWCD5EnNlhnpkSvPavqYQWDeT8zy2WutXYWImXr6aJQWloOn2vfG0BK/j Y+0yWTiJ/VvdGHTSc6iar5xuibU+/vJK7MwTmshECnf2EtuoEgcSESKjDEO2nMpimhhh 6ZDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=sJcssbeZOeZLg1snfbp7HAEhVfxbRm9t0nfgxvZAwpI=; b=JTrqWFRcCyrf4ShyFj106wcTcYLA4Xcquj00vObB4hhxcAlqtxS5cCYuOZzfqlCNvj D02keIaizuYw1oDZ7NKdpSOLXayITfNMM0D8BlCw+6943YTYSQxofoCDFZ9vWxVo/Ff2 IMtHAsYcXN02gST5IJLu3p16sMbY0UcvlLD9vOFDhPnAt0fmKrEdxeG9ZskDb8qIt2Nn TA0KgIcsD95j5LaA73XaNWVSLXGgEcxbEE7SVA6WXPopXMPI3/ajCrnruCDVHuMo0HeE SlHf40k/6Hn+RbymILExOj/7yrbhC95SDtds0uQkZZuTJxBHcGXFgDyKVk2j7LXSRUtu 56Jw==
X-Gm-Message-State: APjAAAV0MqHuPyGZfWyoGpCkGsHNlDWaxQ4R0bV3ZxSwZ9YRMgBMrKuG VCK8M9qKqspNcWFk95DHH6A=
X-Google-Smtp-Source: APXvYqxvMJYEDnz8N3hgUIZa/Y4JFAtR2eLXGd3aZshx8pK8eMrOqvk8vvWjk7I1qGTfMPe70PiB3Q==
X-Received: by 2002:a1c:a5c8:: with SMTP id o191mr8327636wme.168.1573223653935; Fri, 08 Nov 2019 06:34:13 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id q15sm6058193wrr.82.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Nov 2019 06:34:13 -0800 (PST)
From: Stewart Bryant <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0120B035-7F4A-4840-8BF5-58585A1848CC"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Fri, 8 Nov 2019 14:33:10 +0000
In-Reply-To: <>
Cc: Magnus Westerlund <>, "" <>, "" <>, "" <>, "" <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <>
Subject: Re: [dtn] [Last-Call] 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 14:34:18 -0000

> On 8 Nov 2019, at 13:03, wrote:
> <>
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