PATCH and FETCH Methods for the Constrained Application Protocol (CoAP)
draft-ietf-core-etch-04

[Ballot comment]
Thank you for addressing my DISCUSS.

OLD COMMENT:

= Section 2 =

"(However, while processing a search request, a server can be expected
  to allocate computing and memory resources or even create additional
  server resources through which the response to the search can be
  retrieved.)"

s/search/fetch/ would be clearer I think

= Section 3 =

"If the Request-URI does not point to an existing
  resource, the server MAY create a new resource with that URI,
  depending on the patch document type (whether it can logically modify
  a null resource) and permissions, etc."

I know this is the same text as in RFC 5789, but it's vague. What else might create the basis for the server's decision besides the document type and permissions?

= Section 5 =

It seems that FETCH does introduce a new security consideration, in that any observer of FETCH requests can potentially glean information about the specific portions of a resource of interest to the requester. This might factor into decisions about whether to use DTLS to secure a particular request so may be worth mentioning.

[Ballot comment]
Thanks for working with me (and Alexey) to resolve my Discuss, which was:

I'm following most of your reasoning behind having the twin methods PATCH and iPATCH, but I'm struggling a bit that there's nothing that I saw that prevents a problem when the client implements only PATCH and the server implements only iPATCH.

The only text I saw that provides guidance about which method to implement is

  A client can mark a request as idempotent by using the iPATCH method
  instead of the PATCH method.  This is the only difference between the
  two.  The indication of idempotence may enable the server to keep
  less state about the interaction; some constrained servers may only
  implement the iPATCH variant for this reason.
 
Maybe I missed something?

If not, I saw

  There is no guarantee that a resource can be modified with PATCH or
  iPATCH.
 
so, maybe that mismatch isn't going to be a problem in practice, but it seems sad that you might have a patchable resource, that can't be patched because of that mismatch.

I'm not asking for "clients MUST implement iPATCH if you implement PATCH" (which would accommodate servers that only implement iPATCH), but I wonder if the working group talked about a way to avoid this mismatch?

(My previous comment was)

I was a bit uneasy with the "nearly" in

  The security considerations for PATCH or iPATCH are nearly identical
  to the security considerations for PUT ([RFC7252]). 
 
with no explanation of any differences, but I'll leave that for the SEC ADs to pick up on if it matters.

[Ballot comment]
Thanks for the added text.  It doesn't exactly cover my discuss and the attack mentioned, but I'll clear as the text is improved and gets closer to what I think is needed.  If a patch is corrupted or maliciously altered, there is no way to detect this and it can happen when stored (no hash or signature validation is performed).  This is not explicitly stated in the revised draft, although similar considerations are now included.

[Ballot comment]
[reflections on core, as opposed to actionable items for the document]

Coming back to Alissa's DISCUSS and Sheng Jiang's OPS DIR review:

    This Standards Track document defines a new CoAP methods, FETCH, to perform the equivalent of a GET with a request body; and the twin methods PATCH and iPATCH, to modify parts of a CoAP resource. This document is well written. I don't see any major issues from the operations and management perspective. It is almost ready to be published. There are one of potential major (the word potential means I don’t really sure how serious it may be) comments from me:

    In section 2.5, it raises an issue that “a FETCH request cannot be generated from a link alone, but also needs a way to generate the request payload.” From the discussion text, I am not sure whether there are existing way to generate the request payload or not. And I am not sure whether the FECTCH method needs a standard such way to be able to work or not. If the answer for my first question is no, or the question for my second question is yes. Then we probably have an major issue here. I wish my suspecting is wrong.

I would like to make sure I understand (with my OPS background,):
- COAP (RFC7252) is about HTTP GET, POST, PUT, DELETE for constrained nodes and constrained environments
- draft-ietf-core-etch specification specifies the new CoAP methods, FETCH, PATCH and iPATCH, which are used to access and update parts of a resource.
- CBOR (RFC7049) is the binary encoding of JSON for COAP. And for draft-ietf-core-etch, I guess?
- There are two data modeling language in CORE
    YANG: draft-ietf-core-yang-cbor-02 provides the mapping for YANG data models
              encoding: CBOR
    SenML: draft-ietf-core-senml-02 provides Media Types for Sensor Markup Language
                encodings: JSON, CBOR, XML, EXI

Good so far?

Coming to Alissa's DISCUSS:

    It seems that FETCH is not a useful operation unless the server is capable of understanding what it is supposed to fetch. So it's not true that "any" media type can be used, but rather only those media types for which a definition exists for what the fetch parameters indicate and which part of the resource they are intended to delineate. Shouldn't the use of FETCH be constrained to such media types?

