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

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 <yang-doctors-bounces@ietf.org> on behalf of Andy Bierman <andy@yumaworks.com>
Date: Monday, December 19, 2016 at 12:27 PM
To: Benoit Claise <bclaise@cisco.com>
Cc: YANG Doctors <yang-doctors@ietf.org>
Subject: Re: [yang-doctors] Fwd: Benoit Claise's Block on charter-ietf-cbor-00-04: (with BLOCK and COMMENT)

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 <bclaise@cisco.com<mailto:bclaise@cisco.com>> 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 <bclaise@cisco.com><mailto:bclaise@cisco.com>

To:

The IESG <iesg@ietf.org><mailto:iesg@ietf.org>

CC:

cbor@ietf.org<mailto:cbor@ietf.org>, cbor-chairs@ietf.org<mailto:cbor-chairs@ietf.org>

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

.

_______________________________________________
yang-doctors mailing list
yang-doctors@ietf.org<mailto:yang-doctors@ietf.org>
https://www.ietf.org/mailman/listinfo/yang-doctors