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

Hi Benoit,

I confirm that ETCH is a building block for CoMI. It puts accessing 
(multiple) parts of resources such as YANG list instances on a firmer 
footing.
Concerning CoMI and CoOL I understand your confusion.
When we realized that there were more common things in CoMI and CoOL 
than differences, we decided to merge solutions, and coauthor CoMI
with the objective to base it on RESTCONF and target it to low resource 
networks and devices.
The CoOL people also were addressing the management of larger devices 
still connected to low resource networks.
All the additions required for these devices will be part of the 
complementary CoOl specification without burdening the devices that need 
the basics delivered by CoMI.

Accompanying drafts concern specifying mime types, allocating numeric 
identifiers, yang to CBOR encoding, and tools and additions that others 
can describe better.

Hope this helps,
greetings,

Peter

Benoit Claise schreef op 2016-10-18 12:08:
> 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
>>> core@ietf.org
>>> https://www.ietf.org/mailman/listinfo/core
>> .
>> 