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

Mirja Kuehlewind <> Wed, 03 July 2019 13:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 346F8120043; Wed, 3 Jul 2019 06:24:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QNnL-FL-2ida; Wed, 3 Jul 2019 06:24:12 -0700 (PDT)
Received: from ( [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EC46D120603; Wed, 3 Jul 2019 06:23:17 -0700 (PDT)
Received: from ([]; authenticated by running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hifE9-0006QV-Hr; Wed, 03 Jul 2019 15:23:13 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind <>
In-Reply-To: <>
Date: Wed, 3 Jul 2019 15:23:12 +0200
Cc: Alexey Melnikov <>,, The IESG <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Carsten Bormann <>
X-Mailer: Apple Mail (2.3445.104.11)
X-HE-SMSGID: 1hifE9-0006QV-Hr
Archived-At: <>
Subject: Re: [Cbor] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Block_on_charter-ietf-?= =?utf-8?q?cbor-01-01=3A_=28with_BLOCK=29?=
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 03 Jul 2019 13:24:15 -0000

Hi Carsten,

Having a more open charter is fine as well, if you see this as going into maintenance mode. However, I don’t really see the value in defining this additional process with these three categories (which are also not completely clear to everybody and therefore probably not always straight forward to map). I would recommend to discuss every proposed tag separately and have a wg call to add a milestone for a tag if accepted in the group. I’d otherwise even be afraid that having these categories might focus any adoption discussion too much on the scope only and may end up not being very unconstructive. Therefore I still recommend to remove that part from the charter. Maybe say something other like:

"The working group will evaluate such proposal individually and decide about addition of a respective milestone. Proposals that are deemed to be out of scope for the working group, e.g. because they are too narrow purpose specifications, may still be published as individual submission or in another groups if there is a specific need. The cbor group will review these proposals on request.”

Or something similar…


> On 2. Jul 2019, at 19:44, Carsten Bormann <> wrote:
> Hi Mirja,
> On Jul 2, 2019, at 17:52, Mirja Kuehlewind <> 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