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

[Arnold Nipper]

On 07.01.2020 22:58, Chris Caputo wrote:
> 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?)
> 

No, suggested facilities do have an org, but not an admin in general.
There also a couple of facilities which we migrated from PDB1.0 which
still don't have an admin.

>> 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?
> 

Of course there is an ownership in the sense that each facility has an
organisation as a parent node (db wise). However from the pov that a
facility operator in general is really able to decide whether a network
or facility is located in one of its facilities, there is no ownership.
Only in rare cases a facility operator is able to make credible that a
network is not located in their facility.

For IXes we always can tell as the IX has to assign an IPv{4,6} address
to the network. There is no such identifier for being at a facility.

> 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 not. We should mention what the problem space is. And that
there is no way to identify ownership as we can for IXes.

> 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.
> 

I try to make comments to the document as good as possible. And I also
made this comment yesterday or even the day before yesterday.

Discussing record by record via email could be an option. And then have
phone conferences to resolve issues.

> 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.
> 

There is no parent org for record as-set. That is also the reason i
don't like this object :) However, it comes in handy.

> - 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.
> 

Actually, grandparent as the parent of ixpfx is ixlan. Let's see what PC
comes up, once we remove ixlan.

> - 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.
> 

Same as with ixpfx. Parent of poc is net which in turn has an org as
parent. And it would be nice to always have the org_id in all records to
get rid of unnecessary lookups.

> 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?
> 

The ix has to create the ixlan/ixpfx. Otherwise no netixlan can be
created. However, the netixlan object itself may only be created/changed
by a network (possibly proxying via the ix in case of
"allow_ixp_update). The netixlan record may be deleted by the network as
well as by the ix. The ix by deleting the ixlan/ixpfx. What also happens
every now and then unintentionally. Personally I think the ix should
have control in the end, but the net has a veto.

> - 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?
> 

Much the same as above. However, the Facility Org is only able to delete
all the netfac records by deleting the correspondent facility. Which
also happens every now and then unintentionally.

> 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?
> 

ixfac is the same as netfac.

> - 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?
> 

Totally agree. There is no discussion who owns org, fac, ix, ixlan,
ixpfx, net, and org.

And it is also quite clear who is involved in the other objects. Having
a clear description who can create, change, and delete an object helps.
We should also point out what consequences the deletion of an object
has. E.g. deleting fac deletes all netfac, ixfac for this facility.

Last, but not least we should develop robust procedures in case there is
conflict.


Cheers
Arnold

> 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
> 


-- 
Arnold Nipper
email: arnold at nipper.de
mobile: +49 172 2650958

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.peeringdb.com/pipermail/dataownership-tf/attachments/20200108/58964e61/attachment-0001.sig>