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

["Sipos, Brian J." <[e-mail]>]

Richard,
While there are mechanisms to use alternative time scales in CBOR in ways that would be backward (but not forward) compatible, I agree with Jorge's rationale that "a network" and a networking layer should use a consistent time scale. This is similar to how early internet protocols (e.g. SNMP and pre-1.0 HTTP) allowed use of alternative time zones but modern versions disallow all but UTC-representing timestamps (e.g.  HTTP's Date format [1]) because it adds unnecessary burden onto the lower-level processing that should be a higher-level concern.

[1] https://datatracker.ietf.org/doc/html/rfc9110#section-5.6.7

> -----Original Message-----
> From: dtn <[e-mail]> On Behalf Of Jorge Amodio
> Sent: Friday, April 12, 2024 6:25 AM
> To: John Dowdell <[e-mail]>
> Cc: Carsten Bormann <[e-mail]>; Rieber, Richard R (US 347R)
> <richard.r.rieber=[e-mail]>; DTN WG <[e-mail]>;
> [e-mail]
> Subject: [EXT] Re: [dtn] LTC timescale (Re: Question regarding RFC 9171 - How
> to incorporate "Coordinated Lunar Time")
> 
> APL external email warning: Verify sender [e-mail] before
> clicking links or attachments
> 
> 
> 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 <[e-mail]>
> 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 <[e-mail]> 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=[e-mail]> 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
> >>> [e-mail]
> >>> [phone]
> >>> _______________________________________________
> >>> dtn mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/dtn
> >>
> >>
> >> _______________________________________________
> >> dtn mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/dtn
> >
> > _______________________________________________
> > dtn mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dtn
> 
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn