Charlie Perkins <charles.perkins@xxxxxxxxxxxxx> writes: > I'm not sure about this because even in 6TiSCH networks, one could > imagine using NTP-based time representations. Besides that, we'd really > like to avoid restricting the use of the Deadline-6LoRHE to only 6TiSCH. I agree that one could imagine any number of schemes, and in the long run, broad use of Deadline-6LoRHE is desirable. But that doesn't change the fact that while the draft purports to define the meaning of three values of the TU field, for two of those values, the draft doesn't specify what zero-point is being used for the time scale, and so implementations using those values cannot ensure interoperation. Now if what you really mean is "NTP time scale in microseconds" and "NTP time scale in seconds", those *are* definitions. But that's not what the draft says. >> 2. I'm surprised that the OT value is represented as an absolute value >> from the time-base used for the particular Deadline-6LoRHE, rather >> than as an offset before the DT. The difference DT - OT will >> typically be much smaller than OT itself, so if O = 1 and OT is >> present, using a difference would usually shorten the header. This >> change clearly isn't necessary for correctness, but it seems like a >> significant efficiency gain, as after 1 year, a 10 msec ASN with have >> values nearing 2^32, but DT - OT may remain less than 2^8. > > We will rework the time representation and show a proposed new format > soon. I agree that, if both values are present, one should be a delta > from the other. The way you write that suggests that either or both of the times can be present. But the deadline time is not optional. So if the origination time is present, both times are present. Dale
