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

[Benoit Claise <[e-mail]>]

Hi Peter,

Please continue to educate me.
What I make out of this is that without CoMI or CoOL, the solution for 
management over COAP is incomplete: draft-ietf-core-etch is a building 
block. So I understand Alissa's DISCUSS.
When you wrote "CoMI will be the basis that uses FETCH, PATCH, iPATCH; 
CoOL will expand on that", I'm confused. I thought CoMI and CoOL were 
competing solutions, and that one would be selected.

Regards, Benoit
> 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
> .
>