Re: [core] CoRE @ IETF106: Summary and Minutes

Jaime Jiménez <jaime@iki.fi> Mon, 27 January 2020 18:06 UTC

Return-Path: <jaime@iki.fi>
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 095433A08ED for <core@ietfa.amsl.com>; Mon, 27 Jan 2020 10:06:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.14
X-Spam-Level:
X-Spam-Status: No, score=-1.14 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com
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 QdKPt8htquCJ for <core@ietfa.amsl.com>; Mon, 27 Jan 2020 10:06:29 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6862F3A08DD for <core@ietf.org>; Mon, 27 Jan 2020 10:06:15 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 549F322185; Mon, 27 Jan 2020 12:03:23 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Mon, 27 Jan 2020 12:03:23 -0500
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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=c2cuNH7pw57aB80uvqESJzsd00+0djhBcbXjr9UVi gw=; b=OuYX+J9141jDf02S1x4FOZE8eYSm+2CQE7RCw33jM//9Ysf2tPXCDsUrq 4lZrv4HU6G5rKcte3ThMONs/2HOD1f6V5fJkmV90H366pEvwlhUKZ33mEvlR5JZ0 PLLJk/1OQsB2fkTMQXMD93Ti3WP/OyPAj8Vos7FTu3/uWDEH9PD8u1bZarirCFuZ c9Iu0UD5IJJBf+krU2rW4UUkY70HqIIHj+pxzSk0RwhF8DULC83Zrzm6qTCrxhPq I8hPUqcBNI8NM4PP4D8pVDa3aFZcrZkHaW3I0RJyE00N1s/ypXRzEgXCaM2hlJKb UgYu3VgiEDdvycT8VBIZJ9upSOTEg==
X-ME-Sender: <xms:2hcvXgMNoThby_M7T0CQ-cRAT38345hkTtWlsTcRhJ9HyDSIUtz8NQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrfedvgdelgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtugfgjgesthekre dttddtjeenucfhrhhomheplfgrihhmvgculfhimhornhgviicuoehjrghimhgvsehikhhi rdhfiheqnecuffhomhgrihhnpeifihhkihhpvgguihgrrdhorhhgpdhivghtfhdrohhrgh enucfkphepgeejrdduhedtrddvvdegrddvheefnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepjhgrihhmvgesihhkihdrfhhi
X-ME-Proxy: <xmx:2hcvXluh6rovu2ZoxJMTtsI2zZrOUH3Bby1p1qgWSenHRDLKXcyZXw> <xmx:2hcvXr1sQmOedGJedxf7KYihfmqFE2ZAC-1z4QT938fGZMYEDCg8Wg> <xmx:2hcvXkwPGOpwccfNks1c68pFfRru0i6WL3LM-yy2lpXAer38dLscnQ> <xmx:2xcvXpHesm4q15aStY8uAFWoDp5Fz033rVtX5nPFhl5idg9GQlcwzw>
Received: from EMB-918HFH01 (unknown [47.150.224.253]) by mail.messagingengine.com (Postfix) with ESMTPA id B0636328005A; Mon, 27 Jan 2020 12:03:21 -0500 (EST)
Date: Mon, 27 Jan 2020 09:03:20 -0800
From: =?utf-8?Q?Jaime=20Jim=C3=A9nez?= <jaime@iki.fi>
To: core@ietf.org
Message-ID: <20200127170320.y5gu5hh4aqoxtzvm@EMB-918HFH01>
References: <E7EC797D-6219-48F9-861A-18BE43D85B72@tzi.org> <ED7737D2-34C4-4D1C-88B8-74B61B713943@iii.ca> <20200120161000.jxfsyeiffrvih62x@EMB-918HFH01> <5e82c3f0-aa71-460c-a646-9a86427d7f40@www.fastmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: base64
In-Reply-To: <5e82c3f0-aa71-460c-a646-9a86427d7f40@www.fastmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/k4upAscFfBjiV8wJVUs2-sLK-j4>
Subject: Re: [core] CoRE @ IETF106: Summary and Minutes
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 27 Jan 2020 18:06:34 -0000

Dear all,

