Re: [Cbor] Draft text for pull request for tag range IANA allocation policy

Sean Leonard <dev+ietf@seantek.com> Wed, 14 August 2019 16:53 UTC

Return-Path: <dev+ietf@seantek.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 83CBA120BB9 for <cbor@ietfa.amsl.com>; Wed, 14 Aug 2019 09:53:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyrXS-Nfp0y8 for <cbor@ietfa.amsl.com>; Wed, 14 Aug 2019 09:53:43 -0700 (PDT)
Received: from smtp-out-4.mxes.net (smtp-out-4.mxes.net [198.205.123.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3AFE120BBA for <cbor@ietf.org>; Wed, 14 Aug 2019 09:53:43 -0700 (PDT)
Received: from Customer-MUA (mua.mxes.net [10.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 88F382738F for <cbor@ietf.org>; Wed, 14 Aug 2019 12:53:40 -0400 (EDT)
To: cbor@ietf.org
References: <12deba80-20ba-cf55-162f-a9852ad7ab26@seantek.com> <261994BA-150C-44FC-95FD-A5C8429B395A@tzi.org>
From: Sean Leonard <dev+ietf@seantek.com>
Message-ID: <1be2cc46-b253-4db5-f1b3-0d4cbec3061d@seantek.com>
Date: Wed, 14 Aug 2019 09:52:55 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <261994BA-150C-44FC-95FD-A5C8429B395A@tzi.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Sent-To: <Y2JvckBpZXRmLm9yZw==>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/FxxB6we5thl7rFE7s9ivoUi9s9M>
Subject: Re: [Cbor] Draft text for pull request for tag range IANA allocation policy
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, 14 Aug 2019 16:53:45 -0000

On 8/14/2019 9:22 AM, Carsten Bormann wrote:
> On Aug 14, 2019, at 18:07, Sean Leonard <dev+ietf@seantek.com> wrote:
>>     New entries in the range 24 to 255 are assigned by RFC Required.
> Based on previous WG discussions, I think that was a slightly higher hurdle than we wanted here.
> Specification required + designated expert considerations that only provide this space for high-value allocations (which needs to be defined better than I just did).

True in that Thiago's referenced post said 32-255 range.

However, not quite true in that Thiago's prior post 
<mid:10096467.9kdZcmANtY@tjmaciei-mobl1> says:

"Could we get 32-255 to be slightly stricter but not to the level of 
standards
action? I was thinking of publication of a draft to this WG and allow 
for a 2-
week comment period. This could both spur ideas from other passive watchers
and ensure high quality of the ones that do get published."

"do get published" = draft turns into an RFC. But it can be independent 
stream. That is congruent with RFC Required.

The other problem is that we are already half exhausted out of the 
32-255 range. It's going to go entirely pretty soon.

I believe that 32-255 should have a higher level of review than 
256-<some fraction less than 65535>. We need to de-stigmatize the 
256-65535 range. It is perfectly acceptable for widely deployed 
protocols--even for IETF Standards-track protocols. But I think right 
now everybody is trying to go for 32-255 and it's just not sustainable.

Oh, also Carsten's post 
<mid:1A8A7E20-A92C-4242-92EB-950CD1F93B27@tzi.org> said "I like that" 
for RFC Required to 255. :-)

In <mid:045601d543ac$b79f3d40$26ddb7c0$@augustcellars.com> Jim proposed 
Specification Required with a consideration: "Reviewers should be 
reluctant to assign code points in the 24-255 range to specifications 
that are not RFC documents."

However, with regard to the present tag 42 problem, Jim proposed that we 
encourage early IANA allocation. The point is that early IANA allocation 
+ RFC Required will alleviate the problem, and will also permit higher 
analysis + early allocation in the 256-65535 range.

So I think there was not consensus on the mailing list at the time but 
the trend was going towards segregating the spaces into progressively 
higher levels of review.

Sean