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

[Benoit Claise <[e-mail]>]

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

Regards, Benoit

> Hi Benoit,
>
> On Mon, Dec 19, 2016, at 12:48 PM, Benoit Claise wrote:
>> 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
> Yes, the same way there are several schema languages for XML (for
> example).
>
>> 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.
> I am not convinced that the mapping would be needed in all cases. See
> below.
>
>> 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?
> I don't think saying that CBOR is only for IoT is helpful. There is some
> talk about using it for PKIX-like things. I can also see it being used
> directly in protocols. There is no YANG there, because there are no
> devices to manage, just a data structure. I don't think YANG is going to
> be helpful there.
>
> 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.
>
>> 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?
> .
>