So what we're missing for this to work is the equivalent of RESTCONF for constrained nodes/networks
    - Either "CoAP Management Interface", draft-vanderstok-core-comi-09 (btw this draft expired...)
    - Or Constrained Objects Language, draft-veillette-core-cool-02
Note: COMI is mentioned in the draft, but not COOL 

Is this what is meant behind?

    it is
    outside the scope of this document how information about admissible
    media types is obtained by the client



There is a clear parallel with RESTCONF (REST-like) and the CORE work:

                                              NETMOD/NETCONF                                CORE
Data Modeling Language                  YANG                                      YANG or SenML (*)
Data Models                              YANG Module                            YANG Module or SenML (*)
Encoding                                    XML, JSON                CBOR for YANG, JSON/CBOR/XML/EXI for SENML
Protocol                                  HTTP for RESTCONF                                COAP
Mgmt Protocol                        RESTCONF/NETCONF            COMI or COOL for YANG, for SenML?? (**)

(*) not sure if SenML is a data modeling language or data models
(**) not sure if a specific mgmt protocol for SenML

Please let me know.

Regards, Benoit

[Ballot discuss]
I'd like to see more of the actual requirements for this draft in the security considerations as the pointers include all of the configuration options for DTLS, including the "nosec" option.  I would think this operation would require authentication to prevent unauthorized access by devices that are clones.  This is a real problem in the non-IoT space for firmware updates and will be a problem in this space if it isn't already - knock off hardware that installs the firmware of a popular product.  In In section 5 of RFC5789, I see this:
  These
  include authorizing requests (possibly through access control and/or
  authentication) and ensuring that data is not corrupted through
  transport errors or through accidental overwrites.

And would like to see something similar in this section to at least list some of the requirements and reasoning.  For patch and fetch, I think the reason outlined above needs to be included as well so it is top of mind for implementers and they are aware of this very real threat.  It is important they understand why they need authentication and encryption to prevent attacks against their brand.  If someone buys knock-off hardware that is faulty and uses their firmware, they have multiple problems to deal with, not just the loss of sales.

[Ballot discuss]
I'm following most of your reasoning behind having the twin methods PATCH and iPATCH, but I'm struggling a bit that there's nothing that I saw that prevents a problem when the client implements only PATCH and the server implements only iPATCH.

The only text I saw that provides guidance about which method to implement is

  A client can mark a request as idempotent by using the iPATCH method
  instead of the PATCH method.  This is the only difference between the
  two.  The indication of idempotence may enable the server to keep
  less state about the interaction; some constrained servers may only
  implement the iPATCH variant for this reason.
 
Maybe I missed something?

If not, I saw

  There is no guarantee that a resource can be modified with PATCH or
  iPATCH.
 
so, maybe that mismatch isn't going to be a problem in practice, but it seems sad that you might have a patchable resource, that can't be patched because of that mismatch.

I'm not asking for "clients MUST implement iPATCH if you implement PATCH" (which would accommodate servers that only implement iPATCH), but I wonder if the working group talked about a way to avoid this mismatch?

[Ballot comment]
I was a bit uneasy with the "nearly" in

  The security considerations for PATCH or iPATCH are nearly identical
  to the security considerations for PUT ([RFC7252]). 
 
with no explanation of any differences, but I'll leave that for the SEC ADs to pick up on if it matters.

[Ballot comment]
Sheng Jiang  performed the opsdir review

notable discussion

Hi, Carsten,

Thanks for clarification. I took it as that the answer for my second question is no. Then, I have no further concern. Good work.

Regards,

Sheng
________________________________________
From: Carsten Bormann [cabo@tzi.org]
Sent: 09 October 2016 4:29
To: Sheng Jiang
Cc: ops-dir@ietf.org; draft-ietf-core-etch.all@tools.ietf.org
Subject: Re: OPS-DIR review of draft-ietf-core-etch

Hi Sheng,

thank you for your review.

We don't believe there needs to be a single "standard" for the FETCH
request payload media type.  As the media type is somewhat specific to
the kind of selection or search to be performed, as well as to the
structure of the resource, more specific standards will define these
media types.  Please see application/cool-instance-id-list+cbor defined
in https://tools.ietf.org/html/draft-veillette-core-cool-02 for just one
example of such a specific definition.

