Subject: [Cbor] 🔔 Confirmation call for Working Group Adoption for draft-greevenbosch-appsawg-cbor-cddl

From: Francesca Palombini <[email-masked]>
Date: Wed, 5 Jul 2017 09:48:29 +0000

Hi all,

At the IETF98 meeting, we had in-room consensus to adopt draft-greevenbosch-appsawg-cbor-cddl as a starting point to work on CBOR data definition language. The authors have now updated the document and feel this is ready to be a wg item.

This is a confirmation call for adopting this draft as a working group item. If you do not agree with the in-room consensus that we had in Chicago to adopt this as a WG document, please speak up until 2017-07-19. If you weren’t in the room but do agree with adopting this document, you can also tell us.

https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-11

Thanks,
Francesca

---

From: Jeffrey Yasskin <[email-masked]>
Date: Sun, 9 Jul 2017 07:36:06 -0700

The Chicago minutes [1] talk about people using CDDL to write
specifications, but the -11 document is on the informational track
rather than the standards track, meaning, I believe, that it's not
intended to be referenced normatively from specifications. If folks do
want to be able to use CDDL from standards, would the draft need to
change tracks before it becomes a working group item?

If it can change tracks later, then I definitely support adopting it
as a starting point. If adopting it freezes it as informational, then
I'm concerned, however much that counts from a newbie. :)

Thanks,
Jeffrey

[1]: https://mailarchive.ietf.org/arch/msg/cbor/HrfvEralF6mjmO4uK7ZZrz7n7uE/?qid=5a4cfef2594f32f86b5eea519fbbabd0

On Wed, Jul 5, 2017 at 2:48 AM, Francesca Palombini
<[email-masked]> wrote:
> Hi all,
>
>
>
> At the IETF98 meeting, we had in-room consensus to adopt
> draft-greevenbosch-appsawg-cbor-cddl as a starting point to work on CBOR
> data definition language. The authors have now updated the document and feel
> this is ready to be a wg item.
>
>
>
> This is a confirmation call for adopting this draft as a working group item.
> If you do not agree with the in-room consensus that we had in Chicago to
> adopt this as a WG document, please speak up until 2017-07-19. If you
> weren’t in the room but do agree with adopting this document, you can also
> tell us.
>
>
>
> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor
>

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 9 Jul 2017 18:03:08 +0200

On Jul 9, 2017, at 16:36, Jeffrey Yasskin <[email-masked]> wrote:
> If folks do

Yes.  That is not unusual; documents often change the track even when they already are in IESG processing.

> I'm concerned, however much that counts from a newbie. :)

I don’t think the WG has to make the choice (that I talked about the in the previous message) now with adoption.  On the other hand, the purpose of this work is to make the CDDL document a referenceable specification language specification.  For ABNF, this was solved by making the spec language spec itself standards track (starting with RFC 2234 in November 1997, after ABNF had been in use for two decades (*)).  Putting out an informational document on the downref list (**) is more circuitous, but would have the same effect.  

(I would prefer to use RFC 2234/4234/5234 as a model here as much as possible, maybe with the exception of waiting 20 years before standardizing :-).)

Grüße, Carsten

(*) Starting with RFC 733 in November 1977, I think; although older BNF variants had been in use since 1968 (RFC 31). 
(**) https://trac.ietf.org/trac/iesg/wiki/DownrefRegistry

---

From: Michael Richardson <[email-masked]>
Date: Sun, 09 Jul 2017 16:11:04 -0400

> change tracks before it becomes a working group item?

I didn't think that CDDL would always require a normative reference from a
standards track document.

My feeling is that if the structures are relatively simple that the CDDL is
self-describing.  Most readers and implementers won't need to go further.

I guess the question is what happens when more advanced constructs are
needed.  In that case, I guess a normative reference would be required,
and then the question would indeed arise.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 9 Jul 2017 22:37:43 +0200

> self-describing.  Most readers and implementers won't need to go further.

