FETCH and PATCH with Sensor Measurement Lists (SenML)
RFC 8790

Received changes through RFC Editor sync (created alias RFC 8790, changed title to 'FETCH and PATCH with Sensor Measurement Lists (SenML)', changed abstract to 'The Sensor Measurement Lists (SenML) media type and data model can be used to send collections of resources, such as batches of sensor data or configuration parameters.  The Constrained Application Protocol (CoAP) FETCH, PATCH, and iPATCH methods enable accessing and updating parts of a resource or multiple resources with one request.  This document defines new media types for the CoAP FETCH, PATCH, and iPATCH methods for resources represented using the SenML data model.', changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2020-06-30, changed IESG state to RFC Published)

[Ballot comment]
Thank you for addressing my DISCUSS items.

--[ old comments

(3) Section 3.1.  A few questions about how general purpose of a query language is possible with the FETCH:

-- (To confirm based on the text “The SenML Records are selected by giving a set of names that …”) Does a name always have to be in the Fetch Request (i.e., ‘at least one “n” MUST be in the Fetch Request’)? 

Using the third example in Section 5.1.2 of RFC8428 as a source:

-- The current text mentions that names and time can be in the Fetch Pack request.  Can other fields also be used as part of the criteria, say “v”?  For example, would ‘{“n”:” urn:dev:ow:10e2073a01080063”, “v”:”21.5”}’ return the three name+time records where the value is 21.5?

(4) Section 3.1. If there is no match for a Fetch, how is that signaled back in the response?  Is there any guidance to provide on error handling via CoAP error codes?

(5) Editorial Nits:

-- Section 3.1.  s/When SenML Records contain also time values/When SenML Records also contain time values/

[Ballot comment]
Adam raises some good points, and I'm looking forward to seeing the
ensuing discussion.

Just to double-check: these media types/methods are not suitable for use
with streaming lists (SenSML)?

I'll also echo the concerns of the genart reviewer about having a note
in the body of the document about the trailing "_" behavior of key names
for extensibility purposes.  I was going to ask for more detail of how this
works until I checked RFC 8428, but am only assuming the intent is to
"do what 8428 does" -- we should be explicit about it.

Section 4

As for several other reviewers  I'm not entirely sure that I understand the fragment case for
fetch/patch records.  These records (the request body) are themselves
selectors, so a client that wanted to consider just a subset of the
records could just send the (appropriately resolved for base values)
subset of the records in the request to obtain the selected set of
records from the resource instead of requesting the "full" set (from the
request body) and then selecting from the response via the fragment.
So, are we just specifying the fragment semantics out of a sense of
completeness, or are there expected to be cases where we still want to
retrieve records from the server just to "throw them away" at the client
side?  It is perhaps plausible to imagine doing so with (i)Patch, in
order to effect a set of changes but only retain the results for a
subset of them, but I'm having a harder time coming up with a case for
fetch fragments.  The best I can do so far is some (as-yet-to-me)
hypothetical case where the selector is easier to write with multiple
fetch records (e.g., for getting base values) but not all of them are
relevant for the desired computation.

Section 5

  In FETCH and (i)PATCH requests, the client can pass arbitrary names
  to the target resource for manipulation.  The resource implementer
  must take care to only allow access to names that are actually part
  of (or accessible through) the target resource.

I am somewhat inclined to think that we should say a bit more about
explicitly sanitizing the input names in addition to the current "take
care" language, to remove or escape any input that could be interpreted
with special meaning by the local system.

  If the client is not allowed to do a GET or PUT on the full target
  resource (and thus all the names accessible through it), access
  control rules must be evaluated for each record in the pack.

Does it matter if we think about the ACL as being applied to records in
the fetch/patch pack vs. the resource's pack?

[Ballot comment]
I agree with the Gen-ART reviewer and Warren that Section 4 is not specified enough. It's not clear what "analogously applied" means.

Please respond to the rest of the Gen-ART review.

[Ballot discuss]
(1) Section 5.  It’s helpful that this document notes the relevance of SenML’s security and privacy considerations (i.e., Section 13 of RFC8428).  However, this references seems circular.  RFC8428 says, “SenML formats alone do not provide any security and instead rely on the protocol that carries them to provide security.”  This document seems to be that “protocol that carries them” implying it  should cover the security mechanisms.  Is it not appropriate to suggest that CoAPs can address the (per RFC8428) “confidentiality, data integrity, and authentication as appropriate for the usage.”? If not, what additional guidance can be provided?

(2) Section 5.  It seems like it would be appropriate for the server to support access control to restrict the client’s ability access and modify a resource with FETCH and (i)PATCH.  My read of “Per “In FETCH and (i)PATCH requests, the client can pass arbitrary names to the target resource for manipulation.  The resource implementer must take care to only allow access to names that are actually part of (or accessible through) the target resource”, doesn’t suggest that type of access control.

[Ballot comment]
(3) Section 3.1.  A few questions about how general purpose of a query language is possible with the FETCH:

-- (To confirm based on the text “The SenML Records are selected by giving a set of names that …”) Does a name always have to be in the Fetch Request (i.e., ‘at least one “n” MUST be in the Fetch Request’)? 

Using the third example in Section 5.1.2 of RFC8428 as a source:

-- The current text mentions that names and time can be in the Fetch Pack request.  Can other fields also be used as part of the criteria, say “v”?  For example, would ‘{“n”:” urn:dev:ow:10e2073a01080063”, “v”:”21.5”}’ return the three name+time records where the value is 21.5?

(4) Section 3.1. If there is no match for a Fetch, how is that signaled back in the response?  Is there any guidance to provide on error handling via CoAP error codes?

(5) Editorial Nits:

-- Section 3.1.  s/When SenML Records contain also time values/When SenML Records also contain time values/

[Ballot discuss]
Thanks to everyone who worked on this document. I have a couple of
concerns that I think make this specification ambiguous in some very
important ways that will prevent interoperation. These should be
pretty simple to fix.

Section 3.2 talks about patching operations. One of the things it
indicates is:

  "The
  names and times of the Patch Records are given and matched in same
  way as for the Fetch Records, except each Patch Record can match at
  most one Target Record."

I kept waiting for text that tells the recipient of a patch what to do
if a Patch Record matches more than one SenML Record (e.g., if the
Patch Record contains no time value and so matches several different
SenML Records), but I couldn't find any. Presumably, this is an error,
and an error should be sent to the client.

The ability for one Patch Record to raise an error, in turn, raises the
question about how to handle other Patch Records in the same Patch Pack. For
example, if I send a Patch Pack with two Patch Records that can be
successfully applied, and one that cannot (because it matches multiple
SenML Records), does the server apply the two that it can, but not the
one that cannot? If so, how does it communicate to the client which
records succeeded, and which failed?

Relevant to the above points, we also need to clearly specify in this document
whether the Patch Records are considered to be applied in sequence. For example,
consider a SenML database containing:

  [
    {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067464e+09,
      "v":20},
    {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067524e+09,
      "v":20.3}
  ]

Now, I send a Patch Pack like:

  [
    {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067464e+09,
      "v":null},
    {"n":"urn:dev:ow:10e2073a01080063","u":"%RH", "v":21}
  ]

Does this succeed, or does it fail? If executed in sequence, this
succeeds, since the first Patch Record will remove the first SenML
record, and the second Patch Record will unambiguously match the
second SenML record (and update it). On the other hand, if we don't
specify that records are processed in order, then this might be
rejected due to the second Patch Record being ambiguous.

Note that this rejection could also arise if an implementation
naively attempted to validate records prior to executing them,
without taking into account the impact of the preceding record
on the state of the SenML record database.

There are other ways of handling this, but my strawman for how
to address these issues would be to add language that specifies:

- Any Patch Record that matches more than one SenML record results
  in an error that is sent to the client.

- If an error is sent to a client for a Patch Pack, then the final
  state of the SenML records on the client must not be changed.
  In other words, either the Patch Pack works in its entirety, or
  it fails in its entirety.

- Patch Records in a Patch Pack are processed sequentially. In order
  to implement both this and the preceding bullet, the implementation
  will need some ability to roll-back any already-applied changes if
  an error is encountered.

[Ballot comment]
It's a small thing, and not worth putting in as a DISCUSS, but please DO make this change:
Please change the registration templates in Sections 6.2 and 6.3 to accurately match the template in Section 5.6 of RFC 6838.
Thanks.

[Ballot comment]
Firstly, thank you for writing this, and also thanks to Carlos Pignataro for the OpsDir review.

I have a question and a few nits which might be worth addressing if you are making other edits:

Question:
1: The text in Section 4 feels quite hand-wavy / terse, and I don't think gives sufficient guidance to actually use this.
e.g: What takes precedence? Do I refer to a specific record (using fragment identification) and then apply the FETCH / PATCH to that? Or do I use fragment identification to refer to records what have been PATCHed?
As might be clear from the above, I'm not a CoRE person, so I'll be happy to accept "Your question makes no sense, this will be blindingly obvious to anyone who's actually implementing this...." :-)



