[dtn] DTN time and RFC8877

[Brian Sipos <[e-mail]>]

Scott,
Addressing to you since is directly a question on BP spec, but any BP implementor is also welcome to speak up.
A new recommendation for what to include in IETF specifications using timestamps is RFC8877 [1] and brings up a couple of points not addressed by current BPbis section on DTN Time [2].

I'm not suggesting any necessary changes, just questions about DTN Time as an intrinsic value (separate from the old SDNV or new CBOR encodings) relative to the aspects in RFC8877. I'm also not reopening the question of DTN epoch or leap seconds; those have been decided, and I'm looking to RFC8877 nomenclature for expressing those decisions.

  *   Epoch, resolution, and units: These are already well-defined.
  *   Leap seconds: There had been discussion on the mailing list about this and DTN Time does not consider leap seconds, though it does use a UTC epoch. This is not mentioned as explicitly as RFC8877 does for PTP, "This timestamp format is not affected by leap seconds."
  *   Size and wraparound: The encoded syntax has its properties, but it's not clear from [2] whether the DTN Time intrinsically does also. For RFC5050 the DTN Time used SDNV with an explicit restriction to 2^64-1 (seconds) for BPbis the time is a 'unit' so also limited to 2^64-1 (milliseconds). You caution implementors about values larger than 2^32-1.
Is there an intrinsic upper-limit or wraparound behavior to DTN Time?
Is it okay if an implementation stores DTN Time in way (e.g., signed 64-bit int) which does not have the full domain of CBOR uint?
  *   Synchronization: The BPbis doesn't get into the level of detail as Section 5 of RFC8877 about what is required of BP agents. The one notable part of BPbis is that it does allow for agents with bad clocks to represent that as a DTN Time value zero, which has the special interpretation of "unknown time". This is more of a suggestion in Section 4.1.7 and not really a requirement of Section 4.1.6, so is DTN Time of zero really a special sentinel value or a legitimate encoded time?

Thanks for any feedback,
Brian S.

[1] https://tools.ietf.org/html/rfc8877#section-3
[2] https://tools.ietf.org/html/draft-ietf-dtn-bpbis-29#section-4.1.6