Re: [Cbor] Adam Roach's Block on charter-ietf-cbor-01-01: (with BLOCK)

Carsten Bormann <cabo@tzi.org> Wed, 26 June 2019 05:53 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D711D120123; Tue, 25 Jun 2019 22:53:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0y0Za7a0_Egq; Tue, 25 Jun 2019 22:53:36 -0700 (PDT)
Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D9021200EC; Tue, 25 Jun 2019 22:53:36 -0700 (PDT)
Received: from [192.168.217.110] (p54A6CA4C.dip0.t-ipconnect.de [84.166.202.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 45YXJZ2WVTzyYX; Wed, 26 Jun 2019 07:53:34 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <156152155760.31137.14743795939001646314.idtracker@ietfa.amsl.com>
Date: Wed, 26 Jun 2019 07:53:33 +0200
Cc: The IESG <iesg@ietf.org>, cbor@ietf.org, cbor-chairs@ietf.org
X-Mao-Original-Outgoing-Id: 583221211.577556-b6285d443e5b2f525ede3134c4d5273f
Content-Transfer-Encoding: quoted-printable
Message-Id: <DDE43267-4644-436A-BCB7-71D1188A659C@tzi.org>
References: <156152155760.31137.14743795939001646314.idtracker@ietfa.amsl.com>
To: Adam Roach <adam@nostrum.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/zkUEfaxm_a9oiyuW5pc6l8bpLRo>
Subject: Re: [Cbor] Adam Roach's Block on charter-ietf-cbor-01-01: (with BLOCK)
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jun 2019 05:53:40 -0000

Hi Adam,

these are very good questions indeed.

As you may have noticed, the rescoping beyond IoT is not just happening to CDDL.
CBOR is now being used in a wide variety of specifications that have varying aspects of IoTness to them, e.g., consider WebAuthn and CTAP2.  This is also visible in the set of people who are contributing.
So I don’t think the rechartered CBOR WG as proposed will be an obscure IoT only working group.

Of the three jobs of the rechartered WG, the CBORbis part has the shortest timeline.
Once that is finished, we are left with CDDL and the Tags documents (and occasional media type documents).  While Tags are specific to CBOR, they also could be viewed as a component model that will increasingly be used in CDDL as well.  The more general purpose (or internet-wide) Tags documents that would be worked on by the WG would flow together with the desire to componentize CDDL.

With respect to the broader field of “schema languages”, the extreme version of your proposal would be to merge into one WG the existing netmod WG (the work on YANG), the CDDL work of the CBOR WG, and the various approaches to data modeling being discussed on the JSON WG mailing list right now.  Clearly, data modeling has become an important aspect of the field of protocol development.  But that does not mean all that work needs to be in one WG.  The constituents are overlapping, but mostly distinct: operations and management, application layer and security protocol design, application API development.

Creating a new “data modeling for JSON and friends” WG would send a signal that we take the data modeling area more seriously.  But it would also defocus from the evolution of CDDL as one description technique in this space; it seems to me that the current approach of evolving a number of coherent designs in a competitive manner is ultimately more productive.

A pure CDDL working group would certainly work, but would leave the work on Tags on the sidelines — keeping a CBOR working group just for the Tags work (once CBORbis is completed) doesn’t seem to make a lot of sense, and we want to achieve a higher degree of integration between components work and language work anyway.

So I think the charter proposal has it about right, with the possible exception of the need for a signal that this WG is not just about IoT any more.  But that signal can be outside the charter.

Grüße, Carsten


> On Jun 26, 2019, at 05:59, Adam Roach via Datatracker <noreply@ietf.org> wrote:
> 
> Adam Roach has entered the following ballot position for
> charter-ietf-cbor-01-01: 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:
> ----------------------------------------------------------------------
> 
> This is a "DISCUSS-discuss" style block, in the spirit of backing up and making
> sure we're making the right overall decision here.
> 
> I'd like us to have a short conversation about whether it makes sense for the
> CDDL work to continue in the CBOR working group. Given that it has been
> rescoped and renamed to be a more general-purpose schema language covering not
> just CBOR, but the much broader JSON universe, it seems that this work is
> extremely likely to have a broad constituency outside of those people who
> typically participate in working groups that focus on IoT use-cases. Keeping it
> part of CBOR does not seem to serve that community well.
> 
> Should we consider splitting the CDDL update and maintenance work off into a
> separate working group, rather than rechartering CBOR with the rather
> significant expansion considered in this charter proposal?
> 
> 
> 
> 
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor
>