Coming back to this issue, I have not seen a reply on the list
regarding this. I would like to have it concluded so that we can move
the document forward. I agree that the text should reflect that the
secondary registry is not be the preferable option if units in the
primary registry can be used. Maybe the authors could work out a
modified draft that better explains that, after which we can do the
document write up and ship it.

Ciao!
-- Jaime


On Tue, Jan 21, 2020 at 11:35:47AM +0200, Jaime Jimenez wrote:
> Sending it to the core thread. 
> 
> -- 
> Jaime Jiménez
> 
> On Mon, Jan 20, 2020, at 6:10 PM, Jaime Jimenez wrote:
> > Hi,
> > 
> > comments below. 
> > 
> > On Fri, Dec 13, 2019 at 11:27:34AM -0700, Cullen Jennings wrote:
> > > 
> > > 
> > > > On Dec 9, 2019, at 3:42 PM, Carsten Bormann <cabo@tzi.org> wrote:
> > > > 
> > > > 
> > > >  Concerns had been raised about opening up the second registry for
> > > >  derived units, making it harder for a SenML application to find out
> > > >  whether a unit encountered was actually of interest to it.
> > > >  Discussion in the first session resulted in the tentative proposal
> > > >  to mark secondary units with an asterisk (as in "*km/h", as opposed
> > > >  to unmarked "m/s").  Further discussion in the second session made
> > > >  clear that while this makes the use of secondary units stand out, it
> > > >  does not really improve the situation of SenML applications that
> > > >  want to quickly discard measurements for units they do not care
> > > >  about, unless they track the contents of the two registries, which
> > > >  would make the asterisks redundant.
> > > 
> > > I disagree that the asterisk does not improve the situation
> > > 
> > > >  There also was some feedback
> > > >  the asterisks would make the adoption of the SenML units registry by
> > > >  other SDOs more difficult.  The in-room consensus not to go for the
> > > >  asterisks, but to include more explanatory text about implementation
> > > >  strategies, needs to confirmed on the mailing list.  
> > > 
> > > I strongly object to this.  RFC 8428 has a strong assertion that the units 
> > > 
> > >         For a given type of measurement, there will only be one unit
> > >         type defined.  So for length, meters are defined and other
> > >         lengths such as mile, foot, light year are not allowed.  For
> > >         most cases, the SI unit is preferred.
> > > There is running code that is based on that assumption that has been in production for many years. You can’t break that assumption without some backwards compatibility consideration that help theses deployed applications mitigate the breakage this causes.
> > 
> > I believe that the assumption of having only one unit per measurement
> > was broken already with core-senml-more-units as it creates the
> > secondary registry. So the asterisk does not fix that.  
> > 
> > > The ideas that millions of edge aggregation devices, many on far side of slow links, would query the IANA web server to track the units and decide how to process data seems like a very bad design. I would expect the IESG to reject anything that lead to cases like https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse <https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse>
> > > 
> > 
> > I also do not see how the asterisk would make parsing easier. If
> > existing edge devices are hardcoded to use a subset of all units -just
> > the primary senml registry- then they would filter messages containing
> > any unit they do not understand anyways. 
> > 
> > Also the asterisk does not tell an application processing a specific
> > measurement (e.g., temperature in celsius) additional information about
> > the unit (e.g., I am temperature in fahrenheit, this is important)
> > indicating that this new unit  is something it should process, it only indicates
> > that it is part of the secondary registry.
> > 
> > Regarding the querying of the senml registry, I think that would have to
> > happen anyways, as new units will be registered over time, even if not
> > very often. 
> > 
> > I think the real issue here is whether to signal "this unit belongs to a
> > secondary registry, not the main one" or not. Flagging a unit with "*" or
> > having a different field like "u2" can confuse developers unnecessarily, 
> > as they do not need to know about historical standard decisions. It's
> > more of a penalty to those using it :D 
> > 
> > And if you want to convey that the secondary registry is not the
> > preferred one, then I think that is something that should be on the
> > draft itself, right? With very strong wording and so on, but not on the
> > wire in a senml record. 
> > 
> > > 
> > 
> > > _______________________________________________
> > > core mailing list
> > > core@ietf.org
> > > https://www.ietf.org/mailman/listinfo/core
> > 
> >
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core