I agree with the sentiment — but that’s not what happened with COSE (RFC 8152); IESG is going to insist on either duplicating all the normative content that uses CDDL, in another format (read: plain English (*)), or having a normative reference for CDDL.  I cannot really disagree with that from a formal point of view, so let’s make that happen.

Grüße, Carsten

(*) I seriously started writing a CDDL to “plain English” converter, but then the situation defused a bit when the WG almost unanimously decided they wanted to have the CDDL in the main document.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 Jul 2017 08:42:57 +1200

> self-describing.  Most readers and implementers won't need to go further.

Unfortunately I don't think that's correct. It isn't just ABNF; there are
implied semantics in the constructs. For draft-ietf-anima-grasp, this is
the draft appendix I came up with to define the subset we use:

1. CDDL is expressed in ASCII characters.
2. Data items have identifiers. An identifier is a contiguous sequence of case-sensitive letters,
   digits, underscores ("_") and hyphens ("-") starting with a letter.
3. A comment is any text starting with a semi-colon (";") until the end of the line
4. Decimal integers have their normal meaning.
5. Text strings are enclosed by double quotation '"' characters.
6. The operator "=" means that the data item on its left is defined by the expression on its right.
7. The operator "/=" means that the data item on its left MAY be defined by the expression on its right.
In an expression:
8. Parentheses ("(", ")") delimit a syntactic unit.
9. Brackets ("[", "]") delimit a CBOR array.
10. In a CBOR array, items are separated by commas (",").
11. The prefix operator "+" indicates an item that occurs at least once.
12. The prefix operator "?" indicates an item that occurs zero or more times.
13. The infix operator "/" indicates a choice.
14. The infix operator ".." indicates an inclusive range.
15. The datatype name "bytes" indicates a byte string item
16. The datatype name "text" indicates a UTF-8 character string item.
17. The datatype name "uint" indicates an unsigned integer.
18. The datatype name "any" indicates any valid CBOR item.
19. The annotation ".size" precedes the size of a data item.
20. The annotation ".bits" precedes the bit number selected in a data item.
21. The annotation ".within" indicates that the data item on its left is subsetted from the item on its right.
22. "null" means a null value.

    Brian

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 10 Jul 2017 00:45:28 +0200

Hi all,

I have personal knowledge coming from commercial and IETF parties and 
other SDO that would like to use "CDDL instead of english" to create 
normative content and that this course of action would be "very 
appreciated" to say at the least.

I will bring this up. I cannot project the opinion of the group, but I 
am cautiously optimistic and from my personal point of view I feel 
sympathetic with the effort and will support it.

Viele Grüße,

Henk

---

From: "Matthew A. Miller" <[email-masked]>
Date: Tue, 18 Jul 2017 11:22:51 +0200

On 7/5/17 11:48 AM, Francesca Palombini wrote:
> data definition language. The authors have now updated the document and
> feel this is ready to be a wg item.
> 
>  
> 
> This is a confirmation call for adopting this draft as a working group
> item. If you do not agree with the in-room consensus that we had in
> Chicago to adopt this as a WG document, please speak up until
> 2017-07-19. If you weren’t in the room but do agree with adopting this
> document, you can also tell us.
> 
>  
> 

I re-iterate my support for adopting this draft as a working group item.

I also support moving this document to the Standards Track.

- m&m

Matthew A. Miller
< http://goo.gl/LM55L >

---

From: "Kepeng Li" <[email-masked]>
Date: Tue, 18 Jul 2017 17:29:06 +0800

I support for adopting this draft as a working group item.

Kind Regards
Kepeng

---

From: Sean Leonard <[email-masked]>
Date: Wed, 19 Jul 2017 08:50:04 -0700

As expressed at the IETF 99 meeting, I support WG adoption of this draft.

At this time, I also support it being on the Informational track (its current track). The track can be changed later if needed.

Sean

