[core] Benjamin Kaduk's No Objection on draft-ietf-core-senml-etch-05: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-core-senml-etch-05: 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-senml-etch/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Adam raises some good points, and I'm looking forward to seeing the
ensuing discussion.

Just to double-check: these media types/methods are not suitable for use
with streaming lists (SenSML)?

I'll also echo the concerns of the genart reviewer about having a note
in the body of the document about the trailing "_" behavior of key names
for extensibility purposes.  I was going to ask for more detail of how this
works until I checked RFC 8428, but am only assuming the intent is to
"do what 8428 does" -- we should be explicit about it.

Section 4

As for several other reviewers  I'm not entirely sure that I understand the fragment case for
fetch/patch records.  These records (the request body) are themselves
selectors, so a client that wanted to consider just a subset of the
records could just send the (appropriately resolved for base values)
subset of the records in the request to obtain the selected set of
records from the resource instead of requesting the "full" set (from the
request body) and then selecting from the response via the fragment.
So, are we just specifying the fragment semantics out of a sense of
completeness, or are there expected to be cases where we still want to
retrieve records from the server just to "throw them away" at the client
side?  It is perhaps plausible to imagine doing so with (i)Patch, in
order to effect a set of changes but only retain the results for a
subset of them, but I'm having a harder time coming up with a case for
fetch fragments.  The best I can do so far is some (as-yet-to-me)
hypothetical case where the selector is easier to write with multiple
fetch records (e.g., for getting base values) but not all of them are
relevant for the desired computation.

Section 5

   In FETCH and (i)PATCH requests, the client can pass arbitrary names
   to the target resource for manipulation.  The resource implementer
   must take care to only allow access to names that are actually part
   of (or accessible through) the target resource.

I am somewhat inclined to think that we should say a bit more about
explicitly sanitizing the input names in addition to the current "take
care" language, to remove or escape any input that could be interpreted
with special meaning by the local system.

   If the client is not allowed to do a GET or PUT on the full target
   resource (and thus all the names accessible through it), access
   control rules must be evaluated for each record in the pack.

Does it matter if we think about the ACL as being applied to records in
the fetch/patch pack vs. the resource's pack?