[core] Genart last call review of draft-ietf-core-senml-data-ct-04

Christer Holmberg via Datatracker <noreply@ietf.org> Mon, 06 September 2021 10:18 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A30AF3A2A05; Mon, 6 Sep 2021 03:18:23 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Christer Holmberg via Datatracker <noreply@ietf.org>
To: <gen-art@ietf.org>
Cc: core@ietf.org, draft-ietf-core-senml-data-ct.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.36.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <163092350360.5169.1299765677300317336@ietfa.amsl.com>
Reply-To: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Mon, 06 Sep 2021 03:18:23 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/tN373rgA3xR4ZR0SeXrNz4ERCXY>
Subject: [core] Genart last call review of draft-ietf-core-senml-data-ct-04
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
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, 06 Sep 2021 10:18:24 -0000

Reviewer: Christer Holmberg
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-core-senml-data-ct-04
Reviewer: Christer Holmberg
Review Date: 2021-09-06
IETF LC End Date: 2021-09-06
IESG Telechat date: Not scheduled for a telechat

Summary: I have reviewed the document. I have one technical comment, but the
rest is mostly editorial. Related to that, I do think the document could use
some editorial clean-up, e.g., when it comes to consistent terminology. I think
it is also good not to assume that the reader knows CoAP, and to make sure the
appropriate references/explanations are present when CoAP is referred to.

Major issues: N/A

Minor issues:


What happens if the receiver does not support the "ct" value? Is it a
server-error? If so, what response code is used? I think that should be

Nits/editorial comments:


The text should use consistent terminology. See below for a few examples:

The Abstract says:

   "The Sensor Measurement Lists (SenML) media type supports multiple
   types of values, from numbers to text strings and arbitrary binary
   data values.  In order to simplify processing of the data values,
   this document proposes to specify a new SenML field for indicating
   the Content-Format of the data."

First the text talks about types of values, and then suddenly the
Content-Format of the data.

Content-Format is the name of the new field - that is not what you are
indicating. You are using the new field to indicate something.

Also, "Content-Format" is also used by CoAP, so please check that it is clear
what is referred to whenever mentioned.

The text in Section 1 says:

   "To facilitate automatic interpretation it is useful to be able to
   indicate an Internet media type and content-coding right in the SenML

...and, the test in Section 7 says:

"The indication of a media type in the data does not exempt a consuming
application from properly checking its inputs."

Now the text suddenly talks about "an Internet media type and content-coding",
when it earlier (in the Abstract) talked about value of type.


The text says:

"The CoAP Content-Format (Section 12.3 of [RFC7252]) provides just this

I think it would be good with a little introduction on how CoAP is related to
all this.

Also "provides just this information" probably needs some re-wording.


Section 6 contains the ABNF for the new fields.

Is there a reason you don't define them in the same way as the basic field is
defined in RFC 8428 (there is no ABNF)?


The text in Section 7 says:

"The indication of a media type in the data does not exempt a consuming
application from properly checking its inputs."

I assume that by "its inputs" you refer to "received SenML data".

Shouldn't properly checking inputs be a generic CoAP security consideration?