Re: [Idr] The IDR WG has placed draft-spaghetti-idr-deprecate-8-9-10 in state "Candidate for WG Adoption"

Nick Hilliard <nick@foobar.org> Thu, 30 June 2022 14:46 UTC

Return-Path: <nick@foobar.org>
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 E60F2C15CF29 for <idr@ietfa.amsl.com>; Thu, 30 Jun 2022 07:46:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.784
X-Spam-Level:
X-Spam-Status: No, score=-3.784 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.876, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yeP0-h88Qn2 for <idr@ietfa.amsl.com>; Thu, 30 Jun 2022 07:46:49 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [46.182.8.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3429C15AE38 for <idr@ietf.org>; Thu, 30 Jun 2022 07:46:47 -0700 (PDT)
Received: from cupcake.local (unknown [89.101.195.156]) by mail.netability.ie (Postfix) with ESMTPSA id F206A9CF98; Thu, 30 Jun 2022 15:46:43 +0100 (IST)
To: Susan Hares <shares@ndzh.com>
Cc: "idr@ietf.org" <idr@ietf.org>
References: <165659656479.27765.10628634681634527343@ietfa.amsl.com> <1f171a07-ace4-03a8-7d6e-092bb6fa10c6@foobar.org> <BYAPR08MB4872B77A79499DB3AA076F08B3BA9@BYAPR08MB4872.namprd08.prod.outlook.com>
From: Nick Hilliard <nick@foobar.org>
Message-ID: <37248b90-08c9-b4a5-79ff-a7f1dde9b367@foobar.org>
Date: Thu, 30 Jun 2022 15:46:42 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.56
MIME-Version: 1.0
In-Reply-To: <BYAPR08MB4872B77A79499DB3AA076F08B3BA9@BYAPR08MB4872.namprd08.prod.outlook.com>
Content-Type: text/plain; charset="windows-1256"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/qTRH8TJ2zgAKNa0CWlJM0xNzSx8>
Subject: Re: [Idr] The IDR WG has placed draft-spaghetti-idr-deprecate-8-9-10 in state "Candidate for WG Adoption"
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 30 Jun 2022 14:46:51 -0000

[cc: trimmed]

Susan Hares wrote on 30/06/2022 14:58:
> Nick:
> 
> You have asked a good question that the IDR WG has struggled with.
> 
> Do we admit that the reality that shipping code has “squatters”
> so that networks can detect squatters?
> 
> Or do we shame and name the squatters and deprecate the code
> points?
> 
> Both end scenarios up with unusable code points for IANA Assignment.

It sure is a pickle, no doubt about it.  Looking at it from another 
point of view, companies are going to do this sort of thing from time to 
time, no matter how harmful an idea it is in practice.  The question 
then becomes: how can the IETF guide people away from doing this in future?

The IDR already has an early allocation mechanism - BCP100 - and this 
provides a useful and workable mechanism for organisations to request 
codepoints if that's what they need.  Flip side is that this requires an 
ID, but that's hardly insuperable.

Alternatively, if there were experimental ranges assigned, perhaps these 
would work for inhouse tests?

The difficult with deprecating these code points is that it's like 
scolding the organisation who did it with: "That's terrible!  You should 
never have done that!  But carry on - as you were".  If they ever do it 
again, they might face being scolded a second time.

This is obviously a bigger issue than just BGP, or just IDR.  I wonder 
if there were a precedent which were set in the IDR about tolerating 
squatted codepoints, would this then be used to justify it in other IETF 
working groups?

There's precedent for this in terms of ipv4 address allocation.  Lots of 
organisations had squatted various ipv4 address blocks of one form or 
another.  I have a recollection that some years ago, IANA had some 
requests not to assign an entire /8 due to squatting by some community 
network, and there were similar requests not to assign 1/8 for the same 
reason.  But in both cases, those resources were assigned for production 
use, and despite the problems that were going to occur, no-one ever 
queried whether these were bad decisions.

Nick