[core] AD review of draft-ietf-core-senml-data-ct-04

[Francesca Palombini <[e-mail]>]

Thank you for the work on this document. Please take care of these minor comments at the same time as the Last Call comments.

Francesca

1. -----

FP: First of all, I wanted to confirm with the WG that the status "proposed standard" is the appropriate one here. Just making sure this was considered by the working group and the authors, as I note that the standard track is not needed for the IANA registrations, which require only expert review.

2. -----

   used to send various kinds of data.  In the example given in
   Figure 1, a temperature value, an indication whether a lock is open,
   and a data value (with SenML field "vd") read from an NFC reader is
   sent in a single SenML pack.


FP: Might be worth stating in the sentence above that the example uses JSON and base64 encoding.

3. -----


   Media-Type-Name:  A combination of a type-name and a subtype-name
      registered in [IANA.media-types] as per [RFC6838], conventionally
      identified by the two names separated by a slash.

FP: RFC 6838 is an informative reference, I wonder if it wouldn't make more sense to bring it up to normative, given that type-name and subtype-name (and media types in general) need to be understood in this specification.

4. -----

   Content-Type:  A Media-Type-Name, optionally associated with
      parameters (separated from the media type name and from each other
      by a semicolon).  In HTTP and many other protocols, used in a

FP: Please add a reference to the RFC defining media types parameters.

5. ----

      "Content-Encoding"; we *never* use this term (except when we are
      in error).

FP: It is not clear to me the goal of what stated in parenthesis.

6. -----

FP: There is a subtle difference between Content-Format and Content-Format-Spec, the latter being the "string representation" of the former. By reading the two definitions, it does feel like the same thing is specified twice, it might be worth moving the following to Content-Format-Spec:

       , identified by (1) a numeric identifier defined by the
      "CoAP Content-Formats" subregistry of [IANA.core-parameters] as
      per [RFC7252] or (2) a Content-Format-String.

Also, Content-Format-Spec right now mentions "Content-Format number". If you don't do the change above, it might be worth adding the following clarification:

OLD:
   Content-Format:  the combination of a Content-Type and a Content-
      Coding, identified by (1) a numeric identifier defined by the
      "CoAP Content-Formats" subregistry of [IANA.core-parameters] as
      per [RFC7252] or (2) a Content-Format-String.
NEW:
   Content-Format:  the combination of a Content-Type and a Content-
      Coding, identified by (1) a numeric identifier defined by the
      "CoAP Content-Formats" subregistry of [IANA.core-parameters] as
      per [RFC7252] (referred to as Content-Format number) or (2) a
      Content-Format-String.

(Content-Format number is used also in section 3)

7. -----

FP: I would have appreciated an example of use or the "bct" field in Section 4.

8. -----

FP: I think an example using a Content-Format-String including a parameter could have been useful.

9. -----

FP: In Section 8, several columns for the registration of SenML labels are missing: CBOR label, exi ID.