Subject: [core] Spencer Dawkins' No Objection on draft-ietf-core-etch-04: (with COMMENT)

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 14 Nov 2016 19:55:08 -0800

Spencer Dawkins 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:
----------------------------------------------------------------------

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.