[PDB Data Ownership-TF] draft "Data Ownership Policy Document"
Darrell Budic
darrell at unitedix.net
Tue Mar 24 10:40:35 PDT 2020
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
More information about the DataOwnership-TF
mailing list