[core] Benjamin Kaduk's Discuss on draft-ietf-core-senml-data-ct-05: (with DISCUSS and COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Wed, 22 September 2021 17:40 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 ACBD13A2A9B; Wed, 22 Sep 2021 10:40:05 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-core-senml-data-ct@ietf.org, core-chairs@ietf.org, core@ietf.org, Jaime Jimenez <jaime@iki.fi>, jaime@iki.fi
X-Test-IDTracker: no
X-IETF-IDTracker: 7.38.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <163233240502.20840.5498014177264082102@ietfa.amsl.com>
Date: Wed, 22 Sep 2021 10:40:05 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/PZEo67hDLYpO6TXPJpeg29CcSrE>
Subject: [core] Benjamin Kaduk's Discuss on draft-ietf-core-senml-data-ct-05: (with DISCUSS and COMMENT)
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: Wed, 22 Sep 2021 17:40:06 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-core-senml-data-ct-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-senml-data-ct/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have a couple points for discussion, essentially relating to how much we're diverging from HTTP and to what extent the specifics of the divergence should be specifically mentioned in the document. (1) I'd like to dig a little more into the analogy with HTTP and whether we are artificially limiting ourselves: currently we only allow 0 or 1 content-codings to be specified, but per https://www.ietf.org/archive/id/draft-ietf-httpbis-semantics-19.html#name-content-encoding the HTTP ecosystem permits multiple codings to be applied in turn to the same representation. While the sensor data values are likely to be relatively small and applying multiple content-codings is not likely to be useful in such a scenario, this seems like something where we should only consciously diverge from HTTP, rather than inadvertently doing so. (2) Let's also discuss whether we want to reuse ABNF rule names from HTTP while having the rule content diverge, without specific enumeration of the divergence. So far I found instances where this document does not allow HTAB or obs-text in places that draft-ietf-httpbis-semantics does, which may well be the right way to spell the rule, but seems to merit a little discussion. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Do we want to comment anywhere about the situation where an implementation receives a message using an IANA-registered numeric content-format that is "too new" for that implementation to know about? It also feels a little weird that we have to end up using the text-string encoding of a decimal number for the Content-Format, even for the CBOR representation of SenML structures, but I guess that's what RFC 8428 intended and not worth trying to change. Abstract I'm somewhat sympathetic to the gen-art reviewer's contention that the new field is not indicating the "Content-Format" of the binary data values (since Content-Format is a defined term in CoAP and SenML is claimed to not be limited to CoAP usage). Perhaps we could switch around the order of description, i.e., "for indicating the Internet media type (including parameters) of these binary data values (i.e., the CoAP Content-Format that would apply when CoAp is used), as well as any content-coding that is applied"? Section 3 * a CoAP Content-Format identifier in decimal form with no leading zeros (except for the value "0" itself). This value represents an unsigned integer in the range of 0-65535, similar to the CoRE Link Format [RFC6690] "ct" attribute). Should we also reference https://datatracker.ietf.org/doc/html/rfc7252#section-7.2.1 which is where the "ct" link attribute is actually defined? I spent a bit of time looking for it in 6690 itself only to discover that it was removed in draft-ietf-core-link-format-07 with remark "Moved [...] to the base CoAP specification". The CoAP Content-Format number provides a simple and efficient way to indicate the type of the data. [...] If we're limited to string representation, is it really "efficient" in a CBOR context? Section 6 ; Cleaned up from RFC 7231: (per the DISCUSS,) I'm a bit anti-enthused about saying "cleaned up" without saying what changed (i.e., whether it's just refactoring, or actual changes to the rule like requiring specifically *SP instead of OWS that allows HTAB as well). Section 7 These security considerations are well-thought-out and nicely written. Thank you! I think there are some (rare) situations where individual media-type (specifications) have their own security considerations, but I'm not really convinced that we need to mention that/incorporate them by reference, here. NITS Section 1 The receiver is expected to know how to interpret the data in the "vd" field based on the context, e.g., name of the data source and out-of-band knowledge of the application. However, this context may not always be easily available to entities processing the SenML pack. I'd consider adding ", especially if the pack is propagated to multiple entities". Section 2 Content-Coding: A name registered in the HTTP Content Coding registry [IANA.http-parameters] as specified by Section 8.5 of [RFC7230], indicating an encoding transformation with semantics further specified in Section 3.1.2.1 of [RFC7231]. [...] (I expect that the RFC Editor will be able to replace the references to point to draft-ietf-httpb-semantics if it has been published before this document.) Section 4 up to the end of the pack otherwise. Resolution (Section 4.6 of [RFC8428]) of this base field is performed by adding its value with the label "ct" to all Records in this range that carry a "vd" field but do not already contain a Content-Format ("ct") field. The conjugation "resolution" does not actually appear in RFC 8428 itself, just discussion of "resolved records" and "to resolve the records". It might be helpful to tweak things so that we don't rely on the reader knowing the irregular conjugation (but I don't have any good ideas off the top of my head)...
- [core] Benjamin Kaduk's Discuss on draft-ietf-cor… Benjamin Kaduk via Datatracker
- Re: [core] Benjamin Kaduk's Discuss on draft-ietf… Carsten Bormann
- Re: [core] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [core] Benjamin Kaduk's Discuss on draft-ietf… Carsten Bormann