PATCH and FETCH Methods for the Constrained Application Protocol (CoAP)
RFC 8132

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.

I share the concerns from Alissa's DISCUSS point and comment about section 5.

[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

Sheng Jiang <jiangsheng@huawei.com> 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

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.

Does this doc update RFC7252? Maybe not; just asking...

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.