> On Jul 5, 2017, at 2:48 AM, Francesca Palombini <[email-masked]> wrote:
> 
> Hi all,
>  
> https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-11 <https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl-11>
>  
> Thanks,
> Francesca

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Jul 2017 13:26:55 +1200

> As expressed at the IETF 99 meeting, I support WG adoption of this draft.

Yes

> At this time, I also support it being on the Informational track (its current track). The track can be changed later if needed.

It's needed now. The IESG just approved at least one draft that has it as
a normative reference. How else do you plan to precisely specify CBOR
message formats?

    Brian

---

From: "Matthew A. Miller" <[email-masked]>
Date: Thu, 20 Jul 2017 13:25:49 +0200

> a normative reference. How else do you plan to precisely specify CBOR

I agree, and the practical work to convert from informational to
standards track is a single line change in the source.  I suggest the
chairs tell the authors/editors make that change to the
"draft-ietf-cbor-cddl-00" they submit.

- m&m

Matthew A. Miller
< http://goo.gl/LM55L >

---

From: Sean Leonard <[email-masked]>
Date: Thu, 20 Jul 2017 07:03:48 -0700

> On Jul 19, 2017, at 6:26 PM, Brian E Carpenter <[email-masked]> wrote:
> 

“Need” is a very subjective word. It is nice to have. It is better to have a stable reference. But “stable references” are also harder to make technical changes to as more people rely on it and come up with arguments for how things can never change because they already wrote/deployed stuff.

It’s not just the documents that reference this one: it’s also the documents that CDDL references. By way of example, CDDL depends on regular expressions, and specifically calls out PCRE. PCRE is great but is in no way a Standard; it’s a single implementation. There is a lot of variation in regular expression engines, and the most useful ones (thinking about PCRE, Python, Perl, and .NET) are not SDO standards. There are some features in this draft that have not even been implemented yet.

There are other examples of documents (most notably, JSON) that started off as Informational and got promoted to Standards Track later.

CDDL is descriptive (data description language), rather than prescriptive. Sections 4.1 and 4.2. It currently falls far more into the Markdown-esque side of things (Postel’s Law), rather than the XML schema-esque side of things (all errors are fatal). “The matter in how far the data description must be enforced by an application is left to the designers and implementers of that application […].” This is a Good Thing. One glaring point is that a CDDL grammar does not exclusively define all possibilities. You can define a struct with members {foo: tstr, bar: tstr, baz: uint} in CDDL. What if the data contains {foo: “a”, bar: “b”, baz: 6, fred: ‘ffdeff’} ? What if you have {foo: -1}? CDDL doesn’t say whether those are fatal errors. That’s okay, Postel’s law and all. It means that a CDDL processor can be implemented in far less code for resource-constrained devices. But there may be very serious security considerations.

For now, you can precisely define your CBOR message format using prose. Or you can use some combination of CDDL and prose. Just reference CDDL informatively.

As has been pointed out, it’s a one-line change, and it can be done later.

Best regards,

Sean

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 20 Jul 2017 16:16:52 +0200

On Jul 20, 2017, at 16:03, Sean Leonard <[email-masked]> wrote:
> 
> For now, you can precisely define your CBOR message format using prose.

The point of creating this WG and chartering it with completing the CDDL spec was that that frustrating exercise shall no longer be needed, just as ABNF has solved the same problem for textual protocols.

After reading your message, I still have no idea why you don’t want us to do this.

