Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-capabilities-registry-change-08: (with DISCUSS)

Benjamin Kaduk <kaduk@mit.edu> Wed, 06 May 2020 23:43 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512863A0C59; Wed, 6 May 2020 16:43:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 iBhXZItE4MZL; Wed, 6 May 2020 16:43:50 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD51A3A0C56; Wed, 6 May 2020 16:43:49 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 046NhhhW012516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 6 May 2020 19:43:46 -0400
Date: Wed, 06 May 2020 16:43:43 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: John Scudder <jgs@juniper.net>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-idr-capabilities-registry-change@ietf.org" <draft-ietf-idr-capabilities-registry-change@ietf.org>, idr-chairs <idr-chairs@ietf.org>, "idr@ietf. org" <idr@ietf.org>, Hares Susan <shares@ndzh.com>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>
Message-ID: <20200506234343.GL27494@kduck.mit.edu>
References: <158863153407.23292.4827001124495737819@ietfa.amsl.com> <1E6F4050-EDCB-489C-B323-352772341253@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1E6F4050-EDCB-489C-B323-352772341253@juniper.net>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/TrV2qy9H_9AVLYztct8EMOcWliE>
Subject: Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-capabilities-registry-change-08: (with DISCUSS)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 May 2020 23:43:54 -0000

Hi John,

Sorry for the slow response -- I was away from my inbox for a while and
seem to have missed this message when skimming over for important things to
respond to.

I think you have the right understanding, and as others have noted, having
the document state that a survey was done, and that all known codepoints in
use are being registered, is worth doing.  I also think that we should give
a description of what could go wrong if our survey had missed something, to
make it clear that we understand the scope of what we're doing and still
believe that the cost/benefit tradeoff is in favor of what we're doing.
Given that an existing private use is almost surely within some limited
private scope, it seems like dealing with a potential future conflict
should be a manageable prospect, so I'm not very concerned, but I think
it's important to record our current understanding.

Thanks,

Ben

On Mon, May 04, 2020 at 10:42:23PM +0000, John Scudder wrote:
> The described scenario (if I understand it correctly) is essentially why we wrote the draft — there isn’t a sane use for “private use” in the context of Capabilities. The reason we worked hard on the implementation survey was to try to catch any gotchas. Of course there can’t be any guarantee of that we didn’t miss something, but any such collision is no different from any other code point collision, whether due to squatting or whatever.
> 
> —John
> 
> > On May 4, 2020, at 6:32 PM, Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
> > 
> > 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-idr-capabilities-registry-change-08: Discuss
> > 
> > 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.)
> > 
> > 
> > Please refer to https://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!NEt6yMaO-gk!XlwTiOBYEoZ6FbmvITpDe6sQgYHGqOjOvpudaP4aGJTA6cDhw0V0JhRN-wx_9g$
> > for more information about IESG DISCUSS and COMMENT positions.
> > 
> > 
> > The document, along with other ballot positions, can be found here:
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-capabilities-registry-change/__;!!NEt6yMaO-gk!XlwTiOBYEoZ6FbmvITpDe6sQgYHGqOjOvpudaP4aGJTA6cDhw0V0JhSclIaoGg$
> > 
> > 
> > 
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> > 
> > (Quite possibly a "discuss discuss"...)
> > What would the behavior be if someone was shipping an implementation that used
> > a point in the 128-255 range intending for the "private use" semantics, a
> > conflicting codepoint was assigned via FCFS, and then needed to use the feature
> > with conflicting codepoint in that implementation? It seems likely that we
> > should discuss the plausibility of such scenarios and what options are
> > available to handle it.
> > 
> > 
> > 
> > 
> > 
>