Re: [core] WGLC on draft-ietf-core-senml-data-ct-02

[Carsten Bormann <[e-mail]>]

Hi Thomas,

Thank you for the light-speed review!

> * Section 1, first sentence:
>    * One of "various" or "different" look redundant to me.

They mean various different things to me :-), but one would be enough as well.
Fixed on github in https://github.com/core-wg/senml-data-ct

> * Section 2, last sentence:
>    * I-D.bormann-core-media-content-type-format is not just very
>      helpful, it also contains the definition of Content-Coding
>      which is not found elsewhere AFAIK.

Now https://github.com/core-wg/senml-data-ct/issues/2

> * Section 3, first para:
>    * you might want to reorganise the second sentence (starting with
>      "the Content-Format indication") to make it more readable.

Split up. 

> * Section 3, third para:
>    * "[...] appended to the Content Type _value_ (media type [...]"

Nice!

> * Section 3, last sentence:
>    * Might be restructured for readability; one suggestion: "If no "@"
>      sign is present outside any media type parameters, the consumer
>      can assume that no encoding transformation has been applied to the
>      representation."

Not sure we need to bring in the consumer, now says:

 If no "@" sign is
 present outside the media type parameters, the Content-Coding is not
 specified and the "identity" Content-Coding is used — no
 encoding transformation is employed.

> * Section 6:
>    * Maybe add a mention to the risks associated with compression
>      content codings (zip bomb, etc.)"

Yes.  So I tried to point to/steal from RFC 7230; this risk is not discussed there.  The last time I wrote a security considerations paragraph about this was in RFC 7400, but this isn’t very stealable either.  I don’t think the risk is very specific to data-ct, so referencing something is better than writing another description, which is what I did for now.

> * Section 7:
>    * Not sure but, would it be worth adding a note regarding the
>      formatting rules (i.e., an explicit pointer to Section 3)?

The registry has no place for this information, and the reference should include the other sections, so I don’t see a good way to add this. 

> * Section 8.1:
>    * Why is CBOR normative?

Fixed.
(CBOR stays indirectly normative via RFC 8428…)

>    * Why is the SenML registry a normative reference?

Because this specification registers “ct” in that registry.
(I think we can discuss whether that is normative, but I believe you need to understand this registry to understand the registration.
Previously, people just haven’t referenced a registry they registered in, which I consider an omission.)

Grüße, Carsten