Concise Binary Object Representation (CBOR) Tags for Time, Duration, and Period
draft-ietf-cbor-time-tag-12

# Internet AD comments for draft-ietf-cbor-time-tag-11
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S4

* With this definition of Duration, it seems like implementers might need
  to support a duration with an accompanying critical Time Zone Hint, is
  that correct?


  Seems ... odd, but I understand the desire for de-duplication.

Thanks to Thomas Fossati for the ARTART review.

And thanks for the IANA Considerations fix.

NITS:

TAI is never expanded - expand on first use? At least for me this was a new term, unlike UTC. But perhaps it is obvious for implementers in this space.

        The present document

Use "This document"

        therefore is rendered by the surrogate notation seen here in the plain-text rendition.

"here" is a bit weird when I'm reading the HTML version. Can't you just write 2^xx as an example ?


        The security considerations of RFC 8949 apply

A link is missing here.

** Section 2.  
   For example, map keys could be registered for direct representations
   of natural platform time formats.

What are “natural platform time formats”?

** Section 3.
   The map must contain exactly one unsigned integer key that specifies
   the "base time", and may also contain one or more negative integer or
   text-string keys, which may encode supplementary information.

Should a normative MUST and MAY be used here?

** Section 8.  
   Time, of course, has significant security considerations; these
   include the exploitation of ambiguities where time is security
   relevant (e.g., for freshness or in a validity span) or the
   disclosure of characteristics of the emitting system (e.g., time
   zone, or clock resolution and wall clock offset).

Recommend citing the Security Considerations of draft-ietf-sedate-datetime-extended.  The text there covers a number of the topics mentioned above.

Thanks for working on this specification. No objection from TSV point of views but supporting Murray's discuss on clarification of IANA registry creation.

# É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" ?

## 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 ?

## Section 3.3

Should there be a reference for Haskell time ?

## Section 3.4

Please add an informative reference to NTP.

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.

Moving to no-obj based on reply for Carsten.