(Re the one substantive comment about PCRE: That family of languages is definitely more well-defined than the family known as "English language”.  If you think we need to point a spec, we can always use ECMA 262; I don’t think we need all of PCRE.  We could also remove the .regexp control, but I think it is too useful to do that.  We maybe should add a warning that specifiers should avoid the weird ends of PCRE.  None of this is relevant to the question at hand, WG adoption.)

Grüße, Carsten

---

From: Sean Leonard <[email-masked]>
Date: Thu, 20 Jul 2017 07:22:19 -0700

> On Jul 20, 2017, at 7:16 AM, Carsten Bormann <[email-masked]> wrote:
> 

That was not my full quote. I wrote: “For now, you can precisely define your CBOR message format using prose. Or you can use some combination of CDDL and prose. Just reference CDDL informatively.” Since that is what the current CDDL draft itself says: “The matter in how far the data description must be enforced by an application is left to the designers and implementers of that application […].” 

On the original point of this thread, I continue to support WG adoption.

Regards,

Sean

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 20 Jul 2017 16:25:55 +0200

> That was not my full quote. I wrote: “For now, you can precisely define your CBOR message format using prose. Or you can use some combination of CDDL and prose. Just reference CDDL informatively.”…

Which variation includes the use of CDDL as the exact specification of the data exchanged.
For this to be possible, the CDDL language spec must be standards track or downref-enabled informational.
The latter is a bit circuitous — if the point is being normative, we might as well make it standards track.

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Jul 2017 16:25:07 +1200

On 21/07/2017 02:03, Sean Leonard wrote:
> “Need” is a very subjective word. It is nice to have. 

No, I said "need" and I meant "need". A normative reference is a need.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Fri, 21 Jul 2017 12:05:22 +0200

Between starting this email, and pushing send, I went to find RFC-editor.
She happened to be sitting with the AD responsible for GRASP.  Both said
that the downref would be permitted only when the use of CDDL was very
loose.  Otherwise, it would be a problem.

I feel strongly that we need it to be standards track.

Sean Leonard <[email-masked]> wrote:
    >     It's needed now. The IESG just approved at least one draft that has
    > it as a normative reference. How else do you plan to precisely specify
    > CBOR message formats?

    > “Need” is a very subjective word. It is nice to have. It is better to
    > have a stable reference. But “stable references” are also harder to
    > make technical changes to as more people rely on it and come up with
    > arguments for how things can never change because they already
    > wrote/deployed stuff.

This doesn't matter for CDDL the way it does for, i.e. IPv6.

A specification is going to reference a *SPECIFIC* version of CDDL, and
it just fine if we make changes in a new version.  We do need an annotation
for the compilers/checkers/, etc. what version they should process, but
for the purposes of referencing CDDL, we do not have to worry if
it changes afterwards.

    > It’s not just the documents that reference this one: it’s also the
    > documents that CDDL references. By way of example, CDDL depends on
    > regular expressions, and specifically calls out PCRE. PCRE is great but
    > is in no way a Standard; it’s a single implementation. There is a lot
    > of variation in regular expression engines, and the most useful ones
    > (thinking about PCRE, Python, Perl, and .NET) are not SDO
    > standards. There are some features in this draft that have not even
    > been implemented yet.

The lack of a specification for PCRE sounds like a more serious problem
regardless of the status we intend for the document.

    > For now, you can precisely define your CBOR message format using
    > prose. Or you can use some combination of CDDL and prose. Just
    > reference CDDL informatively.

That just isn't useful.
If you tell us to use prose, then our next step will be to write a
specification so that we don't have to be so imprecise.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Sean Leonard <[email-masked]>
Date: Fri, 21 Jul 2017 03:38:18 -0700

Michael, the underlying concern/fear that I have about this CDDL work, remains that despite it being nascent, people will immediately complain that such-and-such features of CDDL can never change because they already wrote stuff. 

Better to get it right, and that means, at this stage, that all features of the language are up for grabs.

(Even in writing this, I’m fully aware that the basic structures, namely vector, record, table, and struct, are very unlikely to change. But some of the unlikeliness will undoubtedly be due to people saying they already wrote stuff. Compare with RFC 8152, which copes all right under the circumstances given the timing of its publication.)

Back at the March meeting, I recall that the chairs asked the WG participants about the possibility of publishing a lightweight CDDL RFC to take pressure off. I don’t think I saw follow-up on that on the list though.

(By the way, are there IETF 98 meeting minutes? I can’t find minutes from IETF 98 based on quick Google and mailing list searches.)

> On Jul 21, 2017, at 3:05 AM, Michael Richardson <[email-masked]> wrote:
> 
> 

I really don’t want us to have to start versioning CDDL before the WG even takes it up. I would like to point out that ABNF is not “versioned” (aside from successive x234 RFCs being published), and people are getting along just fine. That is because the primary way that ABNF is used is “as a guide to a human user”, even though it can be run through compilers/validators. And CDDL is still on that ABNF side of the spectrum, rather than the (unreadable) XML Schema side of the spectrum.

If by “*SPECIFIC* version of CDDL” you are referring to the technique in RFC 8152, then that’s fine.

> regardless of the status we intend for the document.

It is. And it is not.

PCRE is mentioned in RFC 7049, along with JavaScript syntax. Guess the lack of reference escaped review.

At the level of informally saying hey, use regular expressions here, it’s cool. But at the level of demanding implementations conform to supporting PCRE specifically, and that standard documents written with regular expressions import PCRE, it’s not cool (unless the WG considers it and says okay).

Anyway, I hope that we can conclude the WG adoption call and then proceed to the work, which will make everything go more speedily. :-)

