[ICP2_review] Comments on the RIR Governance Document

[Nicholas Nugent]

Lee,

I read your comments when you sent them out on September 17, but I neglected to respond at the time. Please accept this late note of appreciation for your careful review and feedback.

Cheers,

Nick

From: ICP2_review <icp2_review-bounces at arin.net> On Behalf Of Lee Howard via ICP2_review
Sent: Wednesday, September 17, 2025 6:52 PM
To: icp2_review at arin.net
Subject: [ICP2_review] Comments on the RIR Governance Document


First, I want to thank the NRO NC for the clear and considerable work they have put into this document. Although I recall extensive work on ICP-2, I think this has exceeded the initial work by an order of magnitude.

I also want to thank the ARIN region members of the NRO NC for their webinar today on the new document. Nick in particular did a great job of providing much of the context for why the document reads as it does. Great job, and thank you.

In reaction to that webinar, I have taken some time to read the document closely. My notes are below, but for reference I also pasted it into a Google Doc where my edits and comments may be clearer in context: https://docs.google.com/document/d/1Sw1U1o4W7-ZkzsZOHvzYpJycsqQhRbRSgjzkryXU8P4/edit?usp=sharing <https://docs.google.com/document/d/1Sw1U1o4W7-ZkzsZOHvzYpJycsqQhRbRSgjzkryXU8P4/edit?usp=sharing>



ORGANIZATION

Broadly, I think the organization makes sense. There are a few places that I thought were confusing:

1. Use of outline format 1.1(a)(i)(A) made it really difficult to keep track of where I was. It's easier to see the hierarchy with 1.1.1.1.1, and I wouldn't be surprised if that's an accessibility guideline.

2. There are several items in 2.3 that are more fully discussed in later sections. At the least, cross-reference Regonition and Derecognition with their respective sections. To illustrate what I mean, here's a partial outline, showing the same headings repeated:
Preamble
Article 1: Definitions, Interpretation, and Implementation
Article 2: Internet Numbers Registry System
. . .
2.3. Change to RIR Status.
(a) Recognition
(b) Dercognition
(c) ICANN Decision
2.4. Ad Hoc Audit.
. . .
Article 3: Recognition
Article 4: Ongoing Commitments
. . .
4.2 Audit
. . .
Article 5: Emergency Continuity
Article 6: Derecognition
Article 7: Amendment




DEFINITIONS

Generally, I think terms that only appear once do not need to be in the Definitions section; they are better defined in situ, where the context is provided.

Affiliate only appears once, 4.1(o), as part of Control, and only as a participle. Just roll it into the definition of Control.

The ASO MoU doesn't need to be defined up front; spell it out the one time it's mentioned, in the definition of Global Policy.

The definition of Control refers to control of an entity participating in RIR governance. Every use of the term Control in the document refers to control of the RIR.

Global Policy only appears once.

Internet Numbers Registry System has a definition, but also all of Article 2 describing it. Maybe don't define it early.

Resource Holder specifies "registered with an RIR" which excludes the few remaining organizations with delegations directly from IANA.

RIR Services is very traditional; is support for RPKI an RIR Service? It should be, since it has profound operational implications. Maintenance of IPv6.ARPA and IN-ADDR.ARPA should also explicitly in scope.

In several cases, it is unclear whether RIR or ICANN refer to the staff, executive, Governing Body, or communities. In some  cases (audits, emergency continuity), it might even refer to a contracted third party.  It should be explicit--where I think the community may be deciding something, another person might think the CEO or Board speaks for the community.



TERMS

2.3(a)(i) says a Proposal for Recognition must be submitted, but doesn't say what needs to be in it. Hours later, I read section 3.1. Suggest: by submitting a Proposal for Recognition, as specified in 3.1, in writing

It is unclear how a Candidate RIR and incumbent RIR would negotiate for territory. It's mentioned in 3.1(a), but I would think a Candidate RIR should have support from the affected RIR before event submitting a Proposal.

2.3(a)(v)(C) references 2.3(a)(iii), which is for Approval, but also needs to include the following subsection on Rejection.

2.4 "Compliance with this document" is pretty good. But is the audit conducted by ICANN staff, or consultants, and/or in conjunction with the other RIRs? What happens to the audit? Does it go to the ICANN Board, the subject RIR, the full NRO, is it published? Is the subject RIR expected to respond? Remediate? Appeal? It's weird to have the so far separated from 4.2. Aren't they the same? At the very least, cross-reference them.

2.8 "reasonable timeframes" sounds good, but I just want to point out that getting at least one meeting cycle out of every Board and Numbering Community plus ICANN almost certainly requires at least two years. That's after years of building regional support for a new RIR, or after an RIR is in failure.

3.1(f) I would like to strike "relative to the then-existing state of affairs." It is conceivable that we can see an event happening 2-3 years from now, and take action to improve the system in preparation for that event. If the improvement can only be to current state, then we have to wait for things to get worse before we can make them better.

4.1(g) I would like to add "periodically" before "elected." Governing Body members may not be elected for life.

5.1(a) "An Emergency Continuity may only be initiated" by whom? If a natural disaster affects the RIR HQ and surrounding area, who is authorized to declare an Emergency Continuity (event)?

5.1(c) "must cooperate" to the extent reasonably possible. In the case of major natural disaster, there may not be anybody who can cooperate.

5.1(d) "unless renewed pursuant to the conditions" is unclear; there are no renewal provisions. I propose: "But may be continued by repeating the steps to initiate an Emergency Continuity"

6.2 I propose to strike "if requested." Several failure modes may leave an RIR without someone to make the request.

6.2 "outweigh the benefits of continuing to tolerate" I would like to add "or mitigate." It's more consistent with derecognition being a last resort, and giving the RIR a chance to fix things.



WORD CHOICES AND TYPOGRAPHICAL

Preamble paragraph 3 has a stray space before the first line.

Change

This Governance Document for the Recognition, Operation, and Derecognition of Regional Internet Registries (the “RIR Governance Document”) succeeds the document Internet Coordination Policy‑2...

to

This Governance Document for the Recognition, Operation, and Derecognition of Regional Internet Registries (the “RIR Governance Document”) supersedes the document Internet Coordination Policy‑2...

"Succeeds" means "comes after." We intend to replace ICP-2.

2.3(v)(A) replace "outline" with "describe." We need the details, here.

2.3(c)(i) change decision to Notice of Decision. Notice of Decision is a defined term, and should be explicitly used here to require ICANN to publish the formal Notice, not just yea or nay.

4.1(n) replace "community" with "Numbering Community" to make explicit that the RIRs must convene multistakeholder meetings, not just Number Resource Holders or Members.

5.1 Replace

    "If an RIR is unable to adequately provide all or any part of its RIR Services to its Service Region,"

with

           "If an RIR is unable to adequately provide all or any part of its RIR Services for its Service Region,"

I can imagine failure modes where people inside the region can do WHOIS lookups, validate ROAs, and search ipv6.arpa, but where people outside the region can't reach those services. However, the RIRs have a responsibility to the global community, not just their region.

Footnote 1, typo in "accessible." Also, please lit the URL rather than buying it under "here".

Again, thank you to the entire NRO NC for all of the work you have put into this. Although my notes here look lengthy, I think you'll see that in almost every case, I agree with what you have done, and propose only minor clarifications.

I look forward to seeing the document ratified!

Sincerely,

Lee Howard


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/icp2_review/attachments/20250929/9a95d359/attachment-0001.htm>