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

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

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 <[email-masked]>
To: 	The IESG <[email-masked]>
CC: 	[email-masked], [email-masked]

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: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 19 Dec 2016 14:21:47 +0100

> smoking too much, or if you support this statement.

Smoking? I expected perhaps a drink too much. ;-)

There is one point I like to make, well perhaps two...

a) In YANG, we do not really have a way to define just a data
   structure, i.e., a message format. Everything is more or less tied
   to the notion of datastores. We have tried to work around this a
   couple of times but as of today we do not have first class support
   for plain data structures. What CDDL is focussing on right now is
   plain data structures (e.g. message formats) and hence the starting
   point is different (but yes if CDDL gains traction, then they will
   be sooner or later look at the other things YANG does cover
   reasonably well today).

b) Encodings and definition languages for encodings come and go. Are
   you planning to 'block' all of them? Is it worth it or is perhaps
   cheaper to let them go? When we brought YANG to the IETF, this was
   not immediately liked because there were already other data
   definition languages. On second try, we managed to get a working
   group and it seems we had luck to create something that got
   traction. Are we now in the position to block others (like others
   were trying to block us a couple of years ago)?

That written, it might be useful to ask for a concise statement why
YANG and YANG to CBOR is not providing what is needed.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Robert Varga -X (rovarga - PANTHEON TECHNOLOGIES at Cisco)" <[email-masked]>
Date: Mon, 19 Dec 2016 13:32:30 +0000

> -----Original Message-----
> From: yang-doctors [mailto:[email-masked]] On Behalf Of
> Juergen Schoenwaelder
> Sent: Monday, December 19, 2016 2:22 PM
> To: Benoit Claise (bclaise) <[email-masked]>
> Cc: YANG Doctors <[email-masked]>
> Subject: Re: [yang-doctors] Fwd: Benoit Claise's Block on charter-ietf-cbor-00-
> 04: (with BLOCK and COMMENT)
> 
> > I would like to understand your from if I missed anything, if I've
> > been smoking too much, or if you support this statement.
> >
> 

For what it's worth in ODL we use notifications to model individual protocol messages. These instantiate groupings, which are also instantiated in the datastores, providing the ability to move structured data between the two.

>    were trying to block us a couple of years ago)?

Encodings are not really a problem, different languages (with unaligned metamodels) tend to create barriers to adoption.

Regards,
Robert

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 19 Dec 2016 14:36:05 +0100 (CET)

"Robert Varga -X (rovarga - PANTHEON TECHNOLOGIES at Cisco)" <[email-masked]> wrote:
> For what it's worth in ODL we use notifications to model individual
> protocol messages. These instantiate groupings, which are also
> instantiated in the datastores, providing the ability to move
> structured data between the two.

And we're using an extension called tailf:structure.  The drawback
with using an extension for this is that it cannot be augmented with
standard "augment".  So it needs to be added to the core YANG
language.

/martin

> Encodings are not really a problem, different languages (with
> unaligned metamodels) tend to create barriers to adoption.
> 
> Regards,
> Robert
> 
> _______________________________________________
> yang-doctors mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yang-doctors
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 19 Dec 2016 15:13:27 +0100

> On 19 Dec 2016, at 14:32, Robert Varga -X (rovarga - PANTHEON TECHNOLOGIES at Cisco) <[email-masked]> wrote:
> 

Right, because XML, JSON and CBOR are not just different encodings, so, for example, XML schema languages might be a good choice for XML but are of no use for JSON and CBOR.

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Mon, 19 Dec 2016 09:27:39 -0800

Hi,

We also have a proprietary system for describing protocol messages,
internal data structures, model of XRD for RESTCONF, etc.
Sometimes this is done with plain YANG modules including augment.
If the server does not advertise the module then the client cannot get
fooled by the misuse of YANG.

It would be useful to have a standard way of defining YANG data structures.

The CORE WG is very divided about using YANG.
(Look at SenML for example!)
YANG is too heavyweight for sensors and actuators, and many view IoT
and nothing more than that.

The work that concerns me is SID, which attempts to use a single uint32
to identify every possible schema node in every possible module into
a 1-dimensional numbering space.  It is not an accident that identifiers
in SMIv2 or YANG are based on immutable properties of the language.
It is very risky to base the naming scheme on properties that can change
from release to release. The client and server must agree on the conceptual
managed objects. It can be very hard to detect bugs of this nature.

Read their draft and see what you think:
https://datatracker.ietf.org/doc/draft-ietf-core-sid/

On Mon, Dec 19, 2016 at 4:54 AM, Benoit Claise <[email-masked]> wrote:

