[PDB Data Ownership-TF] conditions for being listed in a facility
Arnold Nipper
arnold at peeringdb.com
Tue Jan 7 15:23:23 PST 2020
On 08.01.2020 00:14, Terry Sweetser wrote:
> Great thread!
>
> Chris: very good point on the data models, who controls what and who owns a facility record. I would speculate that it would a long and expensive exercise to engage the owners and operators of those facilities to engage with PeeringDB, to become trusted sources of data, and be trusted by the eco-system.
>
> Arnold: I think it is counter-intuitive for a facility to want to hide the presence of an IXP. Any IXP in a facility attracts more customers for them and also generate XC revenue amongst other benefits. I would think that a subordinate relationship would be in place between an IXP and its "home".
>
In general and theory that's true. However, real life is different :)
> Overall, I would say that a facility listing is just like an address, a place where you do business, and as such the landlord does not have any say in how your IXP lists it's "home" address.
> As to the data integrity of that address, that goes back to a basic principle of "truth in all things", so corrections should be accepted, ISO standards followed, etc.
>
I like this approach. But do we then want a facility owner to be able to
delete a facility?
Cheers
Arnold
> Regards,
> Terry Sweetser
> General Manager, IX Australia
> Terry.Sweetser at ix.asn.au
> Mobile/WhatsApp: +61455067119
>
>
>
> -----Original Message-----
> From: DataOwnership-TF <dataownership-tf-bounces at lists.peeringdb.com> On Behalf Of Chris Caputo
> Sent: Wednesday, 8 January 2020 7:58 AM
> To: DTF PeeringDB <dataownership-tf at lists.peeringdb.com>
> Subject: Re: [PDB Data Ownership-TF] conditions for being listed in a facility
>
> 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
> --
> DataOwnership-TF mailing list
> DataOwnership-TF at lists.peeringdb.com
> https://lists.peeringdb.com/cgi-bin/mailman/listinfo/dataownership-tf
>
--
Arnold Nipper
email: arnold at peeringdb.com
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/0d22f136/attachment.sig>
More information about the DataOwnership-TF
mailing list