--- 0.20200227.3-CC-WM.txt 2020-02-27 17:12:16.786915088 +0000 +++ 0.20200303.2-CC-AN.txt 2020-03-03 17:40:38.155541816 +0000 @@ -1,7 +1,7 @@ PeeringDB Data Ownership Policy Document Date: TBD -Version: 0.20200227.3-CC-WM +Version: 0.20200303.2-CC-AN 1) Background @@ -94,48 +94,47 @@ can result in a conflict based on PeeringDB receiving differing information from two sources. -4) High Level Data Descriptions +4) User Interface Elements of PeeringDB -PeeringDB's mission is to facilitate the exchange of user-maintained +PeeringDB exists to facilitate the exchange of user-maintained interconnection related information. This information is presented in data -relating to entities known mainly as Organizations, Points of Contact, -Facilities, Internet Exchanges, and Networks in the Internet industry. -Derived from that is data relating to where Networks and IXs are located, -and to which IXs, Networks are connected to. +relating to entities known as Organizations, Facilities, Internet +Exchanges, and Networks in the Internet industry. Derived from that is +data relating to where Networks and IXs are located, and to which IXs, +Networks are connected to. 4.1) Organizations PeeringDB uses the term Organization to refer to the holding entity for any number of IXs, Facilities, and Networks. -4.2) Points of Contact +In the current implementation of PeeringDB, Organizations are denoted by +"org" data elements. -PeeringDB uses the term Point of Contact to refer to individuals or roles -along with optional name, email, and telephone information. +4.2) Facilities -4.3) Facilities - -PeeringDB uses the term Facility to record data centers which are +PeeringDB uses the term Facility to record data centers which are public centralized locations where computing and networking equipment of tenants -are located. Within the scope of PeeringDB, Facilities can house IXs and -Networks, and these entities can establish interconnection. +are located, and may include one or more meet-me-rooms. A Facility may +also simply be a public meet-me-room for interconnection. Within the scope +of PeeringDB, Facilities can house IXs and Networks, and these entities +can establish interconnection. -In the current implementation of PeeringDB, Facilities are -referenced in "fac", "ixfac", and "netfac" objects. +In the current implementation of PeeringDB, Facilities are denoted by +"fac" data elements and referenced in "ixfac" and "netfac" data elements. -One can find the following as the major information among Facility -records: +The major information among Facility records: -- the relevant Organization managing the Facility - ("org"), +- the relevant Organization managing the Facility - ("org") - IXs and Networks at the Facility - ("ixfac", "netfac") -4.4) Internet Exchanges +4.3) Internet Exchanges -The definition of an IX or Internet Exchange Point is beyond the scope of -this document. At a minimum, an IX is a communications fabric where -independent networks may engage in Internet Protocol peering - exchange of -Internet data. +PeeringDB uses the term Internet Exchange, also known as an Internet +Exchange Point, to refer to a network facility that enables the +interconnection of more than two independent Autonomous Systems, primarily +for the purpose of facilitating the exchange of Internet traffic. PeeringDB provides methods for both IXs and Networks to indicate the participation of a network at an IX. @@ -143,42 +142,90 @@ IXs may be present at one or more Facilities, and may indicate this in PeeringDB. -In the current implementation of PeeringDB, IXs are referenced in "ix", -"ixfac", "ixlan", "ixpfx", and "netixlan" objects. - -One can find the following as the major information among IX records: +In the current implementation of PeeringDB, IXs are denoted by "ix" data +elements and referenced in "ixfac", "ixlan", "ixpfx", and "netixlan" data +elements. -- the relevant Organization managing the IX - ("org"), +The major information among IX records: -- Contact Information - ("poc"), +- the relevant Organization managing the IX - ("org") -- Peering Local Area Networks (LANs) (MTU and VLAN details) of IXs - - ("ixlan"), +- Local Area Networks (LANs) (MTU and VLAN details) of IXs - ("ixlan") -- Peering LANs (IPv4 and IPv6 subnets) of IXs - ("ixpfx"), +- LANs (IPv4 and IPv6 subnets) of IXs - ("ixpfx") -- Peers at the IX and the specific IP addresses assigned to each - participant - ("netixlan"), +- Networks at the IX and the specific IP addresses assigned to each + participant - ("netixlan") -- Facilities that the IX is present at - ("ixfac") +- Facilities the IX is present at - ("ixfac") -4.5) Networks +4.4) Networks + +Entities with an Autonomous System Number (ASN) may be a Network in +PeeringDB. + +In the current implementation of PeeringDB, Networks are denoted by "net" +data elements and referenced in "as_set", "netfac", and "netixlan" data +elements. + +The major information among Network records: + +- the relevant Organization managing the Network - ("org") + +- Contact Information - ("poc") + +- Connection detail at an IX - ("netixlan") + +- Facilities the Network is present at - ("netfac") + +4.5) Points of Contact + +PeeringDB uses the term Point of Contact to refer to a Network role along +with optional name, email, and telephone information. + +In the current implementation of PeeringDB, Points of Contact are +denoted by "poc" data elements. + +4.6) Public Peering Exchange Points -A PeeringDB Network is a network with a globally unique Autonomous System -Number (ASN). +A Network may have a list of Public Peering Exchange Points that it is +connected to, along with IP address assignments, speed, and route server +peer status. -In the current implementation of PeeringDB, Networks are referenced in -"net", "netfac", and "netixlan" objects. +In the current implementation of PeeringDB, Public Peering Exchange Points +are denoted by "netixlan" data elements. -One can find the following as the major information among Network records: +4.7) Private Peering Facilities -- the relevant Organization managing the Network - ("org"), +A Network may have a list of Private Peering Facilities it is present at. -- Contact Information - ("poc"), +In the current implementation of PeeringDB, Private Peering Facilities are +denoted by "netfac" data elements. -- Network at an IX - ("netixlan") +4.8) LAN -- Network at a Facility - ("netfac") +Each Internet Exchange has a LAN with a configuration for the name, MTU, +whether IEEE 802.1Q is supported, and IX-F Member Import details. + +In the current implementation of PeeringDB, LANs are denoted by "ixlan" +data elements. + +4.9) Prefixes + +Each Internet Exchange has one or more Prefixes which represent an IPv4 or +IPv6 subnet at the IX. + +In the current implementation of PeeringDB, Prefixes are denoted by +"ixpfx" data elements. + +4.10) Local Facilities and Exchanges + +Each Internet Exchange may have a list of Local Facilities it is present +at, while each Facility may have a list of Internet Exchanges, or simply +Exchanges, it hosts. + +In the current implementation of PeeringDB, Local Facilities and Exchanges +are denoted by "ixfac" data elements. 5) Data Elements in PeeringDB @@ -188,9 +235,29 @@ https://peeringdb.com/apidocs/ For each data element, attributes/values and who can update them is listed -below. At the end of the section there is a Table as an executive summary. +below. -5.1) Single-party data elements. +Not all fields of a data element are writable or readable. In this +section these prefixes indicate nuanced fields: + + $: automatic fields, such as timestamps + %: derived (not writable) fields, such as count of related elements + &: deprecated + >: only present in POST/PUT + <: only present in GET + +In the below sections when it is stated: + + ... 'includes an "org_id" with associated privileges.' + +that is shorthand for: + + ... 'includes an "org_id", which points to an "org" data element. Users + with sufficient permission who are affiliated with the Organization + represented by that "org" data element are able to create, update, and + delete this data element.' + +5.1) Single-party Data Elements These data elements contain data provided by a single party. @@ -199,20 +266,20 @@ - Internet Routing Registry (IRR) as-set/route-set from "net" data element. -- The "net" data element from which this API result is derived, has a - parent "org" reference. Users with sufficient permission in the - Organization represented by that "org" data element are able to create, - update, and delete this "as_set" information. +- The "net" data element from which this API result is derived, includes + an "org_id", which points to an "org" data element. Users with + sufficient permission who are affiliated with the Organization + represented by that "org" data element are able to create, update, and + delete this "as_set" information. - The Admin Committee is also able to adjust this record under their discretion, such as at the request of the managing organization. - Example: - - Query: https://www.peeringdb.com/api/as_set/65512 - - Result: + - https://www.peeringdb.com/api/as_set/65512?depth=0 { - "65512": "AS-EXAMPLE" + < "65512": "AS-EXAMPLE" } 5.1.2) fac @@ -220,34 +287,37 @@ - "fac" represents a Facility. Information such as the name, location, and website are contained within the "fac" data element. -- The "fac" data element has a parent "org" reference. Users with - sufficient permission in the Organization represented by that "org" - data element are able to create, update, and delete this "fac" - information. +- The "fac" data element includes an "org_id" with associated privileges. - The Admin Committee is also able to adjust this record under their discretion, such as at the request of the managing organization. +- The deletion or alteration of a "fac" data element may cause associated + "ixfac" and "netfac" data elements to be deleted. Since this may cause + an operational impact, this Task Force recommends that PeeringDB be + modified to prevent disruptive changes to a "fac" data element while it + has one or more dependent data elements. Facilities may work with the + Admin Committee to remove dependent data elements in a safe manner. + - Example: - - Query: https://www.peeringdb.com/api/fac/# - - Result: + - https://www.peeringdb.com/api/fac/#?depth=0 { - "id": #, + < "id": #, "org_id": ##, - "org_name": "Example Building Owners", - "org": {}, + < "org_name": "Example Building Owners", "name": "Example Building", "website": "https://www.building.example/", "clli": "STTLWA", - "rencode": "", + "rencode": "string", "npanxx": "206-443", - "notes": "", - "net_count": 150, - "latitude": 47.6062, - "longitude": -122.3321, - "created": "2001-07-01T00:00:00Z", - "updated": "2020-07-01T20:15:05Z", + "notes": "string", + > "suggest": true, + % "net_count": 150, + % "latitude": 47.6062, + % "longitude": -122.3321, + $ "created": "2004-01-01T00:00:00Z", + $ "updated": "2020-01-01T00:00:00Z", "status": "ok", "address1": "123 Main", "address2": "Suite 321", @@ -263,22 +333,25 @@ location, website, and contact information are contained within the "ix" data element. -- The "ix" data element has a parent "org" reference. Users with - sufficient permission in the Organization represented by that "org" - data element are able to create, update, and delete this "ix" - information. +- The "ix" data element includes an "org_id" with associated privileges. - The Admin Committee is also able to adjust this record under their discretion, such as at the request of the managing organization. +- The deletion or alteration of an "ix" data element may cause associated + "netixlan" data elements to be deleted. Since this may cause an + operational impact, this Task Force recommends that PeeringDB be + modified to prevent disruptive changes to an "ix" data element while it + has one or more dependent data elements. Internet Exchanges may work + with the Admin Committee to remove dependent data elements in a safe + manner. + - Example: - - Query: https://www.peeringdb.com/api/ix/# - - Result: + - https://www.peeringdb.com/api/ix/#?depth=0 { - "id": #, + < "id": #, "org_id": ##, - "org": {}, "name": "Example IX", "name_long": "Example Internet Exchange", "city": "Seattle", @@ -294,78 +367,85 @@ "tech_email": "info@eix.example", "tech_phone": "+12065551212", "policy_email": "info@eix.example", - "policy_phone": "", - "fac_set": [], - "ixlan_set": [], - "net_count": 317, - "created": "2010-07-29T00:00:00Z", - "updated": "2020-01-22T06:32:52Z", - "status": "ok" + "policy_phone": "string", + > "suggest": true, + > "prefix": "string", + % "net_count": 317, + $ "created": "2004-01-01T00:00:00Z", + $ "updated": "2020-01-01T00:00:00Z", + "status": "ok", } 5.1.4) ixlan - "ixlan" represents some aspects of an Internet Exchange LAN such as the - LAN name, description, MTU, and VLAN identifier if any. It also points - to both the "ix" and "ixpfx" data elements. + name, MTU, whether IEEE 802.1Q is supported, and IX-F Member Import + details. It also points to the "ix" data element. -- The "ixlan" data element points to an "ix" data element, which has a - parent "org" reference. Users with sufficient permission in the - Organization represented by that "org" data element are able to create, - update, and delete this "ixlan" information. +- The "ixlan" data element includes an "ix_id", which points to an "ix" + data element, which includes an "org_id" with associated privileges. - The Admin Committee is also able to adjust this record under their discretion, such as at the request of the managing organization. +- The deletion or alteration of an "ixlan" data element may cause + associated "netixlan" data elements to be deleted. Since this may cause + an operational impact, this Task Force recommends that PeeringDB be + modified to prevent disruptive changes to an "ixlan" data element while + it has one or more dependent data elements. Internet Exchanges may work + with the Admin Committee to remove dependent data elements in a safe + manner. + - Example: - - Query: https://www.peeringdb.com/api/ixlan/# - - Result: + - https://www.peeringdb.com/api/ixlan/#?depth=0 { - "id": #, + < "id": #, "ix_id": #, - "ix": {}, "name": "MTU 1500", - "descr": "", + & "descr": "", "mtu": 1500, "dot1q_support": false, "rs_asn": 0, - "arp_sponge": null, - "net_set": [], - "ixpfx_set": [], - "created": "2010-07-29T00:00:00Z", - "updated": "2019-05-08T03:57:10Z", - "status": "ok" + "arp_sponge": "string", + > "ixf_ixp_member_list_url": "string", + > "ixf_ixp_import_enabled": true, + $ "created": "2004-01-01T00:00:00Z", + $ "updated": "2020-01-01T00:00:00Z", + "status": "ok", } 5.1.5) ixpfx - "ixpfx" represents the IP subnet of IP assignments on an Internet - Exchange LAN. It also points to both the associated "ixlan" data - element. + Exchange LAN. It also points to the associated "ixlan" data element. -- The "ixpfx" data element points to an "ixlan" data element, which points - to an "ix" data element, which has a parent "org" reference. Users with - sufficient permission in the Organization represented by that "org" - data element are able to create, update, and delete this "ixpfx" - information. +- The "ixpfx" data element includes an "ixlan_id", which points to an + "ixlan" data element, which includes an "ix_id", which points to an "ix" + data element, which includes an "org_id" with associated privileges. - The Admin Committee is also able to adjust this record under their discretion, such as at the request of the managing organization. +- The deletion or alteration of an "ixpfx" data element may cause + associated "netixlan" data elements to be deleted. Since this may cause + an operational impact, this Task Force recommends that PeeringDB be + modified to prevent disruptive changes to an "ixpfx" data element while + it has one or more dependent data elements. Internet Exchanges may work + with the Admin Committee to remove dependent data elements in a safe + manner. + - Example: - - Query: https://www.peeringdb.com/api/ixpfx/# - - Result: + - https://www.peeringdb.com/api/ixpfx/#?depth=0 { - "id": #, - "ixlan": {}, + < "id": #, "ixlan_id": ##, "protocol": "IPv4", "prefix": "192.0.2.0/24", - "created": "2010-07-29T00:00:00Z", - "updated": "2016-03-14T21:38:00Z", - "status": "ok" + $ "created": "2004-01-01T00:00:00Z", + $ "updated": "2020-01-01T00:00:00Z", + "status": "ok", } 5.1.6) net @@ -374,51 +454,45 @@ as-set/route-set, prefix counts, type of network, traffic ratios, policies, etc. are contained within the "net" data element. -- The "net" data element has a parent "org" reference. Users with - sufficient permission in the Organization represented by that "org" - data element are able to create, update, and delete this "net" - information. +- The "net" data element includes an "org_id" with associated privileges. - The Admin Committee is also able to adjust this record under their discretion, such as at the request of the managing organization. - Example: - - Query: https://www.peeringdb.com/api/net/# - - Result: + - https://www.peeringdb.com/api/net/#?depth=0 { - "id": #, + < "id": #, "org_id": ##, - "org": {}, "name": "Widget Corporation", "aka": "Widgets R Us", "website": "https://www.widgets.example/", "asn": 65512, - "looking_glass": "", - "route_server": "", + "looking_glass": "string", + "route_server": "string", "irr_as_set": "AS-EXAMPLE", "info_type": "Content", "info_prefixes4": 5, "info_prefixes6": 1, - "info_traffic": "", + "info_traffic": "string", "info_ratio": "Balanced", "info_scope": "Global", "info_unicast": true, "info_multicast": false, "info_ipv6": true, "info_never_via_route_servers": false, - "notes": "", + "notes": "string", "policy_url": "https://www.widgets.example/peering.html", "policy_general": "Open", "policy_locations": "Not Required", "policy_ratio": false, "policy_contracts": "Not Required", - "netfac_set": [], - "netixlan_set": [], - "poc_set": [], - "created": "2005-02-01T10:16:50Z", - "updated": "2019-10-04T16:43:46Z", - "status": "ok" + > "allow_ixp_update": true, + > "suggest": true, + $ "created": "2004-01-01T00:00:00Z", + $ "updated": "2020-01-01T00:00:00Z", + "status": "ok", } 5.1.7) org @@ -426,70 +500,62 @@ - "org" represents an Organization. Information such as the name, website, and address are contained within the "org" data element. -- Users with sufficient permission in the Organization represented by this - data element are able to create, update, and delete this "org" - information. +- Users with sufficient permission who are affiliated with the + Organization represented by this data element are able to create, + update, and delete this "org" information. - The Admin Committee is also able to adjust this record under their discretion, such as at the request of the managing organization. - Example: - - Query: https://www.peeringdb.com/api/org/# - - Result: + - https://www.peeringdb.com/api/org/#?depth=0 { - "id": #, + < "id": #, "name": "Widget Conglomerate", "website": "https://www.widgets.example/", - "notes": "", - "net_set": [], - "fac_set": [], - "ix_set": [], + "notes": "string", "address1": "123 Example St", - "address2": "", + "address2": "string", "city": "Seattle", "country": "US", "state": "WA", "zipcode": "90000", - "created": "2005-02-01T10:16:50Z", - "updated": "2019-10-04T16:33:10Z", - "status": "ok" + $ "created": "2004-01-01T00:00:00Z", + $ "updated": "2020-01-01T00:00:00Z", + "status": "ok", } 5.1.8) poc -- "poc" represents a Point of Contact. Information such as the name or - role name, visibility setting, telephone number, email address, and URL - are contained within the "poc" data element. - -- The "poc" data element points to a "net" data element, which has a - parent "org" reference. Users with sufficient permission in the - Organization represented by that "org" data element are able to create, - update, and delete this "poc" information. +- "poc" represents a Point of Contact. Information such as the role name, + contact name, visibility setting, telephone number, email address, and + URL are contained within the "poc" data element. + +- The "poc" data element includes a "net_id", which points to an "net" + data element, which includes an "org_id" with associated privileges. - The Admin Committee is also able to adjust this record under their discretion, such as at the request of the managing organization. - Example: - - Query: https://www.peeringdb.com/api/poc/# - - Result: + - https://www.peeringdb.com/api/poc/#?depth=0 { - "id": #, + < "id": #, "net_id": ##, - "net": {}, - "role": "NOC Example", + "role": "NOC", "visible": "Users", - "name": "Joe Example", + "name": "Example Network Operations", "phone": "206-555-1212", "email": "noc@widget.example", - "url": "", - "created": "2010-07-29T00:00:00Z", - "updated": "2016-03-14T20:31:04Z", - "status": "ok" + "url": "string", + $ "created": "2004-01-01T00:00:00Z", + $ "updated": "2020-01-01T00:00:00Z", + "status": "ok", } -5.2) Multi-party data elements. +5.2) Multi-party Data Elements These data elements can contain data provided by multiple parties. In cases of conflict between the data sources, the PeeringDB Admin Committee @@ -498,92 +564,70 @@ 5.2.1) netixlan -- "netixlan" represents the IP address assignments for a Network at an - Internet Exchange. These assignments are normally made by the Internet - Exchange and provided to the Network. - -- The "netixlan" data element points to a "net" data element, which has a - parent "org" reference. Users with sufficient permission in the - Organization represented by that "org" data element are able to create, - update, and delete this "netixlan" information. In addition, Networks - may take advantage of automated mechanisms that PeeringDB offers, which - utilize data publicly exported by Internet Exchanges. - -- A conflict may arise in which the IP assignment data publicly exported - by an Internet Exchange does not match data provided by a Network. - Alternatively, an Internet Exchange may reach out to PeeringDB to - dispute the IP assignment data provided by a Network. - - Since this data can have an impact on Internet operations, this document - specifies a principle of minimal disruption. This principle means that - conflicted data which is already published shall not be taken down - unless done so by the Network or by a resolution process mediated by the - Admin Committee. - - Similarly, conflicted data which has not been published shall not be - published until a resolution process has been mediated by the Admin - Committee and/or the conflict is resolved due to updated data from the - Internet Exchange or the Network. - - The Task Force recommends PeeringDB employ user interface methods and - email notifications to encourage data harmony between a Network and an - Internet Exchange, as a means of expediting resolution and decreasing - the burdens on the Admin Committee. +- "netixlan" represents the connection of a Network to an Internet + Exchange, including the IP address assignments. These assignments are + normally made by the Internet Exchange and provided to the Network. + +- In order for "netixlan" data elements to be created by a Network or + through automation enabled by a Network, an Internet Exchange must first + create related "ix", "ixlan", and "ixpfx" data elements. Due to this + dependency and a desire to prevent operational disruption, this Task + Force recommends in section 7 that "ix", "ixlan", and "ixpfx" data + elements not be able to be deleted or modified in such a way that would + impact dependent "netixlan" data elements. + +- The "netixlan" data element includes a "net_id", which points to an + "net" data element, which includes an "org_id" with associated + privileges. In addition, Networks may take advantage of automated + mechanisms that PeeringDB offers, which utilize data publicly exported + by Internet Exchanges. + +- See section 6.1 for conflict resolution recommendation. - Example: - - Query: https://www.peeringdb.com/api/netixlan/# - - Result: + - https://www.peeringdb.com/api/netixlan/#?depth=0 { - "id": #, + < "id": #, "net_id": ##, - "net": {}, - "ix_id": ###, - "name": "Example IX", + % "ix_id": ###, + % "name": "Example IX", "ixlan_id": ###, - "ixlan": {}, - "notes": "", + "notes": "string", "speed": 10000, "asn": 65512, "ipaddr4": "192.0.2.10", "ipaddr6": "2001:db8::10", "is_rs_peer": true, - "created": "2010-07-29T00:00:00Z", - "updated": "2019-03-02T03:15:13Z", - "status": "ok" + $ "created": "2004-01-01T00:00:00Z", + $ "updated": "2020-01-01T00:00:00Z", + "status": "ok", } 5.2.2) ixfac - "ixfac" represents the presence of an Internet Exchange at a Facility. -- The "ixfac" data element points to an "ix" data element, which has a - parent "org" reference. Users with sufficient permission in the - Organization represented by that "org" data element are able to create, - update, and delete this "ixfac" information. +- The "ixfac" data element includes an "ix_id", which points to an "ix" + data element, which includes an "org_id" with associated privileges. - While all Facilities have a parent Organization data element, not all of - those Organizations in PeeringDB have actual Users. Some Facilities are - the result of suggestions by other Users, while other Facilities are the - product of the migration from PeeringDB 1.x to PeeringDB 2.x. + those Organizations in PeeringDB have affiliated Users. Some Facilities + are the result of suggestions by other Users, while other Facilities are + the product of the migration from PeeringDB 1.x to PeeringDB 2.x. -- A conflict may arise in which a Facility with an actual owner disputes - the presence of an Internet Exchange at their Facility. In this case, - the Admin Committee is empowered to mediate a resolution process. +- See section 6.2 for conflict resolution recommendation. - Example: - - Query: https://www.peeringdb.com/api/ixfac/# - - Result: + - https://www.peeringdb.com/api/ixfac/#?depth=0 { - "id": #, + < "id": #, "ix_id": ##, - "ix": {}, "fac_id": ###, - "fac": {}, - "created": "2010-07-29T00:00:00Z", - "updated": "2016-03-14T21:44:51Z", - "status": "ok" + $ "created": "2004-01-01T00:00:00Z", + $ "updated": "2020-01-01T00:00:00Z", + "status": "ok", } 5.2.3) netfac @@ -592,37 +636,81 @@ information can include the name of the Facility, the location, and the ASN employed by the Network at the location. -- The "netfac" data element points to an "net" data element, which has a - parent "org" reference. Users with sufficient permission in the - Organization represented by that "org" data element are able to create, - update, and delete this "netfac" information. +- The "netfac" data element includes a "net_id", which points to an "net" + data element, which includes an "org_id" with associated privileges. - While all Facilities have a parent Organization data element, not all of - those Organizations in PeeringDB have actual Users. Some Facilities are - the result of suggestions by other Users, while other Facilities are the - product of the migration from PeeringDB 1.x to PeeringDB 2.x. + those Organizations in PeeringDB have affiliated Users. Some Facilities + are the result of suggestions by other Users, while other Facilities are + the product of the migration from PeeringDB 1.x to PeeringDB 2.x. -- A conflict may arise in which a Facility with an actual owner disputes - the presence of a Network at their Facility. In this case, the Admin - Committee is empowered to mediate a resolution process. +- See section 6.2 for conflict resolution recommendation. - Example: - - Query: https://www.peeringdb.com/api/netfac/# - - Result: + - https://www.peeringdb.com/api/netfac/#?depth=0 { - "id": #, - "name": "Example Building", - "city": "Seattle", - "country": "US", + < "id": #, + % "name": "Example Building", + % "city": "Seattle", + % "country": "US", "net_id": ##, - "net": {}, "fac_id": ###, - "fac": {}, "local_asn": 65512, - "created": "2010-07-29T00:00:00Z", - "updated": "2016-03-14T21:02:43Z", - "status": "ok" + $ "created": "2004-01-01T00:00:00Z", + $ "updated": "2020-01-01T00:00:00Z", + "status": "ok", } +6) Conflicted Data Resolution Recommendations + +6.1) netixlan + +A conflict may arise in which the IP assignment data publicly exported by +an Internet Exchange does not match data provided by a Network. +Alternatively, an Internet Exchange may reach out to PeeringDB to dispute +the IP assignment data provided by a Network. + +Since this data can have an impact on Internet operations, this document +specifies a principle of minimal disruption. This principle means that +conflicted data which is already published shall not be taken down unless +done so by the Network or by a resolution process mediated by the Admin +Committee. + +Similarly, conflicted data which has not been published shall not be +published until a resolution process has been mediated by the Admin +Committee and/or the conflict is resolved due to updated data from the +Internet Exchange or the Network. + +The Task Force recommends PeeringDB employ user interface methods and +email notifications to encourage data harmony between a Network and an +Internet Exchange, as a means of expediting resolution and decreasing the +burdens on the Admin Committee. + +6.2) ixfac & netfac + +A conflict may arise in which a Facility with an actual owner disputes the +presence of an Internet Exchange or Network at their Facility. In this +case, the Admin Committee is empowered to mediate a resolution process. + +7) Action Items + +7.1) "netixlan" dependency on "ix", "ixlan", and "ixpfx" + +In order to prevent operational disruption, this Task Force recommends +that PeeringDB be modified to prevent deletion or updates of "ix", +"ixlan", and "ixpfx" data elements from having a disruptive effect on +dependent "netixlan" data elements, when data exists that would be +disrupted. When needed, the removal of dependent data elements should be +coordinated by the Admin Committee. + +7.2) "ixfac" and "netfac" dependency on "fac" + +In order to prevent operational disruption, this Task Force recommends +that PeeringDB be modified to prevent deletion or updates of "fac" data +elements from having a disruptive effect on dependent "ixfac" and "netfac" +data elements, when data exists that would be disrupted. When needed, the +removal of dependent data elements should be coordinated by the Admin +Committee. + END