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

[Chris Caputo]

On Thu, 9 Jan 2020, Arnold Nipper wrote:
> On 09.01.2020 16:45, Chris Caputo wrote:
> > On 07.01.2020 22:58, Chris Caputo wrote:
> >> - ixlan: Join of ix and netixlan, listing networks at IXP
> >>   - Ex: https://www.peeringdb.com/api/ixlan/13
> > 
> > On Wed, 8 Jan 2020, Arnold Nipper wrote:
> >> Actually, grandparent as the parent of ixpfx is ixlan. Let's see what PC
> >> comes up, once we remove ixlan.
> > 
> > I noticed in the upcoming release notes:
> > 
> >   - * Important note - as part of this release we'll begin dropping 
> >       support for IX LANs. No impact is expected in this release but the 
> >       Admin Committee may be reaching out to various IX owners to remodel 
> >       their IX objects.  Details of this change are in github:  
> >       https://github.com/peeringdb/peeringdb/issues/21
> > 
> > I compared production:
> > 
> >   https://www.peeringdb.com/api/ixlan/13
> > 
> > and beta (since it has the above change in place now):
> > 
> >   https://beta.peeringdb.com/api/ixlan/13
> > 
> > and the results are very similar.
> > 
> 
> Actually the results should be identical.

Mostly.  There's a new field known as "info_never_via_route_servers" in 
the results, and phone numbers have been canonicalized.

> However, up to now and ix may
> have unlimited numbers of ixlans. That will change with the next release
> where each ix exactly has one ixlan. Even with exactly the same id (i.e.
> ix_id == ixlan_id). That's the reason we will be able to drop ixlan in
> V3 completely.
> 
> > Thus it appears the REST API "ixlan" result is very different than the 
> > database table "ixlan".  Just something to keep in mind as we discuss 
> > things.
> > 
> 
> Is the database table layout public somewhere?

A version of it is visible for those that "peeringdb sync" with the 
database.  Ie.:

$ sqlite3 peeringdb.sqlite3
sqlite> .schema
[...]
CREATE TABLE IF NOT EXISTS "peeringdb_ixlan" ("id" integer NOT NULL 
PRIMARY KEY AUTOINCREMENT, "status" varchar(255) NOT NULL, "created" 
datetime NOT NULL, "updated" datetime NOT
 NULL, "version" integer NOT NULL, "name" varchar(255) NOT NULL, "descr" 
text NOT NULL, "mtu" integer unsigned NULL CHECK ("mtu" >= 0), "vlan" 
integer unsigned NULL CHECK ("vlan"
 >= 0), "dot1q_support" bool NOT NULL, "rs_asn" integer unsigned NULL 
CHECK ("rs_asn" >= 0), "arp_sponge" varchar(17) NULL UNIQUE, "ix_id" 
integer NOT NULL REFERENCES "peeringdb_
ix" ("id") DEFERRABLE INITIALLY DEFERRED);
[...]

> And is it relevant? We are always only talking about API objects so far.

I was confused by you saying - "Let's see what PC comes up, once we remove 
ixlan.".  I now understand you meant in the db schema and not the REST 
API.

Thanks,
Chris