We have added a short note to 2.1.1 in the editors' draft to make the
fact more prominent that FETCH media types are typically specifically
defined.  Please see https://core-wg.github.io/etch/ for the current
editor's draft, to become -03 soon.

Grüße, Carsten

[Ballot discuss]
I agree with the comment made by the ops-dir reviewer, and I don't think the parenthetical in 2.2.1 addresses the problem. It seems that FETCH is not a useful operation unless the server is capable of understanding what it is supposed to fetch. So it's not true that "any" media type can be used, but rather only those media types for which a definition exists for what the fetch parameters indicate and which part of the resource they are intended to delineate. Shouldn't the use of FETCH be constrained to such media types?

[Ballot comment]
= Section 2 =

"(However, while processing a search request, a server can be expected
  to allocate computing and memory resources or even create additional
  server resources through which the response to the search can be
  retrieved.)"

s/search/fetch/ would be clearer I think

= Section 3 =

"If the Request-URI does not point to an existing
  resource, the server MAY create a new resource with that URI,
  depending on the patch document type (whether it can logically modify
  a null resource) and permissions, etc."

I know this is the same text as in RFC 5789, but it's vague. What else might create the basis for the server's decision besides the document type and permissions?

= Section 5 =

It seems that FETCH does introduce a new security consideration, in that any observer of FETCH requests can potentially glean information about the specific portions of a resource of interest to the requester. This might factor into decisions about whether to use DTLS to secure a particular request so may be worth mentioning.

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

IANA has completed its review of draft-ietf-core-etch-02.txt. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are three actions which IANA must complete.

First, in the CoAP Method Codes subregistry of the Constrained RESTful Environments (CoRE) Parameters registry located at:

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

three new method codes are to be added to the registry as follows:

Code: 0.05
Name: FETCH
Reference: [ RFC-to-be ]

Code: 0.06
Name: PATCH
Reference: [ RFC-to-be ]

Code: 0.07
Name: iPATCH
Reference: [ RFC-to-be ]

Second, in the CoAP Response Codes subregistry also in the Constrained RESTful Environments (CoRE) Parameters registry located at:

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

two new response codes are to be registered as follows:

Code: 4.09
Name: Conflict
Reference: [ RFC-to-be ]


Code: 4.22
Name: Unprocessable Entity
Reference: [ RFC-to-be ]

Third, in the CoAP Content-Formats subregistry also in the Constrained RESTful Environments (CoRE) Parameters registry located at:

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

two new content formats are to be registered as follows:

Media Type: application/json-patch+json
Encoding:
ID: 51
Reference: [ RFC-to-be ]

Media Type: application/merge-patch+json
Encoding:
ID: 52
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

IANA understands that the three actions above are the only ones 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 only to confirm what actions will be performed. 

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: jaime.jimenez@ericsson.com, core-chairs@ietf.org, draft-ietf-core-etch@ietf.org, core@ietf.org, alexey.melnikov@isode.com, "Jaime Jimenez"
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Patch and Fetch Methods for Constrained Application Protocol (CoAP)) to Proposed Standard


The IESG has received a request from the Constrained RESTful Environments
WG (core) to consider the following document:
- 'Patch and Fetch Methods for Constrained Application Protocol (CoAP)'
  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 2016-09-07. 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 existing Constrained Application Protocol (CoAP) methods only
  allow access to a complete resource, not to parts of a resource.  In
  case of resources with larger or complex data, or in situations where
  a resource continuity is required, replacing or requesting the whole
  resource is undesirable.  Several applications using CoAP will need
  to perform partial resource accesses.

  Similar to HTTP, the existing Constrained Application Protocol (CoAP)
  GET method only allows the specification of a URI and request
  parameters in CoAP options, not the transfer of a request payload
  detailing the request.  This leads to some applications to using POST
  where actually a cacheable, idempotent, safe request is desired.

  Again similar to HTTP, the existing Constrained Application Protocol
  (CoAP) PUT method only allows to replace a complete resource.  This
  also leads applications to use POST where actually a cacheable,
  possibly idempotent request is desired.

  This specification adds new CoAP methods, FETCH, to perform the
  equivalent of a GET with a request body; and the twin methods PATCH
  and iPATCH, to modify parts of a CoAP resource.

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

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


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

The document has a reference to obsolete RFC 2616, this is intentional.

My AD review:

I think response code 4.15 should be mentioned in Section 2 and not just in the IANA Considerations section. I am generally missing Error handling section for the FETCH method, similarly to what you have for PATCH/iPATCH.

draft-hartke-core-apps-03 is mentioned several times in the document. It is currently expired. What is the plan with getting it finished?

