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

[Benjamin Kaduk <[e-mail]>]

Hi Carsten,

Thanks for the updates; the 2**28 threshold does seem like a big
improvement (and the natural semantics of "add base time to relative
time and then compare against the threshold" seems to make perfect
sense in that context).

I have changed my position to Abstain, since the non-hierachical and
especially (potentially) interleaving of base values is still not
something I support, but I recognize that there is consensus to move
forward with it.

If you do have chance to make additional updates, it might still be
worth adding an explicit note that the streaming format only makes
sense in the presence of a reliable, in-order transport.  Since this
requirement really ought to be obvious to anyone who understands
what is going on, I will not attempt to make this a blocking
comment, though.

Adding Ben to the To: field since he also has an outstanding DISCUSS
position in the datatracker.

-Benjamin

On Fri, May 18, 2018 at 01:39:52PM +0200, Carsten Bormann wrote:
> 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
>