Publish the full and transparent criteria used to determine if an object is approved (or not) or removed (or not)

[mustangthz]

Hello PeeringDB Team,

I'd like to request that the Admin Committee publicly publish a full and transparent set of requirements used to evaluate the validity of each type of object for approval.

I'd also like to request that the admin committee provide statistics on the percentage of each type of object that is approved and denied.

[telsin]

Seconded. I'd appreciate documentation on the object criteria. I'd also clarify that I consider "each type of object" to include ownership of facilities/ixs/etc. Would be useful in cases of ownership changes or cases similar to a recent issue which was observed on the NANOG mailing lists where contacts for PhoenixIX were not available.

[martinhannigan]

Totally agree. My experience: The amount of headache to establish a legitimate facility is mind boggling. The criteria appear to be arbitrary. Making it public allows for the rest of us to contribute and everyone to be on the same playing field. +1. Especially on the statistics. It should point to where we have issue.

[jayhanke]

100% agree with @mustangthz, @telsin and @martinhannigan. Publishing the requirements would also give a proper roadmap to new entries and help keep the system clean.

[martinhannigan]

Seconded. I'd appreciate documentation on the object criteria. I'd also clarify that I consider "each type of object" to include ownership of facilities/ixs/etc. Would be useful in cases of ownership changes or cases similar to a recent issue which was observed on the NANOG mailing lists where contacts for PhoenixIX were not available.

Establishing or discerning ownership issues of real estate is way outside the scope of interconnection. However, there are people in the community that are qualified to make such ascertainment's. It may be worth considering bifurcating facilities and IX's operationally. However, and focus, solving for criteria first is a great start.

[mcmanuss8]

+1 from me. I think this is probably 3 issues though: 1) Document the decision criteria on docs.peeringdb.com. Make sure people know it's there/share it widely on social media, etc. 2) Update the UI s.t. there's additional tooltips/help text when entering objects so users don't have to go dig around on the docs page to meet the bar. 3) Some kind of report from AC (automatically would be best, but manually generated every N months would probably be fine to start) to make sure we're transparent about how often we approve/disapprove things.

Let's tackle 1 in this issue and then when done, 2 and 3 could move forward

[telsin]

Seconded. I'd appreciate documentation on the object criteria. I'd also clarify that I consider "each type of object" to include ownership of facilities/ixs/etc. Would be useful in cases of ownership changes or cases similar to a recent issue which was observed on the NANOG mailing lists where contacts for PhoenixIX were not available.

Establishing or discerning ownership issues of real estate is way outside the scope of interconnection. However, there are people in the community that are qualified to make such ascertainment's. It may be worth considering bifurcating facilities and IX's operationally. However, and focus, solving for criteria first is a great start.

I should clarify I meant the appropriate contact for a registered object in peeringdb. I was looking for the contact info to obtain access to an item "owned" by an acquisition of my organization. The issue of ownership of real estate is something else entirely, and probably outside the scope of the immediate issue.

[martinhannigan]

We don’t disagree, but in at least four cases that I am aware of, ownership of the real estate has been a question. No owner of a parcel of real estate should ever have to produce a non public document. In the United States, real estate ownership is a matter of public record. Probably similiar in many other countries. That does indeed tie into ownership of an object. How can poeeringdb reject ownership of 111 8th for example, just because DLR is there? The deeds registry says clearly that the owner is Google. Not saying this happened, but its a common example.

[arnoldnipper]

3. Some kind of report from AC (automatically would be best, but manually generated every N months would probably be fine to start) to make sure we're transparent about how often we approve/disapprove things.

Both DeskPRO and PeeringDB provide an API to retrieve this information automagically

[martinhannigan]

+1 from me. I think this is probably 3 issues though:

1. Document the decision criteria on docs.peeringdb.com. Make sure people know it's there/share it widely on social media, etc.

2. Update the UI s.t. there's additional tooltips/help text when entering objects so users don't have to go dig around on the docs page to meet the bar.

3. Some kind of report from AC (automatically would be best, but manually generated every N months would probably be fine to start) to make sure we're transparent about how often we approve/disapprove things.

Let's tackle 1 in this issue and then when done, 2 and 3 could move forward

I agree, we may be able to solve for this in transparent criteria. Going down these other paths is and will be a giant rathole. If we can solve here it may be easier.

[dorkmatt]

I'd also like to see the criteria for object removal, such as no longer functioning datacenter locations or a peer no longer on an IX - but still "holding" an IP allocation.

[leovegoda]

@mustangthz How much of this was accomplished by publishing https://docs.peeringdb.com/committee/admin/approval-guidelines/ ? The learning step in the processes means that there's always opportunity to update these criteria, but is there anything substantive left? Can we close this issue?

[martinhannigan]

Perhaps for the next round.

NET --

ASN IETF Reserved

Not sure what that means. I can guess it means 'is the ASN reserved by the IETF via an RFC' which would probably be better stated as "Reserved ASN".

Issued by an RIR/NIR

What about legacy ASN's?

The user can confirm the relationship to the ASN through a RPKI based challenge/response (work in progress: draft-ietf-sidrops-rpki-rsc)

I suggest it should be removed. It's not real and noone can predict its outcome or form when/if it does 'come out'.

The user can confirm the relationship to the ASN by entering a PeeringDB suggested random string in their WHOIS record in a comments/remarks field (not yet implemented, a similar strategy to how Amazon AWS does BYOIP)

Can someone explain this one? Whois information is authoritative. Isn't it? If the user entry does not match shouldn't it fail? That would seem to bypass the intent of WHOIS and accuracy.

IXP --

IP prefix must be registered through an RIR or NIR.

You can not register a prefix with an RIR. You are allocated a prefix from an RIR. Its then notated in WHOIS which is authoritative.

The prefix must not overlap with any existing IXP object in PeeringDB

Face value, yes. However, this scenario is in progress and should be allowed:

I set up an IXP in Bradenton, FL and name it Bradenton-IX and number it into 10.0.0.0/22 I set up another IXP in Orlando, FL and name it Orlando-IX and number it into 10.0.0.0/22

That overlaps, but I have two unique fabric which have a direct relationship, but are "white labeled" for the local folks. I won't even get into if this is "on the campus". For the purposes of the example it doesn't matter.

IPv4 prefixes must not be longer than a /27 or shorter than /19

Why is that up to PDB? I saw the later note. With all the concerns about workflow automation shouldn't this simply be addressed through an extra "Is this correct" dialog?

Exception Process

Some of this may be in the domain of the product committee. For example my example of a white label IXP solution. There should be a step before board that a simple process box that may allow for a comment or recommendation from the PC.

On Thu, Feb 17, 2022 at 1:14 PM Leo Vegoda @.***> wrote:

@mustangthz https://github.com/mustangthz How much of this was accomplished by publishing https://docs.peeringdb.com/committee/admin/approval-guidelines/ ? The learning step in the processes means that there's always opportunity to update these criteria, but is there anything substantive left? Can we close this issue?

— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/905#issuecomment-1043261700, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFA2YQXXNKWMKZPY7WPAHXLU3U3HFANCNFSM4U63NF4Q . You are receiving this because you were mentioned.Message ID: @.***>