Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT)

[Carsten Bormann <[e-mail]>]

Hi Benjamin,

after WG input about this late change (all positive) has petered out, https://tools.ietf.org/html/draft-ietf-core-senml-16 is now out with the boundary between “now”-relative and absolute moved from 0 (1970) to 2**28 (1978).  Thank you for making us think this through once more; the result is so much better.

The authors believe that -16 should be addressing all DISCUSSes and COMMENTs.  As we are looking at an OMA deadline (an SDO depending on this) that could be picking up the new version, we could make good use of swift approval.

Grüße, Carsten


> On May 13, 2018, at 20:06, Ari Keränen <[e-mail]> wrote:
> 
> 
> 
>> On 13 May 2018, at 0.02, Alexey Melnikov <[e-mail]> wrote:
>> 
>> Hi Ari,
>> 
>> On 11 May 2018, at 20:05, Ari Keränen <[e-mail]> wrote:
>> 
>>> Hi all,
>>> 
>>> While addressing the IESG review comments regarding the use of time in SenML we came up with a simple way to enable SenML Records to express also relative times in the future that would have minimal impact to any existing use of SenML. We could use the following definition:
>>> 
>>>  Values greater than or equal to 2**28 represent an absolute time relative to the Unix epoch. Values less than 2**28 represent time relative to the current time.
>>> 
>>> That is, instead of only values less than zero, also values less than 2**28 (268,435,456) would be used to express relative time. Negative values and zero are still times in past and "now" respectively, as before. Time values from zero to 2**28 would be relative times in the future.
>>> 
>>> The only change this causes in the current use of SenML is that the smallest absolute time expressible in SenML becomes 1978-07-04 21:24:16 UTC instead of 1970-01-01 00:00 UTC. The absolute times after 1978 are still exactly the same ("Seconds after Unix epoch"). We are not aware of any deployments with SenML data between 1970 and 1978 that would be impacted negatively by this. 
>>> 
>>> For details, see:
>>> https://github.com/core-wg/senml-spec/pull/129/files
>>> 
>>> Would anyone have concerns about including this change in SenML before publication?
>>> 
>>> Since we are already very late in the process and we need to get SenML published as RFC very soon, we would also need to agree on this very soon.
>> 
>> No objections from me personally, but please double check with the WG.
> 
> Great!
> 
> I saw that Christian, Michael, and Klaus from the WG already +1'd (thanks guys!). If there are no concerns raised, we could submit a new version with this change included, e.g., at the end of the work week.
> 
> 
> Cheers,
> Ari