Nits:
1:  Target Record:  A Record in a SenML Pack that is matching the
s/is matching/matches/

2: The names for a Fetch Pack are given using the SenML "name" and/or "base name" Fields.
I *think* that in this case "fields" would be better than "Fields" - you seem to be using the term fields generically in this case.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-core-senml-etch-05. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the CoAP Content-Formats registry on the Constrained RESTful Environments (CoRE) Parameters registry page located at:

https://www.iana.org/assignments/core-parameters/

two, new registrations are to be made as follows:

Media-type: application/senml-etch+json
Encoding:
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Media-type: application/senml-etch+cbor
Encoding:
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

IANA Question --> which range in the registry should these values be registered in?

Second, in the application subregistry of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

two new media types are to be registered as follows:

Name: senml-etch+json
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Name: senml-etch+cbor
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

[Ballot comment]
Just one minor comment: I guess it okay to use IPSO dimmable light smart object as one real life example, however, one could also just use a made-up generic example instead as I guess it's often done in RFCs.

The following Last Call announcement was sent out (ends 2019-09-02):

From: The IESG
To: IETF-Announce
CC: draft-ietf-core-senml-etch@ietf.org, core-chairs@ietf.org, Carsten Bormann , core@ietf.org, alexey.melnikov@isode.com, cabo@tzi.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (FETCH & PATCH with Sensor Measurement Lists (SenML)) to Proposed Standard


