Re: [dtn] AD evaluation of draft-ietf-dtn-bpbis-13

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

> On Jul 5, 2019, at 10:06, Magnus Westerlund <[e-mail]> wrote:
>  
> 2.       Section 4.1.6:
>  
> I think the format and definition of this field are insufficient. It is lacking a reference or a normative description of what "Unix Epoch Time" in an unsigned int format actually is. Is the intention here to simply measure the number of seconds since the start of year 2000? Which Unix epoch time is not due to leap seconds. And I become uncertain as UTC time scale is something else than Unix Epoch time at least when it comes to leap seconds handling. Due to that Unix Time have discontinuities in the time scale at leap seconds I would recommend strongly against using it. Select UTC or TAI depending on where you want the leap second handling pain to exist. 
>  
> Also, you specified only CBOR unsinged integer which is a representation that can use 64-bit and thus not have the issues with 32-bit signed integer seconds epochs that regular unix time has, but that should probably be made explicit that it is expected to handle that. Even if the first wrap of this unsigned 32-bit format will not occur until 2136. 
>  
> And please provide necessary normative references, not informative ones. 

Nota Bene:  I understand that DTN is not mandating the use of any particular time synchronisation protocol by a particular DTN implementation.  I agree that such is a system time implementation decision is outside the DTN protocol scope.

That said, in the context of widely deployed IETF standards for time synchronisation, I wonder whether the right answer really might be to specify that this DTN protocol field contains “Time as defined by the IETF Network Time Protocol (NTP)”.  NTP is derived from UTC, but its epoch is not “seconds since start of year 2000”.  Note also that NTP ought not crash in 2036 (which is a common misconception).  Further, while Unix systems often use NTP, NTP time is not necessarily precisely the same as "Unix time".

Quoting from Dave Mills (who invented NTP):

"However, the NTP protocol will synchronise correctly, regardless of era, as long as the system clock is set initially within 68 years of the correct time.”

URL for above quote:  "https://www.eecis.udel.edu/~mills/ntp/html/warp.html"

For more about NTP time eras, please see the article by Dave Mills which is online here:
      "https://www.eecis.udel.edu/~mills/y2k.html”.

The main alternative standards-based  implementation/deployment alternative to NTP might be to use time as defined by Precision Time Protocol (PTP), which is derived from TAI.  

A 3rd possibility is to pick something consistent with CCSDS’ Proximity-1 protocol.  Mills discusses Proximity-1 here:
"https://www.eecis.udel.edu/~mills/proximity.html"

In the context of Delay-Tolerant Networking, the clock precision of PTP likely is significant overkill, while the lower precision of NTP might be more reasonable.  Further, in the context of Delay-Tolerant Networking, consistent definition of time matters but the presence of leap seconds does not create issues (after all, DTN is supposed to be delay-tolerant).

Maybe just go with NTP time and normatively reference the NTP RFC, possibly also with informational references to some of Dave Mills documents ?

What do others think ?

Yours,

Ran