Subject: [core] Alissa Cooper's No Objection on draft-ietf-core-etch-04: (with COMMENT)

From: "Alissa Cooper" <[email-masked]>
Date: Wed, 30 Nov 2016 12:51:01 -0800

Alissa Cooper has entered the following ballot position for
draft-ietf-core-etch-04: No Objection

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/

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 1 Dec 2016 08:47:40 +0100

> On 30 Nov 2016, at 21:51, Alissa Cooper <[email-masked]> wrote:
> 

Thank you for clearing the DISCUSS.

> s/search/fetch/ would be clearer I think

Done in -04.

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

I don’t think the considerations going into the server’s decision can be enumerated completely, but -04 changes “etc.” into:

   […], as well as other conditions such as
   the degree of control the server gives clients in creating new
   entries in its URI space (see also Section 3.4).  

> particular request so may be worth mentioning.

This is indeed an important security consideration to be aware of.
-04 now says:

   […] 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.

Thank you again for comments that really helped us improve the document.

Grüße, Carsten