Subject: [core] Benjamin Kaduk's Discuss on draft-ietf-core-senml-data-ct-05: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 22 Sep 2021 10:40:05 -0700

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)...