Concise Binary Object Representation Maintenance and Extensions
charter-ietf-cbor-03

[Ballot comment]
The paragraph "The CBOR working group will update RFC 7049 ..." feels like it might now be out of date given that RFC 7049-bis is already in the RFC editor queue.

[Ballot comment]
The purpose of this recharter is to change "add to a second edition of the specification" to "progress them either in a standalone document or as part of a a second edition of the specification", giving the working group flexibility in document organization.  (There are also minor editorial changes to the last paragraph of the charter.)  I do not think this needs External Review.

The purpose of this recharter is to change "add to a second edition of the specification" to "progress them either in a standalone document or as part of a a second edition of the specification", giving the working group flexibility in document organization.  (There are also minor editorial changes to the last paragraph of the charter.)  I do not think this needs External Review.

The purpose of this recharter is to change "add to a second edition of the specification" to "progress them either in a standalone document or as part of a a second edition of the specification", giving the working group flexibility in document organization.  (There are also minor editorial changes to the last paragraph of the charter.)  I do not think this needs External Review.

[Ballot comment]
The last block of new text since the last time I looked at this is a bit jumbled.
Nits below.

> The working group will evaluate such requests individually and decide about
> adoption and milestones in that event. Proposals that are deemed to be out

In which event? Suggest: "...as such requests arise" or similar.

> of scope for the working group, e.g. because they are too narrow purpose

Nit: "e.g.," (add a comma). Even better, replace with "for example"

Nit: "narrow-purpose"

> specifications, may still be published as individual submission or in

Nit: "of a specification" (or remove "specifications" altogether)

Nit: "as an individual submission" or "as individual submissions"

> another groups if there is a specific need. The CBOR group will review these

Nit: "another group" or "other groups"

> proposals on request.

[Ballot comment]
I support Mirja's second DISCUSS item.  I'd add to it that the distinction between "Internet-wide" and "Narrow purpose" is also not clear to me.  In particular, I'm not sure why "Narrow purpose" couldn't also be published through the ISE.

[Ballot comment]
I also agree with Mirja's second point, and with Alvaro's note that examples
of WG adoption work better when they are actually WG-adopted documents.

The enumeration of potential inputs to the DISPATCH-like process seems potentially
quite broad, though I suppose that need not translate to "approval" or adoption  by
the WG.

I found the wording confusing in some parts of the charter, such as "collect these
features", the treatment of CDDL evolution as a "sequence of editions", and what
makes an "Internet wide [sic]" specification.

  This work would not be expected to be published by the IETF.

"as an RFC", presumably?

[Ballot block]
Not sure if my two points justify a block, so I'm happy to change my position if other ADs tell me to, but I'm also not certain if I want to go for "No Objection".

Here are my points:

1) First on this:
"After that, the CBOR working group will monitor issues found with the CBOR specification
and, if needed, will produce an updated document."
This intention seems to contradict the idea of an Internet Standard in RFC2026 a bit:
  "A specification for which significant implementation and successful
  operational experience has been obtained may be elevated to the
  Internet Standard level.  An Internet Standard (which may simply be
  referred to as a Standard) is characterized by a high degree of
  technical maturity and by a generally held belief that the specified
  protocol or service provides significant benefit to the Internet
  community."
Maybe this is nit-picking but if the group is not sure if there are further issue, one should probably simply not push for Internet Standard...

2) I find the later part of the charter rather generic (starting which "There are a number of additional CBOR tagged types..."). I also don't really understand the difference of "General purpose" and "Internet-wide". These are two different aspects for me that don't exclude each other. I would rather like to see a charter that actually limits the technical scope rather than talking about a generic process (that may or could be or is applied in other groups as well).

[Ballot comment]
Hello,

I have few comments:

* why only mention verified errata? what about "held for document update" type of errata? I also note there are 4 Reported errata. A more general sentence could be: "The CBOR working group will update RFC 7049 based on existing errata."

* I find "popular" a bit subjective. Is that really needed?

* s/a Full Internet Standard/an Internet Standard/

Thank you
-m

[Ballot block]
This is a "DISCUSS-discuss" style block, in the spirit of backing up and making sure we're making the right overall decision here.

I'd like us to have a short conversation about whether it makes sense for the CDDL work to continue in the CBOR working group. Given that it has been rescoped and renamed to be a more general-purpose schema language covering not just CBOR, but the much broader JSON universe, it seems that this work is extremely likely to have a broad constituency outside of those people who typically participate in working groups that focus on IoT use-cases. Keeping it part of CBOR does not seem to serve that community well.