The IESG has received a request from the Constrained RESTful Environments WG
(core) to consider the following document: - 'FETCH & PATCH with Sensor
Measurement Lists (SenML)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-09-02. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  The Sensor Measurement Lists (SenML) media type and data model can be
  used to send collections of resources, such as batches of sensor data
  or configuration parameters.  The CoAP iPATCH, PATCH, and FETCH
  methods enable accessing and updating parts of a resource or multiple
  resources with one request.  This document defines new media types
  for the CoAP iPATCH, PATCH, and FETCH methods for resources
  represented with the SenML data model.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-core-senml-etch/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-core-senml-etch/ballot/


No IPR declarations have been submitted directly on this I-D.

        As required by RFC 4858, this is the current template for the Document
        Shepherd Write-Up.

        Changes are expected over time. This version is dated 24 February 2012.

        (1) What type of RFC is being requested (BCP, Proposed Standard,
        Internet Standard, Informational, Experimental, or Historic)?  Why
        is this the proper type of RFC?  Is this type of RFC indicated in the
        title page header?

Standards-Track -- this specification defines a set of media types to
be used in interchange.

        (2) The IESG approval announcement includes a Document Announcement
        Write-Up. Please provide such a Document Announcement Write-Up. Recent
        examples can be found in the "Action" announcements for approved
        documents. The approval announcement contains the following sections:

        Technical Summary

  The Sensor Measurement Lists (SenML) media type and data model can
  be used to send collections of resources, such as batches of sensor
  data or configuration parameters.  The existing media types
  (defined in RFC 8428) are useful for the traditional operations
  GET, PUT, POST.  The CoAP iPATCH, PATCH, and FETCH methods enable
  accessing and updating parts of a resource or multiple resources
  with one request.  For using these methods to access and operate on
  resources represented with the SenML data model, the present
  document defines variants of the SenML media types, for JSON and
  CBOR representations only.

        Working Group Summary

  Most of the discussion in the WG (up to and including the last
  call) centered around whether the existing media types should be
  shoe-horned into use with the new methods or new media types were
  needed.  In the end, having a simple way to apply a slight variant
  won out over having a more complex way to apply something that is
  nominally, but not really SenML.  Christian Amsüss was kind enough
  to summarize his view of the result of the discussion into a Wiki
  page:
  https://github.com/core-wg/wiki/wiki/On-media-types-for-FETCH-and-(i)PATCH
  which will be useful in avoiding revisiting the issues when they
  inevitably come up for the next media type.

        Document Quality

          Are there existing implementations of the protocol? Have a
          significant number of vendors indicated their plan to
          implement the specification? Are there any reviewers that
          merit special mention as having done a thorough review,
          e.g., one that resulted in important changes or a
          conclusion that the document had no substantive issues? If
          there was a MIB Doctor, Media Type or other expert review,
          what was its course (briefly)? In the case of a Media Type
          review, on what date was the request posted?

