Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] A question for the PDWG

Fernando Frediani fhfrediani at gmail.com
Wed May 25 15:44:31 UTC 2022


Hi David
I think you missed my main point about this topic.

I am not saying in any moment ICANN can intervene in any RIR or 
overwrite any decision they made, but simply they can stop recognize it 
as a RIR and that should be done based on ICP-2.
It is just too comfortable for RIR management or membership (if a 
decision was taken with their support) in general to think they are 
untouchable and can do whatever they like with shared resources that may 
severely affect *all the Internet Community*. That must be a counter 
balance measures for the rest o Internet community to stop bad actors, 
including entire RIRs to do things that may affect the stability of the 
Internet. It just does not make any sense to thing that ICP-2 is used 
only to form RIR as some may desire and right after be trashed way 
leaving that RIR alone and doing whatever they like forever. It just 
doesn't have any logical sense.

In reality I recognize that would be something very exceptional and rare 
to happen, but I would strong support any of these bad actors to be 
brought to spot and all necessary discussion be conducted up to ICANN 
Board to analyze the question as well in all other RIRs.
It is just a question of stop recognizing another organization as a 
valid organization for that ecosystem, and although not all other may do 
the same, that may have a strong impact and should be supported if it's 
the case. Defending ICP-2 is only valid for the moment of the creating 
of the RIR is support anarchy in this whole system which organizations 
being able to make final decisions about something that impact all others.

Regarding RFC 7020 I personally hope it gets fixed at some point. I 
don't think that is all bad, but it lacks a fundamental point to any 
system like this: double degree of jurisdiction which must exist in any 
administrative and legal system. It simply makes any RIR administrative 
final. It just makes it too comfortable for RIR management since then to 
not be bothered by other organizations from the same ecosystem should a 
bad decision is taken regarding resource management making in practice 
the only viable way to appeal the local courts which is worse then an 
administrative degree of appeal.

Fernando

On 25/05/2022 11:27, David Conrad wrote:
> Fernando,
>
> On May 24, 2022, at 11:06 AM, Fernando Frediani <fhfrediani at gmail.com> wrote:
>>> On May 24, 2022, at 8:21 AM, Fernando Frediani <fhfrediani at gmail.com> wrote:
>>> The title of ICP-2 is "Criteria for Establishment of New Regional Internet Registries”.  It explicitly states "this document provides criteria and guidelines specifically for ICANN to take into account when evaluating applications for recognition of new RIRs.”  It does not speak to maintaining RIR status after creation.
>> Sorry, but it doesn't make sense at all. It is like having to pass a drive license exam based on several pre-established criteria and after you get you license you are not bound to any law or rules which you may decide yourself.
> Your mental model of how Internet resource management works doesn’t appear to match the way things actually work.  Implicit in your analogy is a governmentally mandated (or at least, mutually agreed supervisory) regulatory body.  ICANN is not a regulatory body.  All powers ICANN has are those mutually agreed upon through contractual obligations. The RIRs did NOT mutually agree, contractually or otherwise, that ICANN is able to regulate them. They agreed that ICANN can recognize the creation of a new RIR, can ratify global policies, and that ICANN via the iANA functions can allocate addresses upon request.  That’s pretty much it.
>
>> This thing about "Internet police" is one of the most meaningless terms used when scenarios where some doesn't like the potential of another intervene in their business.
> No. The lack of Internet police is a fundamental reality of a global network of interconnected, independently owned and operated, private (for the most part) networks. The RIR system works because of voluntary participation of various stakeholders who (more or less) agree that the address registration system is handled through the RIRs, not because there is a higher-level authority (i.e., the Internet police) which forces the stakeholders to participate.
>
>> But that's not the point. First that ICANN would not be forcing another organization to do anything legally, but just in its own right stop recognizing an organization as a valid RIR and according to its own judgment, principles and guidelines.
> Assuming ICANN could even do this (they can’t, but for the sake of argument), what impact do you believe that would have?  Traditionally, the RIRs have been very reluctant for ICANN to take on pretty much any role with respect to them. Why do you think a pronouncement by ICANN regarding recognization of a particular RIR would do anything (other than perhaps have the RIRs withdraw the numbering function from IANA)?
>
>> Other organizations may do that same and that organization may be left isolated for the protection of the rest of the community affect.
> You don’t need ICANN for this. You need to convince the community that the RIR is being bad.
>
>> Look, that potential RIR may still keep existing as an organization, but the different is that not being recognized as a RIR anymore it will not have a point to exist in the ecosystem anymore.
> Do you believe the existing registration service agreements will spontaneously evaporate should ICANN “de-recognize” an RIR?  Do you believe network operators, with whom ICANN does not have any relationship (contractual or otherwise) would even care?
>
>> RFC 7020 establish guidelines for Internet Numbers Registry System, therefore to RIRs that are recognized into that ecosystem.
> No. RFC 7020, like RFC 2050 prior to it, documented how the Internet numbers registry system works (see the last sentence of the Abstract).  It established nothing.
>
> Regards,
> -drc
>



More information about the RPD mailing list