[core] Benoit Claise's No Objection on draft-ietf-core-etch-03: (with COMMENT)

["Benoit Claise" <[e-mail]>]

Benoit Claise has entered the following ballot position for
draft-ietf-core-etch-03: 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:
----------------------------------------------------------------------

[reflections on core, as opposed to actionable items for the document]

Coming back to Alissa's DISCUSS and Sheng Jiang's OPS DIR review:

    This Standards Track document defines a new CoAP methods, FETCH, to
perform the equivalent of a GET with a request body; and the twin methods
PATCH and iPATCH, to modify parts of a CoAP resource. This document is
well written. I don't see any major issues from the operations and
management perspective. It is almost ready to be published. There are one
of potential major (the word potential means I don’t really sure how
serious it may be) comments from me:

    In section 2.5, it raises an issue that “a FETCH request cannot be
generated from a link alone, but also needs a way to generate the request
payload.” From the discussion text, I am not sure whether there are
existing way to generate the request payload or not. And I am not sure
whether the FECTCH method needs a standard such way to be able to work or
not. If the answer for my first question is no, or the question for my
second question is yes. Then we probably have an major issue here. I wish
my suspecting is wrong.

I would like to make sure I understand (with my OPS background,):
- COAP (RFC7252) is about HTTP GET, POST, PUT, DELETE for constrained
nodes and constrained environments
- draft-ietf-core-etch specification specifies the new CoAP methods,
FETCH, PATCH and iPATCH, which are used to access and update parts of a
resource.
- CBOR (RFC7049) is the binary encoding of JSON for COAP. And for
draft-ietf-core-etch, I guess?
- There are two data modeling language in CORE
    YANG: draft-ietf-core-yang-cbor-02 provides the mapping for YANG data
models
               encoding: CBOR
    SenML: draft-ietf-core-senml-02 provides Media Types for Sensor
Markup Language
                 encodings: JSON, CBOR, XML, EXI

Good so far?

Coming to Alissa's DISCUSS:

    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?

So what we're missing for this to work is the equivalent of RESTCONF for
constrained nodes/networks
    - Either "CoAP Management Interface", draft-vanderstok-core-comi-09
(btw this draft expired...)
    - Or Constrained Objects Language, draft-veillette-core-cool-02
Note: COMI is mentioned in the draft, but not COOL  

Is this what is meant behind?

    it is
    outside the scope of this document how information about admissible
    media types is obtained by the client



There is a clear parallel with RESTCONF (REST-like) and the CORE work:

                                               NETMOD/NETCONF            
                   CORE
Data Modeling Language                   YANG                            
         YANG or SenML (*)
Data Models                               YANG Module                    
       YANG Module or SenML (*)
Encoding                                    XML, JSON                
CBOR for YANG, JSON/CBOR/XML/EXI for SENML
Protocol                                  HTTP for RESTCONF              
                 COAP
Mgmt Protocol                         RESTCONF/NETCONF            COMI or
COOL for YANG, for SenML?? (**)

(*) not sure if SenML is a data modeling language or data models
(**) not sure if a specific mgmt protocol for SenML

Please let me know.

Regards, Benoit