[PDB Data Ownership-TF] draft "Data Ownership Policy Document"

Bijal Sanghani bijal at peeringdb.com
Wed Mar 25 00:44:44 PDT 2020


I am happy with the document.

Thank you Filiz and Chris for pushing through.

Regards, Bijal 


> On 24 Mar 2020, at 14:44, 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