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

From: "Benoit Claise" <[email-masked]>
Date: Thu, 13 Oct 2016 05:18:38 -0700

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

---

From: peter van der Stok <[email-masked]>
Date: Thu, 13 Oct 2016 15:58:00 +0200

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:
> Please refer to 
> https://www.ietf.org/iesg/statement/discuss-criteria.html
<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>
> draft-ietf-core-etch, I guess?
<pvds>
YES, but not exclusively.
</pvds>
>                  encodings: JSON, CBOR, XML, EXI
<pvds>
I am sure Carsten can elaborate on those in more detail
For my part, you are absolutely correct.
</pvds>
> 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>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Benoit Claise <[email-masked]>
Date: Tue, 18 Oct 2016 12:08:24 +0200

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
> CoMI will be the basis that uses FETCH, PATCH, iPATCH; CoOL will 
> expand on that
> </pvds>
>>
> .

---

From: peter van der Stok <[email-masked]>
Date: Wed, 19 Oct 2016 08:03:16 +0200

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