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

The issues aren't new nor have they changed much.

The following is a presentation I gave at prior IETFs and periodically give again to our internal developers.

https://www.ietf.org/proceedings/97/slides/slides-97-idr-code-point-management-02 <https://www.ietf.org/proceedings/97/slides/slides-97-idr-code-point-management-02>

(And even giving this presentation, my employer still screws up.)

At some point, "IETF"[1] may wish to consider the ownership of public code points and whether it wants to get into the business of suing companies that mis-use them.

-- Jeff

[1] "IETF" is a particular bit of legal fiction.  See usual presentations on what the actual legal entities are that constitute the IETF activities.

> On Jun 30, 2022, at 11:45 AM, <bruno.decraene@orange.com> <bruno.decraene@orange.com> wrote:
> 
> +1 on Nick's points.
> 
> IMO:
> - we need to better understand the reasons for those squatting. Someone from those companies should come and explain the problem with IETF/IDR codepoint allocation
> - We many need to improve the process with our code point allocation.
> 
> --Bruno
> 
> 
> Orange Restricted
> 
> -----Original Message-----
> From: Idr <idr-bounces@ietf.org> On Behalf Of Nick Hilliard
> Sent: Thursday, June 30, 2022 4:47 PM
> To: Susan Hares <shares@ndzh.com>
> Cc: idr@ietf.org
> Subject: Re: [Idr] The IDR WG has placed draft-spaghetti-idr-deprecate-8-9-10 in state "Candidate for WG Adoption"
> 
> [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
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr