[PDB Data Ownership-TF] draft "Data Ownership Policy Document"
Chris Malayter
mustang at terahertz.net
Tue Mar 24 10:52:14 PDT 2020
I like the revision.
> On Mar 24, 2020, at 1:40 PM, Darrell Budic <darrell at unitedix.net> wrote:
>
> I like it as well.
>
> -Darrell
>
>> On Mar 24, 2020, at 9:44 AM, Chris Caputo <ccaputo at alt.net> wrote:
>>
>> Bill, I like your proposed change from:
>>
>> - This Task Force recommends that the Admin Committee charter be amended
>> by a dispute resolution procedure in general.
>>
>> to:
>>
>> - 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.
>>
>> May we hear from others regarding whether it is okay to substitute this
>> language?
>>
>> Thank you,
>> Chris
>>
>>> On Tue, 24 Mar 2020, William Marantz wrote:
>>> 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.
>>>
>>> I propose the following in place of "This Task Force recommends that the
>>> Admin Committee charter be amended by a dispute resolution procedure in
>>> general."
>>>
>>> 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.
>>>
>>> thanks
>>>
>>> -Bill
>>>
>>>> On Mon, Mar 23, 2020 at 9:16 PM Chris Caputo <ccaputo at alt.net> wrote:
>>> Off-list, I worked with Arnold and Job to come up with some language they
>>> both agree on regarding the Admin Committee & appeals. I then shared the
>>> changes (diff and complete draft below) with others and have noted their
>>> support, in order of approval:
>>>
>>> Chris Caputo
>>> Arnold Nipper
>>> Job Snijders
>>> Darrell Budic
>>> Patrick Gilmore
>>> William Marantz
>>> Terry Sweetser
>>>
>>> I welcome them and anyone else to share their feedback,
>>> caveats/reservations, etc.
>>>
>>> The intent of the change is to clarify from where the Admin Committee
>>> derives existence while also making clear a recommendation that the Admin
>>> Committee come up with a generalized dispute resolution procedure as part
>>> of a revised charter, which handles both the recommendations of this Task
>>> Force and other matters the Admin Committee deals with. It will be up to
>>> the PeeringDB Board to ensure that the new charter makes explicit an
>>> appeals process to the Board, prior to approving any new charter.
>>>
>>> The grammar of the below could potentially be corrected if there is
>>> support for it. For example, "be amended by a dispute" should likely
>>> become "be amended to include a dispute". Please let the list know if
>>> there is interest in that or other suggestions.
>>>
>>> I'll be the first to admit this is not perfect, but I do believe it is
>>> progress and something we can live with, even if not further improved
>>> upon.
>>>
>>> Thank you for your consideration,
>>> Chris
>>>
>>> -------------------------------------------------------------------------
>>>
>>> Versions & Diffs: https://www.caputo.com/dotf/
>>>
>>> -------------------------------------------------------------------------
>>>
>>> https://www.caputo.com/dotf/0.20200320.2-CC-AN-WM-DB_0.20200324.1-CC-AN-JS-DB-PG-WM-TS.diff.txt
>>>
>>> --- 0.20200320.2-CC-AN-WM-DB.txt 2020-03-20 18:00:43.398782366 +0000
>>> +++ 0.20200324.1-CC-AN-JS-DB-PG-WM-TS.txt 2020-03-24 01:08:48.994698417 +0000
>>> @@ -1,7 +1,7 @@
>>> PeeringDB Data Ownership Policy Document
>>>
>>> Date: TBD
>>> -Version: 0.20200320.2-CC-AN-WM-DB
>>> +Version: 0.20200324.1-CC-AN-JS-DB-PG-WM-TS
>>>
>>> 1) Background
>>>
>>> @@ -68,6 +68,11 @@
>>>
>>> 3.3) Admin Committee
>>>
>>> +Per the PeeringDB Bylaws, the affairs of PeeringDB are managed by a Board
>>> +of Directors elected by the members. The board created the Admin Committee
>>> +and this committee has a public charter that declares the committee is
>>> +"responsible for the day to day end-user support of PeeringDB".
>>> +
>>> The PeeringDB Admin Committee may alter data. This is done because as a
>>> community we want to make sure we have good quality data. Depending on the
>>> circumstances, data may be deleted, hidden, overridden, or flagged. The
>>> @@ -78,6 +83,9 @@
>>> deal with user data. The Task Force recommends this practice continue as
>>> having audit trails of all data is good practice.
>>>
>>> +This Task Force recommends that the Admin Committee charter be amended by
>>> +a dispute resolution procedure in general.
>>> +
>>> 3.4) Conflicted Data
>>>
>>> In some cases ownership of data elements may not be either/or, but rather
>>>
>>> -------------------------------------------------------------------------
>>>
>>> https://www.caputo.com/dotf/0.20200324.1-CC-AN-JS-DB-PG-WM-TS.txt
>>>
>>> PeeringDB Data Ownership Policy Document
>>>
>>> Date: TBD
>>> Version: 0.20200324.1-CC-AN-JS-DB-PG-WM-TS
>>>
>>> 1) Background
>>>
>>> The Data Ownership Task Force was established in September, 2019, with the
>>> aim of working on a PeeringDB Policy proposal about data ownership, after
>>> a need was recognized by the Product Committee as issues consistently had
>>> been raised relating to who owns the data in PeeringDB when more than one
>>> party is involved (ex: netixlan, ixfac, netfac).
>>>
>>> A call for participation to the Task Force was made on September 10th,
>>> 2019.
>>>
>>> 2) Scope
>>>
>>> The Data Ownership Task Force is established to discuss and agree on who
>>> owns the data tokens and/or objects in PeeringDB. Their agreements,
>>> findings, and any sort of recommendations will be documented in a Policy
>>> Document as a direct outcome of the Task Force.
>>>
>>> This Policy Document will include a clear description of each data element
>>> and the relation between each other, as well as who should be allowed to
>>> create, update, and delete them.
>>>
>>> The Task Force is estimated to conclude its work within about 6 months
>>> from its inception, which was September 2019. This time frame will be
>>> extended if the Task Force needs more time to conclude its work.
>>>
>>> The resulting Policy Document will be announced and shared with the
>>> PeeringDB Community.
>>>
>>> After the publishing of the Policy Document, the Task Force will end.
>>>
>>> 3) Overarching Principles
>>>
>>> 3.1) Purpose of PeeringDB
>>>
>>>> From https://www.peeringdb.com/about as of February 26th, 2020:
>>>
>>> - PeeringDB, as the name suggests, was set up to facilitate peering
>>> between networks and peering coordinators. In recent years, the vision
>>> of PeeringDB has developed to keep up with the speed and diverse manner
>>> in which the Internet is growing. The database is no longer just for
>>> peering and peering related information. It now includes all types of
>>> interconnection data for networks, clouds, services, and enterprise, as
>>> well as interconnection facilities that are developing at the edge of
>>> the Internet.
>>>
>>> - We believe in, and rely on the community to grow and improve the
>>> PeeringDB database. The volunteers who run the database are passionate
>>> about security, privacy, integrity, and validation of the data in the
>>> database. Even though PeeringDB is a freely available and public tool,
>>> users strictly adhere to the acceptable use policy
>>> (https://www.peeringdb.com/aup), which prevents the database being used
>>> for commercial purposes and discourages unsolicited communications.
>>> This is largely policed by the community and has been very effective
>>> since PeeringDB was launched.
>>>
>>> 3.2) Expectations
>>>
>>> - Data is expected to be consistent and correct following good
>>> engineering practices.
>>>
>>> - Users are expected to keep their Organization's data current.
>>>
>>> 3.3) Admin Committee
>>>
>>> Per the PeeringDB Bylaws, the affairs of PeeringDB are managed by a Board
>>> of Directors elected by the members. The board created the Admin Committee
>>> and this committee has a public charter that declares the committee is
>>> "responsible for the day to day end-user support of PeeringDB".
>>>
>>> The PeeringDB Admin Committee may alter data. This is done because as a
>>> community we want to make sure we have good quality data. Depending on the
>>> circumstances, data may be deleted, hidden, overridden, or flagged. The
>>> Admin Committee may perform research and/or involve multiple parties in
>>> order help resolve matters.
>>>
>>> The Admin Committee has their own ticketing and logging systems as they
>>> deal with user data. The Task Force recommends this practice continue as
>>> having audit trails of all data is good practice.
>>>
>>> This Task Force recommends that the Admin Committee charter be amended by
>>> a dispute resolution procedure in general.
>>>
>>> 3.4) Conflicted Data
>>>
>>> In some cases ownership of data elements may not be either/or, but rather
>>> may be nuanced. PeeringDB data is often used for Internet operations and
>>> changes should not disrupt existing operational processes. This policy
>>> 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, PeeringDB automation explicitly authorized by the
>>> Network, or by a resolution process mediated by the Admin Committee.
>>>
>>> For example, an Internet Exchange (IX) may have shared an IP assignment
>>> with a new participant in advance of updating the IX's public records,
>>> some of which may be processed by PeeringDB in an automated fashion. This
>>> can result in a conflict based on PeeringDB receiving differing
>>> information from two sources.
>>>
>>> 4) User Interface Elements of PeeringDB
>>>
>>> PeeringDB exists to facilitate the exchange of user-maintained
>>> interconnection related information. This information is presented in data
>>> 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.
>>>
>>> In the current implementation of PeeringDB, Organizations are denoted by
>>> "org" data elements.
>>>
>>> 4.2) Facilities
>>>
>>> PeeringDB uses the term Facility to record data centers which are public
>>> centralized locations where computing and networking equipment of tenants
>>> 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 denoted by
>>> "fac" data elements and referenced in "ixfac" and "netfac" data elements.
>>>
>>> The major information among Facility records:
>>>
>>> - the relevant Organization managing the Facility - ("org")
>>>
>>> - IXs and Networks at the Facility - ("ixfac", "netfac")
>>>
>>> 4.3) Internet Exchanges
>>>
>>> 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.
>>>
>>> IXs may be present at one or more Facilities, and may indicate this in
>>> PeeringDB.
>>>
>>> In the current implementation of PeeringDB, IXs are denoted by "ix" data
>>> elements and referenced in "ixfac", "ixlan", "ixpfx", and "netixlan" data
>>> elements.
>>>
>>> The major information among IX records:
>>>
>>> - the relevant Organization managing the IX - ("org")
>>>
>>> - Local Area Networks (LANs) (MTU and VLAN details) of IXs - ("ixlan")
>>>
>>> - LANs (IPv4 and IPv6 subnets) of IXs - ("ixpfx")
>>>
>>> - Networks at the IX and the specific IP addresses assigned to each
>>> participant - ("netixlan")
>>>
>>> - Facilities the IX is present at - ("ixfac")
>>>
>>> 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 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, Public Peering Exchange Points
>>> are denoted by "netixlan" data elements.
>>>
>>> 4.7) Private Peering Facilities
>>>
>>> A Network may have a list of Private Peering Facilities it is present at.
>>>
>>> In the current implementation of PeeringDB, Private Peering Facilities are
>>> denoted by "netfac" data elements.
>>>
>>> 4.8) LAN
>>>
>>> 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
>>>
>>> This section lists the data elements that are listed in PeeringDB API as
>>> listed at:
>>>
>>> https://peeringdb.com/apidocs/
>>>
>>> For each data element, attributes/values and who can update them is listed
>>> below.
>>>
>>> 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.
>>>
>>> 5.1.1) as_set
>>>
>>> - Internet Routing Registry (IRR) as-set/route-set from "net" data
>>> element.
>>>
>>> - 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:
>>> - https://www.peeringdb.com/api/as_set/65512?depth=0
>>>
>>> {
>>> < "65512": "AS-EXAMPLE"
>>> }
>>>
>>> 5.1.2) fac
>>>
>>> - "fac" represents a Facility. Information such as the name, location,
>>> and website are contained within the "fac" data element.
>>>
>>> - 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:
>>> - https://www.peeringdb.com/api/fac/#?depth=0
>>>
>>> {
>>> < "id": #,
>>> "org_id": ##,
>>> < "org_name": "Example Building Owners",
>>> "name": "Example Building",
>>> "website": "https://www.building.example/",
>>> "clli": "STTLWA",
>>> "rencode": "string",
>>> "npanxx": "206-443",
>>> "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",
>>> "city": "Seattle",
>>> "country": "US",
>>> "state": "WA",
>>> "zipcode": "90000"
>>> }
>>>
>>> 5.1.3) ix
>>>
>>> - "ix" represents an Internet Exchange. Information such as the name,
>>> location, website, and contact information are contained within the "ix"
>>> data element.
>>>
>>> - 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:
>>> - https://www.peeringdb.com/api/ix/#?depth=0
>>>
>>> {
>>> < "id": #,
>>> "org_id": ##,
>>> "name": "Example IX",
>>> "name_long": "Example Internet Exchange",
>>> "city": "Seattle",
>>> "country": "US",
>>> "region_continent": "North America",
>>> "media": "Ethernet",
>>> "notes": "EIX port fees: etc.\n",
>>> "proto_unicast": true,
>>> "proto_multicast": false,
>>> "proto_ipv6": true,
>>> "website": "https://www.eix.example/",
>>> "url_stats": "https://www.eix.example/statistics/",
>>> "tech_email": "info at eix.example",
>>> "tech_phone": "+12065551212",
>>> "policy_email": "info at eix.example",
>>> "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
>>> 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 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:
>>> - https://www.peeringdb.com/api/ixlan/#?depth=0
>>>
>>> {
>>> < "id": #,
>>> "ix_id": #,
>>> "name": "MTU 1500",
>>> & "descr": "",
>>> "mtu": 1500,
>>> "dot1q_support": false,
>>> "rs_asn": 0,
>>> "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 the associated "ixlan" data element.
>>>
>>> - 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:
>>> - https://www.peeringdb.com/api/ixpfx/#?depth=0
>>>
>>> {
>>> < "id": #,
>>> "ixlan_id": ##,
>>> "protocol": "IPv4",
>>> "prefix": "192.0.2.0/24",
>>> $ "created": "2004-01-01T00:00:00Z",
>>> $ "updated": "2020-01-01T00:00:00Z",
>>> "status": "ok",
>>> }
>>>
>>> 5.1.6) net
>>>
>>> - "net" represents a Network. Information such as the name, website, ASN,
>>> as-set/route-set, prefix counts, type of network, traffic ratios,
>>> policies, etc. are contained within the "net" data element.
>>>
>>> - 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:
>>> - https://www.peeringdb.com/api/net/#?depth=0
>>>
>>> {
>>> < "id": #,
>>> "org_id": ##,
>>> "name": "Widget Corporation",
>>> "aka": "Widgets R Us",
>>> "website": "https://www.widgets.example/",
>>> "asn": 65512,
>>> "looking_glass": "string",
>>> "route_server": "string",
>>> "irr_as_set": "AS-EXAMPLE",
>>> "info_type": "Content",
>>> "info_prefixes4": 5,
>>> "info_prefixes6": 1,
>>> "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": "string",
>>> "policy_url": "https://www.widgets.example/peering.html",
>>> "policy_general": "Open",
>>> "policy_locations": "Not Required",
>>> "policy_ratio": false,
>>> "policy_contracts": "Not Required",
>>>> "allow_ixp_update": true,
>>>> "suggest": true,
>>> $ "created": "2004-01-01T00:00:00Z",
>>> $ "updated": "2020-01-01T00:00:00Z",
>>> "status": "ok",
>>> }
>>>
>>> 5.1.7) org
>>>
>>> - "org" represents an Organization. Information such as the name, website,
>>> and address are contained within the "org" data element.
>>>
>>> - 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:
>>> - https://www.peeringdb.com/api/org/#?depth=0
>>>
>>> {
>>> < "id": #,
>>> "name": "Widget Conglomerate",
>>> "website": "https://www.widgets.example/",
>>> "notes": "string",
>>> "address1": "123 Example St",
>>> "address2": "string",
>>> "city": "Seattle",
>>> "country": "US",
>>> "state": "WA",
>>> "zipcode": "90000",
>>> $ "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 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:
>>> - https://www.peeringdb.com/api/poc/#?depth=0
>>>
>>> {
>>> < "id": #,
>>> "net_id": ##,
>>> "role": "NOC",
>>> "visible": "Users",
>>> "name": "Example Network Operations",
>>> "phone": "206-555-1212",
>>> "email": "noc at widget.example",
>>> "url": "string",
>>> $ "created": "2004-01-01T00:00:00Z",
>>> $ "updated": "2020-01-01T00:00:00Z",
>>> "status": "ok",
>>> }
>>>
>>> 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
>>> may become involved to help resolve differences. In addition, the
>>> PeeringDB user interface may help guide participants toward harmony.
>>>
>>> 5.2.1) netixlan
>>>
>>> - "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:
>>> - https://www.peeringdb.com/api/netixlan/#?depth=0
>>>
>>> {
>>> < "id": #,
>>> "net_id": ##,
>>> % "ix_id": ###,
>>> % "name": "Example IX",
>>> "ixlan_id": ###,
>>> "notes": "string",
>>> "speed": 10000,
>>> "asn": 65512,
>>> "ipaddr4": "192.0.2.10",
>>> "ipaddr6": "2001:db8::10",
>>> "is_rs_peer": true,
>>> $ "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 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 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.
>>>
>>> - See section 6.2 for conflict resolution recommendation.
>>>
>>> - Example:
>>> - https://www.peeringdb.com/api/ixfac/#?depth=0
>>>
>>> {
>>> < "id": #,
>>> "ix_id": ##,
>>> "fac_id": ###,
>>> $ "created": "2004-01-01T00:00:00Z",
>>> $ "updated": "2020-01-01T00:00:00Z",
>>> "status": "ok",
>>> }
>>>
>>> 5.2.3) netfac
>>>
>>> - "netfac" represents the presence of a Network at a Facility. This
>>> information can include the name of the Facility, the location, and the
>>> ASN employed by the Network at the location.
>>>
>>> - 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 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.
>>>
>>> - See section 6.2 for conflict resolution recommendation.
>>>
>>> - Example:
>>> - https://www.peeringdb.com/api/netfac/#?depth=0
>>>
>>> {
>>> < "id": #,
>>> % "name": "Example Building",
>>> % "city": "Seattle",
>>> % "country": "US",
>>> "net_id": ##,
>>> "fac_id": ###,
>>> "local_asn": 65512,
>>> $ "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, new data from an IX-F Member Import or which is entered by a
>>> Network, which conflicts with existing data, 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.
>>>
>>> It is understood that an IX-F Member Import may be incomplete, such as due
>>> to an information embargo requirement. If a conflict arises due to new
>>> data provided by a Network, the above conflict resolution recommendations
>>> are appropriate.
>>>
>>> 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
>>> --
>>> DataOwnership-TF mailing list
>>> DataOwnership-TF at lists.peeringdb.com
>>> https://lists.peeringdb.com/cgi-bin/mailman/listinfo/dataownership-tf
>>>
>>>
>>>
>>> --
>>> Bill Marantz
>>> Principal Network Engineer
>>> Backbone Engineering
>>> Mobile: 848-404-4613email: wmarantz at salesforce.com
>>>
>>>
>> --
>> DataOwnership-TF mailing list
>> DataOwnership-TF at lists.peeringdb.com
>> https://lists.peeringdb.com/cgi-bin/mailman/listinfo/dataownership-tf
>
> --
> DataOwnership-TF mailing list
> DataOwnership-TF at lists.peeringdb.com
> https://lists.peeringdb.com/cgi-bin/mailman/listinfo/dataownership-tf
More information about the DataOwnership-TF
mailing list