Implementations of this media type will often be done in the context
of the OMA LWM2M specification, which is set to pick up the new media
types in future versions (1.1.1 hints: "The media types,
application/senml-etch+json and application/senml-etch+cbor, will
remove the requirement for context aware parsing.").  None of the
implementations this shepherd is aware of is public yet: one existing
implementation, and one implementation that is in the product plan of
a vendor.

A media type review has been requested 2019-07-12 in
⁨⁩


        Personnel

          Who is the Document Shepherd? Who is the Responsible Area
          Director?

Shepherd: Carsten Bormann  (CoRE Co-chair)
Responsible AD: Alexey Melnikov

        (3) Briefly describe the review of this document that was performed by
        the Document Shepherd.  If this version of the document is not ready
        for publication, please explain why the document is being forwarded to
        the IESG.

This document was reviewed by the Shepherd in a "Chair's Review", a
process step we like to exercise in the CoRE WG before issuing a WGLC.
The document is ready.

        (4) Does the document Shepherd have any concerns about the depth or
        breadth of the reviews that have been performed?

This is a simple specification.  The WGLC ended without any further
reviews at all, maybe because the document is so obvious.  After some
nudging, re-reviews came from previous commenters (Christian Amsüss)
as well as a new review from Klaus Hartke, whose comments were then
addressed in -04.

        (5) Do portions of the document need review from a particular or from
        broader perspective, e.g., security, operational complexity, AAA, DNS,
        DHCP, XML, or internationalization? If so, describe the review that
        took place.

No.

        (6) Describe any specific concerns or issues that the Document Shepherd
        has with this document that the Responsible Area Director and/or the
        IESG should be aware of? For example, perhaps he or she is uncomfortable
        with certain parts of the document, or has concerns whether there really
        is a need for it. In any event, if the WG has discussed those issues and
        has indicated that it still wishes to advance the document, detail those
        concerns here.

None.

        (7) Has each author confirmed that any and all appropriate IPR
        disclosures required for full conformance with the provisions of BCP 78
        and BCP 79 have already been filed. If not, explain why.

Yes; both authors indicated to the Shepherd that they are not
personally aware of any IPR claims applying to this specification.

        (8) Has an IPR disclosure been filed that references this document?
        If so, summarize any WG discussion and conclusion regarding the IPR
        disclosures.

No.

        (9) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with others
        being silent, or does the WG as a whole understand and agree with it? 

SenML is a bit of a specialty topic in the WG.  Those interested in
SenML, understand and agree.

        (10) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in separate
        email messages to the Responsible Area Director. (It should be in a
        separate email because this questionnaire is publicly available.)

No.

        (11) Identify any ID nits the Document Shepherd has found in this
        document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
        Checklist). Boilerplate checks are not enough; this check needs to be
        thorough.

None found.

        (12) Describe how the document meets any required formal review
        criteria, such as the MIB Doctor, media type, and URI type reviews.

A media type review has been requested 2019-07-12 in
⁨⁩

        (13) Have all references within this document been identified as
        either normative or informative?

Yes

        (14) Are there normative references to documents that are not ready for
        advancement or are otherwise in an unclear state? If such normative
        references exist, what is the plan for their completion?

All normative references are Proposed Standard RFCs (plus BCP 14).

        (15) Are there downward normative references references (see RFC 3967)?
        If so, list these downward references to support the Area Director in
        the Last Call procedure.

