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

[Andy Bierman <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> on behalf of Andy
> Bierman <[e-mail]>
> *Date: *Monday, December 19, 2016 at 12:27 PM
> *To: *Benoit Claise <[e-mail]>
> *Cc: *YANG Doctors <[e-mail]>
> *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 <[e-mail]> 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 <[e-mail]> <[e-mail]>
>
> *To: *
>
> The IESG <[e-mail]> <[e-mail]>
>
> *CC: *
>
> [e-mail], [e-mail]
>
>
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/yang-doctors
>
>
>