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

[Brian Dickson <[e-mail]>]

On Thu, Jun 30, 2022 at 9:47 AM Jeffrey Haas <[e-mail]> wrote:

> 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
>
> (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.
>
>
Or, using what mechanisms are directly under IETF control to influence
behavior, e.g. requesting issuance of future code points. This could be
limited to the same WG, or expanded to include all WGs.
Potentially, this could extend to having squatter companies to fix the
squatting situation (at least to the degree they can), prior to having any
new code points issued.
Certainly applicable to early allocation, but potentially to any
allocations period.
(I realize the allocations are not "to the company", but in situations
where the drafts are authored by employees of a single squatting company or
group of employees of multiple companies that squat, the rationale may be
applicable.)

I'd view it similar to the request for IPR disclosures: a "code point
squatting" disclosure: Have you squatted on code points, and are you still
squatting on code points?

This might not require lawyers, but perhaps be at the direction of or with
the support of the IESG and/or IAB.

Brian


> -- 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, <[e-mail]> <
> [e-mail]> 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 <[e-mail]> On Behalf Of Nick Hilliard
> Sent: Thursday, June 30, 2022 4:47 PM
> To: Susan Hares <[e-mail]>
> Cc: [e-mail]
> 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
> [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>