No.

        (16) Will publication of this document change the status of any
        existing RFCs? Are those RFCs listed on the title page header, listed
        in the abstract, and discussed in the introduction? If the RFCs are not
        listed in the Abstract and Introduction, explain why, and point to the
        part of the document where the relationship of this document to the
        other RFCs is discussed. If this information is not in the document,
        explain why the WG considers it unnecessary.

No.

        (17) Describe the Document Shepherd's review of the IANA considerations
        section, especially with regard to its consistency with the body of the
        document. Confirm that all protocol extensions that the document makes
        are associated with the appropriate reservations in IANA registries.
        Confirm that any referenced IANA registries have been clearly
        identified. Confirm that newly created IANA registries include a
        detailed specification of the initial contents for the registry, that
        allocations procedures for future registrations are defined, and a
        reasonable name for the new registry has been suggested (see RFC 8126).

No new registries.  Registration of two new media types and the
attendant CoRE Content-Format numbers.

        (18) List any new IANA registries that require Expert Review for future
        allocations. Provide any public guidance that the IESG would find
        useful in selecting the IANA Experts for these new registries.

No new registries.

        (19) Describe reviews and automated checks performed by the Document
        Shepherd to validate sections of the document written in a formal
        language, such as XML code, BNF rules, MIB definitions, etc.

No FDT were in use.

The JSON examples in the specification have been checked by the
Shepherd; a superfluous comma in the second JSON example (FETCH
response) in Section 3.1 needs to be removed before advancing the
document.

        As required by RFC 4858, this is the current template for the Document
        Shepherd Write-Up.

        Changes are expected over time. This version is dated 24 February 2012.

        (1) What type of RFC is being requested (BCP, Proposed Standard,
        Internet Standard, Informational, Experimental, or Historic)?  Why
        is this the proper type of RFC?  Is this type of RFC indicated in the
        title page header?

Standards-Track -- this specification defines a set of media types to
be used in interchange.

        (2) The IESG approval announcement includes a Document Announcement
        Write-Up. Please provide such a Document Announcement Write-Up. Recent
        examples can be found in the "Action" announcements for approved
        documents. The approval announcement contains the following sections:

        Technical Summary

  The Sensor Measurement Lists (SenML) media type and data model can
  be used to send collections of resources, such as batches of sensor
  data or configuration parameters.  The existing media types
  (defined in RFC 8428) are useful for the traditional operations
  GET, PUT, POST.  The CoAP iPATCH, PATCH, and FETCH methods enable
  accessing and updating parts of a resource or multiple resources
  with one request.  For using these methods to access and operate on
  resources represented with the SenML data model, the present
  document defines variants of the SenML media types, for JSON and
  CBOR representations only.

        Working Group Summary

  Most of the discussion in the WG (up to and including the last
  call) centered around whether the existing media types should be
  shoe-horned into use with the new methods or new media types were
  needed.  In the end, having a simple way to apply a slight variant
  won out over having a more complex way to apply something that is
  nominally, but not really SenML.  Christian Amsüss was kind enough
  to summarize his view of the result of the discussion into a Wiki
  page:
  https://github.com/core-wg/wiki/wiki/On-media-types-for-FETCH-and-(i)PATCH
  which will be useful in avoiding revisiting the issues when they
  inevitably come up for the next media type.

        Document Quality

          Are there existing implementations of the protocol? Have a
          significant number of vendors indicated their plan to
          implement the specification? Are there any reviewers that
          merit special mention as having done a thorough review,
          e.g., one that resulted in important changes or a
          conclusion that the document had no substantive issues? If
          there was a MIB Doctor, Media Type or other expert review,
          what was its course (briefly)? In the case of a Media Type
          review, on what date was the request posted?

