Re: [dtn] DTN time and RFC8877

["R. Atkinson" <[e-mail]>]

> On Dec 4, 2020, at 08:25, Brian Sipos <[e-mail]> wrote:
> 
> 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."

Brian,

To avoid an unexpected interoperability issue if/when a Leap Second occurs, I think DTN time should specify how leap seconds are handled (or specify that they are ignored).  

I don’t really care whether they are ignored or handled, but I think it ought to be clearly specified what happens if/when a leap second occurs (or explicitly what doesn’t happen in the case of “ignored” leap seconds).

This is merely a matter of specification completeness.

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

Again, I’m open to any resolution the WG or authors choose, but I’d like it to be clearly specified — whichever resolution folks prefer needs to be clearly documented so all
implementations will behave the same way.

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

Again, please clearly specify one or the other behaviour, but I don’t care which choice is made.

Thanks,

Ran