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

From: Jaime Jiménez <[email-masked]>
Date: Mon, 17 Aug 2020 10:22:36 +0200

Dear all,

We are now closing this call. As you can see there have been no comments on this WGLC at all, which is odd.
The document does seem mature and the chairs would be happy to close the call and ship the document, however I'd like to check with the AD (Barry) to confirm that it's OK as we have gotten no feedback. We could extend the call, but I am not sure that'd bring more comments.

Thanks!
-- 
Jaime Jiménez

On Wed, Jul 29, 2020, at 7:44 PM, Jaime Jiménez wrote:
> Dear CoRE WG,
> 
> we would like to issue the WGLC for 
> https://tools.ietf.org/html/draft-ietf-core-senml-data-ct-02
> 
> This short draft specifies a new SenML field (“ct”) that indicates the 
> content format of the data. 
> 
> The authors believe the draft is ready and we have discussed it on 
> several CoRE meetings. I think it is a great opportunity to provide 
> some last minute feedback so please, if you have a bit of time it is 
> only few pages long.
>   
> We will close the call in two weeks, the 12th of August. 
> 
> Thanks!
> -- 
> Jaime Jiménez

---

From: Barry Leiba <[email-masked]>
Date: Mon, 17 Aug 2020 16:04:25 -0400

I leave this to the chairs’ judgment, with this advice:
I’m concerned more with how much review and discussion the document has had
throughout it’s development than with specifically the comments during
WGLC.  If you think there’s been enough of the former, be sure that the
shepherd writeup talks about that, and it will be fine.  If it’s really the
case that the WG doesn’t have enough interest to have reviewed the document
in general, then that’s a different coloured horse.

You could also, rather than directly extending WGLC, post to the working
group that there have been no further comments and that the document is
ready for publication... but that you would like (pick a small number)
three reviews that agree that it’s ready.  “Who will volunteer to give it a
final review before you send it to the AD?”  And see if that prompts a
coupla participants to say, “Yep, I had a look: ship it!”

Barry

On Mon, Aug 17, 2020 at 4:22 AM Jaime Jiménez <[email-masked]> wrote:

> The document does seem mature and the chairs would be happy to close the
> call and ship the document, however I'd like to check with the AD (Barry)
> to confirm that it's OK as we have gotten no feedback. We could extend the
> call, but I am not sure that'd bring more comments.
>
>
>
> Thanks!
>
> --
>
> Jaime Jiménez
>
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 17 Aug 2020 22:09:30 +0200

On 2020-08-17, at 22:04, Barry Leiba <[email-masked]> wrote:
> 
> You could also, rather than directly extending WGLC, post to the working group that there have been no further comments and that the document is ready for publication... but that you would like (pick a small number) three reviews that agree that it’s ready.  “Who will volunteer to give it a final review before you send it to the AD?”  And see if that prompts a coupla participants to say, “Yep, I had a look: ship it!”

I’m no longer a WG chair, but I would have considered this very good advice.

The underlying problem maybe is that we have a hard time reacting to requests that are coming from implementers — we may not be able to import these people into the WG permanently, so we need to get better in dragging them in when their requests are actually being handled.

Grüße, Carsten

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 17 Aug 2020 20:22:47 +0000

Hi Barry, Jaime,

On 17/08/2020, 21:05, "core on behalf of Barry Leiba" <[email-masked] on behalf of [email-masked]> wrote:
> You could also, rather than directly extending WGLC, post to the
> working group that there have been no further comments and that the
> document is ready for publication... but that you would like (pick a
> small number) three reviews that agree that it’s ready.  “Who will
> volunteer to give it a final review before you send it to the AD?”
> And see if that prompts a coupla participants to say, “Yep, I had a
> look: ship it!”

One thing that might explain why this doc managed to slip under the
radar is that in August some folks (including myself) tend to be on
holiday.  That said, I volunteer for reviewing the draft.

cheers!

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 17 Aug 2020 16:31:35 -0400

Thanks, Thomas!

And, yes, August is always a challenge.

Barry

On Mon, Aug 17, 2020 at 4:22 PM Thomas Fossati <[email-masked]>
wrote:

> Hi Barry, Jaime,
>
>
>
> On 17/08/2020, 21:05, "core on behalf of Barry Leiba" <
> [email-masked] on behalf of [email-masked]> wrote:
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
>

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 18 Aug 2020 10:57:11 +0100

Hi all,

> The document does seem mature and the chairs would be happy to close the call and ship the document, however I'd like to check with the AD (Barry) to confirm that it's OK as we have gotten no feedb…

Sorry for the belated review. I think the document is nearly ready for 
progression. I have a couple of minor related issues:

2.  Terminology

    Readers should also be familiar with the terms and concepts discussed
    in [RFC8428].  Awareness of terminology issues discussed in
    [I-D.bormann-core-media-content-type-format] can also be very

It is expired and it is currently not a WG document. At minimum it 
should be revived. (Or see below)

    helpful.

3.  SenML Content-Format ("ct") Field

