[yang-doctors] Fwd: Benoit Claise's Block on charter-ietf-cbor-00-04: (with BLOCK and COMMENT)

[Benoit Claise <[e-mail]>]

YANG experts,

I would like to understand your from if I missed anything, if I've been 
smoking too much, or if you support this statement.

Regards, B.


-------- Forwarded Message --------
Subject: 	Benoit Claise's Block on charter-ietf-cbor-00-04: (with BLOCK 
and COMMENT)
Date: 	Mon, 19 Dec 2016 04:48:53 -0800
From: 	Benoit Claise <[e-mail]>
To: 	The IESG <[e-mail]>
CC: 	[e-mail], [e-mail]



Benoit Claise has entered the following ballot position for
charter-ietf-cbor-00-04: Block

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.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-cbor/



----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

Sorry for this late BLOCK.
I had a very quick call with Alexey before the last IESG telechat: I want
to understand if I missed anything.
I filed a quick "NO RECORD" COMMENT.
Then, we discussed some more during the telechat itself.
And now, I finally had the time to think some more about this.

My BLOCK is about this charter paragraph:

     Similar to the way ABNF (RFC 5234/7405) can be used to describe the
set of valid messages in a text representation, it would be useful if
protocol specifications could use a description format for the data in
CBOR-encoded messages. The CBOR data definition language (CDDL, based on
draft-greevenbosch-appsawg-cbor-cddl) is a proposal for such a
description technique that has already been used in CORE, ANIMA, CDNI,
and efforts outside the IETF. The CBOR WG will complete the development
of this specification by creating an Informational or Standards Track
RFC.


In OPS, we need automation. And automation will come from data models as,
from data models, we're able to generate APIs.
In the world of data modeling-driven management, we have:
     YANG as a data modeling language, with ABNF specifications
     YANG data modules, written with the YANG data modeling language
     different encodings, such as XML, JSON, or CBOR
(draft-ietf-core-yang-cbor-03)
     protocols such as NETCONF or RESTCONF for
configuration/monitoring/capabilities discovery
     note: working on pub/sub protocol (aka telemetry) for events

See the first picture at
http://www.claise.be/2016/12/yang-opensource-tools-for-data-modeling-driven-management/
Btw, I should add cbor.

Now, in this proposed WG, you want to define a new data modeling
language, "The CBOR data definition language"
When I ask the question: So the structure of what could be accessed on a
managed device?, you answer:

     No. While CDDL could be used to describe the structure of data at
rest (a data store), that is not the objective. CDDL is used to define
the structure of data in flight, e.g. a protocol message going from a
node to a different node. (Using a term popular in semantic
interoperability work in the health care domain, CDDL is about
"structural interoperability” — it can tell you that there is supposed to
be a data item “cheese-firmness” in the message and out of what set of
values it needs to come, but it cannot tell you what the specific values
mean in the real world or what cheese firmness is in the first place on a
semantic level.)


But what about the semantic definition (which is in YANG modules) of this
information? This is key for management.
I guess that the next item you'll want after this milestone is exactly
data models and semantic, right?

There are many schemas for IoT and I'm not trying to impose YANG in the
IoT world but I want to understand why we need duplication.
Note that there was an IAB-organized workshop on IoT data modeling in the
past (https://www.iab.org/activities/workshops/iotsi/)
However, it seems to me that your effort is exactly the reverse of data
modeling driven management? You have an encoding, and then you want a new
schema language

Next, you'll need a mechanism to discover what is available on the
managed devices, a mechanism to know the device capabilities, a mechanism
for pub/sub, ...
And you will redo the full OPS stack, for IoT (hence duplication). And,
obviously, in the end, we will need a mapping between the two data
modeling languages: YANG and CDDL.

What is specific here?  I wanted to write: what's specific to IoT here,
but I don't even see IoT in the charter. There is just a kind of IoT
reference in RFC7049 abstract.
Why do we need this duplication within the IETF?
Why don't draft-ietf-core-yang-cbor and draft-vanderstok-core-comi work?
Those are completely inline with data modeling-driven management and this
charter seems to contradict this effort?
What do I miss?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

OLD:

Concise Binary Object Representation (CBOR, RFC 7049) extends the
JavaScript Object Notation (JSON, RFC 7159) data model to include binary
data
and an extensibility model

NEW:
Concise Binary Object Representation (CBOR, RFC 7049) extends the
JavaScript Object Notation (JSON, RFC 7159) data interchange format to
include binary data
and an extensibility model

Note:
- In OPS, we make a clear distinction between the (YANG) data model, and
the encoding (XML, JSON, etc.)
- RFC 7159 mentions "data interchange format" in his abstract
- I see in RFC 7049:
    The format defined here follows some specific design goals that are
    not well met by current formats.  The underlying data model is an
    extended version of the JSON data model [RFC4627].
This is a mistake. Great we will have a new charter to accomplish this
work

- And don't forget the milestones.

Regards, Benoit


.