[PDB Data Ownership-TF] draft "Data Ownership Policy Document"
William Marantz
wmarantz at salesforce.com
Tue Mar 24 07:26:17 PDT 2020
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-4613
email: wmarantz at salesforce.com <ihamilton at salesforce.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.peeringdb.com/pipermail/dataownership-tf/attachments/20200324/2bf1a96e/attachment-0001.htm>
More information about the DataOwnership-TF
mailing list