Nit: It looks like RFC 6902 and RFC 7396 should be Normative (IANA Registrations).

Obsolete reference: RFC 2616. You also need to update section references you use when referencing RFC 2616 to point to the correct section and RFC from the latest HTTP/1.1 set of RFCs.

## Shepherd Writeup

Full HTML version can be found at: http://jaimejim.github.io/temp/draft-ietf-core-etch#shepherd-writeup

###Summary

Document Shepherd: [Jaime Jiménez](jaime.jimenez@ericsson.com)
Area Director: [Alexey Melnikov](aamelnikov@fastmail.fm)

The existing Constrained Application Protocol (CoAP) methods only allow access to a complete resource.  This does not permit applications to access parts of a resource.  In case of resources with larger or complex data, or in situations where a resource continuity is required, replacing or requesting the whole resource is undesirable.  Several applications using CoAP will need to perform partial resource accesses.

Similar to HTTP, the existing Constrained Application Protocol (CoAP) GET method only allows the specification of a URI and request parameters in CoAP options, not the transfer of a request payload detailing the request.  This leads to some applications to using POST where actually a cacheable, idempotent, safe request is desired.

Again similar to HTTP, the existing Constrained Application Protocol (CoAP) PUT method only allows to replace a complete resource.  This also leads applications to use POST where actually a cacheable, possibly idempotent request is desired.

This specification adds new CoAP methods, FETCH, to perform the equivalent of a GET with a request body; and the twin methods PATCH and iPATCH, to modify parts of an existing CoAP resource.

The document is intended as an Standards Track RFC.

###Review and Consensus

The document has gone through multiple expert reviews and has been discussed on multiple IETF meetings. Before the last IETF the WGLC was completed.

There are no known implementations available.

###Intellectual Property

Each author has stated that they do not have direct, personal knowledge of any IPR related to this document. I am not aware of any IPR discussion about this document on the CoRE WG.

###Other Points
>
There is a downref to RFC 2616: This is in there because the security considerations of RFC 7252 reference (the now obsoleted) RFC 2616. The authors are not aware of someone having done the work to collect the relevant security considerations from the splinters of RFC 2616 (RFC 7230 and following).


###Checklist

* [x] Does the shepherd stand behind the document and think the document is ready for publication?
* [x] Is the correct RFC type indicated in the title page header?
* [x] Is the abstract both brief and sufficient, and does it stand alone as a brief summary?
* [x] Is the intent of the document accurately and adequately explained in the introduction?
* [x] Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been requested and/or completed?
* [x] Has the shepherd performed automated checks -- idnits (see http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of BNF rules, XML code and schemas, MIB definitions, and so on -- and determined that the document passes the tests?
` There is no ABNF in this draft`
* [x] Has each author stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79?
* [x] Have all references within this document been identified as either normative or informative, and does the shepherd agree with how they have been classified?
`There is a normative reference to [I-D.ietf-core-block] but that shouldn't be a problem as it is in late stages`
* [x] Are all normative references made to documents that are ready for advancement and are otherwise in a clear state?
* [x] If publication of this document changes the status of any existing RFCs, are those RFCs listed on the title page header, and are the changes listed in the abstract and discussed (explained, not just mentioned) in the introduction? `Does not apply`
* [x] If this is a "bis" document, have all of the errata been considered? `Does not apply`

* **IANA** Considerations:

* [x] Are the IANA Considerations clear and complete? Remember that IANA have to understand unambiguously what's being requested, so they can perform the required actions.
`I wonder if adding a link to the CoRE Parameters registry could help, but it looks OK to me. `
`http://www.iana.org/assignments/core-parameters/core-parameters.xhtml#method-codes`
* [x] Are all protocol extensions that the document makes associated with the appropriate reservations in IANA registries?
* [x] Are all IANA registries referred to by their exact names (check them in http://www.iana.org/protocols/ to be sure)?
`The two new entries to the content format registry (51 and 52) require expert review and a request has been SENT to that list.`
* [x] Have you checked that any registrations made by this document correctly follow the policies and procedures for the appropriate registries?
* [x] For registrations that require expert review (policies of Expert Review or Specification Required), have you or the working group had any early review done, to make sure the requests are ready for last call?
* [x] For any new registries that this document creates, has the working group actively chosen the allocation procedures and policies and discussed the alternatives?
`no new registries`
* [x]  Have reasonable registry names been chosen (that will not be confused with those of other registries), and have the initial contents and valid value ranges been clearly specified?