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

Jorge Amodio <jmamodio@gmail.com> Fri, 12 April 2024 10:26 UTC

Return-Path: <jmamodio@gmail.com>
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 B9A77C14F694; Fri, 12 Apr 2024 03:26:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 P15lY2XxU1MP; Fri, 12 Apr 2024 03:26:00 -0700 (PDT)
Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D947CC14F5FB; Fri, 12 Apr 2024 03:26:00 -0700 (PDT)
Received: by mail-ot1-x335.google.com with SMTP id 46e09a7af769-6ea29cf24c6so429852a34.3; Fri, 12 Apr 2024 03:26:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712917560; x=1713522360; darn=ietf.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=20MjAJD/gCRgjCXc+93ITzGnXcgBpH4EzxQCUZU8cgs=; b=ghfvedntmqFS0yyFjq2nwatcd4Dot/QzqpqnIo8r5ezYGic4jv7tISvaPhgMXl1XOb 45F6QzKnibRMXuUJY+AjqhPpu3bsaTCpdbGn2kblZhJAlt1YMOdvttMZljzPkYMrl3i9 2YHM1ExBTlTO4MHUqePIQ0LCw/jnxRTx7N3/w2w5AV7cYp98yAc/aujJfpXzA09KSs3l SOu887GjO/cEvh5teOLdDJVWNt1/ec7Wm2BEvG2l/XTmHLO73QfHbVe8DATArK1vPBIe Z9AO4KnK4tw5a4kRes0eW+6Irbu587uPW70QYULZvu0Ga8Ec4i13q5d5ewjELZ3MbnAg pk3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712917560; x=1713522360; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=20MjAJD/gCRgjCXc+93ITzGnXcgBpH4EzxQCUZU8cgs=; b=sbfWdljSTeqO1Jx81dtKrZ7slahg3tgCaixoj1FR3hlaTGb0S9bln7YA4nE6E+vGZ3 QZOEpEB2UnXKcvPS9QDh2Y1/qaOsPcIzENRfOcF9aSBSKBReX7ynlkK4ai1OLtOJv+iO 7gT5NE9rTcvzWgvEb3IZ493dNMJqVCYjRb9DKVYP16kFryZMkJ5vhg5Hr3VdYspsVkPA oNZe+M9ed4AWGw2dcO55V8RIDkAz0RoTMuw3Ygt0ANf4dznaEBo9doxKbHraS7/c4f9N 36L7j9crzcXXuzCH2tQA5dEGY2jUQFQyjfa3h9il1htMhYgfN7TqxeZ/AD2ATyTo8+j0 REOQ==
X-Forwarded-Encrypted: i=1; AJvYcCVUW9K8FuH0zV6Co41uwyWBOmi9GZsexFnJciQU0Bib59180vi+lJKeY4d5I7lt7InCi1N7hKYoy0+lCluSzHBHOrYk6FztsHlm3xk=
X-Gm-Message-State: AOJu0Yzp+oZTxOb6++VD79hm7o9qIVkP9jFkVHLLOhQohVyu+O/9TICT kfg3PD7Gi+2/pWFhJpfwhoXKrU3A4+NYzm9+tZzwd4omZB/JEdRpXI3ZRA==
X-Google-Smtp-Source: AGHT+IHPuwmd4gfj8T4amcdI6ur4k/o50zNGPLJy12WwVC7Z1peIdJ5zVV599Snyobf0AyrejM7QDQ==
X-Received: by 2002:a05:6830:140d:b0:6e9:f2f0:fadd with SMTP id v13-20020a056830140d00b006e9f2f0faddmr2533846otp.1.1712917559691; Fri, 12 Apr 2024 03:25:59 -0700 (PDT)
Received: from smtpclient.apple (c-73-255-89-160.hsd1.tx.comcast.net. [73.255.89.160]) by smtp.gmail.com with ESMTPSA id b13-20020a9d754d000000b006ea12d5cb15sm633728otl.62.2024.04.12.03.25.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Apr 2024 03:25:59 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Jorge Amodio <jmamodio@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Fri, 12 Apr 2024 05:25:28 -0500
Message-Id: <141AE72F-7E78-47E6-9912-65A46AD11EF4@gmail.com>
References: <85584DCA-C858-4298-B0F4-555FC42138F1@gmail.com>
Cc: Carsten Bormann <cabo@tzi.org>, "Rieber, Richard R (US 347R)" <richard.r.rieber=40jpl.nasa.gov@dmarc.ietf.org>, DTN WG <dtn@ietf.org>, cbor@ietf.org
In-Reply-To: <85584DCA-C858-4298-B0F4-555FC42138F1@gmail.com>
To: John Dowdell <john.dowdell.ietf@gmail.com>
X-Mailer: iPad Mail (21E236)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/NGMpBSAktxnozVr0VrY3G9RAqA8>
Subject: Re: [Cbor] [dtn] 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: Fri, 12 Apr 2024 10:26:05 -0000

