[PDB Data Ownership-TF] draft "Data Ownership Policy Document"
Chris Caputo
ccaputo at alt.net
Tue Mar 24 07:44:38 PDT 2020
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
>
>
>
More information about the DataOwnership-TF
mailing list