> From: Benoit Claise <[email-masked]> <[email-masked]>
> To: The IESG <[email-masked]> <[email-masked]>
> The document, along with other ballot positions, can be found here:https://datatracker.ietf.org/doc/charter-ietf-cbor/
>
>
>
> See the first picture athttp://www.claise.be/2016/12/yang-opensource-tools-for-data-modeling-driven-management/
> Btw, I should add cbor.
>

---

From: Kent Watsen <[email-masked]>
Date: Tue, 20 Dec 2016 19:05:54 +0000

This is the issue I raised during the NETCONF session in Seoul.  Both the zerotouch and the voucher drafts are currently using a YANG module to define a data structure, which they claim is encoded the same as if returned by a RESTCONF server using a GET request with a URL to the specific resource.

I still need to formally raise this as an issue blocking these drafts, but assuming we are able to resolve this YANG mapping issue, and there already exists a CBOR encoding, then I wonder if this would be sufficient and negate the need to define CDDL.

Kent

From: yang-doctors <[email-masked]> on behalf of Andy Bierman <[email-masked]>
Date: Monday, December 19, 2016 at 12:27 PM
To: Benoit Claise <[email-masked]>
Cc: YANG Doctors <[email-masked]>
Subject: Re: [yang-doctors] Fwd: Benoit Claise's Block on charter-ietf-cbor-00-04: (with BLOCK and COMMENT)

Hi,

On Mon, Dec 19, 2016 at 4:54 AM, Benoit Claise <[email-masked]<mailto:[email-masked]>> wrote:
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 <[email-masked]><mailto:[email-masked]>

To:

The IESG <[email-masked]><mailto:[email-masked]>

CC:

[email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

BLOCK:

RFC.

See the first picture at

Btw, I should add cbor.

semantic level.)

schema language

for pub/sub, ...

What do I miss?

COMMENT:

OLD:

data

NEW:

include binary data

Note:

- I see in RFC 7049:

work

Regards, Benoit

.

_______________________________________________
yang-doctors mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/yang-doctors

---

From: Andy Bierman <[email-masked]>
Date: Tue, 20 Dec 2016 11:23:08 -0800

Hi,

Did you read this draft?

https://www.ietf.org/id/draft-greevenbosch-appsawg-cbor-cddl-09.txt

Kind of a toy compared to YANG.
e.g., no concept of modules, revisions, interactions between modules.

However, I do not want to go back to "DML beauty contest" mode
like we had before YANG.

Ironically, APPS area originally blocked YANG because they already had DSDL.
Now they are working on a tinker-toy language that is just for CBOR
encoding?

This draft does not impact YANG.  There is a YANG to CBOR draft in progress.
(It doesn't actually work, but maybe it can be fixed)

CDDL would be a separate unrelated language that also happens to have a
CBOR encoding.
Obviously YANG advocates do not think we need both, but I prefer to let
IETFers
flail in their own sandbox, rather than take away their sand.

Andy

On Tue, Dec 20, 2016 at 11:05 AM, Kent Watsen <[email-masked]> wrote:

> This is the issue I raised during the NETCONF session in Seoul.  Both the
> zerotouch and the voucher drafts are currently using a YANG module to
> define a data structure, which they claim is encoded the same as if
> returned by a RESTCONF server using a GET request with a URL to the
> specific resource.
>
>
>
> I still need to formally raise this as an issue blocking these drafts, but
> assuming we are able to resolve this YANG mapping issue, and there already
> exists a CBOR encoding, then I wonder if this would be sufficient and
> negate the need to define CDDL.
>
>
>
> Kent
>
>
>
>
>
> *From: *yang-doctors <[email-masked]> on behalf of Andy
> Bierman <[email-masked]>
> *Date: *Monday, December 19, 2016 at 12:27 PM
> *To: *Benoit Claise <[email-masked]>
> *Cc: *YANG Doctors <[email-masked]>
> *Subject: *Re: [yang-doctors] Fwd: Benoit Claise's Block on
> charter-ietf-cbor-00-04: (with BLOCK and COMMENT)
>
>
>
> Hi,
>
>
>
> *Subject: *
> *Date: *
> *From: *
> Benoit Claise <[email-masked]> <[email-masked]>
>
> *To: *
>
> The IESG <[email-masked]> <[email-masked]>
>
> *CC: *
>
> [email-masked], [email-masked]
>
>
>

---

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

Dear all,

The point behind this BLOCK (btw, I never liked the BLOCK term; I prefer 
DISCUSS, like for documents) was to get different view points regarding 
this proposed CBOR maintenance and extensions charter.
Thank you for sharing your views.  This was exactly what was expected 
from this group.

Enjoy your Christmas break, if you take one.

Regards, Benoit