IETF Logo Mail Archive

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

Alexey Melnikov <aamelnikov@fastmail.fm> Sat, 12 May 2018 20:50 UTC

Return-Path: <aamelnikov@fastmail.fm>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49CF0127369; Sat, 12 May 2018 13:50:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.197
X-Spam-Level:
X-Spam-Status: No, score=-1.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=svI3/820; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HhTSdE5y
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SItg6ckaxjOf; Sat, 12 May 2018 13:50:33 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EADA1270AB; Sat, 12 May 2018 13:50:33 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 0FEB125BF0; Sat, 12 May 2018 16:50:32 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Sat, 12 May 2018 16:50:32 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=jlTgiKHJ87/UmZUNtgNb8isqBvxL4 4zyfB0N3MpmNdU=; b=svI3/820bvc0rpkZhyZb0jifjE5J8ECs5kJfnY1Ngjsf/ AGVO5/AR7rltAjpxGwq6fotlam0/dUOEDp+HzXg4P8Z0zntg+Zv2mAoZXFq/MbOZ 3B+gza+CEKZl2PdGWvQanzFvCYw6l3WfqrxfCjWJ77h//gpcHRTlK+CvQjnXGoIo 6wCt4vbLFKJFb0txY6NUa8MSsP8H1yZZZoO9jIL0GRqDSjPS4FVig0ldODT4jJPg gPIMFCjaW+xUENPG8uGPInMseYa3jZXm0t/i0hdTbtTw5AW7pfDICtiL5VZZ0Ag7 DgmscMNlTqI+8lKXbROaJuutKDw9ptPS8Pi5JWSHA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=jlTgiK HJ87/UmZUNtgNb8isqBvxL44zyfB0N3MpmNdU=; b=HhTSdE5yB0KI2+zPT59C9W Wf7VsUzbX/0xid1skmQijUoKc9n4Jvcc77PvtKDmjor49CfozHTpmw9TOyTfgsct DNDc4xk4QkFWupwRWFKKF6BpDOhjF/G4cv8X5Jno+QbpYc/kb/VjtLYgXv1PuB5I FzM19EPCjCGYxqdOYCD3zTuUN5RG6YGufHg2As5jFNe+JtARsyhlsR2FVA9AalLg bJEvNd5w+ph6S8I8PSvozDTkNHX2+eNZS9HaxoSMpkMcMh+5Su5NzZeqSuoJw3xf pwUix6CHsMEsF0YAp1YIB+H5au4j0NJlzYPLlPKDfXMhPE4nCk0o/nZtwvutP5VQ ==
X-ME-Sender: <xms:mFP3WiiJV49hY6NfBr5fax8tt_nYtRb19_7XGf6ioMTgcmxYHQ27sw>
Received: from [192.168.1.77] (ppp109-252-166-127.pppoe.spdop.ru [109.252.166.127]) by mail.messagingengine.com (Postfix) with ESMTPA id 80A811025E; Sat, 12 May 2018 16:50:31 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-84BB8ACE-BE57-4CCB-B40A-EADDC7A739D5"
Mime-Version: 1.0 (1.0)
From: Alexey Melnikov <aamelnikov@fastmail.fm>
X-Mailer: iPad Mail (14F89)
In-Reply-To: <0C881DE7-7991-4E3C-A8C8-B77AEC2F55CC@ericsson.com>
Date: Sun, 13 May 2018 00:02:29 +0300
Cc: Benjamin Kaduk <kaduk@mit.edu>, core <core@ietf.org>, The IESG <iesg@ietf.org>, "core-chairs@ietf.org" <core-chairs@ietf.org>, "draft-ietf-core-senml@ietf.org" <draft-ietf-core-senml@ietf.org>, Carsten Bormann <cabo@tzi.org>, Cullen Jennings <fluffy@iii.ca>
Content-Transfer-Encoding: 7bit
Message-Id: <3C64FC4D-B771-4B43-BC19-DE7BD1132173@fastmail.fm>
References: <152410519508.28821.948642754454286088.idtracker@ietfa.amsl.com> <84E57656-B191-4DB4-B7EC-97059D5B19DE@ericsson.com> <20180508000154.GY84491@kduck.kaduk.org> <44DB4CCE-62E7-43FF-9E0B-9AF27E14EE87@tzi.org> <0C881DE7-7991-4E3C-A8C8-B77AEC2F55CC@ericsson.com>
To: Ari Keränen <ari.keranen@ericsson.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/0WjhS7PuWKg1ktmQi5CAFqem8vo>
Subject: Re: [core] Benjamin Kaduk's Discuss on draft-ietf-core-senml-14: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 12 May 2018 20:50:35 -0000

Hi Ari,

> On 11 May 2018, at 20:05, Ari Keränen <ari.keranen@ericsson.com> 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.

Best Regards,
Alexey

v2.23.0 | Report a Bug | By Email