Should we consider splitting the CDDL update and maintenance work off into a separate working group, rather than rechartering CBOR with the rather significant expansion considered in this charter proposal?

[Ballot comment]
I have a couple of editorial suggestions:

(1) The charter talks about "using a DISPATCH like process".  While most people might have an idea of what that is, I think mentioning it is not necessary.

(2) The first category is:

  General purpose specifications that are expected to have broad usage: The
  working group will normally adopt and publish such proposals. Examples of
  proposals in this category are CBOR Sequence media type
  (draft-bormann-cbor-sequence) and Error Indications tag
  (draft-richter-cbor-error-tag).

It would be nice if the examples of WG adoption were adopted documents.  I think the description is enough -- let the WG decide if these are this type of documents.

(3) Similarly, in the third category... "An example of this might be portions of draft-bormann-cbor-tags-oid..."  The tentative language is not great, even for an example.

[Ballot comment]
Nit: "a mechanism other that" should be "a mechanism other than".

"and add to a second edition of the specification if warranted" ... presumably this is in the re-charter because it *is* warranted.  I suggest removing "if warranted".

"The body of existing specifications that make use of CDDL is considered precious":  Awwwwwwwww...  :-)

"It is currently expected that this would be done using a Wiki of some type. This work would not be expected to be published by the IETF."  Yayyyyy!  Thanks.

Nit: that are either currently adopted by the working group, by other working groups, or as individual submissions" is not a parallel list.  Maybe, "that are currently adopted by the working group, are work items in other working groups, or exist as individual submissions."  Also, I suggest removing the paragraph break between this paragraph and the next.

Nit: "Internet wide specifications" needs a hyphen: "Internet-wide specifications".

[Ballot 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

[Ballot 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?

[Ballot 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

[Ballot 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

[Ballot comment]
I saw the answer to Stephen's "what is GRASP" question in the Internet Review ballot, but I'm still not sure why it's necessary to say "ANIMA GRASP" in this charter. For the parallel case in CORE, the WG name is provided, but no detail beyond that. If I knew what GRASP was without having to look back at Stephen's ballot thread, I wouldn't mention this, of course ... but I wonder how many other readers will have to look it up, too!

[Ballot comment]

Were this being proposed for approval, I would be balloting
a BLOCK so I'd like to understand the issue below before
we get there, if at all possible.

- What is GRASP?

- As I think of it, COSE did not really adopt CBOR, but
is an ancillary part of CBOR. For example, it would be
impossible for COSE to be COSE and choose something
that is not CBOR:-) So there was no "adoption" step
ever, for COSE.

- COSE did not "successfully" use CDDL IMO. The CDDL
text there is specifically stated to be non-normative, and
its inclusion was controversial during the WG process.

The above seems to me to mean that the level of
interest claimed for CBOR/CDDL is not justified by the
charter text.

And the reason that raises to a possible BLOCK
ballot for me is that such enthusiasm, while understandable,
doesn't seem to go well with the last part of the charter.
"Where these proposals are deemed useful" just seems
too likely to happen if I'm to judge by the overly
positive "spin" in the current charter language. (Note
that "spin" isn't meant pejoratively there, it's quite
fine that the proponents of this are proponents of
this:-)

I think the solution here is to provide more evidence
of the claimed level of interest in CBOR/CDDL That could be
done in the charter text but may be fine if only done in
the email discussion leading up to that. And toning down
the language would help too. (Note that fixing errata
in CBOR isn't a problem but by itself wouldn't justify
a WG.)

[Ballot comment]
Given that

"Where these proposals are
deemed useful and do not require significant new development, the CBOR WG will
complete these specifications as well."

is describing a limited license for the working group for two proposals, I found myself wondering if there might be other proposals that are deemed useful and don't require significant new development, that the charter might allow without requiring rechartering. Maybe something like

"Where these CBOR extensions, or other CBOR extension proposals are
deemed useful and do not require significant new development, the CBOR WG will
complete these specifications as well."

? But if you want the charter to be tight in this respect, the current text is fine.

[Ballot comment]
What is meant by "RFC that can be used as a normative reference in a protocol
specification"? If this means standards track or BCP--if so, why not say that?

[Ballot comment]
Quick question out of curiosity: Is this wg intended to be a short term effort that will closed after publishing the named docs or is the plan to eventually add more stuff for long term maintenance or is that no clear yet?