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, 02 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 >>> >> >>
- [Cbor] Adam Roach's Block on charter-ietf-cbor-01… Adam Roach via Datatracker
- Re: [Cbor] Adam Roach's Block on charter-ietf-cbo… Carsten Bormann
- Re: [Cbor] Adam Roach's Block on charter-ietf-cbo… Alexey Melnikov
- Re: [Cbor] Adam Roach's Block on charter-ietf-cbo… Adam Roach