Implementations of this media type will often be done in the context
of the OMA LWM2M specification, which is set to pick up the new media
types in future versions (1.1.1 hints: "The media types,
application/senml-etch+json and application/senml-etch+cbor, will
remove the requirement for context aware parsing.").  None of the
implementations this shepherd is aware of is public yet: one existing
implementation, and one implementation that is in the product plan of
a vendor.

A media type review has been requested 2019-07-12 in
⁨⁩


        Personnel

          Who is the Document Shepherd? Who is the Responsible Area
          Director?

Shepherd: Carsten Bormann  (CoRE Co-chair)
Responsible AD: Alexey Melnikov

        (3) Briefly describe the review of this document that was performed by
        the Document Shepherd.  If this version of the document is not ready
        for publication, please explain why the document is being forwarded to
        the IESG.

This document was reviewed by the Shepherd in a "Chair's Review", a
process step we like to exercise in the CoRE WG before issuing a WGLC.
The document is ready.

        (4) Does the document Shepherd have any concerns about the depth or
        breadth of the reviews that have been performed?

This is a simple specification.  The WGLC ended without any further
reviews at all, maybe because the document is so obvious.  After some
nudging, re-reviews came from previous commenters (Christian Amsüss)
as well as a new review from Klaus Hartke, whose comments were then
addressed in -04.

        (5) Do portions of the document need review from a particular or from
        broader perspective, e.g., security, operational complexity, AAA, DNS,
        DHCP, XML, or internationalization? If so, describe the review that
        took place.

No.

        (6) Describe any specific concerns or issues that the Document Shepherd
        has with this document that the Responsible Area Director and/or the
        IESG should be aware of? For example, perhaps he or she is uncomfortable
        with certain parts of the document, or has concerns whether there really
        is a need for it. In any event, if the WG has discussed those issues and
        has indicated that it still wishes to advance the document, detail those
        concerns here.

None.

        (7) Has each author confirmed that any and all appropriate IPR
        disclosures required for full conformance with the provisions of BCP 78
        and BCP 79 have already been filed. If not, explain why.

Yes; both authors indicated to the Shepherd that they are not
personally aware of any IPR claims applying to this specification.

        (8) Has an IPR disclosure been filed that references this document?
        If so, summarize any WG discussion and conclusion regarding the IPR
        disclosures.

No.

        (9) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with others
        being silent, or does the WG as a whole understand and agree with it? 

SenML is a bit of a specialty topic in the WG.  Those interested in
SenML, understand and agree.

        (10) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in separate
        email messages to the Responsible Area Director. (It should be in a
        separate email because this questionnaire is publicly available.)

No.

        (11) Identify any ID nits the Document Shepherd has found in this
        document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
        Checklist). Boilerplate checks are not enough; this check needs to be
        thorough.

None found.

        (12) Describe how the document meets any required formal review
        criteria, such as the MIB Doctor, media type, and URI type reviews.

A media type review has been requested 2019-07-12 in
⁨⁩

        (13) Have all references within this document been identified as
        either normative or informative?

Yes

        (14) Are there normative references to documents that are not ready for
        advancement or are otherwise in an unclear state? If such normative
        references exist, what is the plan for their completion?

All normative references are Proposed Standard RFCs (plus BCP 14).

        (15) Are there downward normative references references (see RFC 3967)?
        If so, list these downward references to support the Area Director in
        the Last Call procedure.

No.

        (16) Will publication of this document change the status of any
        existing RFCs? Are those RFCs listed on the title page header, listed
        in the abstract, and discussed in the introduction? If the RFCs are not
        listed in the Abstract and Introduction, explain why, and point to the
        part of the document where the relationship of this document to the
        other RFCs is discussed. If this information is not in the document,
        explain why the WG considers it unnecessary.

No.

        (17) Describe the Document Shepherd's review of the IANA considerations
        section, especially with regard to its consistency with the body of the
        document. Confirm that all protocol extensions that the document makes
        are associated with the appropriate reservations in IANA registries.
        Confirm that any referenced IANA registries have been clearly
        identified. Confirm that newly created IANA registries include a
        detailed specification of the initial contents for the registry, that
        allocations procedures for future registrations are defined, and a
        reasonable name for the new registry has been suggested (see RFC 8126).

No new registries.  Registration of two new media types and the
attendant CoRE Content-Format numbers.

        (18) List any new IANA registries that require Expert Review for future
        allocations. Provide any public guidance that the IESG would find
        useful in selecting the IANA Experts for these new registries.

No new registries.

        (19) Describe reviews and automated checks performed by the Document
        Shepherd to validate sections of the document written in a formal
        language, such as XML code, BNF rules, MIB definitions, etc.

No FDT were in use.

The JSON examples in the specification have been checked by the
Shepherd; a superfluous comma in the second JSON example (FETCH
response) in Section 3.1 needs to be removed before advancing the
document.