Subject: [core] Alissa Cooper's Discuss on draft-ietf-core-etch-03: (with DISCUSS and COMMENT)

From: "Alissa Cooper" <[email-masked]>
Date: Mon, 10 Oct 2016 12:44:47 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-core-etch-03: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-etch/

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

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

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 11 Oct 2016 14:35:12 +0200

Hi Alissa,

thank you for these comments.

> https://datatracker.ietf.org/doc/draft-ietf-core-etch/

This seems to chime in with a comment that Alexey made, which prompted
us to write a new section 2.2:

https://core-wg.github.io/etch/#rfc.section.2.2

In particular, we talk about unsupported payloads:

Unsupported FETCH payload:
In case a client sends payload that is inappropriate for the resource
identified by the Request-URI, the server can return a 4.15 (Unsupported
Content-Format) CoAP error. The server can determine if the payload is
supported by checking the CoAP Content-Format specified with the request.

Even the existing text already talks about "admissible media types".
We could expand this treatment a bit.

For now, I have added a qualification to the "of any media type"
sentence such that it reads:

With the
FETCH method, implementations may submit a request body of any media
type that is
defined with the semantics of selecting information from
a resource in such a FETCH request; it is outside the scope of this
document how
information about media types admissible for the specific resource is
obtained by the client

(I'm not entirely happy yet, as it may be the resource that is the one
that defines how the media type is to be interpreted as a selector; say,
there may be resources that allow searching by text/plain -- maybe this
is hard to read from the previous sentence.)

Done in editor's draft.

> might create the basis for the server's decision besides the document

The server can run into all kinds of errors, e.g., creating a resource
in this way might cause a 4.09 Conflict. This is already discussed in
Section 3.4, which we can link to.

Replaced "etc.", "as well as other conditions (see also Section 3.4)".

> particular request so may be worth mentioning.

Good point.  Added:

The FETCH method is subject to the same general security
considerations as all CoAP methods as described in {{-coap}}.
The payload of a FETCH request may reveal more detailed information
about the specific portions of a resource of interest to the
requester than a GET request for the entire resource would; this may
mean that confidentiality protection of the request by DTLS or other
means is needed for FETCH where it wouldn't be needed for GET.

Grüße, Carsten

---

From: peter van der Stok <[email-masked]>
Date: Wed, 12 Oct 2016 09:03:43 +0200

> information about media types admissible for the specific resource is
(Over?)Simplified:
With the FETCH method, implementations may submit a request body of any 
media
type that indicates to the target resource the semantics of the request 
payload
such that the server can decide on accepting the request;
>  it is outside the scope of this
> document how

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 12 Oct 2016 12:27:49 -0400

Carsten,

Thanks for your response. Inline ...

> On Oct 11, 2016, at 8:35 AM, Carsten Bormann <[email-masked]> wrote:
> 
> Hi Alissa,
> 

Yes, I think characterization of this just needs to be consistent throughout the document.

> is hard to read from the previous sentence.)

I agree that the sentence does not convey your last point above. Peter’s suggestion is more clear but also does not capture this point I don’t think.

Thanks,
Alissa