Re: [Cbor] Éric Vyncke's No Objection on draft-ietf-cbor-time-tag-11: (with COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

Hello Carsten,

Thanks for your reply.

As you know, my comments were just suggestions. After looking into the PR:
- why not expanding TAI (even if I guess the expansion is in French) rather than referencing to another document ?
- I still think that a reference to Haskel time would be welcome (99% of the readers know about java and Unix so no need to add a reference for those)

But more important, thanks for the added information about “GPS time” (and ChatGPT sounds better than me on this topic). But, it raises a major concern (at least for me) about lack of diversity/inclusiveness as *only* the GPS from USA is included in this document and not the other “time epoch” from other organizations. Hence, I will change my ballot into an ABSTAIN for this USA-only focus for an IETF standard. Sorry.

Regards

-éric






From: Carsten Bormann <[e-mail]>
Date: Wednesday, 25 October 2023 at 11:03
To: Eric Vyncke (evyncke) <[e-mail]>
Cc: The IESG <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [Cbor] Éric Vyncke's No Objection on draft-ietf-cbor-time-tag-11: (with COMMENT)
Hi Éric,

thank you for this review.
The changes I propose based on your comments are in:
https://github.com/cbor-wg/time-tag/pull/23

Please see details below.

Grüße, Carsten



> On 2023-10-24, at 13:42, Éric Vyncke via Datatracker <[e-mail]> wrote:
>
> Éric Vyncke has entered the following ballot position for
> draft-ietf-cbor-time-tag-11: No Objection
> […]
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-cbor-time-tag/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> # Éric Vyncke, INT AD, comments for draft-ietf-cbor-time-tag-11
>
> Thank you for the work put into this document. I am trusting the responsible AD
> for the CDDL specifications, please also note that I am not a time specialist.
>
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education).
>
> Special thanks to Barry Leiba for the shepherd's minimalist write-up including
> the WG consensus and the justification of the intended status.
>
> Other thanks to Qin Wu, the IoT directorate reviewer (at my request), please
> consider this int-dir review:
> https://datatracker.ietf.org/doc/review-ietf-cbor-time-tag-10-iotdir-telechat-wu-2023-10-17/
> (and I have read the follow-up email discussion)
>
> I hope that this review helps to improve the document,
>
> Regards,
>
> -éric
>
> # COMMENTS
>
> ## Section 2
>
> What is "TAI" ?

International Atomic Time (note how this is almost, but not entirely, not an acronym, just like UTC).

Paul Wouters noticed this gap, too, so in
https://github.com/cbor-wg/time-tag/pull/22
we put a pointer to the recently approved draft-ietf-sedate-datetime-extended into the terminology section, too (and not just for key ±10/±11).

> ## Section 3
>
> As non native English speaker, I find this clause unclear: `these keys are
> "elective", as the extended time is still usable if an implementation elects
> not to implement them` I.e., how can it be usable if the implementation does
> not support it ? Is it because the added information is not critical ?

Proposed clarification:

-these keys are "elective", as the extended time is still
-usable if an implementation elects not to implement them.
+these keys are "elective", as the extended time as a whole is still
+usable without the information they carry if an implementation elects not to implement them.

Now
35d3be9

> ## Section 3.3
>
> Should there be a reference for Haskell time ?

We could add something like:
https://hackage.haskell.org/package/time-1.12.2/docs/Data-Time-LocalTime.html
But then we’d need to add references to Java time, and old/new UNIX time as well.

References of this type are usually rather ephemeral, so I’d think that googling wins.

> ## Section 3.4
>
> Please add an informative reference to NTP.

Now
0342ffe

>
> More important, "GPS" is a specific system out of the USA. Please use "GNSS" as
> it also covers non-USA satellite systems such as Galileo.

Of course, generally we don’t want to single out GPS among the GNSSes, but here specifically the widely used GPS timescale is meant (the one that starts at 1980-01-06 00:00:19 UTC, an epoch which is not shared by other GNSS (*)).



(*) ChatGPT says it well (I haven’t verified the details, though):

>> [The GPS] epoch is specific to the Global Positioning System (GPS), which is a specific GNSS, and it serves as the starting point for GPS time.
>>
>> Other GNSS systems, such as GLONASS, Galileo, and BeiDou, have their own epochs and time references, which are not identical to the GPS epoch. The GPS epoch is used as the reference time for GPS satellites and receivers, and it is based on the GPS system's own timekeeping.
>>
>> The GLONASS epoch started on January 1, 1996, at 00:00:00 UTC.
>> The BeiDou epoch started on January 4, 2006, at 00:00:00 UTC.
>> The Galileo epoch started on January 22, 2006, at 00:00:00 UTC.

and it gets worse…

>> GPS time is based on TAI (International Atomic Time) and does not incorporate leap seconds. While the GPS system is closely related to UTC, it does not directly include leap seconds. Leap seconds are typically added to UTC to keep it within 0.9 seconds of TAI. GPS time, on the other hand, does not have leap seconds, making it a continuous time scale based on TAI.
>>
>> GLONASS, on the other hand, has historically included leap seconds in its timekeeping to stay in sync with UTC. Again, I recommend checking the latest documentation for each GNSS system to verify their current practices regarding leap seconds, as policies may change over time.