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

From: "Benoit Claise" <[email-masked]>
Date: Mon, 19 Dec 2016 04:48:53 -0800

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

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 19 Dec 2016 15:18:51 +0000

Hi Benoit,

> https://datatracker.ietf.org/doc/charter-ietf-cbor/

Yes, the same way there are several schema languages for XML (for
example).

> modeling languages: YANG and CDDL.

I am not convinced that the mapping would be needed in all cases. See
below.

> Why do we need this duplication within the IETF?

I don't think saying that CBOR is only for IoT is helpful. There is some
talk about using it for PKIX-like things. I can also see it being used
directly in protocols. There is no YANG there, because there are no
devices to manage, just a data structure. I don't think YANG is going to
be helpful there.

I am Ok with having some text in CDDL saying that if you want to do
modeling-driven device management, CDDL is not the right tool. But as I
said above I see other uses for CBOR/CDDL, which should be allowed.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Dec 2016 08:38:53 +1300

H Benoit,
> charter-ietf-cbor-00-04: Block

...
> IoT world but I want to understand why we need duplication.

What duplication? I am a CDDL user and in fact it is a normative reference
for the GRASP protocol spec. It is the best way to objectively specify
CBOR message formats without either very complicated and error-prone English
or embedding pages of ABNF. In fact it is roughly speaking an ABNF vocabulary.
It's a method of syntax definition, which like ABNF doesn't express semantics.
It's orthogonal to YANG in purpose and capability. As an example:

   In fragmentary CDDL, every GRASP message follows the pattern:

     grasp-message = (message .within message-structure) / noop-message

     message-structure = [MESSAGE_TYPE, session-id, ?initiator,
                          *grasp-option]

     MESSAGE_TYPE = 1..255
     session-id = 0..4294967295 ;up to 32 bits
     grasp-option = any

If I was deprived of CDDL, I would never consider YANG as an alternative.
I'd simply have to write an appendix for the GRASP spec that defines all
the parts of CDDL that I need.

BTW this has nothing in particular to do with IoT. It's a very general tool,
but for a completely different purpose than YANG.

Regards
    Brian

---

From: Joe Hildebrand <[email-masked]>
Date: Mon, 19 Dec 2016 13:24:10 -0700

> On Dec 19, 2016, at 12:38 PM, Brian E Carpenter <[email-masked]> wrote:
> 

+1.  Not everything is YANG.  CDDL is for some of those things.

-- 
Joe Hildebrand

---

From: Benoit Claise <[email-masked]>
Date: Fri, 23 Dec 2016 15:53:00 +0100

Thanks Brian,

This is useful.

Regards, Benoit
> .

---

From: Benoit Claise <[email-masked]>
Date: Fri, 23 Dec 2016 16:01:10 +0100

Thanks to all who educated me, in the different email threads.

Moving back to a COMMENT at this point in time.
As Alexey mentioned, some more wording about this in the charter would 
help (if nobody else, at least me):

In the end, I missed the key message that CDDL is more helpful for 
horizontal protocol to support device-to-device communication, as 
opposed to a management protocol. I've been probably too biased by my 
OPS background :-)

Regards, Benoit