[PDB Data Ownership-TF] conditions for being listed in a facility

[Chris Caputo]

On Tue, 7 Jan 2020, Arnold Nipper wrote:
> On 07.01.2020 20:00, Chris Caputo wrote:
> > I just posted the following to the Data Ownership Policy Document, based 
> > on discussion in today's conf.  Feedback welcome.
> 
> I made my remarks as comments in the document. Just to repeat.
> 
> Adding a flag FacilityPriorApproval (default FALSE) completely
> contradicts the current philosophy of PeeringDB as we even allow
> suggestion of facilities. These suggested facilities don't have admin
> users, hence no one who can set a flag.

Am confused by this.  From what I can tell, all Facilities have a parent 
Organization, so isn't that the owner?  (and the Org has Admins, no?)

> PC intentionally added the "SUGGEST" feature to make the DB more useful.
> 
> Furthermore, most of the colocation operators allow subleasing. Hence,
> in general, they will not be able to decide whether a network is at
> their facility or not. This is the big difference between a colocation
> and an IX.

This is great info Arnold and I apologize for not being better informed.  
I haved removed the paragraphs in favor of further discussion here or at 
the next meeting.  They can be added back later if needed.

What are your thoughts on Facilities?

Is there a data ownership aspect for them that you can help us understand?  

Should the document just state there is no ownership of Facilities and 
that any network/IXP can list themselves anywhere?

If we rule out Facilities from consideration is there really any question 
for the task force to solve other than the one that inspired it?  (ie., 
the IXP IP assignment race condition)

Generally: I am concerned that our phone conferences are not the best 
place to make progress since all interested parties are not consistently 
able to be present.  Maybe the mailing list is where we should really try 
to make progress since it allows asynchronous involvement.

With that in mind, looking at the objects listed in the "Data Ownership 
Policy Document"...

Potentially Obvious:

- as_set: IRR Record
  - Ex: https://www.peeringdb.com/api/as_set/65512
    - [...]"AS-EXAMPLE"[...]
  - Parent Org owns and controls.

- ix:
  - Ex: https://www.peeringdb.com/api/ix/13
    - [...]"name": "Seattle Internet Exchange"[...]
  - Parent Org owns and controls.

- ixpfx: IXP subnet
  - Ex: https://www.peeringdb.com/api/ixpfx/31
    - [...]"name": "SIX Seattle"[...]
    - [...]"prefix": "206.81.80.0/23"[...]
  - Parent Org owns and controls.

- net: Network record
  - Ex: https://www.peeringdb.com/api/net/416
    - [...]"name": "Altopia Corporation"[...]
  - Parent Org owns and controls.

- org: Org record
  - Ex: https://www.peeringdb.com/api/org/550
    - [...]"name": "Altopia Corporation"[...]
  - Org owns and controls.

- poc: Point of contact
  - Ex: https://www.peeringdb.com/api/poc/415
    - [...]"role": "NOC"[...]
  - Parent Org owns and controls.

Debateable:

- fac: Facility record
  - Ex:https://www.peeringdb.com/api/fac/71
    - [...]"org_name": "The Westin Building", "org": {"id": 116[..]
    - [...]"name": "The Westin Building"[...]
  - Does not the parent Org own and control?

- netixlan: Network's IP assignment at an IXP
  - Ex: https://www.peeringdb.com/api/netixlan/1534
  - Does the IXP Org own and control or does the Network Org own and 
    control or is there a mutual agreement needed?

- netfac: Network's presence at a Facility
  - Ex: https://www.peeringdb.com/api/netfac/743
    - [...]"name": "Westin Building Seattle"[...]
    - [...]"name": "Altopia Corporation"[...]
  - Does the Facility Org own and control or does the Network Org own and 
    control or is there a mutual agreement needed?

Simply a database Join, thus dependent on the decisions about the 
"Debateable" objects:

- ixfac: Join of ix and fac, listing those present at facility
  - Ex: https://www.peeringdb.com/api/ixfac/21
  - Does the Facility Org own and control or does the IXP Org own and 
    control or is there a mutual agreement needed?

- ixlan: Join of ix and netixlan, listing networks at IXP
  - Ex: https://www.peeringdb.com/api/ixlan/13
  - Does the IXP Org own and control or does the Network Org own and 
    control or is there a mutual agreement needed?

Does anyone disagree with my list of "Potentially Obvious" objects - 
as_set, ix, ixpfx, net, org, poc - as being simply what they are, with 
obvious ownership by their parent organizations?

If the "Potentially Obvious" objects are settled in terms of who 
owns/controls them, we can move on to the meat of the discussion which 
would be the following objects:

  - fac: Facility record

  - netixlan: Network's IP assignment at an IXP

  - netfac: Network's presence at a Facility

I propose that if we accept that "fac" objects are owned and controlled by 
their parent Organization (once claimed, if not already claimed), then the 
flow chart I proposed earlier in this thread can be used to resolve 
"netfac" issues.

And similarly, the flowchart can be adapted to the "netixlan" question, 
with a change being that if an IXP is configured to have their IX-F JSON 
data imported, that means the IXP asserts a flag fIXPPriorApproval be set 
to TRUE.

In cases of disputes about presense at a Facility or an IXP, information 
can be listed on the client page asserting presence or IP assignment, with 
an indication of dispute, while at the same time NOT being listed on the 
pages that show the result of a database Join and not in the REST API 
results of database Joins.  Then when a dispute is resolved (either by a 
Facility allowing listing or by an IXP indicating presence) the dispute 
indication goes away and the database Joins pages/API results include the 
client.

Thoughts?

Thanks,
Chris