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

[Chris Caputo]

On Wed, 8 Jan 2020, Arnold Nipper wrote:
> 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.

I don't disagree with you, but I am not certain this should be stated as a 
settled matter as you have done.  Concern has been expressed that some 
facilities may believe they have a legal right to prevent a listing, given 
these facilities are not denoted only by street address but rather often 
include trademarked names.  That said, I totally understand this 
arbitration being beyond the mission of PeeringDB.

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

I am not directing my comment at you, but to the group as a whole.  
Document commenting is like teleconferences in that they do not involve 
the whole membership of the task force, and are hard to follow along with 
and keep up with.

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

The as-set is directly derived from the "net" (network) object.  The "net" 
object has an Org parent, thus the as-set REST object is owned/controlled 
by the Org parent.

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

The task force is working on what is now the case.  I am not sure waiting 
to see what the PC comes up with makes sense.

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

I think you are talking about the database schema.  I am talking 
conceptionally about who is the parent, ie. the responsible party.

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

Ah, you are right.  It is a 1:1 relationship rather than a Join, except 
that it pertains to IXPs and not Networks.  So that moves it to the 
"Debateable" column.  :-)

So the only actual Join (listing) in the REST API is "ixlan".

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

What is presented publically for "ixlan" is certainly part of this 
discussion.  That goes to the heart of the creation of the task force.

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

Arnold, I am trying to understand your perspective.  Do you think we need 
only document things and not actually make any decisions about data 
ownership?  The database schema and database relationships are a no 
brainer, while the complexity of what to do or what to present when there 
is a conflict, is why we are here.

Chris

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