Re: [Cbor] [dtn] [EXTERNAL] Re: [EXT] Re: LTC timescale (Re: Question regarding RFC 9171 - How to incorporate "Coordinated Lunar Time")

scott@solarnetone.org Sat, 13 April 2024 01:54 UTC

Return-Path: <scott@solarnetone.org>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22804C14F68D; Fri, 12 Apr 2024 18:54:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPCYL0ZFJveh; Fri, 12 Apr 2024 18:54:20 -0700 (PDT)
Received: from www.solarnetone.org (solarnetone.org [IPv6:2602:fdf2:bee:feed::a1a]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05E29C14F68A; Fri, 12 Apr 2024 18:54:19 -0700 (PDT)
Received: from scott (helo=localhost) by www.solarnetone.org with local-esmtp (Exim 4.96) (envelope-from <scott@solarnetone.org>) id 1rvSaq-00065p-1G; Fri, 12 Apr 2024 21:54:12 -0400
Date: Fri, 12 Apr 2024 21:54:12 -0400
From: scott@solarnetone.org
To: sburleig.sb@gmail.com
cc: 'Stephen Farrell' <stephen.farrell@cs.tcd.ie>, "'Rieber, Richard R (US 347R)'" <richard.r.rieber=40jpl.nasa.gov@dmarc.ietf.org>, 'Jorge Amodio' <jmamodio@gmail.com>, "'EXTERNAL-Sipos, Brian J (US 9300-Affiliate)'" <brian.sipos@jhuapl.edu>, 'John Dowdell' <john.dowdell.ietf@gmail.com>, 'Carsten Bormann' <cabo@tzi.org>, 'DTN WG' <dtn@ietf.org>, cbor@ietf.org
In-Reply-To: <042001da8d3f$4f9bd640$eed382c0$@gmail.com>
Message-ID: <c14b9834-50cc-3627-4ac1-04960b7254f4@solarnetone.org>
References: <85584DCA-C858-4298-B0F4-555FC42138F1@gmail.com> <141AE72F-7E78-47E6-9912-65A46AD11EF4@gmail.com> <d19700964a314d6e9cd24c07b2a47c10@jhuapl.edu> <017b01da8cef$ecbdb920$c6392b60$@gmail.com> <CAMzo+1aYC+cg=os8zQi3US1i+YX_WrMy-XcJY-haFp2GbMYavw@mail.gmail.com> <PH8PR09MB89266BA5D11006169DD30B31F1042@PH8PR09MB8926.namprd09.prod.outlook.com> <d320b79e-fef4-4845-8caf-db138c795db6@cs.tcd.ie> <042001da8d3f$4f9bd640$eed382c0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/j_xujHALLOvCnHyvm5rJSDFQBwg>
Subject: Re: [Cbor] [dtn] [EXTERNAL] Re: [EXT] Re: LTC timescale (Re: Question regarding RFC 9171 - How to incorporate "Coordinated Lunar Time")
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Apr 2024 01:54:24 -0000

It would seem that there are ample other measures that could be 
implemented to resolve the problem described, all well short in complexity 
of standards action.

ScottJ

On Fri, 12 Apr 2024, sburleig.sb@gmail.com wrote:

> I completely agree.  As I suggested earlier, absolute alignment among BP nodes' clocks to microsecond accuracy is in no way necessary.  Changing the definition of "DTN time" would destabilize the BP specification - requiring modification of all BP implementations on all BP nodes in the Solar System, further deferring adoption of BP by flight missions, and broadly increasing mission cost - to no material benefit.  Let's not do it.
>
> Scott
>
> -----Original Message-----
> From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
> Sent: Friday, April 12, 2024 12:56 PM
> To: Rieber, Richard R (US 347R) <richard.r.rieber=40jpl.nasa.gov@dmarc.ietf.org>; Jorge Amodio <jmamodio@gmail.com>; sburleig.sb@gmail.com
> Cc: EXTERNAL-Sipos, Brian J (US 9300-Affiliate) <brian.sipos@jhuapl.edu>; John Dowdell <john.dowdell.ietf@gmail.com>; Carsten Bormann <cabo@tzi.org>; DTN WG <dtn@ietf.org>; cbor@ietf.org
> Subject: Re: [dtn] [EXTERNAL] Re: [EXT] Re: LTC timescale (Re: Question regarding RFC 9171 - How to incorporate "Coordinated Lunar Time")
>
>
> Hiya,
>
> On 12/04/2024 18:05, Rieber, Richard R (US 347R) wrote:
>> Does anyone think we should tweak the DTN Time field to utilize the
>> CBOR Timescale/Timesystem standard Carsten mentioned? I think we
>> should.
>
> I do not think such a change would be a good idea.
>
> If you did, then ISTM eventually nearly every BP node would need to be able to understand and translate between every possible planetary timescale. Sounds like a recipe for bugs and possible vulnerabilities to me.
>
> So, better for the lunar devices to translate to/from UTC when making or reading bundles I think.
>
> Cheers,
> S.
>
> _______________________________________________
> dtn mailing list
> dtn@ietf.org
> https://www.ietf.org/mailman/listinfo/dtn
>