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

From: "Benoit Claise" <[email-masked]>
Date: Fri, 23 Dec 2016 07:02:32 -0800

Benoit Claise has entered the following ballot position for
charter-ietf-cbor-00-04: 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.)

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

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

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

    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.

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

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