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

Adam Roach <adam@nostrum.com> Tue, 02 July 2019 16:17 UTC

Return-Path: <adam@nostrum.com>
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 E08EF120394; Tue, 2 Jul 2019 09:17:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level:
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, MIME_QP_LONG_LINE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
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 3oT3WK1PO0DJ; Tue, 2 Jul 2019 09:17:32 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F1F112047D; Tue, 2 Jul 2019 09:17:13 -0700 (PDT)
Received: from [IPv6:2607:fb90:408a:cc9e:d887:fc1:944a:77d0] ([172.58.169.78]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x62GGtSd090148 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 2 Jul 2019 11:17:04 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1562084226; bh=HSxQt3H/2lF9xlAQa0/ksMknVejo6NlehFoZF+r8oek=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=NpCMXL5eaN5RTGfrsfA2fx8ow6++PF/tfMTc+zQQ++/o4s6UioOj5JvZEHD68xCvE wdwS0HA+3GMKIfEsiW0wmhxs31kPxmREKVANU1EDxOnJT9Sm46PaxnCu7GLkOcRv3I +w9+VRpBgn6gWJBFTTtFR6eXBWEgW7VeJWOQRs28=
X-Authentication-Warning: raven.nostrum.com: Host [172.58.169.78] claimed to be [IPv6:2607:fb90:408a:cc9e:d887:fc1:944a:77d0]
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Adam Roach <adam@nostrum.com>
X-Mailer: iPhone Mail (16F203)
In-Reply-To: <f88c76e5-0d68-44cd-8d9c-15fa7258e095@www.fastmail.com>
Date: Tue, 2 Jul 2019 12:16:48 -0400
Cc: Carsten Bormann <cabo@tzi.org>, cbor@ietf.org, The IESG <iesg@ietf.org>, cbor-chairs@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <D92B072E-16C8-4280-8DF2-6BFF655C16CA@nostrum.com>
References: <156152155760.31137.14743795939001646314.idtracker@ietfa.amsl.com> <DDE43267-4644-436A-BCB7-71D1188A659C@tzi.org> <f88c76e5-0d68-44cd-8d9c-15fa7258e095@www.fastmail.com>
To: Alexey Melnikov <aamelnikov@fastmail.fm>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/A1JxWzZIk7E13uClFIb31y6Fxk4>
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: Tue, 02 Jul 2019 16:17:34 -0000

Okay — I’m happy with the level of consideration that’s happened here. I merely wanted to ensure the possibility had been considered. I’ll clear.

/a

> On Jul 2, 2019, at 10:37, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
> 
>> On Wed, Jun 26, 2019, at 6:53 AM, Carsten Bormann wrote:
>> 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.
> 
> I agree that use of CBOR is not limited to IoT space. I struggle to make this any clearer in the charter text. Adam, do you think anything needs to change/ can be improved here?
> 
>> 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.
> 
> Considering size of the WG, people involved and the fact that CBOR model is more complex than JSON, so it is more likely to affect CDDL, I think it makes sense to keep both CBOR and any possible CDDL extensions in one place.
> 
>> 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.
> 
> Agreed.
> 
> Best Regards,
> Alexey
> 
>> 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
>>> 
>> 
>>