Subject: [Cbor] Benoit Claise's No Record on charter-ietf-cbor-00-03: (with COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Thu, 15 Dec 2016 07:03:54 -0800

Benoit Claise has entered the following ballot position for
charter-ietf-cbor-00-03: No Record

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/

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

[ No record for now]
- I have some questions regarding "The CBOR data definition language"
In the world of data modeling-driven management,  we have:
   YANG as a data modeling language, with ABNF specifications
   YANG modules, written with YANG
   different encoding, such as XML, JSON, or CBOR
   and finally protocols such as NETCONF or RESTCONF

Now, in this WG, you want to define a new data modeling language, "The
CBOR data definition language", right?
So the structure of what could be accessed on a managed device, but
without the semantic definition (which is in YANG modules) of data
models? Am I right?
How does it work from a management point of view?

Disclaimer: I haven't read draft-greevenbosch-appsawg-cbor-cdd. I
probably should.

- 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: Carsten Bormann <[email-masked]>
Date: Thu, 15 Dec 2016 18:09:12 +0100

Hi Benoit,

great questions.

Let me try to put in my position on these.

> CBOR data definition language", right?

Yes.

> So the structure of what could be accessed on a managed device,

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

In that sense CDDL is very similar to the use of ABNF for text-based messages, and CDDL indeed was modeled on ABNF as far as that is reasonable for this application.

> and an extensibility model

Ah, that is an interesting terminology problem.

Data interchange formats have (if they are half-way reasonable) a generic data model, into which all specific data models that are being interchanged using that format need to fit.  One of the major innovations of JSON was to make this generic data model simple and reasonably close to what application developers want to interchange.
JSON’s generic data model has never been formally defined (and the finer details are an interesting area of contention!), but most application writers familiar with JSON would be able to define that generic data model to about 99 % precision.
CBOR goes ahead and extends JSON's generic data model (with binary data and with extensibility).
As with JSON, CBOR is not a data modeling language though, so whenever people needed to describe the specific data model used by the messages interchanged from their application, they had to resort to ad-hoc methods.  CDDL is filling in the structural level of that need.

CBOR does not extend JSON’s interchange format — it has its own (binary) one, which is completely different from JSON’s text-based format.

> This is a mistake.

Well, we neglected to make the distinction between the generic data model and the application specific data models here., but I don’t agree with your proposed change.

> Great we will have a new charter to accomplish this
> work
> 

Good point.

Grüße, Carsten

---

From: Benoit Claise <[email-masked]>
Date: Mon, 19 Dec 2016 13:52:17 +0100

Hi Carsten,

Let me reduce this email thread to the terminology issue, as I just file 
a BLOCK regarding my main point.
> Data interchange formats have (if they are half-way reasonable) a generic data model, into which all specific data models that are being interchanged using that format need to fit.
But there is no semantic. So what you call a data interchange format 
here is a basically an encoding, not a data model.

Regards, B.
> One of the major innovations of JSON was to make this generic data model simple and reasonably close to what application developers want to interchange.
> .

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 22 Dec 2016 01:20:31 +0100

On 19 Dec 2016, at 13:52, Benoit Claise <[email-masked]> wrote:
> But there is no semantic. So what you call a data interchange format here is a basically an encoding, not a data model.

Hi Benoit,

there cannot be an encoding unless there is something to encode.
That something is best described by a data model.  
(Interchange formats are often not separating data models and encoding very well.  
That has been a major cause for lots of pain.)

Whether the data model focuses at the level of structural interoperability or it is semantically rooted is not making the former less of a data model.

I’m not aware of any successful use of semantically rooted formal description techniques (FDT) for protocol data models in the IETF, so I’m not even sure what you are aiming at.  Today, semantics are typically described in English.  Structural interoperability is described in ABNF, or in a special purpose FDT (e.g., RFC 4997 formal notation — which is rather advanced as it combines elements of a data model with specialized encoding semantics for stateful compression —, or TLS "presentation language").

(To use the terminology in another context: A YANG model describes a specific data model for data at rest, from which a protocol for manipulating that data is then automatically derived.  This is great, but not all protocols are about manipulating data at rest [that would then also happen to fit into the YANG generic data model].  BTW, YANG models are not semantically rooted either, except for the “semantics” of being able to automatically derive a protocol from the model.)

Grüße, Carsten