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

lloyd.wood@yahoo.co.uk Fri, 08 November 2019 13:13 UTC

Return-Path: <lloyd.wood@yahoo.co.uk>
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 345C0120125 for <dtn@ietfa.amsl.com>; Fri, 8 Nov 2019 05:13:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level:
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.co.uk
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 pdtksIE0qTud for <dtn@ietfa.amsl.com>; Fri, 8 Nov 2019 05:13:29 -0800 (PST)
Received: from sonic303-20.consmr.mail.ir2.yahoo.com (sonic303-20.consmr.mail.ir2.yahoo.com [77.238.178.201]) (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 0E429120133 for <dtn@ietf.org>; Fri, 8 Nov 2019 05:13:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1573218806; bh=7qvBjGva35kCJRvSBdAkrkD+4SD2mjSiwwucMmFwYwM=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=eRvifpn7WpXjL/HqloA/miPjuwJENtR6vjNO+rB4tYlB7CKFo5HkDwPuo8sobuW7niKGMOPrW6ZQA+QqhxDRoQJOg9FzbhQ2iUUC/xAhvHDi7wHHCNbq75NCWo8mrP2SeKju1IBA4HO3tcYL2E3sz0t0fbRrNPgEhJ7i4i1V0gpBqVosVXSUV8qyh6Yf0t4txW8R2mmxhlcH+n7JexTNj/LpqL3GvIexSv/inB9ULGBNoPjlYvyIiDi8w3uBqfXnSqwqB6wEpMk5hC3po+nCxqhwegHUOdP9IRTdwldF85bnuwMGRfc6WcqXr3W/U0G0bRv+s3sIQ4MnDd3J19OG9A==
X-YMail-OSG: ug3TYUUVM1nc3PCCP1taGgHkz3L0T8802DtNdPm8un9_8xhziEIV_f7TTnUK28q CocAIWqQlip4pBUHNE_Mh_fOfpcSVXIkpOY0P1djpbKfUBbb.2rOprBPc_7ZnZRmcN1g1NomLast M4jqeNVMl7R8LTd.ok2mlhMyb4F_F6ShkTiD6oQ234mQsnlhid5.zhZUlE6eKu49_plWTwNt5sb2 O9z3v.2qABLWRlwatQ34FjzdKJkdITABh_ifMjPcbkeMbzKBnBAt3uffoiiLvRaKeJphPc3y.7Wu U2q1vDNCYV3_IqWU30wcKnDBGCRLdv1T8.2KZcs_arld60INSl8pKdVI02g9RLaoilwmdR7s6QUp fL6qHVzAbeHGmNx2R0zReBdfYxzy8eMED.m41cJR8.OVvqx9BTfra7f0hjXFvSBOWW1IhklE5jx3 sp0mwAMOAZaZBOfNx63tntfurOKBNlqgDsbp.ESUfQbWPV56HYrfBQMOKdZ1k.YHrD2xrUkUZsXv g05of78e3LIHGdsa.wvxII4SVmF_4vI1Rhqe0pSGG0yiYXlzQpEyZSvo0x5RrwML.yI2jG4eEeAo ZU.ilcr9Jal.FnhYpOlu1XvP0hRqk36lMgOdRgSRwgNvIdSQAtSnJqBmLtfRL8z2sUv6zbNSqEmi 3PQPRjR0nY_hyVrg8do4nz5kCUu5CmGbY78E5ldNLltXgMgLzFu8hYcSCjyh4_6_gX7yCPSLl6t5 UbBfVOTDPXLVtZNr1FWqdMAUl.mTABcOI5m3C7u9h3CuoaQlKeSFRqCz.5MJEH6w3toNeevBLsLx eUnvM22ARlKjvLcoRChp230oju_0j.ohRF42I0t8MrcQOOdI7FaGWyEWgQIXuExPw_ha2SOnO4Vc mGXNspVr2U26KxKyJqDLN1rgDCQP_Brc0mJfnnysG_tw6jjO2IojwRXEYPEK_zNaxp7brFEFTuA6 Y15kAK5xKEXtTeLwBmD09hpLGAxZpWsePv772Mdn0w_WzaGmsh4zqGARZAgta99ajvR32hp.GKJG o5ci9WMI0c7sZVGPqxarnms0ILo_JJcLw6KYKDvsDU0Dw5_wAGhTY2X.Fv9_MmUCfc9OUVHWI6ZH P5MI1HoDjLt.Mu0kec70HWOhZSuOtdK9OxRjnGCIQJqkuRxTKw.x2uXCeqe3Yo6GHqE06HSLg2OG nB8Ig9Se6mxqaYd1oSKyJl858l.FvskupXaVLkRURqfec36Am4xgCDEC6r7IVgk9.IGP6n8LV1h_ d1RiLVicQt_5R7gw0QLHeBHkKjvklv9f7_SntUH3GgDwsZ_mJ77_rh_zX4.LqLKuoOr.r8hbjDvX p1zt9IrineTpbuxdFaWXv5qr_WSN1Ga2tTLYUFJdSKl7vY0wE1.ao1wIfmm1BkeU2GvCW4sAD_xa lvQ83fA--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ir2.yahoo.com with HTTP; Fri, 8 Nov 2019 13:13:26 +0000
Date: Fri, 8 Nov 2019 13:03:17 +0000 (UTC)
From: lloyd.wood@yahoo.co.uk
To: Stewart Bryant <stewart.bryant@gmail.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>
Cc: "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>
Message-ID: <430992730.1235576.1573218197349@mail.yahoo.com>
In-Reply-To: <A75165E4-126B-4791-9A6D-7CDF555A431C@gmail.com>
References: <157306815414.27362.18239257168598208900@ietfa.amsl.com> <65cb92a64e5e6d5010392ad33d70be44c8abc962.camel@ericsson.com> <A75165E4-126B-4791-9A6D-7CDF555A431C@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_1235575_1334993064.1573218197347"
X-Mailer: WebService/1.1.14680 YahooMailIosMobile Raven/44290 CFNetwork/811.5.4 Darwin/16.7.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/GGloaisWk63JnR_kWaIzyaFIUn4>
Subject: Re: [dtn] [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 13:13:30 -0000

Yes, there is a risk that systems will drift due to accumulated leap seconds without updates.We worked throuugh the details... http://lloydwood.users.sourceforge.net/Personal/L.Wood/publications/wood-ieee-aerospace-2009-bundle-problems.pdf 
but keeping time accurately and continuously (temperature extremes causing drift, power loss) is likely more of an issue in many use cases.
The background assumption here is the NASA interplanetary internet use case (and first RG before DTNRG), where a spacecraft without a clock is useless, the clock is a critical component and sync'd with updates continuously somehow, all hail the clock.
DTN doesn't scale beyond that to other use cases that well.

Lloyd Woodlloyd.wood@yahoo.co.uk



On Friday, November 8, 2019, 11:35 pm, Stewart Bryant <stewart.bryant@gmail.com>; wrote:


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.