I wish the document has ABNF for the "ct" field. If you want to use ABNF 
from draft-bormann-core-media-content-type-format-01, it should be 
Normative reference. If not, I think you should just cut & paste the 
ABNF into this document.

Best Regards,

Alexey

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 18 Aug 2020 14:32:52 +0200

Hi Alexey,

On 2020-08-18, at 11:57, Alexey Melnikov <[email-masked]> wrote:
> 
> I wish the document has ABNF for the "ct" field. If you want to use ABNF from draft-bormann-core-media-content-type-format-01, it should be Normative reference. If not, I think you should just cut & paste the ABNF into this document.

This is a good point.

Since data-ct needs almost all of the “normative” ABNF in media-content-type-format, I think the right thing to do would be to fully develop media-content-type-format and make it a normative reference.  (Note that media-content-type-format probably needs to be run by httpbis and emailcore [?] soon and when it is nearing WGLC, and there may be surprises there.)

This course of action would probably delay data-ct a bit; we might counteract the damage by early registration.  Since data-ct only needs an “Expert Review” registration, we could decide to do this when we have processed the reviews that are now incoming.

Grüße, Carsten

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 18 Aug 2020 19:28:46 +0000

Hi Ari, Carsten,

I have reviewed draft-ietf-core-senml-data-ct-02 and overall it looks
good to me.  I've left a few annotations below.

Cheers!

* Section 1, first sentence:
    * One of "various" or "different" look redundant to me.
* 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.
* Section 3, first para:
    * you might want to reorganise the second sentence (starting with
      "the Content-Format indication") to make it more readable.
* Section 3, third para:
    * "[...] appended to the Content Type _value_ (media type [...]"
* 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."
* Section 6:
    * Maybe add a mention to the risks associated with compression
      content codings (zip bomb, etc.)"
* Section 7:
    * Not sure but, would it be worth adding a note regarding the
      formatting rules (i.e., an explicit pointer to Section 3)?
* Section 8.1:
    * Why is CBOR normative?
    * Why is the SenML registry a normative reference?

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 18 Aug 2020 22:12:42 +0200

On 2020-08-18, at 11:57, Alexey Melnikov <[email-masked]> wrote:
> 
> It is expired and it is currently not a WG document. At minimum it should be revived.

Done.
(I left one bug in, of course to check whether anyone reads this :-)

Status:
https://datatracker.ietf.org/doc/draft-bormann-core-media-content-type-format/

HTMLized:
https://tools.ietf.org/html/draft-bormann-core-media-content-type-format-02
HTML:
https://www.ietf.org/id/draft-bormann-core-media-content-type-format-02.html

diff:
https://www.ietf.org/rfcdiff?url2=draft-bormann-core-media-content-type-format-02

Grüße, Carsten

---

From: Jim Schaad <[email-masked]>
Date: Tue, 18 Aug 2020 19:29:57 -0700

For the most part it looks good.  However, I am not sure that I understand what the correct behavior for 

{"bn":"urn:dev:ow:10e2073a01080063:","n":"temp","u":"Cel","vs":"7.1","ct":"0"}
{"bn":"urn:dev:ow:10e2073a01080063:","n":"temp","u":"Cel","v":7.1,"ct":"0"}

Should the ct be ignored if the value is not "vd"?  If it is present but does not make sense what should happen?

Jim

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 19 Aug 2020 06:46:46 +0200

> {"bn":"urn:dev:ow:10e2073a01080063:","n":"temp","u":"Cel","v":7.1,"ct":"0"}

Right, this would be what you easily get if you do a “naïve” resolution of “bct" base fields.

(However, Section 4 says that you only copy them to records with “vd” fields.)

> Should the ct be ignored if the value is not "vd"?  If it is present but does not make sense what should happen?

I think that it would be good to do the same thing with “naïve” resolution, i.e., ignore “ct” if there is no “vd”.  But I don’t have a strong opinion.

Section 3 says:

   When a SenML Record contains a Data Value field ("vd"), the Record
   MAY also include a Content-Format indication field. 

In logic, it simply doesn’t say anything about records without “vd”.
In English, it does seem to imply that the MAY does not apply to them.
(But then it doesn’t say what is supposed to happen.)

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

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 19 Aug 2020 15:17:22 +0200

Hi Thomas,

Thank you for the light-speed review!

>    * 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

>      which is not found elsewhere AFAIK.

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

>      "the Content-Format indication") to make it more readable.

Split up. 

>    * "[...] appended to the Content Type _value_ (media type [...]"

Nice!

>      can assume that no encoding transformation has been applied to the

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.

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

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

>    * 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

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 19 Aug 2020 13:31:39 +0000

Your changes look great.  Just a couple of comments:

On 19/08/2020, 14:17, "Carsten Bormann" <[email-masked]> wrote:
> 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.

I noticed a "Notes" column in the registry [1], that's why I suggested
using it to offer a more granular pointer into the spec.  But since the
document is very compact, the RFC reference works as well.

[1] https://www.iana.org/assignments/senml/senml.xhtml#senml-labels

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

Fair enough :-)

Cheers!