Regards,

Sean

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 21 Jul 2017 14:29:00 +0200

> Michael, the underlying concern/fear that I have about this CDDL work, remains that despite it being nascent, people will immediately complain that such-and-such features of CDDL can never change b…

There is much less of a problem defining a CDDL 2.0 than would be for an on-the-wire protocol.

Still, a need for that is not yet known, so I also don’t see it happen very soon.

> Better to get it right, and that means, at this stage, that all features of the language are up for grabs.

That is not the intention of the charter and not what the people who pushed for completion of this work want.

It is not like CDDL was freshly invented — much of it is derived from ABNF, which has been around since 1978.  The way “groups" are used to define arrays and maps is an innovation, but it seems to have worked quite well for a number of specification projects a couple of years already.

Of course, all those features can and should be discussed in the WG process — that’s why we are going through this.  
But when that’s done, it’s done, and the document should then be standards-track.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Fri, 21 Jul 2017 15:42:14 +0200

Sean Leonard <[email-masked]> wrote:
    > Michael, the underlying concern/fear that I have about this CDDL work,
    > remains that despite it being nascent, people will immediately complain
    > that such-and-such features of CDDL can never change because they
    > already wrote stuff.

I very very very strongly disagree.
They can't complain, because they will have referenced the previous RFC in
their document.  CDDL *itself* is not bits on the wire.

Any tools that are created can easily (and SHOULD) have an --rfcXXXX option,
or perhaps we want to put "version rfcXXXX" as a clause in the file.

    > Better to get it right, and that means, at this stage, that all
    > features of the language are up for grabs.

I strongly disagree.
We have a free hand.

    > (By the way, are there IETF 98 meeting minutes? I can’t find minutes
    > from IETF 98 based on quick Google and mailing list searches.)

98?  or 99?
There are meetecho records if there were no minutes posted to the list.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 22 Jul 2017 08:22:19 +1200

> loose.  Otherwise, it would be a problem.

Actually that's an IESG decision. But why we'd contort ourselves in that
way is beyond me.

     Brian

---

From: Francesca Palombini <[email-masked]>
Date: Mon, 24 Jul 2017 07:37:13 +0000

Hi all,

The deadline has passed, and from listening to the face-to-face meeting and mailing list, the draft is adopted by the working group. Moreover, I hear a majority of people (including our AD) agreeing on this being changed to standard track right away.

So, authors: please resubmit as draft-ietf-cbor-cddl and change to standard track.

Thanks,
Francesca

From: Francesca Palombini [mailto:[email-masked]]
Sent: den 5 juli 2017 11:48
To: [email-masked]
Cc: [email-masked]
Subject: 🔔 Confirmation call for Working Group Adoption for draft-greevenbosch-appsawg-cbor-cddl

Hi all,

Thanks,
Francesca