[PDB Data Ownership-TF] conditions for being listed in a facility
arnold at nipper.de
Thu Jan 9 10:45:35 PST 2020
On 09.01.2020 18:00, Chris Caputo wrote:
> 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:
>>> I compared production:
>>> and beta (since it has the above change in place now):
>>> 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.
The ixlan object has none of these fields. Hence output is identical.
>> 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
>> 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
I meant in the API. We will drop ixlan in V3. I.e. there will be no
ixlan object any more. This is my understanding.
email: arnold at nipper.de
mobile: +49 172 2650958
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 261 bytes
Desc: OpenPGP digital signature
More information about the DataOwnership-TF