<div dir="ltr"><div>I'd prefer more clarity on intent ( assuming I properly captured the consensus opinion on intent ) in the sentence and not ending it with the phrase in general. However, if the majority want to leave the sentence alone I do not object.</div><div><br></div>I propose the following in place of "This Task Force recommends that the Admin Committee charter be amended by<br>a dispute resolution procedure in general."<br><br>This Task Force recommends that the Admin Committee charter be amended to include a general dispute resolution procedure that covers data ownership in addition to other potential disputes.<br><div><br></div><div>thanks</div><div><br></div><div> -Bill</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 23, 2020 at 9:16 PM Chris Caputo <<a href="mailto:ccaputo@alt.net">ccaputo@alt.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Off-list, I worked with Arnold and Job to come up with some language they <br>
both agree on regarding the Admin Committee & appeals. I then shared the <br>
changes (diff and complete draft below) with others and have noted their <br>
support, in order of approval:<br>
<br>
Chris Caputo<br>
Arnold Nipper<br>
Job Snijders<br>
Darrell Budic<br>
Patrick Gilmore<br>
William Marantz<br>
Terry Sweetser<br>
<br>
I welcome them and anyone else to share their feedback, <br>
caveats/reservations, etc.<br>
<br>
The intent of the change is to clarify from where the Admin Committee <br>
derives existence while also making clear a recommendation that the Admin <br>
Committee come up with a generalized dispute resolution procedure as part <br>
of a revised charter, which handles both the recommendations of this Task <br>
Force and other matters the Admin Committee deals with. It will be up to <br>
the PeeringDB Board to ensure that the new charter makes explicit an <br>
appeals process to the Board, prior to approving any new charter.<br>
<br>
The grammar of the below could potentially be corrected if there is <br>
support for it. For example, "be amended by a dispute" should likely <br>
become "be amended to include a dispute". Please let the list know if <br>
there is interest in that or other suggestions.<br>
<br>
I'll be the first to admit this is not perfect, but I do believe it is <br>
progress and something we can live with, even if not further improved <br>
upon.<br>
<br>
Thank you for your consideration,<br>
Chris<br>
<br>
-------------------------------------------------------------------------<br>
<br>
Versions & Diffs: <a href="https://www.caputo.com/dotf/" rel="noreferrer" target="_blank">https://www.caputo.com/dotf/</a><br>
<br>
-------------------------------------------------------------------------<br>
<br>
<a href="https://www.caputo.com/dotf/0.20200320.2-CC-AN-WM-DB_0.20200324.1-CC-AN-JS-DB-PG-WM-TS.diff.txt" rel="noreferrer" target="_blank">https://www.caputo.com/dotf/0.20200320.2-CC-AN-WM-DB_0.20200324.1-CC-AN-JS-DB-PG-WM-TS.diff.txt</a><br>
<br>
--- 0.20200320.2-CC-AN-WM-DB.txt 2020-03-20 18:00:43.398782366 +0000<br>
+++ 0.20200324.1-CC-AN-JS-DB-PG-WM-TS.txt 2020-03-24 01:08:48.994698417 +0000<br>
@@ -1,7 +1,7 @@<br>
PeeringDB Data Ownership Policy Document<br>
<br>
Date: TBD<br>
-Version: 0.20200320.2-CC-AN-WM-DB<br>
+Version: 0.20200324.1-CC-AN-JS-DB-PG-WM-TS<br>
<br>
1) Background<br>
<br>
@@ -68,6 +68,11 @@<br>
<br>
3.3) Admin Committee<br>
<br>
+Per the PeeringDB Bylaws, the affairs of PeeringDB are managed by a Board <br>
+of Directors elected by the members. The board created the Admin Committee <br>
+and this committee has a public charter that declares the committee is <br>
+"responsible for the day to day end-user support of PeeringDB".<br>
+<br>
The PeeringDB Admin Committee may alter data. This is done because as a <br>
community we want to make sure we have good quality data. Depending on the <br>
circumstances, data may be deleted, hidden, overridden, or flagged. The <br>
@@ -78,6 +83,9 @@<br>
deal with user data. The Task Force recommends this practice continue as <br>
having audit trails of all data is good practice.<br>
<br>
+This Task Force recommends that the Admin Committee charter be amended by <br>
+a dispute resolution procedure in general.<br>
+<br>
3.4) Conflicted Data<br>
<br>
In some cases ownership of data elements may not be either/or, but rather <br>
<br>
-------------------------------------------------------------------------<br>
<br>
<a href="https://www.caputo.com/dotf/0.20200324.1-CC-AN-JS-DB-PG-WM-TS.txt" rel="noreferrer" target="_blank">https://www.caputo.com/dotf/0.20200324.1-CC-AN-JS-DB-PG-WM-TS.txt</a><br>
<br>
PeeringDB Data Ownership Policy Document<br>
<br>
Date: TBD<br>
Version: 0.20200324.1-CC-AN-JS-DB-PG-WM-TS<br>
<br>
1) Background<br>
<br>
The Data Ownership Task Force was established in September, 2019, with the <br>
aim of working on a PeeringDB Policy proposal about data ownership, after <br>
a need was recognized by the Product Committee as issues consistently had <br>
been raised relating to who owns the data in PeeringDB when more than one <br>
party is involved (ex: netixlan, ixfac, netfac).<br>
<br>
A call for participation to the Task Force was made on September 10th, <br>
2019.<br>
<br>
2) Scope<br>
<br>
The Data Ownership Task Force is established to discuss and agree on who <br>
owns the data tokens and/or objects in PeeringDB. Their agreements, <br>
findings, and any sort of recommendations will be documented in a Policy <br>
Document as a direct outcome of the Task Force.<br>
<br>
This Policy Document will include a clear description of each data element <br>
and the relation between each other, as well as who should be allowed to <br>
create, update, and delete them.<br>
<br>
The Task Force is estimated to conclude its work within about 6 months <br>
from its inception, which was September 2019. This time frame will be <br>
extended if the Task Force needs more time to conclude its work.<br>
<br>
The resulting Policy Document will be announced and shared with the <br>
PeeringDB Community.<br>
<br>
After the publishing of the Policy Document, the Task Force will end.<br>
<br>
3) Overarching Principles<br>
<br>
3.1) Purpose of PeeringDB<br>
<br>
>From <a href="https://www.peeringdb.com/about" rel="noreferrer" target="_blank">https://www.peeringdb.com/about</a> as of February 26th, 2020:<br>
<br>
- PeeringDB, as the name suggests, was set up to facilitate peering <br>
between networks and peering coordinators. In recent years, the vision <br>
of PeeringDB has developed to keep up with the speed and diverse manner <br>
in which the Internet is growing. The database is no longer just for <br>
peering and peering related information. It now includes all types of <br>
interconnection data for networks, clouds, services, and enterprise, as <br>
well as interconnection facilities that are developing at the edge of <br>
the Internet.<br>
<br>
- We believe in, and rely on the community to grow and improve the <br>
PeeringDB database. The volunteers who run the database are passionate <br>
about security, privacy, integrity, and validation of the data in the <br>
database. Even though PeeringDB is a freely available and public tool, <br>
users strictly adhere to the acceptable use policy <br>
(<a href="https://www.peeringdb.com/aup" rel="noreferrer" target="_blank">https://www.peeringdb.com/aup</a>), which prevents the database being used <br>
for commercial purposes and discourages unsolicited communications. <br>
This is largely policed by the community and has been very effective <br>
since PeeringDB was launched.<br>
<br>
3.2) Expectations<br>
<br>
- Data is expected to be consistent and correct following good <br>
engineering practices.<br>
<br>
- Users are expected to keep their Organization's data current.<br>
<br>
3.3) Admin Committee<br>
<br>
Per the PeeringDB Bylaws, the affairs of PeeringDB are managed by a Board <br>
of Directors elected by the members. The board created the Admin Committee <br>
and this committee has a public charter that declares the committee is <br>
"responsible for the day to day end-user support of PeeringDB".<br>
<br>
The PeeringDB Admin Committee may alter data. This is done because as a <br>
community we want to make sure we have good quality data. Depending on the <br>
circumstances, data may be deleted, hidden, overridden, or flagged. The <br>
Admin Committee may perform research and/or involve multiple parties in <br>
order help resolve matters.<br>
<br>
The Admin Committee has their own ticketing and logging systems as they <br>
deal with user data. The Task Force recommends this practice continue as <br>
having audit trails of all data is good practice.<br>
<br>
This Task Force recommends that the Admin Committee charter be amended by <br>
a dispute resolution procedure in general.<br>
<br>
3.4) Conflicted Data<br>
<br>
In some cases ownership of data elements may not be either/or, but rather <br>
may be nuanced. PeeringDB data is often used for Internet operations and <br>
changes should not disrupt existing operational processes. This policy <br>
specifies a principle of minimal disruption. This principle means that <br>
conflicted data which is already published shall not be taken down unless <br>
done so by the Network, PeeringDB automation explicitly authorized by the <br>
Network, or by a resolution process mediated by the Admin Committee.<br>
<br>
For example, an Internet Exchange (IX) may have shared an IP assignment <br>
with a new participant in advance of updating the IX's public records, <br>
some of which may be processed by PeeringDB in an automated fashion. This <br>
can result in a conflict based on PeeringDB receiving differing <br>
information from two sources.<br>
<br>
4) User Interface Elements of PeeringDB<br>
<br>
PeeringDB exists to facilitate the exchange of user-maintained <br>
interconnection related information. This information is presented in data <br>
relating to entities known as Organizations, Facilities, Internet <br>
Exchanges, and Networks in the Internet industry. Derived from that is <br>
data relating to where Networks and IXs are located, and to which IXs, <br>
Networks are connected to.<br>
<br>
4.1) Organizations<br>
<br>
PeeringDB uses the term Organization to refer to the holding entity for <br>
any number of IXs, Facilities, and Networks.<br>
<br>
In the current implementation of PeeringDB, Organizations are denoted by <br>
"org" data elements.<br>
<br>
4.2) Facilities<br>
<br>
PeeringDB uses the term Facility to record data centers which are public <br>
centralized locations where computing and networking equipment of tenants <br>
are located, and may include one or more meet-me-rooms. A Facility may <br>
also simply be a public meet-me-room for interconnection. Within the scope <br>
of PeeringDB, Facilities can house IXs and Networks, and these entities <br>
can establish interconnection.<br>
<br>
In the current implementation of PeeringDB, Facilities are denoted by <br>
"fac" data elements and referenced in "ixfac" and "netfac" data elements.<br>
<br>
The major information among Facility records:<br>
<br>
- the relevant Organization managing the Facility - ("org")<br>
<br>
- IXs and Networks at the Facility - ("ixfac", "netfac")<br>
<br>
4.3) Internet Exchanges<br>
<br>
PeeringDB uses the term Internet Exchange, also known as an Internet <br>
Exchange Point, to refer to a network facility that enables the <br>
interconnection of more than two independent Autonomous Systems, primarily <br>
for the purpose of facilitating the exchange of Internet traffic.<br>
<br>
PeeringDB provides methods for both IXs and Networks to indicate the <br>
participation of a network at an IX.<br>
<br>
IXs may be present at one or more Facilities, and may indicate this in <br>
PeeringDB.<br>
<br>
In the current implementation of PeeringDB, IXs are denoted by "ix" data <br>
elements and referenced in "ixfac", "ixlan", "ixpfx", and "netixlan" data <br>
elements.<br>
<br>
The major information among IX records:<br>
<br>
- the relevant Organization managing the IX - ("org")<br>
<br>
- Local Area Networks (LANs) (MTU and VLAN details) of IXs - ("ixlan")<br>
<br>
- LANs (IPv4 and IPv6 subnets) of IXs - ("ixpfx")<br>
<br>
- Networks at the IX and the specific IP addresses assigned to each <br>
participant - ("netixlan")<br>
<br>
- Facilities the IX is present at - ("ixfac")<br>
<br>
4.4) Networks <br>
<br>
Entities with an Autonomous System Number (ASN) may be a Network in <br>
PeeringDB.<br>
<br>
In the current implementation of PeeringDB, Networks are denoted by "net" <br>
data elements and referenced in "as_set", "netfac", and "netixlan" data <br>
elements.<br>
<br>
The major information among Network records:<br>
<br>
- the relevant Organization managing the Network - ("org")<br>
<br>
- Contact Information - ("poc")<br>
<br>
- Connection detail at an IX - ("netixlan")<br>
<br>
- Facilities the Network is present at - ("netfac")<br>
<br>
4.5) Points of Contact<br>
<br>
PeeringDB uses the term Point of Contact to refer to a Network role along <br>
with optional name, email, and telephone information.<br>
<br>
In the current implementation of PeeringDB, Points of Contact are <br>
denoted by "poc" data elements.<br>
<br>
4.6) Public Peering Exchange Points<br>
<br>
A Network may have a list of Public Peering Exchange Points that it is <br>
connected to, along with IP address assignments, speed, and route server <br>
peer status.<br>
<br>
In the current implementation of PeeringDB, Public Peering Exchange Points <br>
are denoted by "netixlan" data elements.<br>
<br>
4.7) Private Peering Facilities<br>
<br>
A Network may have a list of Private Peering Facilities it is present at.<br>
<br>
In the current implementation of PeeringDB, Private Peering Facilities are <br>
denoted by "netfac" data elements.<br>
<br>
4.8) LAN<br>
<br>
Each Internet Exchange has a LAN with a configuration for the name, MTU, <br>
whether IEEE 802.1Q is supported, and IX-F Member Import details.<br>
<br>
In the current implementation of PeeringDB, LANs are denoted by "ixlan" <br>
data elements.<br>
<br>
4.9) Prefixes<br>
<br>
Each Internet Exchange has one or more Prefixes which represent an IPv4 or <br>
IPv6 subnet at the IX.<br>
<br>
In the current implementation of PeeringDB, Prefixes are denoted by <br>
"ixpfx" data elements.<br>
<br>
4.10) Local Facilities and Exchanges<br>
<br>
Each Internet Exchange may have a list of Local Facilities it is present <br>
at, while each Facility may have a list of Internet Exchanges, or simply <br>
Exchanges, it hosts.<br>
<br>
In the current implementation of PeeringDB, Local Facilities and Exchanges <br>
are denoted by "ixfac" data elements.<br>
<br>
5) Data Elements in PeeringDB<br>
<br>
This section lists the data elements that are listed in PeeringDB API as <br>
listed at:<br>
<br>
<a href="https://peeringdb.com/apidocs/" rel="noreferrer" target="_blank">https://peeringdb.com/apidocs/</a><br>
<br>
For each data element, attributes/values and who can update them is listed <br>
below.<br>
<br>
Not all fields of a data element are writable or readable. In this <br>
section these prefixes indicate nuanced fields:<br>
<br>
$: automatic fields, such as timestamps<br>
%: derived (not writable) fields, such as count of related elements<br>
&: deprecated<br>
>: only present in POST/PUT<br>
<: only present in GET<br>
<br>
In the below sections when it is stated:<br>
<br>
... 'includes an "org_id" with associated privileges.'<br>
<br>
that is shorthand for:<br>
<br>
... 'includes an "org_id", which points to an "org" data element. Users <br>
with sufficient permission who are affiliated with the Organization <br>
represented by that "org" data element are able to create, update, and <br>
delete this data element.'<br>
<br>
5.1) Single-party Data Elements<br>
<br>
These data elements contain data provided by a single party.<br>
<br>
5.1.1) as_set<br>
<br>
- Internet Routing Registry (IRR) as-set/route-set from "net" data <br>
element.<br>
<br>
- The "net" data element from which this API result is derived, includes <br>
an "org_id", which points to an "org" data element. Users with <br>
sufficient permission who are affiliated with the Organization <br>
represented by that "org" data element are able to create, update, and <br>
delete this "as_set" information.<br>
<br>
- The Admin Committee is also able to adjust this record under their <br>
discretion, such as at the request of the managing organization.<br>
<br>
- Example:<br>
- <a href="https://www.peeringdb.com/api/as_set/65512?depth=0" rel="noreferrer" target="_blank">https://www.peeringdb.com/api/as_set/65512?depth=0</a><br>
<br>
{<br>
< "65512": "AS-EXAMPLE"<br>
}<br>
<br>
5.1.2) fac<br>
<br>
- "fac" represents a Facility. Information such as the name, location, <br>
and website are contained within the "fac" data element.<br>
<br>
- The "fac" data element includes an "org_id" with associated privileges.<br>
<br>
- The Admin Committee is also able to adjust this record under their <br>
discretion, such as at the request of the managing organization.<br>
<br>
- The deletion or alteration of a "fac" data element may cause associated <br>
"ixfac" and "netfac" data elements to be deleted. Since this may cause <br>
an operational impact, this Task Force recommends that PeeringDB be <br>
modified to prevent disruptive changes to a "fac" data element while it <br>
has one or more dependent data elements. Facilities may work with the <br>
Admin Committee to remove dependent data elements in a safe manner.<br>
<br>
- Example:<br>
- <a href="https://www.peeringdb.com/api/fac/#?depth=0" rel="noreferrer" target="_blank">https://www.peeringdb.com/api/fac/#?depth=0</a><br>
<br>
{<br>
< "id": #,<br>
"org_id": ##,<br>
< "org_name": "Example Building Owners",<br>
"name": "Example Building",<br>
"website": "<a href="https://www.building.example/" rel="noreferrer" target="_blank">https://www.building.example/</a>",<br>
"clli": "STTLWA",<br>
"rencode": "string",<br>
"npanxx": "206-443",<br>
"notes": "string",<br>
> "suggest": true,<br>
% "net_count": 150,<br>
% "latitude": 47.6062,<br>
% "longitude": -122.3321,<br>
$ "created": "2004-01-01T00:00:00Z",<br>
$ "updated": "2020-01-01T00:00:00Z",<br>
"status": "ok",<br>
"address1": "123 Main",<br>
"address2": "Suite 321",<br>
"city": "Seattle",<br>
"country": "US",<br>
"state": "WA",<br>
"zipcode": "90000"<br>
}<br>
<br>
5.1.3) ix<br>
<br>
- "ix" represents an Internet Exchange. Information such as the name, <br>
location, website, and contact information are contained within the "ix" <br>
data element.<br>
<br>
- The "ix" data element includes an "org_id" with associated privileges.<br>
<br>
- The Admin Committee is also able to adjust this record under their <br>
discretion, such as at the request of the managing organization.<br>
<br>
- The deletion or alteration of an "ix" data element may cause associated <br>
"netixlan" data elements to be deleted. Since this may cause an <br>
operational impact, this Task Force recommends that PeeringDB be <br>
modified to prevent disruptive changes to an "ix" data element while it <br>
has one or more dependent data elements. Internet Exchanges may work <br>
with the Admin Committee to remove dependent data elements in a safe <br>
manner.<br>
<br>
- Example:<br>
- <a href="https://www.peeringdb.com/api/ix/#?depth=0" rel="noreferrer" target="_blank">https://www.peeringdb.com/api/ix/#?depth=0</a><br>
<br>
{<br>
< "id": #,<br>
"org_id": ##,<br>
"name": "Example IX",<br>
"name_long": "Example Internet Exchange",<br>
"city": "Seattle",<br>
"country": "US",<br>
"region_continent": "North America",<br>
"media": "Ethernet",<br>
"notes": "EIX port fees: etc.\n",<br>
"proto_unicast": true,<br>
"proto_multicast": false,<br>
"proto_ipv6": true,<br>
"website": "<a href="https://www.eix.example/" rel="noreferrer" target="_blank">https://www.eix.example/</a>",<br>
"url_stats": "<a href="https://www.eix.example/statistics/" rel="noreferrer" target="_blank">https://www.eix.example/statistics/</a>",<br>
"tech_email": "info@eix.example",<br>
"tech_phone": "+12065551212",<br>
"policy_email": "info@eix.example",<br>
"policy_phone": "string",<br>
> "suggest": true,<br>
> "prefix": "string",<br>
% "net_count": 317,<br>
$ "created": "2004-01-01T00:00:00Z",<br>
$ "updated": "2020-01-01T00:00:00Z",<br>
"status": "ok",<br>
}<br>
<br>
5.1.4) ixlan<br>
<br>
- "ixlan" represents some aspects of an Internet Exchange LAN such as the <br>
name, MTU, whether IEEE 802.1Q is supported, and IX-F Member Import <br>
details. It also points to the "ix" data element.<br>
<br>
- The "ixlan" data element includes an "ix_id", which points to an "ix" <br>
data element, which includes an "org_id" with associated privileges.<br>
<br>
- The Admin Committee is also able to adjust this record under their <br>
discretion, such as at the request of the managing organization.<br>
<br>
- The deletion or alteration of an "ixlan" data element may cause <br>
associated "netixlan" data elements to be deleted. Since this may cause <br>
an operational impact, this Task Force recommends that PeeringDB be <br>
modified to prevent disruptive changes to an "ixlan" data element while <br>
it has one or more dependent data elements. Internet Exchanges may work <br>
with the Admin Committee to remove dependent data elements in a safe <br>
manner.<br>
<br>
- Example:<br>
- <a href="https://www.peeringdb.com/api/ixlan/#?depth=0" rel="noreferrer" target="_blank">https://www.peeringdb.com/api/ixlan/#?depth=0</a><br>
<br>
{<br>
< "id": #,<br>
"ix_id": #,<br>
"name": "MTU 1500",<br>
& "descr": "",<br>
"mtu": 1500,<br>
"dot1q_support": false,<br>
"rs_asn": 0,<br>
"arp_sponge": "string",<br>
> "ixf_ixp_member_list_url": "string",<br>
> "ixf_ixp_import_enabled": true,<br>
$ "created": "2004-01-01T00:00:00Z",<br>
$ "updated": "2020-01-01T00:00:00Z",<br>
"status": "ok",<br>
}<br>
<br>
5.1.5) ixpfx<br>
<br>
- "ixpfx" represents the IP subnet of IP assignments on an Internet <br>
Exchange LAN. It also points to the associated "ixlan" data element.<br>
<br>
- The "ixpfx" data element includes an "ixlan_id", which points to an <br>
"ixlan" data element, which includes an "ix_id", which points to an "ix" <br>
data element, which includes an "org_id" with associated privileges.<br>
<br>
- The Admin Committee is also able to adjust this record under their <br>
discretion, such as at the request of the managing organization.<br>
<br>
- The deletion or alteration of an "ixpfx" data element may cause <br>
associated "netixlan" data elements to be deleted. Since this may cause <br>
an operational impact, this Task Force recommends that PeeringDB be <br>
modified to prevent disruptive changes to an "ixpfx" data element while <br>
it has one or more dependent data elements. Internet Exchanges may work <br>
with the Admin Committee to remove dependent data elements in a safe <br>
manner.<br>
<br>
- Example:<br>
- <a href="https://www.peeringdb.com/api/ixpfx/#?depth=0" rel="noreferrer" target="_blank">https://www.peeringdb.com/api/ixpfx/#?depth=0</a><br>
<br>
{<br>
< "id": #,<br>
"ixlan_id": ##,<br>
"protocol": "IPv4",<br>
"prefix": "<a href="http://192.0.2.0/24" rel="noreferrer" target="_blank">192.0.2.0/24</a>",<br>
$ "created": "2004-01-01T00:00:00Z",<br>
$ "updated": "2020-01-01T00:00:00Z",<br>
"status": "ok",<br>
}<br>
<br>
5.1.6) net<br>
<br>
- "net" represents a Network. Information such as the name, website, ASN, <br>
as-set/route-set, prefix counts, type of network, traffic ratios, <br>
policies, etc. are contained within the "net" data element.<br>
<br>
- The "net" data element includes an "org_id" with associated privileges.<br>
<br>
- The Admin Committee is also able to adjust this record under their <br>
discretion, such as at the request of the managing organization.<br>
<br>
- Example:<br>
- <a href="https://www.peeringdb.com/api/net/#?depth=0" rel="noreferrer" target="_blank">https://www.peeringdb.com/api/net/#?depth=0</a><br>
<br>
{<br>
< "id": #,<br>
"org_id": ##,<br>
"name": "Widget Corporation",<br>
"aka": "Widgets R Us",<br>
"website": "<a href="https://www.widgets.example/" rel="noreferrer" target="_blank">https://www.widgets.example/</a>",<br>
"asn": 65512,<br>
"looking_glass": "string",<br>
"route_server": "string",<br>
"irr_as_set": "AS-EXAMPLE",<br>
"info_type": "Content",<br>
"info_prefixes4": 5,<br>
"info_prefixes6": 1,<br>
"info_traffic": "string",<br>
"info_ratio": "Balanced",<br>
"info_scope": "Global",<br>
"info_unicast": true,<br>
"info_multicast": false,<br>
"info_ipv6": true,<br>
"info_never_via_route_servers": false,<br>
"notes": "string",<br>
"policy_url": "<a href="https://www.widgets.example/peering.html" rel="noreferrer" target="_blank">https://www.widgets.example/peering.html</a>",<br>
"policy_general": "Open",<br>
"policy_locations": "Not Required",<br>
"policy_ratio": false,<br>
"policy_contracts": "Not Required",<br>
> "allow_ixp_update": true,<br>
> "suggest": true,<br>
$ "created": "2004-01-01T00:00:00Z",<br>
$ "updated": "2020-01-01T00:00:00Z",<br>
"status": "ok",<br>
}<br>
<br>
5.1.7) org<br>
<br>
- "org" represents an Organization. Information such as the name, website, <br>
and address are contained within the "org" data element.<br>
<br>
- Users with sufficient permission who are affiliated with the <br>
Organization represented by this data element are able to create, <br>
update, and delete this "org" information.<br>
<br>
- The Admin Committee is also able to adjust this record under their <br>
discretion, such as at the request of the managing organization.<br>
<br>
- Example:<br>
- <a href="https://www.peeringdb.com/api/org/#?depth=0" rel="noreferrer" target="_blank">https://www.peeringdb.com/api/org/#?depth=0</a><br>
<br>
{<br>
< "id": #,<br>
"name": "Widget Conglomerate",<br>
"website": "<a href="https://www.widgets.example/" rel="noreferrer" target="_blank">https://www.widgets.example/</a>",<br>
"notes": "string",<br>
"address1": "123 Example St",<br>
"address2": "string",<br>
"city": "Seattle",<br>
"country": "US",<br>
"state": "WA",<br>
"zipcode": "90000",<br>
$ "created": "2004-01-01T00:00:00Z",<br>
$ "updated": "2020-01-01T00:00:00Z",<br>
"status": "ok",<br>
}<br>
<br>
5.1.8) poc<br>
<br>
- "poc" represents a Point of Contact. Information such as the role name, <br>
contact name, visibility setting, telephone number, email address, and <br>
URL are contained within the "poc" data element.<br>
<br>
- The "poc" data element includes a "net_id", which points to an "net" <br>
data element, which includes an "org_id" with associated privileges.<br>
<br>
- The Admin Committee is also able to adjust this record under their <br>
discretion, such as at the request of the managing organization.<br>
<br>
- Example:<br>
- <a href="https://www.peeringdb.com/api/poc/#?depth=0" rel="noreferrer" target="_blank">https://www.peeringdb.com/api/poc/#?depth=0</a><br>
<br>
{<br>
< "id": #,<br>
"net_id": ##,<br>
"role": "NOC",<br>
"visible": "Users",<br>
"name": "Example Network Operations",<br>
"phone": "206-555-1212",<br>
"email": "noc@widget.example",<br>
"url": "string",<br>
$ "created": "2004-01-01T00:00:00Z",<br>
$ "updated": "2020-01-01T00:00:00Z",<br>
"status": "ok",<br>
}<br>
<br>
5.2) Multi-party Data Elements<br>
<br>
These data elements can contain data provided by multiple parties. In <br>
cases of conflict between the data sources, the PeeringDB Admin Committee <br>
may become involved to help resolve differences. In addition, the <br>
PeeringDB user interface may help guide participants toward harmony.<br>
<br>
5.2.1) netixlan<br>
<br>
- "netixlan" represents the connection of a Network to an Internet <br>
Exchange, including the IP address assignments. These assignments are <br>
normally made by the Internet Exchange and provided to the Network.<br>
<br>
- In order for "netixlan" data elements to be created by a Network or <br>
through automation enabled by a Network, an Internet Exchange must first <br>
create related "ix", "ixlan", and "ixpfx" data elements. Due to this <br>
dependency and a desire to prevent operational disruption, this Task <br>
Force recommends in section 7 that "ix", "ixlan", and "ixpfx" data <br>
elements not be able to be deleted or modified in such a way that would <br>
impact dependent "netixlan" data elements.<br>
<br>
- The "netixlan" data element includes a "net_id", which points to an <br>
"net" data element, which includes an "org_id" with associated <br>
privileges. In addition, Networks may take advantage of automated <br>
mechanisms that PeeringDB offers, which utilize data publicly exported <br>
by Internet Exchanges.<br>
<br>
- See section 6.1 for conflict resolution recommendation.<br>
<br>
- Example:<br>
- <a href="https://www.peeringdb.com/api/netixlan/#?depth=0" rel="noreferrer" target="_blank">https://www.peeringdb.com/api/netixlan/#?depth=0</a><br>
<br>
{<br>
< "id": #,<br>
"net_id": ##,<br>
% "ix_id": ###,<br>
% "name": "Example IX",<br>
"ixlan_id": ###,<br>
"notes": "string",<br>
"speed": 10000,<br>
"asn": 65512,<br>
"ipaddr4": "192.0.2.10",<br>
"ipaddr6": "2001:db8::10",<br>
"is_rs_peer": true,<br>
$ "created": "2004-01-01T00:00:00Z",<br>
$ "updated": "2020-01-01T00:00:00Z",<br>
"status": "ok",<br>
}<br>
<br>
5.2.2) ixfac<br>
<br>
- "ixfac" represents the presence of an Internet Exchange at a Facility.<br>
<br>
- The "ixfac" data element includes an "ix_id", which points to an "ix" <br>
data element, which includes an "org_id" with associated privileges.<br>
<br>
- While all Facilities have a parent Organization data element, not all of <br>
those Organizations in PeeringDB have affiliated Users. Some Facilities <br>
are the result of suggestions by other Users, while other Facilities are <br>
the product of the migration from PeeringDB 1.x to PeeringDB 2.x.<br>
<br>
- See section 6.2 for conflict resolution recommendation.<br>
<br>
- Example:<br>
- <a href="https://www.peeringdb.com/api/ixfac/#?depth=0" rel="noreferrer" target="_blank">https://www.peeringdb.com/api/ixfac/#?depth=0</a><br>
<br>
{<br>
< "id": #,<br>
"ix_id": ##,<br>
"fac_id": ###,<br>
$ "created": "2004-01-01T00:00:00Z",<br>
$ "updated": "2020-01-01T00:00:00Z",<br>
"status": "ok",<br>
}<br>
<br>
5.2.3) netfac<br>
<br>
- "netfac" represents the presence of a Network at a Facility. This <br>
information can include the name of the Facility, the location, and the <br>
ASN employed by the Network at the location.<br>
<br>
- The "netfac" data element includes a "net_id", which points to an "net" <br>
data element, which includes an "org_id" with associated privileges.<br>
<br>
- While all Facilities have a parent Organization data element, not all of <br>
those Organizations in PeeringDB have affiliated Users. Some Facilities <br>
are the result of suggestions by other Users, while other Facilities are <br>
the product of the migration from PeeringDB 1.x to PeeringDB 2.x.<br>
<br>
- See section 6.2 for conflict resolution recommendation.<br>
<br>
- Example:<br>
- <a href="https://www.peeringdb.com/api/netfac/#?depth=0" rel="noreferrer" target="_blank">https://www.peeringdb.com/api/netfac/#?depth=0</a><br>
<br>
{<br>
< "id": #,<br>
% "name": "Example Building",<br>
% "city": "Seattle",<br>
% "country": "US",<br>
"net_id": ##,<br>
"fac_id": ###,<br>
"local_asn": 65512,<br>
$ "created": "2004-01-01T00:00:00Z",<br>
$ "updated": "2020-01-01T00:00:00Z",<br>
"status": "ok",<br>
}<br>
<br>
6) Conflicted Data Resolution Recommendations<br>
<br>
6.1) netixlan<br>
<br>
A conflict may arise in which the IP assignment data publicly exported by <br>
an Internet Exchange does not match data provided by a Network. <br>
Alternatively, an Internet Exchange may reach out to PeeringDB to dispute <br>
the IP assignment data provided by a Network.<br>
<br>
Since this data can have an impact on Internet operations, this document <br>
specifies a principle of minimal disruption. This principle means that <br>
conflicted data which is already published shall not be taken down unless <br>
done so by the Network or by a resolution process mediated by the Admin <br>
Committee.<br>
<br>
Similarly, new data from an IX-F Member Import or which is entered by a <br>
Network, which conflicts with existing data, shall not be published until <br>
a resolution process has been mediated by the Admin Committee and/or the <br>
conflict is resolved due to updated data from the Internet Exchange or the <br>
Network.<br>
<br>
The Task Force recommends PeeringDB employ user interface methods and <br>
email notifications to encourage data harmony between a Network and an <br>
Internet Exchange, as a means of expediting resolution and decreasing the <br>
burdens on the Admin Committee.<br>
<br>
It is understood that an IX-F Member Import may be incomplete, such as due <br>
to an information embargo requirement. If a conflict arises due to new <br>
data provided by a Network, the above conflict resolution recommendations <br>
are appropriate.<br>
<br>
6.2) ixfac & netfac<br>
<br>
A conflict may arise in which a Facility with an actual owner disputes the <br>
presence of an Internet Exchange or Network at their Facility. In this <br>
case, the Admin Committee is empowered to mediate a resolution process.<br>
<br>
7) Action Items<br>
<br>
7.1) "netixlan" dependency on "ix", "ixlan", and "ixpfx"<br>
<br>
In order to prevent operational disruption, this Task Force recommends <br>
that PeeringDB be modified to prevent deletion or updates of "ix", <br>
"ixlan", and "ixpfx" data elements from having a disruptive effect on <br>
dependent "netixlan" data elements, when data exists that would be <br>
disrupted. When needed, the removal of dependent data elements should be <br>
coordinated by the Admin Committee.<br>
<br>
7.2) "ixfac" and "netfac" dependency on "fac"<br>
<br>
In order to prevent operational disruption, this Task Force recommends <br>
that PeeringDB be modified to prevent deletion or updates of "fac" data <br>
elements from having a disruptive effect on dependent "ixfac" and "netfac" <br>
data elements, when data exists that would be disrupted. When needed, the <br>
removal of dependent data elements should be coordinated by the Admin <br>
Committee.<br>
<br>
END<br>
-- <br>
DataOwnership-TF mailing list<br>
<a href="mailto:DataOwnership-TF@lists.peeringdb.com" target="_blank">DataOwnership-TF@lists.peeringdb.com</a><br>
<a href="https://lists.peeringdb.com/cgi-bin/mailman/listinfo/dataownership-tf" rel="noreferrer" target="_blank">https://lists.peeringdb.com/cgi-bin/mailman/listinfo/dataownership-tf</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><b>Bill Marantz</b><br>Principal Network Engineer</div><div dir="ltr">Backbone Engineering<br>Mobile: 848-404-4613<div>email: <a href="mailto:ihamilton@salesforce.com" style="color:rgb(17,85,204)" target="_blank">wmarantz@salesforce.com</a><br></div></div></div></div></div></div><br></div></div></div></div></div>