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

[peter van der Stok <[e-mail]>]

Hi Benoit,

Thanks for your extensive comment. It contains very valuable feedback.

Although you write that your comment exceeds the etch boundaries and 
refers to CORE as a whole, many of the commented subjects have my name 
on it.
Therefore, I will answer some of your comments and trust that Carsten 
will expand and complete.
See below, please.

Benoit Claise schreef op 2016-10-13 14:18:
> 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.
<pvds>
The answer is a bit less black and white.
A draft is in preparation that describes the payload format for the 
FETCH request in context of CoMI and CoOL.
I expect that more drafts in the future will describe payload formats 
for FETCH requests.
</pvds>
> 
> 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?
<pvds>
YES, but not exclusively.
</pvds>
> - 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?
<pvds>
I am sure Carsten can elaborate on those in more detail
For my part, you are absolutely correct.
</pvds>
> 
> 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
<pvds>
CoMI will be the basis that uses FETCH, PATCH, iPATCH; CoOL will expand 
on that
</pvds>
> 
> Is this what is meant behind?
<pvds>
yes, and other applications beyond
</pvds>
> 
>     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
> 
> 
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core