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

From: Carsten Bormann <[email-masked]>
Date: Mon, 14 Nov 2016 10:29:09 +0900

Hi Alissa,

> On 13 Oct 2016, at 01:27, Alissa Cooper <[email-masked]> wrote:
> 
> Carsten,
> 
> Thanks for your response. Inline ...
> 
>> On Oct 11, 2016, at 8:35 AM, Carsten Bormann <[email-masked]> wrote:
>> 
>> Hi Alissa,
>> 
>> thank you for these comments.
>> 
>> Alissa Cooper wrote:
>>> 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?
>> 
>> 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.
> 
> Yes, I think characterization of this just needs to be consistent throughout the document.

We went ahead and put in a recommendation that relates to where the info should come from (last sentence is new):

   […] 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 (although we can hint that form relations
   ([I-D.hartke-core-apps]) might be a preferred way).  It is
   RECOMMENDED that any discovery method that allows a client to find
   out that the server supports FETCH also provides information what
   FETCH payload media types are applicable.

I think that together with the other editorial improvements that should be enough to address the concern and clear the DISCUSS.

> 
>> 
>> 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.)
> 
> 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
> 
>> 
>>> ----------------------------------------------------------------------
>>> 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
>> 
>> Done in editor's draft.
>> 
>>> = 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?
>> 
>> 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)".
>> 
>>> = 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.
>> 
>> 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: Carsten Bormann <[email-masked]>
Date: Wed, 30 Nov 2016 18:03:46 +0100

Hi Alissa,

just checking whether this fell on the floor in the run up to IETF97.

Grüße, Carsten