I believe that for the time being until an international standard not a government mandate is fully developed, implemented, tested and accepted we will have to stick with UTC.

Also, location based time systems should in the long term be defined on a planetary basis, not only for the Moon, which brings again the question of developing an international standard that goes beyond the cislunar space.

But still we will always need a common system of reference for the whole interplanetary network, and so far for now UTC is the most reasonable answer.

On a planetary basis such as the Moon, for those applications that require a local time system of reference we will have to figure how we convert from/to UTC, but at the *application* level, IMHO for comms and networking we should stick with UTC.

My .02

Regards
-Jorge

> On Apr 12, 2024, at 04:42, John Dowdell <john.dowdell.ietf@gmail.com> wrote:
> 
> Hi Carsten and Richard
> 
> As a comms engineer working on ESA Moonlight, I’m also interested in resolving this. Given timescales, I guess we’ll end up going with UTC even on the moon, but in the longer term there is a need for a standards-based resolution.
> 
> - John
> 
>> On 12 Apr 2024, at 06:58, Carsten Bormann <cabo@tzi.org> wrote:
>> 
>> Hi Richard,
>> 
>> I read your message with interest.
>> 
>> draft-ietf-cbor-time-tag [1], an approved specification that is currently in the RFC editor queue for publication as an RFC, defines a versatile representation of timestamps in CBOR.
>> While DTN BP does not directly use this extended time tag currently, I would imagine that any evolution of its time representations would coordinate to maintain interoperability with the extended time tag.
>> 
>> [1]: https://datatracker.ietf.org/doc/draft-ietf-cbor-time-tag/
>> 
>> The extended time tag defines a way to indicate the timescale in use [2].
>> This is based on a IANA registry [3] that is currently just listing UTC and TAI [4].
>> 
>> [2]: https://www.ietf.org/archive/id/draft-ietf-cbor-time-tag-12.html#section-3.4
>> [3]: https://www.ietf.org/archive/id/draft-ietf-cbor-time-tag-12.html#section-7.2
>> [4]: https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml#timescales
>> 
>> I would expect that LTC should be added to this registry, and that a short specification could provide information about how this is to be used and how this timescale interoperates with the existing ones.
>> 
>> Grüße, Carsten
>> 
>> 
>>>> On 12. Apr 2024, at 06:46, Rieber, Richard R (US 347R) <richard.r.rieber=40jpl.nasa.gov@dmarc.ietf.org> wrote:
>>> 
>>> Hello DTN leads,
>>> I am a DTN advocate at JPL and working as the Mission Operations Systems Engineer on the CADRE mission. This mission is slated to send 3 shoe-box sized rovers to the moon on Intuitive Machine’s IM-3 lander in Q1 2025. Needless to say, I’m paying attention to all things moon-related and DTN-related.
>>> There are two things I want to highlight:
>>>   • NASA’s SCaN office has released the LunaNet Interoperability specification, which mandates the use of DTN for communications in Feb. 2023, and
>>>   • On 4/2/2024, the White House has tasked NASA with developing a “Coordinated Lunar Time”, amongst other planetary time systems.
>>> BP’s DTN Time (see 4.2.6 of RFC-9171) is defined as milliseconds since 2000-001T00:00:00 UTC. How should this change if there is a lunar time system?
>>> I would imagine that Lunar spacecraft use LTC for their internal clocks. How do they interpret bundles sent from Earth that are stamped with UTC? Must they internally convert the current LTC to UTC to compare to that bundle’s DTN Time? Similarly, what time system is used in the DTN Time field for bundles created by a lunar spacecraft?
>>> Now imagine the Artemis Gateway that may act as a communication relay node. Some bundles would be from Earth and tagged with UTC. Some bundles would be from the moon and may be tagged in LTC. This gets quite confusing.
>>> Needless to say, I think the DTN community needs to have a conversation about if and how the protocol must be modified to support different time systems across the solar system. What’s the venue for having that conversation? How would one go about proposing a protocol modification?
>>> Thanks in advance,
>>> ~Rich
>>>  Richard Rieber
>>> NASA/JPL
>>> Robotics Systems Engineer
>>> 347R – Robotics Operations and V&V
>>> Richard.R.Rieber@jpl.nasa.gov
>>> +1-818-480-2861
>>> _______________________________________________
>>> dtn mailing list
>>> dtn@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dtn
>> 
>> 
>> _______________________________________________
>> dtn mailing list
>> dtn@ietf.org
>> https://www.ietf.org/mailman/listinfo/dtn
> 
> _______________________________________________
> dtn mailing list
> dtn@ietf.org
> https://www.ietf.org/mailman/listinfo/dtn