Re: [Cbor] Mirja Kühlewind's Block on charter-ietf-cbor-01-01: (with BLOCK)

Carsten Bormann <cabo@tzi.org> Tue, 02 July 2019 17:45 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 A1C111206AF; Tue, 2 Jul 2019 10:45:07 -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 Z4MECweY0T_C; Tue, 2 Jul 2019 10:45:04 -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 B6BCE120731; Tue, 2 Jul 2019 10:45:02 -0700 (PDT)
Received: from [192.168.217.110] (p5089AF7E.dip0.t-ipconnect.de [80.137.175.126]) (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 45dWph2CdmzyWj; Tue, 2 Jul 2019 19:45:00 +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: <2FD505EB-EA0F-4F61-898A-13E0F60DE685@kuehlewind.net>
Date: Tue, 02 Jul 2019 19:44:59 +0200
Cc: Alexey Melnikov <aamelnikov@fastmail.fm>, cbor@ietf.org, The IESG <iesg@ietf.org>, cbor-chairs@ietf.org
X-Mao-Original-Outgoing-Id: 583782297.497997-cc1f21878659cf9b9d87f0a083321d6e
Content-Transfer-Encoding: quoted-printable
Message-Id: <7ACCCA75-39DC-499E-A108-CE392D0889B6@tzi.org>
References: <156156286460.20075.13525430993942460353.idtracker@ietfa.amsl.com> <D074E533-6438-476B-86BB-796C2CEB3A41@tzi.org> <c44bb156-163f-4cb0-b99b-229926bd8055@www.fastmail.com> <2FD505EB-EA0F-4F61-898A-13E0F60DE685@kuehlewind.net>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/yscH8WTB1mmVDs7Evi5ae91JZdo>
Subject: Re: [Cbor] Mirja Kühlewind'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 17:45:08 -0000

Hi Mirja,

On Jul 2, 2019, at 17:52, Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
> 
>> Are you suggesting that the Charter should just list specific documents and require rechartering once the work is done?
> 
> Yes, I think that would actually be the better approach, where document should not be specific drafts but specific work items.

We did that in the previous (current) charter, and it was a mistake.

Tags are the most prominent defined extension point for CBOR, defined so there is a low threshold to actually making an “extension” (defining a tag), mostly done by third parties via IANA registrations.  It does make sense to coordinate some of this from the WG and pick some strategic tags for WG attention.  It makes more sense when this can be done flexibly and quickly.

The current charter from 2.5 years ago lists a couple of tag documents, one of which we chose not to progress right now after all and one that did move forward (WGLC completed).  There are a couple other documents that are de facto WG documents but can’t be officially.  That just serves to slow down work.  It’s a bit as if the DHC working group needed to be rechartered for each new DHCP option.

Grüße, Carsten