diff --git a/index.html b/index.html
index aa384ea2..bed01c10 100644
--- a/index.html
+++ b/index.html
@@ -403,5 +403,5 @@ Keyboard Shortcuts
diff --git a/presentation/20241119_RSNOG10_Livio_Morina.pdf b/presentation/20241119_RSNOG10_Livio_Morina.pdf
new file mode 100644
index 00000000..d9b47709
Binary files /dev/null and b/presentation/20241119_RSNOG10_Livio_Morina.pdf differ
diff --git a/presentations/index.html b/presentations/index.html
index 04e76ee1..80f1c0ad 100644
--- a/presentations/index.html
+++ b/presentations/index.html
@@ -185,6 +185,7 @@
Presentations
2024
+- What's new on PeeringDB? at RSNOG 10, Belgrade, RS - November 19, 2024 - Livio Morina
- What's new on PeeringDB? at 8th South African Peering Forum, Cape Town, ZA - November 14, 2024 - Obinna Adumike
- What's new on PeeringDB? at nog.fi meeting 2024.11, Helsinki, FI - November 6, 2024 - Livio Morina
- PeeringDB Update at RIPE 89, Prague, CZ - October 31, 2024 - Leo Vegoda
diff --git a/search/search_index.json b/search/search_index.json
index 8c91c16d..66e3f689 100644
--- a/search/search_index.json
+++ b/search/search_index.json
@@ -1 +1 @@
-{"config":{"indexing":"full","lang":["en"],"min_search_length":3,"prebuild_index":false,"separator":"[\\s\\-]+"},"docs":[{"location":"","text":"About PeeringDB How can PeeringDB help me to interconnect? Policies By using this service, you agree to adhere to PeeringDB's Acceptable Use Policy . The Admin Committee Guidelines and Criteria for Approving Networks, IXPs, and Facilities documents PeeringDB\u2019s registration approval process. Getting started Several short HOWTOs provide a beginner detailed instructions on how to get started using PeeringDB. Create an account and register in PeeringDB. We also have a glossary of PeeringDB terms. Getting help Please log bugs and feature requests at GitHub . Questions, comments and everything else should go to support@peeringdb.com . Mailing lists We have changed the way in which PeeringDB will be announcing future enhancements, changes, maintenance windows, and other information. If you would like to be notified of certain events, or participate in certain discussions, please subscribe to one of the following email lists: PeeringDB Announce All PeeringDB administrative announcement information, such as upgrades, maintenances, outages, etc. PeeringDB Governance Discussion list for PeeringDB governance issues. This is a community-based effort, the community\u2019s input will help guide the future of the PeeringDB as it has always done. PeeringDB Technical Discussion about PeeringDB technical topics. PeeringDB Translate Discussions about PeeringDB translations. PeeringDB User-Discuss All other topics. Our goal is to give you all the information you want, and no more. Please subscribe to any of these lists you feel are appropriate, or none. You will still be able to use the database even if you are not subscribed to any lists. Quick API start PeeringDB is available at https://www.peeringdb.com/ with self-describing API docs at https://www.peeringdb.com/apidocs/ . More thorough docs are at API Specs , but in a nutshell, just prepend the URL with api/ to get that object in JSON. For example: https://www.peeringdb.com/net/1 becomes: https://www.peeringdb.com/api/net/1 List all via API by taking the id off: https://www.peeringdb.com/api/net Local database replication is accomplished with this command line tool , please see the documentation for more information. Release notes and schedule The release notes and schedule page lists upcoming releases, and the GitHub issues and a summary of what has changed in PeeringDB software releases. Guides [es] Gu\u00eda corta para uso de peeringdb.com - Fabi\u00e1n Mej\u00eda [pt-BR] Guia de cadastro de informa\u00e7\u00f5es de ASNs no PeeringDB - Julimar Lunguinho Mendes / Equipe de Engenharia [pt-BR] Guia de cadastro de informa\u00e7\u00f5es de Facilities no PeeringDB - Julimar Lunguinho Mendes / Equipe de Engenharia Tools The tools page features tools developed by PeeringDB users. Tutorials and workshops High-level HOWTOs provide a beginner detailed instructions on how to get started using PeeringDB. PDB 101 in 20 Minutes at Peering Asia 6.0 - November 5, 2024 - Arnold Nipper PeeringDB Tutorial, learning the GUI and the API at APRICOT 2022 - February 25, 2022 - Arnold Nipper The How-to Guide at Teraco Virtual Tech Day with PeeringDB - May 6, 2021 - Ben Ryall PeeringDB Tutorial, learning the GUI and the API at APRICOT 2020 , Melbourne, AU - February 20, 2020 - Arnold Nipper How is PeeringDB organised? and The PeeringDB API at DENOG11 , Hamburg, DE - November 10, 2019 - Arnold Nipper PeeringDB Workshop at AfPIF-10 , Balaclava, MV - August 20, 2019 - Arnold Nipper ( video starts at 14:00) Part 1: Intro , Part 2: Main , Part 3: API at APRICOT 2019 , Daejeon, KR - February 27, 2018 - Arnold Nipper ( video ) Presentations The presentations page has a complete list of PeeringDB presentations that were given at events around the world. Open source Source code audit PeeringDB commissioned a full audit of PeeringDB's source code in 2018. Computest (the auditor) prepared a Third Party Memo , this memo provides a high level overview of the outcome of the source code audit. The report is available here . Beta development The PeeringDB beta server runs the latest beta software version, with full access over HTTP and the API. Note that changes made to the beta database are local to the beta server only, and are not reflected on the production servers. The latest changes to PeeringDB automagically redirects to the list of issues on PeeringDB's GitHub repository that document all of the changes in the current beta version. Historical data MySQL dumps from July, 29 2010 to March 14, 2016 are archived by CAIDA at http://data.caida.org/datasets/peeringdb-v1/ . How you can help Check your entries and make sure everything looks correct Port any scripts to the new API Send us feedback Improve these docs Add or improve a translation Thanks for your feedback, we look forward to hearing from you!","title":"About"},{"location":"#about-peeringdb","text":"","title":"About PeeringDB"},{"location":"#how-can-peeringdb-help-me-to-interconnect","text":"","title":"How can PeeringDB help me to interconnect?"},{"location":"#policies","text":"By using this service, you agree to adhere to PeeringDB's Acceptable Use Policy . The Admin Committee Guidelines and Criteria for Approving Networks, IXPs, and Facilities documents PeeringDB\u2019s registration approval process.","title":"Policies"},{"location":"#getting-started","text":"Several short HOWTOs provide a beginner detailed instructions on how to get started using PeeringDB. Create an account and register in PeeringDB. We also have a glossary of PeeringDB terms.","title":"Getting started"},{"location":"#getting-help","text":"Please log bugs and feature requests at GitHub . Questions, comments and everything else should go to support@peeringdb.com .","title":"Getting help"},{"location":"#mailing-lists","text":"We have changed the way in which PeeringDB will be announcing future enhancements, changes, maintenance windows, and other information. If you would like to be notified of certain events, or participate in certain discussions, please subscribe to one of the following email lists: PeeringDB Announce All PeeringDB administrative announcement information, such as upgrades, maintenances, outages, etc. PeeringDB Governance Discussion list for PeeringDB governance issues. This is a community-based effort, the community\u2019s input will help guide the future of the PeeringDB as it has always done. PeeringDB Technical Discussion about PeeringDB technical topics. PeeringDB Translate Discussions about PeeringDB translations. PeeringDB User-Discuss All other topics. Our goal is to give you all the information you want, and no more. Please subscribe to any of these lists you feel are appropriate, or none. You will still be able to use the database even if you are not subscribed to any lists.","title":"Mailing lists"},{"location":"#quick-api-start","text":"PeeringDB is available at https://www.peeringdb.com/ with self-describing API docs at https://www.peeringdb.com/apidocs/ . More thorough docs are at API Specs , but in a nutshell, just prepend the URL with api/ to get that object in JSON. For example: https://www.peeringdb.com/net/1 becomes: https://www.peeringdb.com/api/net/1 List all via API by taking the id off: https://www.peeringdb.com/api/net Local database replication is accomplished with this command line tool , please see the documentation for more information.","title":"Quick API start"},{"location":"#release-notes-and-schedule","text":"The release notes and schedule page lists upcoming releases, and the GitHub issues and a summary of what has changed in PeeringDB software releases.","title":"Release notes and schedule"},{"location":"#guides","text":"[es] Gu\u00eda corta para uso de peeringdb.com - Fabi\u00e1n Mej\u00eda [pt-BR] Guia de cadastro de informa\u00e7\u00f5es de ASNs no PeeringDB - Julimar Lunguinho Mendes / Equipe de Engenharia [pt-BR] Guia de cadastro de informa\u00e7\u00f5es de Facilities no PeeringDB - Julimar Lunguinho Mendes / Equipe de Engenharia","title":"Guides"},{"location":"#tools","text":"The tools page features tools developed by PeeringDB users.","title":"Tools"},{"location":"#tutorials-and-workshops","text":"High-level HOWTOs provide a beginner detailed instructions on how to get started using PeeringDB. PDB 101 in 20 Minutes at Peering Asia 6.0 - November 5, 2024 - Arnold Nipper PeeringDB Tutorial, learning the GUI and the API at APRICOT 2022 - February 25, 2022 - Arnold Nipper The How-to Guide at Teraco Virtual Tech Day with PeeringDB - May 6, 2021 - Ben Ryall PeeringDB Tutorial, learning the GUI and the API at APRICOT 2020 , Melbourne, AU - February 20, 2020 - Arnold Nipper How is PeeringDB organised? and The PeeringDB API at DENOG11 , Hamburg, DE - November 10, 2019 - Arnold Nipper PeeringDB Workshop at AfPIF-10 , Balaclava, MV - August 20, 2019 - Arnold Nipper ( video starts at 14:00) Part 1: Intro , Part 2: Main , Part 3: API at APRICOT 2019 , Daejeon, KR - February 27, 2018 - Arnold Nipper ( video )","title":"Tutorials and workshops"},{"location":"#presentations","text":"The presentations page has a complete list of PeeringDB presentations that were given at events around the world.","title":"Presentations"},{"location":"#open-source","text":"","title":"Open source"},{"location":"#source-code-audit","text":"PeeringDB commissioned a full audit of PeeringDB's source code in 2018. Computest (the auditor) prepared a Third Party Memo , this memo provides a high level overview of the outcome of the source code audit. The report is available here .","title":"Source code audit"},{"location":"#beta-development","text":"The PeeringDB beta server runs the latest beta software version, with full access over HTTP and the API. Note that changes made to the beta database are local to the beta server only, and are not reflected on the production servers. The latest changes to PeeringDB automagically redirects to the list of issues on PeeringDB's GitHub repository that document all of the changes in the current beta version.","title":"Beta development"},{"location":"#historical-data","text":"MySQL dumps from July, 29 2010 to March 14, 2016 are archived by CAIDA at http://data.caida.org/datasets/peeringdb-v1/ .","title":"Historical data"},{"location":"#how-you-can-help","text":"Check your entries and make sure everything looks correct Port any scripts to the new API Send us feedback Improve these docs Add or improve a translation Thanks for your feedback, we look forward to hearing from you!","title":"How you can help"},{"location":"api_specs/","text":"RESTful API endpoints and specifications Object types and tags Each object has an associated short hand tag you can use, current available tags are listed at https://www.peeringdb.com/apidocs/ . Requests URL The URL base appended with /api/ , append with object type and optionally object primary key Object type is not case sensitive. For example: https://www.peeringdb.com/api/ OBJ / id Encoding To specify the output format, either use the Accept: HTTP header Accept: application/json Or use extension type https://www.peeringdb.com/api/network/42.json JSON all returns fit into object: { meta: { status: message: } data: [ {}, {} ] } meta are optional data always array Note Please let us know what serializers you'd like to see. Authentication Basic HTTP authorization In order to access the API as a guest simply omit any authentication Operations GET: multiple objects endpoint: GET /api/ OBJ optional URL parameters limit int limits rows in the result set skip int skips n rows in the result set depth int nested sets will be loaded (slow) fields str comma separated list of field names - only matching fields will be returned in the data since int retrieve all objects updated since specified time (unix timestamp, seconds) [field_name] int|string queries for fields with matching value returns array of objects HTTP: GET /api/OBJ curl: curl -X GET https://:@peeringdb.com/api/OBJ Nested data Any field ending in the suffix _set (with the exception of 'irr_as_set') is a list of objects in a relationship with the parent object, you can expand those lists with the 'depth' parameter as explained below. The naming schema of the field will always tell you which type of object the set is holding and will correspond with the object's endpoint on the API _set So a set called 'net_set' will hold Network objects (API endpoint /net) Note: unlike GET single, 'depth' here will ONLY expand sets, no single relationships will be expanded - this is by design Depth 0: don't expand anything (default) 1: expand all first level sets to ids 2: expand all first level sets to objects curl: curl -X GET https://:@peeringdb.com/api/OBJ?depth=2 Querying examples exact: curl -X GET https://:@peeringdb.com/api/OBJ?name=something modifier: curl -X GET https://:@peeringdb.com/api/OBJ?name__contains=something Querying modifiers numeric fields: __lt, less than __lte, less than equal __gt, greater than __gte, greater than equal __in, value inside set of values (comma separated) string fields: __contains, field value contains this value __startswith, field value starts with this value __in, value inside set of values (comma separated) Since You can use the since argument with a unix timestamp (seconds) to retrieve all objects updated since then. ?since=1443414678 GET: single object endpoint: GET /api/ OBJ / id required URL parameters id int optional URL parameters depth int defaults to 2 aka. nested sets and objects will be expanded fields str comma separated list of field names - only matching fields will be returned in the data returns single object in an array HTTP: GET /api/OBJ/42 curl: curl -H \"Accept: application/json\" -X GET https://:@peeringdb.com/api/OBJ/42 Nested data Any field ending in the suffix _set (with the exception of 'irr_as_set') is a list of objects in a relationship with the parent object, you can expand those lists with the 'depth' parameter as explained below. The naming schema of the field will always tell you which type of object the set is holding and will correspond with the object's endpoint on the API _set So a set called 'net_set' will hold Network objects (API endpoint /net) Note: unlike GET multiple, 'depth' here will also expand single relationship in addition to sets. So 'net_id' would get expanded into a network object. unexpanded: { ... \"net_id\" : 1 } expanded: { ... \"net_id\" : 1 \"net\" : { ... network object ... } } Depth 0: don't expand anything 1 to 4: expand all sets and related objects according to level of depth specified 2 is default POST: create new object endpoint: POST /api/ OBJ required URL parameters id int fields to post in either JSON obj \"{}\" or urlencoded field=value curl: curl -H \"Content-Type: application/json\" -X POST --data \"{\\\"state\\\":\\\"active\\\"}\" https://:@peeringdb.com/api/OBJ PUT: edit object endpoint: PUT /api/ OBJ / id required URL parameters id int fields to post in either JSON obj \"{}\" or urlencoded field=value you have to provide the complete object with modified data. Retrieve data with depth=0, modify and then put up again. HTTP: PUT /api/OBJ/42 curl: curl -H \"Content-Type: application/json\" -X PUT --data \"{\\\"state\\\":\\\"active\\\"}\" https://:@peeringdb.com/api/OBJ/42 DELETE: delete object endpoint: DELETE /api/ OBJ / id required URL parameters id int HTTP: DELETE /api/OBJ/42 curl: curl -H \"Accept: application/json\" -X DELETE https://:@peeringdb.com/api/OBJ/42 Deleted objects can be retrieved by filtering on status=deleted with since > 0. Real world example Q: I'd like to search for Microsoft's, Salesforce.com's and Amazon.com's peering points in Europe. How can I do this? A: You can use the API to perform complex queries, like in this example. curl -sG https://www.peeringdb.com/api/netixlan --data-urlencode net_id__in=694,1100,1418 --data-urlencode ix_id__in=`curl -sG https://www.peeringdb.com/api/ix --data-urlencode region_continent=Europe | jq -c '[.data[].id]' | sed 's/\\[//;s/\\]//'` | jq -c '.data[] | [.ix_id, .net_id, .ipaddr4, .ipaddr6, .speed]' | sort -V The query looks for netixlan records belonging to Microsoft, Salesforce.com and Amazone.com (net_id__in=694,1100,1418) which are constrained to IXes in Europe based on the output from the embedded query. The embedded query in single quotes looks for all IXes with \"Continental Region = Europe\". We do a little massaging on the IX ids to get a comma-separated list, which we then use as input in the query. curl -sG https://www.peeringdb.com/api/ix --data-urlencode region_continent=Europe | jq -c '[.data[].id]' | sed 's/\\[//;s/\\]//'","title":"API Specs"},{"location":"api_specs/#restful-api-endpoints-and-specifications","text":"","title":"RESTful API endpoints and specifications"},{"location":"api_specs/#object-types-and-tags","text":"Each object has an associated short hand tag you can use, current available tags are listed at https://www.peeringdb.com/apidocs/ .","title":"Object types and tags"},{"location":"api_specs/#requests","text":"","title":"Requests"},{"location":"api_specs/#url","text":"The URL base appended with /api/ , append with object type and optionally object primary key Object type is not case sensitive. For example: https://www.peeringdb.com/api/ OBJ / id","title":"URL"},{"location":"api_specs/#encoding","text":"To specify the output format, either use the Accept: HTTP header Accept: application/json Or use extension type https://www.peeringdb.com/api/network/42.json JSON all returns fit into object: { meta: { status: message: } data: [ {}, {} ] } meta are optional data always array Note Please let us know what serializers you'd like to see.","title":"Encoding"},{"location":"api_specs/#authentication","text":"Basic HTTP authorization In order to access the API as a guest simply omit any authentication","title":"Authentication"},{"location":"api_specs/#operations","text":"","title":"Operations"},{"location":"api_specs/#get-multiple-objects","text":"endpoint: GET /api/ OBJ optional URL parameters limit int limits rows in the result set skip int skips n rows in the result set depth int nested sets will be loaded (slow) fields str comma separated list of field names - only matching fields will be returned in the data since int retrieve all objects updated since specified time (unix timestamp, seconds) [field_name] int|string queries for fields with matching value returns array of objects HTTP: GET /api/OBJ curl: curl -X GET https://:@peeringdb.com/api/OBJ","title":"GET: multiple objects"},{"location":"api_specs/#nested-data","text":"Any field ending in the suffix _set (with the exception of 'irr_as_set') is a list of objects in a relationship with the parent object, you can expand those lists with the 'depth' parameter as explained below. The naming schema of the field will always tell you which type of object the set is holding and will correspond with the object's endpoint on the API _set So a set called 'net_set' will hold Network objects (API endpoint /net) Note: unlike GET single, 'depth' here will ONLY expand sets, no single relationships will be expanded - this is by design","title":"Nested data"},{"location":"api_specs/#depth","text":"0: don't expand anything (default) 1: expand all first level sets to ids 2: expand all first level sets to objects curl: curl -X GET https://:@peeringdb.com/api/OBJ?depth=2","title":"Depth"},{"location":"api_specs/#querying-examples","text":"exact: curl -X GET https://:@peeringdb.com/api/OBJ?name=something modifier: curl -X GET https://:@peeringdb.com/api/OBJ?name__contains=something","title":"Querying examples"},{"location":"api_specs/#querying-modifiers","text":"numeric fields: __lt, less than __lte, less than equal __gt, greater than __gte, greater than equal __in, value inside set of values (comma separated) string fields: __contains, field value contains this value __startswith, field value starts with this value __in, value inside set of values (comma separated)","title":"Querying modifiers"},{"location":"api_specs/#since","text":"You can use the since argument with a unix timestamp (seconds) to retrieve all objects updated since then. ?since=1443414678","title":"Since"},{"location":"api_specs/#get-single-object","text":"endpoint: GET /api/ OBJ / id required URL parameters id int optional URL parameters depth int defaults to 2 aka. nested sets and objects will be expanded fields str comma separated list of field names - only matching fields will be returned in the data returns single object in an array HTTP: GET /api/OBJ/42 curl: curl -H \"Accept: application/json\" -X GET https://:@peeringdb.com/api/OBJ/42","title":"GET: single object"},{"location":"api_specs/#nested-data_1","text":"Any field ending in the suffix _set (with the exception of 'irr_as_set') is a list of objects in a relationship with the parent object, you can expand those lists with the 'depth' parameter as explained below. The naming schema of the field will always tell you which type of object the set is holding and will correspond with the object's endpoint on the API _set So a set called 'net_set' will hold Network objects (API endpoint /net) Note: unlike GET multiple, 'depth' here will also expand single relationship in addition to sets. So 'net_id' would get expanded into a network object. unexpanded: { ... \"net_id\" : 1 } expanded: { ... \"net_id\" : 1 \"net\" : { ... network object ... } }","title":"Nested data"},{"location":"api_specs/#depth_1","text":"0: don't expand anything 1 to 4: expand all sets and related objects according to level of depth specified 2 is default","title":"Depth"},{"location":"api_specs/#post-create-new-object","text":"endpoint: POST /api/ OBJ required URL parameters id int fields to post in either JSON obj \"{}\" or urlencoded field=value curl: curl -H \"Content-Type: application/json\" -X POST --data \"{\\\"state\\\":\\\"active\\\"}\" https://:@peeringdb.com/api/OBJ","title":"POST: create new object"},{"location":"api_specs/#put-edit-object","text":"endpoint: PUT /api/ OBJ / id required URL parameters id int fields to post in either JSON obj \"{}\" or urlencoded field=value you have to provide the complete object with modified data. Retrieve data with depth=0, modify and then put up again. HTTP: PUT /api/OBJ/42 curl: curl -H \"Content-Type: application/json\" -X PUT --data \"{\\\"state\\\":\\\"active\\\"}\" https://:@peeringdb.com/api/OBJ/42","title":"PUT: edit object"},{"location":"api_specs/#delete-delete-object","text":"endpoint: DELETE /api/ OBJ / id required URL parameters id int HTTP: DELETE /api/OBJ/42 curl: curl -H \"Accept: application/json\" -X DELETE https://:@peeringdb.com/api/OBJ/42 Deleted objects can be retrieved by filtering on status=deleted with since > 0.","title":"DELETE: delete object"},{"location":"api_specs/#real-world-example","text":"Q: I'd like to search for Microsoft's, Salesforce.com's and Amazon.com's peering points in Europe. How can I do this? A: You can use the API to perform complex queries, like in this example. curl -sG https://www.peeringdb.com/api/netixlan --data-urlencode net_id__in=694,1100,1418 --data-urlencode ix_id__in=`curl -sG https://www.peeringdb.com/api/ix --data-urlencode region_continent=Europe | jq -c '[.data[].id]' | sed 's/\\[//;s/\\]//'` | jq -c '.data[] | [.ix_id, .net_id, .ipaddr4, .ipaddr6, .speed]' | sort -V The query looks for netixlan records belonging to Microsoft, Salesforce.com and Amazone.com (net_id__in=694,1100,1418) which are constrained to IXes in Europe based on the output from the embedded query. The embedded query in single quotes looks for all IXes with \"Continental Region = Europe\". We do a little massaging on the IX ids to get a comma-separated list, which we then use as input in the query. curl -sG https://www.peeringdb.com/api/ix --data-urlencode region_continent=Europe | jq -c '[.data[].id]' | sed 's/\\[//;s/\\]//'","title":"Real world example"},{"location":"blogs/","text":"PeeringDB Blogs 2024 PeeringDB blogs provide deeper insight into the releases and product roadmap. October 2024 PeeringDB Product Update - October 4, 2024 Data Quality \u2014 Removing Closed Networks - September 7, 2024 Structured Data and More With PeeringDB - July 31, 2024 Containerized Deployment - July 12, 2024 Making beta.peeringdb.com, Search, and KMZ More Attractive - April 15, 2024 Better Search and Export - March 14, 2024 2023 Product Report - February 19, 2024 What happened to our web UI? - February 5, 2024 Better Data - January 19, 2024 2023 PeeringDB Whois Service to Close - November 3, 2023 Your Internal Source of Truth Can Now Push Updates to PeeringDB - November 2, 2023 See Locations in PeeringDB on a Map - October 25, 2023 Alphabetical Search Results - July 21, 2023 Network Type \u2013 What did you tell us? - July 12, 2023 We're Updating our Web UI - July 6, 2023 Network Type \u2013 Your Input Sought - June 3, 2023 New Permission: Manage Peering Sessions - May 23, 2023 Search Gets Better - May 17, 2023 PeeringDB in Your Preferred Language - March 24, 2023 User Suggestions Improve PeeringDB Usability - March 24, 2023 Do You Want Your Configuration Management System to Update PeeringDB - February 23, 2023 PeeringDB's Product Roadmap for 2023 - February 6, 2023 Carrier Objects - January 24, 2023 PeeringDB 2022 Product Report - January 9, 2023 2022 Installing peeringdb-py at NANOG 86 - November 8, 2022 Introducing Analytics - November 3, 2022 Data Quality Improvements Rolled Out - October 26, 2022 API Writes now Need an API Key - September 25, 2022 Organizational Policy Features and More - September 25, 2022 PeeringDB 2022 User Survey - September 14, 2022 Faster PeeringDB Queries - No Limits - July 26, 2022 NANOG 85 Hackathon Project - April 25, 2022 Improve Your Account Security - And Check Our URL - March 28, 2022 2021 Survey Results and 2022 Product Roadmap - February 10, 2022 PeeringDB is Developed by its Community - January 17, 2022 2021 Guidelines for Registering in PeeringDB - October 21, 2021 Your Logo Goes Here! - October 12, 2021 More Details on Facilities - September 21, 2021 Changes to Contacts Marked as Private - September 14, 2021 PeeringDB 2021 User Survey - September 7, 2021 Automating Configuration - Why We Support the IX-F Member Export Schema - August 18, 2021 Advanced Search (Part 2) - July 23, 2021 Should PeeringDB Create a New \u201cCarrier\u201d Object? - July 5, 2021 Advanced Search (Part 1) - June 23, 2021 PeeringDB Can Bring Users to Your Application - May 24, 2021 Getting the Most from PeeringDB with User Developed Tools - May 4, 2021 Geographic Search - March 24, 2021 API Keys - March 10, 2021 2020 Survey Results and 2021 Product Roadmap - March 9, 2021 2020 Contributing Code to PeeringDB Just Got Easier - December 7, 2020 PeeringDB Release v2.24.0 - November 12, 2020 PeeringDB 2020 Satisfaction Survey - November 2, 2020 PeeringDB Release v2.23.0 - October 7, 2020","title":"Blogs"},{"location":"blogs/#peeringdb-blogs","text":"","title":"PeeringDB Blogs"},{"location":"blogs/#2024","text":"PeeringDB blogs provide deeper insight into the releases and product roadmap. October 2024 PeeringDB Product Update - October 4, 2024 Data Quality \u2014 Removing Closed Networks - September 7, 2024 Structured Data and More With PeeringDB - July 31, 2024 Containerized Deployment - July 12, 2024 Making beta.peeringdb.com, Search, and KMZ More Attractive - April 15, 2024 Better Search and Export - March 14, 2024 2023 Product Report - February 19, 2024 What happened to our web UI? - February 5, 2024 Better Data - January 19, 2024","title":"2024"},{"location":"blogs/#2023","text":"PeeringDB Whois Service to Close - November 3, 2023 Your Internal Source of Truth Can Now Push Updates to PeeringDB - November 2, 2023 See Locations in PeeringDB on a Map - October 25, 2023 Alphabetical Search Results - July 21, 2023 Network Type \u2013 What did you tell us? - July 12, 2023 We're Updating our Web UI - July 6, 2023 Network Type \u2013 Your Input Sought - June 3, 2023 New Permission: Manage Peering Sessions - May 23, 2023 Search Gets Better - May 17, 2023 PeeringDB in Your Preferred Language - March 24, 2023 User Suggestions Improve PeeringDB Usability - March 24, 2023 Do You Want Your Configuration Management System to Update PeeringDB - February 23, 2023 PeeringDB's Product Roadmap for 2023 - February 6, 2023 Carrier Objects - January 24, 2023 PeeringDB 2022 Product Report - January 9, 2023","title":"2023"},{"location":"blogs/#2022","text":"Installing peeringdb-py at NANOG 86 - November 8, 2022 Introducing Analytics - November 3, 2022 Data Quality Improvements Rolled Out - October 26, 2022 API Writes now Need an API Key - September 25, 2022 Organizational Policy Features and More - September 25, 2022 PeeringDB 2022 User Survey - September 14, 2022 Faster PeeringDB Queries - No Limits - July 26, 2022 NANOG 85 Hackathon Project - April 25, 2022 Improve Your Account Security - And Check Our URL - March 28, 2022 2021 Survey Results and 2022 Product Roadmap - February 10, 2022 PeeringDB is Developed by its Community - January 17, 2022","title":"2022"},{"location":"blogs/#2021","text":"Guidelines for Registering in PeeringDB - October 21, 2021 Your Logo Goes Here! - October 12, 2021 More Details on Facilities - September 21, 2021 Changes to Contacts Marked as Private - September 14, 2021 PeeringDB 2021 User Survey - September 7, 2021 Automating Configuration - Why We Support the IX-F Member Export Schema - August 18, 2021 Advanced Search (Part 2) - July 23, 2021 Should PeeringDB Create a New \u201cCarrier\u201d Object? - July 5, 2021 Advanced Search (Part 1) - June 23, 2021 PeeringDB Can Bring Users to Your Application - May 24, 2021 Getting the Most from PeeringDB with User Developed Tools - May 4, 2021 Geographic Search - March 24, 2021 API Keys - March 10, 2021 2020 Survey Results and 2021 Product Roadmap - March 9, 2021","title":"2021"},{"location":"blogs/#2020","text":"Contributing Code to PeeringDB Just Got Easier - December 7, 2020 PeeringDB Release v2.24.0 - November 12, 2020 PeeringDB 2020 Satisfaction Survey - November 2, 2020 PeeringDB Release v2.23.0 - October 7, 2020","title":"2020"},{"location":"faq/","text":"Frequently Asked Questions General What is PeeringDB? PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions. The database is a non-profit, community-driven initiative run and promoted by volunteers. It is a public tool for the growth and good of the Internet. Join the community and support the continued development of the Internet. How do I get started? See our Quick Start guide: http://docs.peeringdb.com/#quick-start Affiliation requests Q: How does affiliation to an organization work? A: After you have registered, go to your profile . If your organization owns a network (also called AS or ASN), type in the AS number into the field ASN . Then click on the button Affiliate . If your ASN already is in PeeringDB and your org record does not yet have an admin account this request will be sent to PeeringDB Support If your organisation already has one or more admins your request is forwarded to them. They will have to approve / deny your request If your ASN is not in PeeringDB this procedure will first try to retrieve information about this ASN via RDAP to prepopulate the net record and the org record in case it also does not exist. We also use information from this query to auto approve your request if the email address in the RDAP record matches your email address. If this fails your request will be sent to PeeringDB Support You may also use the field organisation to request affiliation to an existing or new organisation. Start typing the name of your company and select from the popup or create a new organisation. Your request is sent to your admins if there is one or to PeeringDB Support otherwise In any case you should get an answer either from your admin or PeeringDB Support . If you don't get an answer within two working days, please mail PeeringDB Support providing necessary information (ASN, Organization). Technical How do I query by ASN? You may type in the ASN in the search box, or for web: http://as42.peeringdb.com https://www.peeringdb.com/net?asn=42 For API: https://www.peeringdb.com/api/net?asn=42 Using /asn used to work, what happened? Please see http://lists.peeringdb.com/pipermail/pdb-announce/2016-March/000036.html for details. How do the new permissions work? Now there is an org entity which owns the records. A record can be a facility, an exchange point, or a network. Users are added to the org entity and can then be given access to any facility, any network, any exchange point, or anything the org itself owns. Authenticating via embedded user/pass in the URL Support for this depends on the client and some browsers have stopped supporting embedded authentication in the URL So for example https://:@peeringdb.com/api/net/1 may work or it may not depending on the browser you are using. Why are dates represented as strings in the API? Date strings are ISO 8601 to keep a standard format. Comparison operations such as __gt , __lt , etc all still work as expected. For fetching records against updated timestamp, you may also use ?since= How do I sync the whole database to my local machine? You may make a full local copy with https://github.com/peeringdb/peeringdb-py , see docs at http://peeringdb.github.io/peeringdb-py/cli/ The initial run will perform a full sync, while subsequent runs will incrementally update changed records. Alternatively peeringdb-simplesync can be used to maintain a mirror in PostgreSQL. When syncing to MySQL I get 'Illegal mix of collations' Such as: django.db.utils.OperationalError: (1267, \"Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation '='\") We will fix that when time allows, for the time being, just run: alter database peeringdb default character set utf8 default collate utf8_unicode_ci; What does the Never via route servers flag mean and how does it work? With release 2.18.0 a new feature Never via route servers (API field info_never_via_route_servers ) has been introduced. There is a tick box in section \"Protocols Supported\" to set it. If set it is a hint for an IXP to use that information to block any BGP updates where the AS_PATH matches the regular expression ASN . Please make sure that the IXPs you are connected to are supporting this feature. I.e. they have to check PeeringDB regularly, evaluate this field and honour the setting. Governance and membership How does one become a PeeringDB member? Your organization does not need to be a Member to have an active account at PeeringDB.com, but Membership is available to those that do. Per the Bylaws, Membership is determined by having an active PeeringDB.com account, and a subscription to the pdb-gov mailing list. What are the Terms and Conditions for PeeringDB membership? Please see http://docs.peeringdb.com/gov/#organizational-documents for the legal aspects of PeeringDB. The Acceptable Use Policy is at https://www.peeringdb.com/aup . Are there any membership fees required for members? No, there are no membership fees required. The organization welcomes sponsorships as its method of financial support. Please see https://www.peeringdb.com/sponsors for more information on supporting the PeeringDB. Are there any liabilities imposed on members? No, there are not. To register network information in the PeeringDB, is an organization required to join as a member? No, that isn't necessary.","title":"FAQs"},{"location":"faq/#frequently-asked-questions","text":"","title":"Frequently Asked Questions"},{"location":"faq/#general","text":"","title":"General"},{"location":"faq/#what-is-peeringdb","text":"PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions. The database is a non-profit, community-driven initiative run and promoted by volunteers. It is a public tool for the growth and good of the Internet. Join the community and support the continued development of the Internet.","title":"What is PeeringDB?"},{"location":"faq/#how-do-i-get-started","text":"See our Quick Start guide: http://docs.peeringdb.com/#quick-start","title":"How do I get started?"},{"location":"faq/#affiliation-requests","text":"Q: How does affiliation to an organization work? A: After you have registered, go to your profile . If your organization owns a network (also called AS or ASN), type in the AS number into the field ASN . Then click on the button Affiliate . If your ASN already is in PeeringDB and your org record does not yet have an admin account this request will be sent to PeeringDB Support If your organisation already has one or more admins your request is forwarded to them. They will have to approve / deny your request If your ASN is not in PeeringDB this procedure will first try to retrieve information about this ASN via RDAP to prepopulate the net record and the org record in case it also does not exist. We also use information from this query to auto approve your request if the email address in the RDAP record matches your email address. If this fails your request will be sent to PeeringDB Support You may also use the field organisation to request affiliation to an existing or new organisation. Start typing the name of your company and select from the popup or create a new organisation. Your request is sent to your admins if there is one or to PeeringDB Support otherwise In any case you should get an answer either from your admin or PeeringDB Support . If you don't get an answer within two working days, please mail PeeringDB Support providing necessary information (ASN, Organization).","title":"Affiliation requests"},{"location":"faq/#technical","text":"","title":"Technical"},{"location":"faq/#how-do-i-query-by-asn","text":"You may type in the ASN in the search box, or for web: http://as42.peeringdb.com https://www.peeringdb.com/net?asn=42 For API: https://www.peeringdb.com/api/net?asn=42","title":"How do I query by ASN?"},{"location":"faq/#using-asn-used-to-work-what-happened","text":"Please see http://lists.peeringdb.com/pipermail/pdb-announce/2016-March/000036.html for details.","title":"Using /asn used to work, what happened?"},{"location":"faq/#how-do-the-new-permissions-work","text":"Now there is an org entity which owns the records. A record can be a facility, an exchange point, or a network. Users are added to the org entity and can then be given access to any facility, any network, any exchange point, or anything the org itself owns.","title":"How do the new permissions work?"},{"location":"faq/#authenticating-via-embedded-userpass-in-the-url","text":"Support for this depends on the client and some browsers have stopped supporting embedded authentication in the URL So for example https://:@peeringdb.com/api/net/1 may work or it may not depending on the browser you are using.","title":"Authenticating via embedded user/pass in the URL"},{"location":"faq/#why-are-dates-represented-as-strings-in-the-api","text":"Date strings are ISO 8601 to keep a standard format. Comparison operations such as __gt , __lt , etc all still work as expected. For fetching records against updated timestamp, you may also use ?since=","title":"Why are dates represented as strings in the API?"},{"location":"faq/#how-do-i-sync-the-whole-database-to-my-local-machine","text":"You may make a full local copy with https://github.com/peeringdb/peeringdb-py , see docs at http://peeringdb.github.io/peeringdb-py/cli/ The initial run will perform a full sync, while subsequent runs will incrementally update changed records. Alternatively peeringdb-simplesync can be used to maintain a mirror in PostgreSQL.","title":"How do I sync the whole database to my local machine?"},{"location":"faq/#when-syncing-to-mysql-i-get-illegal-mix-of-collations","text":"Such as: django.db.utils.OperationalError: (1267, \"Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation '='\") We will fix that when time allows, for the time being, just run: alter database peeringdb default character set utf8 default collate utf8_unicode_ci;","title":"When syncing to MySQL I get 'Illegal mix of collations'"},{"location":"faq/#what-does-the-never-via-route-servers-flag-mean-and-how-does-it-work","text":"With release 2.18.0 a new feature Never via route servers (API field info_never_via_route_servers ) has been introduced. There is a tick box in section \"Protocols Supported\" to set it. If set it is a hint for an IXP to use that information to block any BGP updates where the AS_PATH matches the regular expression ASN . Please make sure that the IXPs you are connected to are supporting this feature. I.e. they have to check PeeringDB regularly, evaluate this field and honour the setting.","title":"What does the Never via route servers flag mean and how does it work?"},{"location":"faq/#governance-and-membership","text":"","title":"Governance and membership"},{"location":"faq/#how-does-one-become-a-peeringdb-member","text":"Your organization does not need to be a Member to have an active account at PeeringDB.com, but Membership is available to those that do. Per the Bylaws, Membership is determined by having an active PeeringDB.com account, and a subscription to the pdb-gov mailing list.","title":"How does one become a PeeringDB member?"},{"location":"faq/#what-are-the-terms-and-conditions-for-peeringdb-membership","text":"Please see http://docs.peeringdb.com/gov/#organizational-documents for the legal aspects of PeeringDB. The Acceptable Use Policy is at https://www.peeringdb.com/aup .","title":"What are the Terms and Conditions for PeeringDB membership?"},{"location":"faq/#are-there-any-membership-fees-required-for-members","text":"No, there are no membership fees required. The organization welcomes sponsorships as its method of financial support. Please see https://www.peeringdb.com/sponsors for more information on supporting the PeeringDB.","title":"Are there any membership fees required for members?"},{"location":"faq/#are-there-any-liabilities-imposed-on-members","text":"No, there are not.","title":"Are there any liabilities imposed on members?"},{"location":"faq/#to-register-network-information-in-the-peeringdb-is-an-organization-required-to-join-as-a-member","text":"No, that isn't necessary.","title":"To register network information in the PeeringDB, is an organization required to join as a member?"},{"location":"glossary/","text":"Glossary This glossary focuses on terms that are specific to PeeringDB. Other organizations provide glossaries of a wide range of Internet infrastructure terminology. These include: APNIC Euro-IX ICANN RIPE NCC The first set of definitions describes object types and the second set defines the different kinds of contacts. PeeringDB specific terms Object Name Definition fac The name of the database object representing interconnection facilities. Facility A place where networks can connect with other networks. Some interconnection facilities are data centers or suites within data centers. Others are significantly smaller. facix The name of an object derived from the intersection of a fac and an ix object. This happens when an IXP has a presence at an interconnection facility. ix The name of the database object representing IXPs. ix-f The Internet Exchange Federation is a group of four regional IXP Associations. In the context of PeeringDB, their name is applied to the import of JSON structured data that complies with the IX-F Member Export Schema . IXP An infrastructure for interconnecting three or more Autonomous Systems. net The name of the database object representing networks. netix The name of an object derived from the intersection of a net and an ix object. This happens when a network is connected to an IXP. Network An Autonomous System, as defined in RFC 1930 . PeeringDB PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions. poc A Point of Contact for a specific functional role at an organization (see below). Contact role types Not all organizations will have all contact types. For example, an academic institution might not need a sales contact. Role Description Abuse A contact address where reports of abuse can be submitted. Maintenance A contact address for the receipt of maintenance notifications, such as the scheduling of maintenance windows from peers. NOC A contact address for a Network Operations Center. This is the address to use when discussing network anomalies. Policy A contact address for peering and interconnection requests and questions. Public Relations A contact address for an organization\u2019s PR or marketing team. Sales A contact address for an organization\u2019s sales team. Technical A contact address for non-routine technical questions that aren't handled by the NOC.","title":"Glossary"},{"location":"glossary/#glossary","text":"This glossary focuses on terms that are specific to PeeringDB. Other organizations provide glossaries of a wide range of Internet infrastructure terminology. These include: APNIC Euro-IX ICANN RIPE NCC The first set of definitions describes object types and the second set defines the different kinds of contacts.","title":"Glossary"},{"location":"glossary/#peeringdb-specific-terms","text":"Object Name Definition fac The name of the database object representing interconnection facilities. Facility A place where networks can connect with other networks. Some interconnection facilities are data centers or suites within data centers. Others are significantly smaller. facix The name of an object derived from the intersection of a fac and an ix object. This happens when an IXP has a presence at an interconnection facility. ix The name of the database object representing IXPs. ix-f The Internet Exchange Federation is a group of four regional IXP Associations. In the context of PeeringDB, their name is applied to the import of JSON structured data that complies with the IX-F Member Export Schema . IXP An infrastructure for interconnecting three or more Autonomous Systems. net The name of the database object representing networks. netix The name of an object derived from the intersection of a net and an ix object. This happens when a network is connected to an IXP. Network An Autonomous System, as defined in RFC 1930 . PeeringDB PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions. poc A Point of Contact for a specific functional role at an organization (see below).","title":"PeeringDB specific terms"},{"location":"glossary/#contact-role-types","text":"Not all organizations will have all contact types. For example, an academic institution might not need a sales contact. Role Description Abuse A contact address where reports of abuse can be submitted. Maintenance A contact address for the receipt of maintenance notifications, such as the scheduling of maintenance windows from peers. NOC A contact address for a Network Operations Center. This is the address to use when discussing network anomalies. Policy A contact address for peering and interconnection requests and questions. Public Relations A contact address for an organization\u2019s PR or marketing team. Sales A contact address for an organization\u2019s sales team. Technical A contact address for non-routine technical questions that aren't handled by the NOC.","title":"Contact role types"},{"location":"gov/","text":"PeeringDB Governance Mission Statement PeeringDB, a nonprofit member-based organization, facilitates the interconnection of Internet networks globally, with user-maintained information. Organizational Documents Organizational Consent (2015-12-08) Certificate and Articles of Incorporation (2015-12-16) Bylaws (2024-05-18) Policies Acceptable Use Policy Conflict of Interest Policy Data Ownership Policy Financial Controls Policy Press Release Policy Privacy Policy Member Meetings April 18th, 2024: Agenda - Minutes - Audio - Video April 13th, 2023: Agenda - Minutes April 12th, 2022: Agenda - Minutes - Audio April 8th, 2021: Agenda - Minutes - Audio April 17th, 2020: Agenda - Minutes - Audio April 25th, 2019: Agenda - Minutes - Audio April 19th, 2018: Agenda - Minutes - Audio April 20th, 2017: Agenda - Minutes - Audio April 21st, 2016: Agenda - Minutes - Audio Board Meetings & Consents 2024: 2024-05-18 , 2024-02-27 2023: 2023-08-11 , 2023-05-18 , 2023-05-08 2022: 2022-07-29 2021: 2021-09-01 , 2021-01-13 2020: 2020-07-09 , 2020-05-08 , 2020-01-13 2019: 2019-09-27 , 2019-07-16 , 2019-05-16 , 2019-03-27 , 2019-01-29 2018: 2018-11-15 , 2018-10-09 , 2018-07-19 , 2018-05-18 , 2018-04-09 , 2018-02-08 2017: 2017-10-18 , 2017-09-20 , 2017-07-07 , 2017-05-18 , 2017-02-09 , 2017-01-13 2016: 2016-12-02 , 2016-09-22 , 2016-08-10 , 2016-07-01 , 2016-05-18 , 2016-04-06 , 2016-03-04 , 2016-02-04 , 2016-01-07 2015: 2015-12-08 Strategic Plan & Organizational Objectives 2020-2021 2019-2020 2017-2018 DRAFT Finances Finance Reports: 2023 , 2022 , 2021 , 2020 , 2019 , 2018 , 2017 , 2016 , 2015 , 2014 IRS Form 990 Tax Exempt Return: 2023 , 2022 , 2021 , 2020 , 2019 , 2018 , 2017 , 2016 , 2015 , 2014 IRS Form W-9: Request for Taxpayer Identification Number and Certification (2019-09-17) IRS Exemption Letter for 501(c)(6) (2016-02-24) IRS Form 1024: Application for Recognition of Exemption Under Section 501(c)(6) (2016-01-07) Washington State Nonprofit Corporation Annual Reports 2024-11-14 , 2023-11-03 , 2022-11-01 , 2021-11-01 , 2020-11-02 , 2019-11-01 , 2018-11-01 , 2017-12-01 , 2016-12-01 , 2016-05-18 Elections & Surveys Election Results: 2024 , 2023 , 2022 , 2021 , 2020 , 2019 , 2018 , 2017 , 2016 , 2015 Voter's Guides: 2024 , 2023 , 2022 , 2021 , 2020 , 2019 , 2018 , 2017 , 2016 , 2015 Announcement of survey results and Board election plan (2015-10-20) Survey for future of PeeringDB (2015-08) Board of Directors Seat 1 (term expires 2025): Christopher Malayter , 2021- Seat 2 (term expires 2026): Job Snijders , 2015- Seat 3 (term expires 2025): Rahul Makhija , 2023- Seat 4 (term expires 2026): Aaron Hughes , 2015- Seat 5 (term expires 2025): Livio Morina , 2023- Officers Christopher Malayter , President, 2023- Aaron Hughes , Vice President, 2023- Shawna Bong , Secretary & Treasurer, 2024- Admin Committee Please see the Admin Committee page. Operations Committee Board members Snijders (Chair) and Hughes. Outreach Committee Please see the Outreach Committee page. Product Committee Please see the Product Committee page. Alumni Chris Caputo, Secretary & Treasurer 2015-2024 Patrick W. Gilmore, Board of Directors 2015-2023, Vice President 2015-2016 Matt Griswold, Board of Directors 2015-2017 Aaron Hughes, President 2015-2023 Fredrik Korsb\u00e4ck, Board of Directors 2019-2021 Arnold Nipper, Board of Directors 2015-2019 Bijal Sanghani, Board of Directors 2017-2023 Job Snijders, Vice President 2016-2023","title":"Governance"},{"location":"gov/#peeringdb-governance","text":"","title":"PeeringDB Governance"},{"location":"gov/#mission-statement","text":"PeeringDB, a nonprofit member-based organization, facilitates the interconnection of Internet networks globally, with user-maintained information.","title":"Mission Statement"},{"location":"gov/#organizational-documents","text":"Organizational Consent (2015-12-08) Certificate and Articles of Incorporation (2015-12-16) Bylaws (2024-05-18)","title":"Organizational Documents"},{"location":"gov/#policies","text":"Acceptable Use Policy Conflict of Interest Policy Data Ownership Policy Financial Controls Policy Press Release Policy Privacy Policy","title":"Policies"},{"location":"gov/#member-meetings","text":"April 18th, 2024: Agenda - Minutes - Audio - Video April 13th, 2023: Agenda - Minutes April 12th, 2022: Agenda - Minutes - Audio April 8th, 2021: Agenda - Minutes - Audio April 17th, 2020: Agenda - Minutes - Audio April 25th, 2019: Agenda - Minutes - Audio April 19th, 2018: Agenda - Minutes - Audio April 20th, 2017: Agenda - Minutes - Audio April 21st, 2016: Agenda - Minutes - Audio","title":"Member Meetings"},{"location":"gov/#board-meetings-consents","text":"2024: 2024-05-18 , 2024-02-27 2023: 2023-08-11 , 2023-05-18 , 2023-05-08 2022: 2022-07-29 2021: 2021-09-01 , 2021-01-13 2020: 2020-07-09 , 2020-05-08 , 2020-01-13 2019: 2019-09-27 , 2019-07-16 , 2019-05-16 , 2019-03-27 , 2019-01-29 2018: 2018-11-15 , 2018-10-09 , 2018-07-19 , 2018-05-18 , 2018-04-09 , 2018-02-08 2017: 2017-10-18 , 2017-09-20 , 2017-07-07 , 2017-05-18 , 2017-02-09 , 2017-01-13 2016: 2016-12-02 , 2016-09-22 , 2016-08-10 , 2016-07-01 , 2016-05-18 , 2016-04-06 , 2016-03-04 , 2016-02-04 , 2016-01-07 2015: 2015-12-08","title":"Board Meetings & Consents"},{"location":"gov/#strategic-plan-organizational-objectives","text":"2020-2021 2019-2020 2017-2018 DRAFT","title":"Strategic Plan & Organizational Objectives"},{"location":"gov/#finances","text":"Finance Reports: 2023 , 2022 , 2021 , 2020 , 2019 , 2018 , 2017 , 2016 , 2015 , 2014 IRS Form 990 Tax Exempt Return: 2023 , 2022 , 2021 , 2020 , 2019 , 2018 , 2017 , 2016 , 2015 , 2014 IRS Form W-9: Request for Taxpayer Identification Number and Certification (2019-09-17) IRS Exemption Letter for 501(c)(6) (2016-02-24) IRS Form 1024: Application for Recognition of Exemption Under Section 501(c)(6) (2016-01-07)","title":"Finances"},{"location":"gov/#washington-state-nonprofit-corporation-annual-reports","text":"2024-11-14 , 2023-11-03 , 2022-11-01 , 2021-11-01 , 2020-11-02 , 2019-11-01 , 2018-11-01 , 2017-12-01 , 2016-12-01 , 2016-05-18","title":"Washington State Nonprofit Corporation Annual Reports"},{"location":"gov/#elections-surveys","text":"Election Results: 2024 , 2023 , 2022 , 2021 , 2020 , 2019 , 2018 , 2017 , 2016 , 2015 Voter's Guides: 2024 , 2023 , 2022 , 2021 , 2020 , 2019 , 2018 , 2017 , 2016 , 2015 Announcement of survey results and Board election plan (2015-10-20) Survey for future of PeeringDB (2015-08)","title":"Elections & Surveys"},{"location":"gov/#board-of-directors","text":"Seat 1 (term expires 2025): Christopher Malayter , 2021- Seat 2 (term expires 2026): Job Snijders , 2015- Seat 3 (term expires 2025): Rahul Makhija , 2023- Seat 4 (term expires 2026): Aaron Hughes , 2015- Seat 5 (term expires 2025): Livio Morina , 2023-","title":"Board of Directors"},{"location":"gov/#officers","text":"Christopher Malayter , President, 2023- Aaron Hughes , Vice President, 2023- Shawna Bong , Secretary & Treasurer, 2024-","title":"Officers"},{"location":"gov/#admin-committee","text":"Please see the Admin Committee page.","title":"Admin Committee"},{"location":"gov/#operations-committee","text":"Board members Snijders (Chair) and Hughes.","title":"Operations Committee"},{"location":"gov/#outreach-committee","text":"Please see the Outreach Committee page.","title":"Outreach Committee"},{"location":"gov/#product-committee","text":"Please see the Product Committee page.","title":"Product Committee"},{"location":"gov/#alumni","text":"Chris Caputo, Secretary & Treasurer 2015-2024 Patrick W. Gilmore, Board of Directors 2015-2023, Vice President 2015-2016 Matt Griswold, Board of Directors 2015-2017 Aaron Hughes, President 2015-2023 Fredrik Korsb\u00e4ck, Board of Directors 2019-2021 Arnold Nipper, Board of Directors 2015-2019 Bijal Sanghani, Board of Directors 2017-2023 Job Snijders, Vice President 2016-2023","title":"Alumni"},{"location":"howtos/","text":"PeeringDB HOWTOs HOWTOs provide a beginner detailed instructions on how to get started using PeeringDB. Create entries Get Started with PeeringDB as a Carrier Operator Get Started with PeeringDB as a Exchange Operator Get Started with PeeringDB as a Facility or Campus Operator Get Started with PeeringDB as a Network Operator Manage entries Manage Organizational Policy Manage User Permissions Search Get Started with Search in PeeringDB Work Within PeeringDB\u2019s Query Limits v2 Search Authentication and security Authenticate to PeeringDB Get Started with API Keys Report a Security Issue Turn on 2FA and Require Users to Enable It Other Become a PeeringDB Member and Vote Install peeringdb-py Get Started with Developing for PeeringDB Setup a PeeringDB Development Environment What is AS112?","title":"HOWTOs"},{"location":"howtos/#peeringdb-howtos","text":"HOWTOs provide a beginner detailed instructions on how to get started using PeeringDB.","title":"PeeringDB HOWTOs"},{"location":"howtos/#create-entries","text":"Get Started with PeeringDB as a Carrier Operator Get Started with PeeringDB as a Exchange Operator Get Started with PeeringDB as a Facility or Campus Operator Get Started with PeeringDB as a Network Operator","title":"Create entries"},{"location":"howtos/#manage-entries","text":"Manage Organizational Policy Manage User Permissions","title":"Manage entries"},{"location":"howtos/#search","text":"Get Started with Search in PeeringDB Work Within PeeringDB\u2019s Query Limits v2 Search","title":"Search"},{"location":"howtos/#authentication-and-security","text":"Authenticate to PeeringDB Get Started with API Keys Report a Security Issue Turn on 2FA and Require Users to Enable It","title":"Authentication and security"},{"location":"howtos/#other","text":"Become a PeeringDB Member and Vote Install peeringdb-py Get Started with Developing for PeeringDB Setup a PeeringDB Development Environment What is AS112?","title":"Other"},{"location":"ix-f-json-import-rules/","text":"IX-F JSON Importer PeeringDB allows networks and IXPs to update entries via the IX-F JSON import feature. General remarks The Importer abides by the recommendations of the Data Ownership Task Force and its resulting Policy Document . Most significantly, this means that unless the tick box Allow IXP Update is enabled by a network, published data will not automatically become unpublished nor will unpublished data automatically become published. For Networks There is a tick box Allow IXP Update which governs the behavior of the Importer. By default this is set to disabled. If Allow IXP Update is enabled, a network entry at an IX may automatically be created, changed, or removed. The network's IX entry is completely governed by the settings in the IX-F JSON data provided by the IX. If Allow IXP Update is disabled, differences in data provided by the IX and the network will result in the following: An email to the network with details about the differences. An email to the IX with details about the differences. Admins for the network will see hints for their network within the PeeringDB web interface. These hints may be accepted or dismissed. The network and the IX are encouraged to reach out to each other to resolve any differences. IXP Update Tools: The Preview button shows the changes that will be performed or suggested during the next IX-F import, depending on the Allow IXP Update setting. The Postmortem button shows a log of recent changes performed as a result of IX-F imports. For IXPs To enable IX-F JSON import: Make sure that your JSON file is valid . Provide a URL to your IX-F JSON data. To do so, click Edit on your IX web page and set the IX-F Member Export URL to the URL and set Enable IX-F Import to enabled. You may also set the visibility of your IX-F JSON URL. Daily at 0000 UTC, the IX-F JSON data will be retrieved and processed by the Importer. The steps above for networks will then be followed. If the IX-F JSON state field is present, settings of active , connected , or operational may be used to indicate a network is operational, while a setting of inactive will be interpreted as the network not being operational. This may be used to denote a network in the process of connecting but not yet active, or a network on hiatus. IX-F Import Preview: The Preview button shows the changes that will be performed or suggested, depending on participant Allow IXP Update settings. A JSON form of this preview is available at: https://www.peeringdb.com/import/ixlan/###/ixf/preview (replace ### with the ID that appears in the URL after /ix/ when viewing your IX page) Note : The Importer expects that you also provide IP addresses. If your IX-F JSON has an empty member_list or only contains ASNs, there will be no useful information. You might want to disable the import. Further Information August 17th, 2020 Data Ownership Policy Implementation Presentation: slides and video","title":"IX-F JSON"},{"location":"ix-f-json-import-rules/#ix-f-json-importer","text":"PeeringDB allows networks and IXPs to update entries via the IX-F JSON import feature.","title":"IX-F JSON Importer"},{"location":"ix-f-json-import-rules/#general-remarks","text":"The Importer abides by the recommendations of the Data Ownership Task Force and its resulting Policy Document . Most significantly, this means that unless the tick box Allow IXP Update is enabled by a network, published data will not automatically become unpublished nor will unpublished data automatically become published.","title":"General remarks"},{"location":"ix-f-json-import-rules/#for-networks","text":"There is a tick box Allow IXP Update which governs the behavior of the Importer. By default this is set to disabled. If Allow IXP Update is enabled, a network entry at an IX may automatically be created, changed, or removed. The network's IX entry is completely governed by the settings in the IX-F JSON data provided by the IX. If Allow IXP Update is disabled, differences in data provided by the IX and the network will result in the following: An email to the network with details about the differences. An email to the IX with details about the differences. Admins for the network will see hints for their network within the PeeringDB web interface. These hints may be accepted or dismissed. The network and the IX are encouraged to reach out to each other to resolve any differences. IXP Update Tools: The Preview button shows the changes that will be performed or suggested during the next IX-F import, depending on the Allow IXP Update setting. The Postmortem button shows a log of recent changes performed as a result of IX-F imports.","title":"For Networks"},{"location":"ix-f-json-import-rules/#for-ixps","text":"To enable IX-F JSON import: Make sure that your JSON file is valid . Provide a URL to your IX-F JSON data. To do so, click Edit on your IX web page and set the IX-F Member Export URL to the URL and set Enable IX-F Import to enabled. You may also set the visibility of your IX-F JSON URL. Daily at 0000 UTC, the IX-F JSON data will be retrieved and processed by the Importer. The steps above for networks will then be followed. If the IX-F JSON state field is present, settings of active , connected , or operational may be used to indicate a network is operational, while a setting of inactive will be interpreted as the network not being operational. This may be used to denote a network in the process of connecting but not yet active, or a network on hiatus. IX-F Import Preview: The Preview button shows the changes that will be performed or suggested, depending on participant Allow IXP Update settings. A JSON form of this preview is available at: https://www.peeringdb.com/import/ixlan/###/ixf/preview (replace ### with the ID that appears in the URL after /ix/ when viewing your IX page) Note : The Importer expects that you also provide IP addresses. If your IX-F JSON has an empty member_list or only contains ASNs, there will be no useful information. You might want to disable the import.","title":"For IXPs"},{"location":"ix-f-json-import-rules/#further-information","text":"August 17th, 2020 Data Ownership Policy Implementation Presentation: slides and video","title":"Further Information"},{"location":"oauth/","text":"OAuth PeeringDB now offers OAuth2 authentication for third-party applications to allow users to authenticate against PeeringDB. Implementation details are at Github #131 . For an example, see IXP-Manager issue #322 . What is OAuth? There is a good write up at https://aaronparecki.com/oauth-2-simplified/ . Register an application First you need to register your application at PeeringDB. : For most applications, you'll want to use the following: Client type: Confidential Authorization grant type: Authorization code Redirect uris: add your redirect URLs here An OIDC algorithm must be selected. URLs PDB_ENDPOINT = \"https://auth.peeringdb.com/\" PDB_OAUTH_ACCESS_TOKEN_URL = '{}oauth2/token/'.format(PDB_ENDPOINT) PDB_OAUTH_AUTHORIZE_URL = '{}oauth2/authorize/'.format(PDB_ENDPOINT) PDB_OAUTH_PROFILE_URL = '{}profile/v1'.format(PDB_ENDPOINT) Fields The fields are based largely on OpenID Connect. Scopes currently are defined as profile : user profile email : adds fields email and verified_email networks : add field networks The perms field is a bitmask for CRUD as the 4 least significant bits. See following: 0b0000 1 1 1 1 | | | +-- Delete | | +---- Update | +------ Read + ------- Create Example for my user: { \"id\": 3, \"name\": \"Matt Griswold\", \"given_name\": \"Matt\", \"family_name\": \"Griswold\", \"email\": \"grizz@20c.com\", \"verified_user\": true, \"verified_email\": true, \"networks\": [ { \"perms\": 15, \"asn\": 63311, \"name\": \"20C\", \"id\": 20 }, { \"perms\": 15, \"asn\": 33713, \"name\": \"United IX\", \"id\": 7889 } ] }","title":"OAuth"},{"location":"oauth/#oauth","text":"PeeringDB now offers OAuth2 authentication for third-party applications to allow users to authenticate against PeeringDB. Implementation details are at Github #131 . For an example, see IXP-Manager issue #322 .","title":"OAuth"},{"location":"oauth/#what-is-oauth","text":"There is a good write up at https://aaronparecki.com/oauth-2-simplified/ .","title":"What is OAuth?"},{"location":"oauth/#register-an-application","text":"First you need to register your application at PeeringDB. : For most applications, you'll want to use the following: Client type: Confidential Authorization grant type: Authorization code Redirect uris: add your redirect URLs here An OIDC algorithm must be selected.","title":"Register an application"},{"location":"oauth/#urls","text":"PDB_ENDPOINT = \"https://auth.peeringdb.com/\" PDB_OAUTH_ACCESS_TOKEN_URL = '{}oauth2/token/'.format(PDB_ENDPOINT) PDB_OAUTH_AUTHORIZE_URL = '{}oauth2/authorize/'.format(PDB_ENDPOINT) PDB_OAUTH_PROFILE_URL = '{}profile/v1'.format(PDB_ENDPOINT)","title":"URLs"},{"location":"oauth/#fields","text":"The fields are based largely on OpenID Connect. Scopes currently are defined as profile : user profile email : adds fields email and verified_email networks : add field networks The perms field is a bitmask for CRUD as the 4 least significant bits. See following: 0b0000 1 1 1 1 | | | +-- Delete | | +---- Update | +------ Read + ------- Create Example for my user: { \"id\": 3, \"name\": \"Matt Griswold\", \"given_name\": \"Matt\", \"family_name\": \"Griswold\", \"email\": \"grizz@20c.com\", \"verified_user\": true, \"verified_email\": true, \"networks\": [ { \"perms\": 15, \"asn\": 63311, \"name\": \"20C\", \"id\": 20 }, { \"perms\": 15, \"asn\": 33713, \"name\": \"United IX\", \"id\": 7889 } ] }","title":"Fields"},{"location":"presentations/","text":"Presentations 2024 What's new on PeeringDB? at 8th South African Peering Forum , Cape Town, ZA - November 14, 2024 - Obinna Adumike What's new on PeeringDB? at nog.fi meeting 2024.11 , Helsinki, FI - November 6, 2024 - Livio Morina PeeringDB Update at RIPE 89 , Prague, CZ - October 31, 2024 - Leo Vegoda What's new on PeeringDB? at NgNOG 2024 , Lagos, NG - October 23, 2024 - Obinna Adumike What's new on PeeringDB? at Netnod Tech Meeting 2024 , Stockhold, SE - October 15, 2024 - Livio Morina What's new on PeeringDB? at RONOG 9 , Bucharest, RO - October 2, 2024 - Livio Morina PeeringDB in Five Minutes at AusNOG 2024 , Sydney, AU - September 5, 2024 - Arnold Nipper What's new on PeeringDB? at AfPIF 2024 , Kinsahsa, CD - August 20, 2024 - Ben Ryall PeeringDB Introduction & Update at PhNOG 2024 Week , Makati City, PH - July 10, 2024 - Arnold Nipper PeeringDB Update at NetUK 1 , London, UK - July 8, 2024 - Paul Hoogsteder What's new on PeeringDB? at WAPF 2024 , Abidjan, CI - June 26, 2024 - Ben Ryall PeeringDB Update at MWPS 2024 , Kansas City, MO, US - June 14, 2024 - Martin Hannigan PeeringDB Update at LINX122 , London, UK - May 28, 2024 - Ben Ryall PeeringDB Update at RIPE 88 , Krak\u00f3w, PL - May 23, 2024 - Paul Hoogsteder What's new on PeeringDB? at ITNOG8 , Bologna, IT - May 7, 2024 - Livio Morina PeeringDB Introduction & Update at SANOG 41 , Mumbai, IN - April 29, 2024 - Arnold Nipper What's new on PeeringDB? at SEE 12 , Athens, GR - April 22, 2024 - Livio Morina PeeringDB Update at GPF 2024 , San Juan, PR, US - April 15, 2024 - Chris Malayter PeeringDB Update at DKNOG14 , Copenhagen, DK - March 8, 2024 - Chriztoffer Hansen PeeringDB Update at Peering Days 2024 , Krakow, PL - March 7, 2024 - Ben Ryall PeeringDB Update at NANOG 90 , Charlotte, NC, US - February 12, 2024 - Martin Hannigan 2023 PeeringDB Update at RIPE 87 , Rome, IT - November 30, 2023 - Leo Vegoda What's new on PeeringDB? at MIX Salotto 2023 , Milan, IT - November 15, 2023 - Livio Morina What is PeeringDB? Why is it important for network operators? at RSNOG9 , Belgrade, RS - November 9, 2023 - Livio Morina What\u2019s new on PeeringDB? at GRNOG 15 , Athens, GR - October 25, 2023 - Livio Morina What\u2019s new on PeeringDB? at FRnOG 38 , Paris, FR - October 6, 2023 - Livio Morina PeeringDB Operations & Product Update at SwiNOG#38 , Berne, CH - June 21, 2023 - Arnold Nipper PeeringDB Update at RIPE 86 , Rotterdam, NL - May 25, 2023 - Leo Vegoda PeeringDB Operations & Product Update at ITNOG7 , Bologna, IT - May 9, 2023 - Arnold Nipper What\u2019s new on PeeringDB? at the 38th Euro-IX Forum , Cluj-Napoca, RO - April 24, 2023 - Arnold Nipper PeeringDB Operations & Product Update at SEE 11 , Split, HR - April 5, 2023 - Arnold Nipper PeeringDB Operations & Product Update at GPF 2023 , Coronado, CA, US - April 4, 2023 - Matt Griswold PeeringDB Operations & Product Update at Peering Days 2023 , Sofia, BG - March 30, 2023 - Arnold Nipper PeeringDB Operations & Product Update at DKNOG13 , Copenhagen, DK - March 10, 2023 - Arnold Nipper 2022 PeeringDB at AOPF/AONOG 2022 - December 8, 2022 - Darwin Da Costa PeeringDB Operations & Product Update at DENOG14 , Hamburg, DE - November 15, 2022 - Arnold Nipper PeeringDB Operations & Product Update at RIPE 85 , Belgrade, RS - October 26, 2022 - Arnold Nipper PeeringDB Operations & Product Update at ngPIF 2022 , Lagos, NG - October 25, 2022 - Ben Ryall PeeringDB at WTR POP-PI 2022 - October 20, 2022 - Julimar Lunguinho Mendes ( video ) PeeringDB Call for Committee Members at NANOG 86 , Hollywood, CA, US - October 19, 2022 - Patrick Gilmore PeeringDB Operations & Product Update at the 37th Euro-IX Forum , Edinburgh, UK - October 11, 2022 - Greg Hankins PeeringDB Update at EPF 2022 , Rome, IT - September 12, 2022 - Arnold Nipper PeeringDB Update at AfPIF 2022 , Kigali, RW - August 23, 2022 - Ben Ryall PeeringDB Update at GPF 2022 , Washington, DC, US - May 12, 2022 - Chris Malayter 2021 Status Update at Virtual Tech Day with Euro-IX PeeringToolbox - February 3, 2022 - Leo Vegoda 2021 Introduction to PeeringDB at GNA-G Routing WG - December 14, 2021 - Arnold Nipper PeeringDB Update at Semana de Capacita\u00e7\u00e3o On-line 3 - October 1, 2021 - Julimar Lunguinho Mendes PeeringDB Update at WTR PoP-MA - September 30, 2021 - Julimar Lunguinho Mendes 2020 PeeringDB at IX F\u00f3rum 14 - December 4, 2020 - Julimar Lunguinho Mendes ( video ) Introducci\u00f3n a PeeringDB at Seguridad en el Ruteo: MANRS para Operadores de Red de Universidades - October 2, 2020 - Diego Dominguez Data Ownership Policy Implementation Presentation - August 17, 2020 - Filiz Yilmaz, Steve McManus, Arnold Nipper ( video ) PeeringDB Data Ownership Task Force at PeeringDB Annual Meeting 2020 - April 17, 2020 - Filiz Yilmaz PeeringDB at ABRINT na Estrada Campo Grande , Campo Grande, BR - March 10, 2020 - Julimar Lunguinho Mendes PeeringDB Update at PhNOG 2020 , Manila, PH - February 26, 2020 - Arnold Nipper PeeringDB Update at APRICOT 2020 , Melbourne, AU - February 19, 2020 - Arnold Nipper 2019 PeeringDB Update (English)/ \u041d\u043e\u0432\u043e\u0441\u0442\u0438 \u043e\u0442 PeeringDB (P\u0443\u0441\u0441\u043a\u0438\u0439) at MSK-IX Peering Forum 2019 , Moscow, RU - December 5, 2019 - Filiz Yilmaz PeeringDB - Como Est\u00e1 a Ado\u00e7\u00e3o no Brasil at MUM in Brazil , Foz do Igua\u00e7u, BR - November 29, 2019 - Julimar Lunguinho Mendes PeeringDB Para Que Sirve? at XII Encuentro Nacional de T\u00e9cnicos , Salta, AR - November 28, 2019 - Hernan Moguilevsky PeeringDB Update: A Look Into PeeringDB's Data for AT/CH/DE/LU and the Latest Changes at DENOG11 , Hamburg, DE - November 12, 2019 - Stefan Funke PeeringDB Update at Peering Asia 3.0 , Kuala Lumpur, MY - November 7, 2019 - Arnold Nipper PeeringDB Update at ATNOG 2019/2 , Vienna, AT - November 5, 2019 - Stefan Funke Introduction to PeeringDB at JBIX Peering Forum 2019 , Kuala Lumpur, MY - November 5, 2019 - Arnold Nipper Introduction to PeeringDB at ngNOG 2019 , Lagos, NG - October 30, 2019 - Ben Ryall Cadastro para participantes do IX.br at IX F\u00f3rum Regional , Florian\u00f3polis, BR - October 25, 2019 - Julimar Lunguinho Mendes OAuth for IXP Operators at the 35th Euro-IX Forum , Zaandam, NL - October 21, 2019 - Barry O'Donovan The PeeringDB API at the 35th Euro-IX Forum , Zaandam, NL - October 21, 2019 - Arnold Nipper Introduction to PeeringDB at RONOG 6 , Bucharest, RO - October 1, 2019 - Arnold Nipper PeeringDB Update at EPF14 , Tallinn, EE - September 18, 2019 - Filiz Yilmaz Cadastro para participantes do IX.br at IX F\u00f3rum Regional , Natal, BR - September 6, 2019 - Julimar Lunguinho Mendes Introduction to PeeringDB at SAFNOG-5 , Johannesburg, ZA - August 28, 2019 - Arnold Nipper Introduction to PeeringDB at AfPIF-10 , Balaclava, MV - August 22, 2019 - Arnold Nipper Introducci\u00f3n a PeeringDB at MexNOG 2019 , Mexico City, MX - August 14, 2019 - Diego Dominguez Introduction to PeeringDB at ATNOG 2019/1 , Salzburg, AT - July 16, 2019 - Arnold Nipper Introduction to PeeringDB at INNOG 2 , New Delhi, IN - July 1, 2019 - Arnold Nipper ( video ) Cadastro para participantes do IX.br at IX F\u00f3rum Regional , S\u00e3o Paulo, BR - June 10, 2019 - Julimar Lunguinho Mendes News from PeeringDB at ENOG 16 , Tbilisi, GE - June 3, 2019 - Arnold Nipper PeeringDB Update at NONOG-3 , Oslo, NO - May 27, 2019 - Arnold Nipper PeeringDB Update at SINOG 6.0 , Ljubljana, SI - May 14, 2019 - Arnold Nipper Introduction to PeeringDB at BKNIX Peering Forum and ThaiNOG Day 2019 , Bangkok, TH - May 7, 2019 - Arnold Nipper Use in Latin America at Peering Forum LAC , Punta Cana, DR - May 6, 2019 - Julimar Lunguinho Mendes and Carlos Martinez Cagnazzo Cadastro para participantes do IX.br at IX F\u00f3rum Regional , Campo Grande, BR - April 26, 2019 - Julimar Lunguinho Mendes Introduction to PeeringDB at Telecom Day , St. Petersburg, RU - April 19, 2019 - Arnold Nipper PeeringDB Update at SEE 8 , Sarajevo, BH - April 17, 2019 - Arnold Nipper PeeringDB Update at Curso Avan\u00e7ado de IPv6 , S\u00e3o Paulo, BR - April 5, 2019 - Julimar Lunguinho Mendes PeeringDB Update at BCIX Round Table April 2019 , Berlin, DE - April 4, 2019 - Stefan Funke PeeringDB Update at MENOG 19 , Beirut, LB - April 3, 2019 - Arnold Nipper PeeringDB Update at DKNOG9 , Copenhagen, DK - March 15, 2019 - Arnold Nipper PeeringDB Update at Peering Days 2019 , Zagreb, CR - March 12, 2019 - Arnold Nipper PeeringDB Update at PhNOG 2019 , Cebu, PH - March 8, 2019 - Arnold Nipper PeeringDB Update at HKNOG 7.0 , Hong Kong, HK - March 1, 2019 - Arnold Nipper 2018 PeeringDB Update at MSK-IX Peering Forum 2018 , Moscow, RU - November 23, 2018 - Rebecca Stani\u0107 PeeringDB Update at DENOG10 , Darmstadt, DE - November 21, 2018 - Arnold Nipper PeeringDB Update at ITNOG4 , Bologna, IT - November 9, 2018 - Arnold Nipper Introduction to PeeringDB API at the 33rd Euro-IX Forum , Venice, IT - November 6, 2018 - Arnold Nipper PeeringDB Introduction at ngNOG 2018 , Lagos, NG - October 31, 2018 - Ben Ryall PeeringDB Update at SwiNOG #34 , Berne, CH - October 30, 2018 - Arnold Nipper PeeringDB Update and Japanese Localization Experience at Peering Asia 2.0 , Hong Kong, HK - October 25, 2018 - Arnold Nipper and Masataka Mawatari PeeringDB Update at SAFNOG-4/EANOG/tzNOG , Dar es Salaam, TZ - September 25, 2018 - Arnold Nipper PeeringDB Update at EPF 13 , Athens, GR - September 18, 2018 - Rebecca Stani\u0107 Cadastro para participantes do IX.br at IX (PTT) F\u00f3rum Regional , Natal, BR - September 14, 2018 - Julimar Lunguinho Mendes PeeringDB Frontend Translation Project at APNIC 46 , Noumea, NC - September 12, 2018 - Masataka Mawatari PeeringDB Update at AfPIF2018 , Cape Town, ZA - August 23, 2018 - Arnold Nipper PeeringDB for IXes at AFIX , Cape Town, ZA - August 20, 2018 - Arnold Nipper Introduction to PeeringDB API at SANOG 32 , Dhaka, BD - August 10, 2018 - Arnold Nipper PeeringDB Update at SANOG 32 , Dhaka, BD - August 9, 2018 - Arnold Nipper PeeringDB: What is it, how to and benefits at New England Peering Forum 2018 , Cambridge, MA, US - June 22, 2018 - Patrick W. Gilmore PeeringDB Update at SEE 7 , Timi\u0219oara, R0 - June 18, 2018 - Arnold Nipper PeeringDB Update at ENOG 15 , Moscow, RU - June 5, 2018 - Arnold Nipper PeeringDB Update at SwiNOG 33 , Berne, CH - May 24, 2018 - Arnold Nipper PeeringDB Update e cadastro de Facilities at GTER 45 , Florian\u00f3polis, BR - May 22, 2018 - Julimar Lunguinho Mendes ( video ) PeeringDB Update at RIPE 76 Connect Working Group , Marseille, FR - May 16, 2018 - Arnold Nipper ( video ) PeeringDB Update at African Internet Summit 2018 , Dakar, SN - May 8, 2018 - Arnold Nipper PeeringDB Update at DKNOG8 , Copenhagen, DK - March 9, 2018 - Arnold Nipper PeeringDB Update at CEE Peering Days 2018 , Berlin, DE - March 7, 2018 - Arnold Nipper Introduction to PeeringDB at APRICOT 2018 , Kathmandu, NP - February 26, 2018 - Arnold Nipper PeeringDB Update at APIX Meeting #17 , Kathmandu, NP - February 24, 2018 - Arnold Nipper PeeringDB Introduction at Capacity India & SAARC 2018 , New Delhi, IN - February 8, 2018 - Arnold Nipper 2017 PeeringDB Update at NIX.cz Member Meering , Prague, CZ - November 23, 2017 - Bijal Sanghani PeeringDB Update at DENOG9 , Darmstadt, DE - November 23, 2017 - Arnold Nipper PeeringDB Update at ALNOF , Tirana, AL - November 14, 2017 - Bijal Sanghani PeeringDB Update at Peering Asia 1.0 , Kyoto, JP - November 1, 2017 - Arnold Nipper PeeringDB Update at TOP-IX Meeting , Torino, IT - September 26, 2017 - Bijal Sanghani PeeringDB Update at NPD 17 , The Hague, NL - September 15, 2017 - Arnold Nipper PeeringDB Update at SAFNOG-3 , Durban, ZA - September 6, 2017 - Arnold Nipper PeeringDB Update at AfPIF 2017 , Abidjan, CI - August 24, 2017 - Arnold Nipper PeeringDB Update at SANOG 30 Peering Forum, Gurgaon, IN - July 10, 2017 - Arnold Nipper More benefits from PeeringDB at DE-CIX Technical Meeting , Frankfurt, DE - June 22, 2017 - Arnold Nipper PeeringDB Update at NANOG 70 , Bellevue, WA, US - June 5, 2017 - Aaron Hughes PeeringDB Update at BOSNOG Meeting & IX Peering Forum , Cambridge, MA, US - June 2, 2017 - Stephen McManus Orienta\u00e7\u00f5es no preenchimento de participantes do IX.br at GTER 43 , Foz do Igua\u00e7u, BR - May 25, 2017 - Julimar Lunguinho Mendes PeeringDB Update at ENOG 13.0 , Saint Petersburg, RU - May 23, 2017 - Arnold Nipper PeeringDB Update at Global Peering Forum 12.0 , New York, NY, US - April 26, 2017 - Aaron Huges PeeringDB at GORE/ESNOG Reunion 19 , Barcelona, ES - April 6, 2017 - Arnold Nipper PeeringDB at CEE Peering Days 2017 , Ljubljana, SL - March 23, 2017 - Arnold Nipper PeeringDB 2.0 at APRICOT 2017 , Ho Chi Minh City, VN - February 28, 2017 - Arnold Nipper 2016 PeeringDB at 19 KIKE Conference , Serock, PL - November 23, 2016 - Robert Jakub PeeringDB 2.0 at ITNOG2 , Bologna, IT - November 3, 2016 - Arnold Nipper PeeringDB Product Committee Charter Survey at EPF 11 , Sofia, BG - September 20, 2016 - Eric Loos PeeringDB 2.0 at NPD 16 , The Hague, NL - September 16, 2016 - Walt Wollny PeeringDB 2.0 at AfPIF 2016 , Dar es Salaam, TZ - August 30, 2016 - Arnold Nipper PeeringDB 2.0 for IXPs at AFIX 2016 , Dar es Salaam, TZ - August 29, 2016 - Arnold Nipper PeeringDB 2.0 at ENOG 11 , Moscow, RU - June 7, 2016 - Arnold Nipper PeeringDB 2.0 at RIPE 72 , Copenhagen, DK - May 25, 2016 - Greg Hankins PeeringDB 2.0 at CHI-NOG 06 , Chicago, IL, US - May 12, 2016 - Matt Griswold PeeringDB 2.0 e o Cen\u00e1rio Brasileiro and IX.br Guia de cadastro de informa\u00e7\u00f5es de ASNs no PeeringDB at GTER 41 , Uberl\u00e2ndia, BR - May 12, 2016 - Eduardo Ascen\u00e7o Reis PeeringDB 2.0 for IXPs at 28th Euro-IX Forum , Luxembourg, LU - April 26, 2016 - Greg Hankins / Arnold Nipper RIPE SEE 5 , Tirana, AL - April 19, 2016 - Arnold Nipper PeeringDB 2.0 at UKNOF34 , Manchester, UK - April 21, 2016 - Greg Hankins PeeringDB Update at GPF 11 , Los Angeles, CA, US - April 13, 2016 - Aaron Hughes NetNod , Stockholm, SE - March 17, 2016 - Job Snijders DKNOG6 , Copenhagen, DK - March 10, 2016 - Job Snijders PeeringDB Update - Aaron Hughes APRICOT 2016 , Auckland, NZ - February 23, 2016 - Aaron Hughes NANOG 66 , San Diego, CA, US - February 10, 2016 - Aaron Hughes PeeringDB Version 2 Coding Introduction at NANOG 66 , San Diego, CA, US - February 8, 2016 - Matt Griswold 2015 PeeringDB Version 2 Brazil - Matt Griswold / Greg Hankins IX (PTT) F\u00f3rum 9 , S\u00e3o Paulo, BR - December 8, 2015 - Greg Hankins PeeringDB Version 2 Introduction - Matt Griswold 27th Euro-IX Forum , Berlin, DE - October 26, 2015 - Greg Hankins DENOG7 , Darmstadt, DE - October 30, 2015 - Arnold Nipper","title":"Presentations"},{"location":"presentations/#presentations","text":"","title":"Presentations"},{"location":"presentations/#2024","text":"What's new on PeeringDB? at 8th South African Peering Forum , Cape Town, ZA - November 14, 2024 - Obinna Adumike What's new on PeeringDB? at nog.fi meeting 2024.11 , Helsinki, FI - November 6, 2024 - Livio Morina PeeringDB Update at RIPE 89 , Prague, CZ - October 31, 2024 - Leo Vegoda What's new on PeeringDB? at NgNOG 2024 , Lagos, NG - October 23, 2024 - Obinna Adumike What's new on PeeringDB? at Netnod Tech Meeting 2024 , Stockhold, SE - October 15, 2024 - Livio Morina What's new on PeeringDB? at RONOG 9 , Bucharest, RO - October 2, 2024 - Livio Morina PeeringDB in Five Minutes at AusNOG 2024 , Sydney, AU - September 5, 2024 - Arnold Nipper What's new on PeeringDB? at AfPIF 2024 , Kinsahsa, CD - August 20, 2024 - Ben Ryall PeeringDB Introduction & Update at PhNOG 2024 Week , Makati City, PH - July 10, 2024 - Arnold Nipper PeeringDB Update at NetUK 1 , London, UK - July 8, 2024 - Paul Hoogsteder What's new on PeeringDB? at WAPF 2024 , Abidjan, CI - June 26, 2024 - Ben Ryall PeeringDB Update at MWPS 2024 , Kansas City, MO, US - June 14, 2024 - Martin Hannigan PeeringDB Update at LINX122 , London, UK - May 28, 2024 - Ben Ryall PeeringDB Update at RIPE 88 , Krak\u00f3w, PL - May 23, 2024 - Paul Hoogsteder What's new on PeeringDB? at ITNOG8 , Bologna, IT - May 7, 2024 - Livio Morina PeeringDB Introduction & Update at SANOG 41 , Mumbai, IN - April 29, 2024 - Arnold Nipper What's new on PeeringDB? at SEE 12 , Athens, GR - April 22, 2024 - Livio Morina PeeringDB Update at GPF 2024 , San Juan, PR, US - April 15, 2024 - Chris Malayter PeeringDB Update at DKNOG14 , Copenhagen, DK - March 8, 2024 - Chriztoffer Hansen PeeringDB Update at Peering Days 2024 , Krakow, PL - March 7, 2024 - Ben Ryall PeeringDB Update at NANOG 90 , Charlotte, NC, US - February 12, 2024 - Martin Hannigan","title":"2024"},{"location":"presentations/#2023","text":"PeeringDB Update at RIPE 87 , Rome, IT - November 30, 2023 - Leo Vegoda What's new on PeeringDB? at MIX Salotto 2023 , Milan, IT - November 15, 2023 - Livio Morina What is PeeringDB? Why is it important for network operators? at RSNOG9 , Belgrade, RS - November 9, 2023 - Livio Morina What\u2019s new on PeeringDB? at GRNOG 15 , Athens, GR - October 25, 2023 - Livio Morina What\u2019s new on PeeringDB? at FRnOG 38 , Paris, FR - October 6, 2023 - Livio Morina PeeringDB Operations & Product Update at SwiNOG#38 , Berne, CH - June 21, 2023 - Arnold Nipper PeeringDB Update at RIPE 86 , Rotterdam, NL - May 25, 2023 - Leo Vegoda PeeringDB Operations & Product Update at ITNOG7 , Bologna, IT - May 9, 2023 - Arnold Nipper What\u2019s new on PeeringDB? at the 38th Euro-IX Forum , Cluj-Napoca, RO - April 24, 2023 - Arnold Nipper PeeringDB Operations & Product Update at SEE 11 , Split, HR - April 5, 2023 - Arnold Nipper PeeringDB Operations & Product Update at GPF 2023 , Coronado, CA, US - April 4, 2023 - Matt Griswold PeeringDB Operations & Product Update at Peering Days 2023 , Sofia, BG - March 30, 2023 - Arnold Nipper PeeringDB Operations & Product Update at DKNOG13 , Copenhagen, DK - March 10, 2023 - Arnold Nipper","title":"2023"},{"location":"presentations/#2022","text":"PeeringDB at AOPF/AONOG 2022 - December 8, 2022 - Darwin Da Costa PeeringDB Operations & Product Update at DENOG14 , Hamburg, DE - November 15, 2022 - Arnold Nipper PeeringDB Operations & Product Update at RIPE 85 , Belgrade, RS - October 26, 2022 - Arnold Nipper PeeringDB Operations & Product Update at ngPIF 2022 , Lagos, NG - October 25, 2022 - Ben Ryall PeeringDB at WTR POP-PI 2022 - October 20, 2022 - Julimar Lunguinho Mendes ( video ) PeeringDB Call for Committee Members at NANOG 86 , Hollywood, CA, US - October 19, 2022 - Patrick Gilmore PeeringDB Operations & Product Update at the 37th Euro-IX Forum , Edinburgh, UK - October 11, 2022 - Greg Hankins PeeringDB Update at EPF 2022 , Rome, IT - September 12, 2022 - Arnold Nipper PeeringDB Update at AfPIF 2022 , Kigali, RW - August 23, 2022 - Ben Ryall PeeringDB Update at GPF 2022 , Washington, DC, US - May 12, 2022 - Chris Malayter 2021 Status Update at Virtual Tech Day with Euro-IX PeeringToolbox - February 3, 2022 - Leo Vegoda","title":"2022"},{"location":"presentations/#2021","text":"Introduction to PeeringDB at GNA-G Routing WG - December 14, 2021 - Arnold Nipper PeeringDB Update at Semana de Capacita\u00e7\u00e3o On-line 3 - October 1, 2021 - Julimar Lunguinho Mendes PeeringDB Update at WTR PoP-MA - September 30, 2021 - Julimar Lunguinho Mendes","title":"2021"},{"location":"presentations/#2020","text":"PeeringDB at IX F\u00f3rum 14 - December 4, 2020 - Julimar Lunguinho Mendes ( video ) Introducci\u00f3n a PeeringDB at Seguridad en el Ruteo: MANRS para Operadores de Red de Universidades - October 2, 2020 - Diego Dominguez Data Ownership Policy Implementation Presentation - August 17, 2020 - Filiz Yilmaz, Steve McManus, Arnold Nipper ( video ) PeeringDB Data Ownership Task Force at PeeringDB Annual Meeting 2020 - April 17, 2020 - Filiz Yilmaz PeeringDB at ABRINT na Estrada Campo Grande , Campo Grande, BR - March 10, 2020 - Julimar Lunguinho Mendes PeeringDB Update at PhNOG 2020 , Manila, PH - February 26, 2020 - Arnold Nipper PeeringDB Update at APRICOT 2020 , Melbourne, AU - February 19, 2020 - Arnold Nipper","title":"2020"},{"location":"presentations/#2019","text":"PeeringDB Update (English)/ \u041d\u043e\u0432\u043e\u0441\u0442\u0438 \u043e\u0442 PeeringDB (P\u0443\u0441\u0441\u043a\u0438\u0439) at MSK-IX Peering Forum 2019 , Moscow, RU - December 5, 2019 - Filiz Yilmaz PeeringDB - Como Est\u00e1 a Ado\u00e7\u00e3o no Brasil at MUM in Brazil , Foz do Igua\u00e7u, BR - November 29, 2019 - Julimar Lunguinho Mendes PeeringDB Para Que Sirve? at XII Encuentro Nacional de T\u00e9cnicos , Salta, AR - November 28, 2019 - Hernan Moguilevsky PeeringDB Update: A Look Into PeeringDB's Data for AT/CH/DE/LU and the Latest Changes at DENOG11 , Hamburg, DE - November 12, 2019 - Stefan Funke PeeringDB Update at Peering Asia 3.0 , Kuala Lumpur, MY - November 7, 2019 - Arnold Nipper PeeringDB Update at ATNOG 2019/2 , Vienna, AT - November 5, 2019 - Stefan Funke Introduction to PeeringDB at JBIX Peering Forum 2019 , Kuala Lumpur, MY - November 5, 2019 - Arnold Nipper Introduction to PeeringDB at ngNOG 2019 , Lagos, NG - October 30, 2019 - Ben Ryall Cadastro para participantes do IX.br at IX F\u00f3rum Regional , Florian\u00f3polis, BR - October 25, 2019 - Julimar Lunguinho Mendes OAuth for IXP Operators at the 35th Euro-IX Forum , Zaandam, NL - October 21, 2019 - Barry O'Donovan The PeeringDB API at the 35th Euro-IX Forum , Zaandam, NL - October 21, 2019 - Arnold Nipper Introduction to PeeringDB at RONOG 6 , Bucharest, RO - October 1, 2019 - Arnold Nipper PeeringDB Update at EPF14 , Tallinn, EE - September 18, 2019 - Filiz Yilmaz Cadastro para participantes do IX.br at IX F\u00f3rum Regional , Natal, BR - September 6, 2019 - Julimar Lunguinho Mendes Introduction to PeeringDB at SAFNOG-5 , Johannesburg, ZA - August 28, 2019 - Arnold Nipper Introduction to PeeringDB at AfPIF-10 , Balaclava, MV - August 22, 2019 - Arnold Nipper Introducci\u00f3n a PeeringDB at MexNOG 2019 , Mexico City, MX - August 14, 2019 - Diego Dominguez Introduction to PeeringDB at ATNOG 2019/1 , Salzburg, AT - July 16, 2019 - Arnold Nipper Introduction to PeeringDB at INNOG 2 , New Delhi, IN - July 1, 2019 - Arnold Nipper ( video ) Cadastro para participantes do IX.br at IX F\u00f3rum Regional , S\u00e3o Paulo, BR - June 10, 2019 - Julimar Lunguinho Mendes News from PeeringDB at ENOG 16 , Tbilisi, GE - June 3, 2019 - Arnold Nipper PeeringDB Update at NONOG-3 , Oslo, NO - May 27, 2019 - Arnold Nipper PeeringDB Update at SINOG 6.0 , Ljubljana, SI - May 14, 2019 - Arnold Nipper Introduction to PeeringDB at BKNIX Peering Forum and ThaiNOG Day 2019 , Bangkok, TH - May 7, 2019 - Arnold Nipper Use in Latin America at Peering Forum LAC , Punta Cana, DR - May 6, 2019 - Julimar Lunguinho Mendes and Carlos Martinez Cagnazzo Cadastro para participantes do IX.br at IX F\u00f3rum Regional , Campo Grande, BR - April 26, 2019 - Julimar Lunguinho Mendes Introduction to PeeringDB at Telecom Day , St. Petersburg, RU - April 19, 2019 - Arnold Nipper PeeringDB Update at SEE 8 , Sarajevo, BH - April 17, 2019 - Arnold Nipper PeeringDB Update at Curso Avan\u00e7ado de IPv6 , S\u00e3o Paulo, BR - April 5, 2019 - Julimar Lunguinho Mendes PeeringDB Update at BCIX Round Table April 2019 , Berlin, DE - April 4, 2019 - Stefan Funke PeeringDB Update at MENOG 19 , Beirut, LB - April 3, 2019 - Arnold Nipper PeeringDB Update at DKNOG9 , Copenhagen, DK - March 15, 2019 - Arnold Nipper PeeringDB Update at Peering Days 2019 , Zagreb, CR - March 12, 2019 - Arnold Nipper PeeringDB Update at PhNOG 2019 , Cebu, PH - March 8, 2019 - Arnold Nipper PeeringDB Update at HKNOG 7.0 , Hong Kong, HK - March 1, 2019 - Arnold Nipper","title":"2019"},{"location":"presentations/#2018","text":"PeeringDB Update at MSK-IX Peering Forum 2018 , Moscow, RU - November 23, 2018 - Rebecca Stani\u0107 PeeringDB Update at DENOG10 , Darmstadt, DE - November 21, 2018 - Arnold Nipper PeeringDB Update at ITNOG4 , Bologna, IT - November 9, 2018 - Arnold Nipper Introduction to PeeringDB API at the 33rd Euro-IX Forum , Venice, IT - November 6, 2018 - Arnold Nipper PeeringDB Introduction at ngNOG 2018 , Lagos, NG - October 31, 2018 - Ben Ryall PeeringDB Update at SwiNOG #34 , Berne, CH - October 30, 2018 - Arnold Nipper PeeringDB Update and Japanese Localization Experience at Peering Asia 2.0 , Hong Kong, HK - October 25, 2018 - Arnold Nipper and Masataka Mawatari PeeringDB Update at SAFNOG-4/EANOG/tzNOG , Dar es Salaam, TZ - September 25, 2018 - Arnold Nipper PeeringDB Update at EPF 13 , Athens, GR - September 18, 2018 - Rebecca Stani\u0107 Cadastro para participantes do IX.br at IX (PTT) F\u00f3rum Regional , Natal, BR - September 14, 2018 - Julimar Lunguinho Mendes PeeringDB Frontend Translation Project at APNIC 46 , Noumea, NC - September 12, 2018 - Masataka Mawatari PeeringDB Update at AfPIF2018 , Cape Town, ZA - August 23, 2018 - Arnold Nipper PeeringDB for IXes at AFIX , Cape Town, ZA - August 20, 2018 - Arnold Nipper Introduction to PeeringDB API at SANOG 32 , Dhaka, BD - August 10, 2018 - Arnold Nipper PeeringDB Update at SANOG 32 , Dhaka, BD - August 9, 2018 - Arnold Nipper PeeringDB: What is it, how to and benefits at New England Peering Forum 2018 , Cambridge, MA, US - June 22, 2018 - Patrick W. Gilmore PeeringDB Update at SEE 7 , Timi\u0219oara, R0 - June 18, 2018 - Arnold Nipper PeeringDB Update at ENOG 15 , Moscow, RU - June 5, 2018 - Arnold Nipper PeeringDB Update at SwiNOG 33 , Berne, CH - May 24, 2018 - Arnold Nipper PeeringDB Update e cadastro de Facilities at GTER 45 , Florian\u00f3polis, BR - May 22, 2018 - Julimar Lunguinho Mendes ( video ) PeeringDB Update at RIPE 76 Connect Working Group , Marseille, FR - May 16, 2018 - Arnold Nipper ( video ) PeeringDB Update at African Internet Summit 2018 , Dakar, SN - May 8, 2018 - Arnold Nipper PeeringDB Update at DKNOG8 , Copenhagen, DK - March 9, 2018 - Arnold Nipper PeeringDB Update at CEE Peering Days 2018 , Berlin, DE - March 7, 2018 - Arnold Nipper Introduction to PeeringDB at APRICOT 2018 , Kathmandu, NP - February 26, 2018 - Arnold Nipper PeeringDB Update at APIX Meeting #17 , Kathmandu, NP - February 24, 2018 - Arnold Nipper PeeringDB Introduction at Capacity India & SAARC 2018 , New Delhi, IN - February 8, 2018 - Arnold Nipper","title":"2018"},{"location":"presentations/#2017","text":"PeeringDB Update at NIX.cz Member Meering , Prague, CZ - November 23, 2017 - Bijal Sanghani PeeringDB Update at DENOG9 , Darmstadt, DE - November 23, 2017 - Arnold Nipper PeeringDB Update at ALNOF , Tirana, AL - November 14, 2017 - Bijal Sanghani PeeringDB Update at Peering Asia 1.0 , Kyoto, JP - November 1, 2017 - Arnold Nipper PeeringDB Update at TOP-IX Meeting , Torino, IT - September 26, 2017 - Bijal Sanghani PeeringDB Update at NPD 17 , The Hague, NL - September 15, 2017 - Arnold Nipper PeeringDB Update at SAFNOG-3 , Durban, ZA - September 6, 2017 - Arnold Nipper PeeringDB Update at AfPIF 2017 , Abidjan, CI - August 24, 2017 - Arnold Nipper PeeringDB Update at SANOG 30 Peering Forum, Gurgaon, IN - July 10, 2017 - Arnold Nipper More benefits from PeeringDB at DE-CIX Technical Meeting , Frankfurt, DE - June 22, 2017 - Arnold Nipper PeeringDB Update at NANOG 70 , Bellevue, WA, US - June 5, 2017 - Aaron Hughes PeeringDB Update at BOSNOG Meeting & IX Peering Forum , Cambridge, MA, US - June 2, 2017 - Stephen McManus Orienta\u00e7\u00f5es no preenchimento de participantes do IX.br at GTER 43 , Foz do Igua\u00e7u, BR - May 25, 2017 - Julimar Lunguinho Mendes PeeringDB Update at ENOG 13.0 , Saint Petersburg, RU - May 23, 2017 - Arnold Nipper PeeringDB Update at Global Peering Forum 12.0 , New York, NY, US - April 26, 2017 - Aaron Huges PeeringDB at GORE/ESNOG Reunion 19 , Barcelona, ES - April 6, 2017 - Arnold Nipper PeeringDB at CEE Peering Days 2017 , Ljubljana, SL - March 23, 2017 - Arnold Nipper PeeringDB 2.0 at APRICOT 2017 , Ho Chi Minh City, VN - February 28, 2017 - Arnold Nipper","title":"2017"},{"location":"presentations/#2016","text":"PeeringDB at 19 KIKE Conference , Serock, PL - November 23, 2016 - Robert Jakub PeeringDB 2.0 at ITNOG2 , Bologna, IT - November 3, 2016 - Arnold Nipper PeeringDB Product Committee Charter Survey at EPF 11 , Sofia, BG - September 20, 2016 - Eric Loos PeeringDB 2.0 at NPD 16 , The Hague, NL - September 16, 2016 - Walt Wollny PeeringDB 2.0 at AfPIF 2016 , Dar es Salaam, TZ - August 30, 2016 - Arnold Nipper PeeringDB 2.0 for IXPs at AFIX 2016 , Dar es Salaam, TZ - August 29, 2016 - Arnold Nipper PeeringDB 2.0 at ENOG 11 , Moscow, RU - June 7, 2016 - Arnold Nipper PeeringDB 2.0 at RIPE 72 , Copenhagen, DK - May 25, 2016 - Greg Hankins PeeringDB 2.0 at CHI-NOG 06 , Chicago, IL, US - May 12, 2016 - Matt Griswold PeeringDB 2.0 e o Cen\u00e1rio Brasileiro and IX.br Guia de cadastro de informa\u00e7\u00f5es de ASNs no PeeringDB at GTER 41 , Uberl\u00e2ndia, BR - May 12, 2016 - Eduardo Ascen\u00e7o Reis PeeringDB 2.0 for IXPs at 28th Euro-IX Forum , Luxembourg, LU - April 26, 2016 - Greg Hankins / Arnold Nipper RIPE SEE 5 , Tirana, AL - April 19, 2016 - Arnold Nipper PeeringDB 2.0 at UKNOF34 , Manchester, UK - April 21, 2016 - Greg Hankins PeeringDB Update at GPF 11 , Los Angeles, CA, US - April 13, 2016 - Aaron Hughes NetNod , Stockholm, SE - March 17, 2016 - Job Snijders DKNOG6 , Copenhagen, DK - March 10, 2016 - Job Snijders PeeringDB Update - Aaron Hughes APRICOT 2016 , Auckland, NZ - February 23, 2016 - Aaron Hughes NANOG 66 , San Diego, CA, US - February 10, 2016 - Aaron Hughes PeeringDB Version 2 Coding Introduction at NANOG 66 , San Diego, CA, US - February 8, 2016 - Matt Griswold","title":"2016"},{"location":"presentations/#2015","text":"PeeringDB Version 2 Brazil - Matt Griswold / Greg Hankins IX (PTT) F\u00f3rum 9 , S\u00e3o Paulo, BR - December 8, 2015 - Greg Hankins PeeringDB Version 2 Introduction - Matt Griswold 27th Euro-IX Forum , Berlin, DE - October 26, 2015 - Greg Hankins DENOG7 , Darmstadt, DE - October 30, 2015 - Arnold Nipper","title":"2015"},{"location":"tools/","text":"Tools to Help You Get the Best from PeeringDB Many PeeringDB users develop tools that make use of our API to help you analyze our data and make informed decisions. This page features tools that have been made freely available for anyone to use under permissive licenses. If you have developed a tool and would like to be added to this page, please contact support@peeringdb.com with details and we will follow up with you. Name Function ARouteServer ARouteServer builds and tests feature-rich configurations for BGP route servers. Routing policy information is sourced from PeeringDB. It delivers a templated configuration file for BIRD or OpenBGPD route servers. django-peeringdb Django library with a local PeeringDB database sync. It defines the database schema to create a local database copy. The library is easy to integrate into a common framework for local tools and custom interfaces, and also supports multiple database engines (MySQL, Postgres, SQLite). ixgen Ixgen is yet-another open-source, multi-platform generator for peering configurations on IXs incorporating the global peeringdb api, but also is able to spin up its own \"compatible\" server for faster results. Ixgen is configured by an INI- or JSON-style format, producing custom template-driven or fixed json-style configurations, that can be printed on the terminal, to a file or served by HTTP. IXP Manager IXP Manager is a full stack management platform for Internet eXchange Points (IXPs) which includes an administration and customer portal; provides end to end provisioning; and both teaches and implements best practice. pdb-intersect Find common peering points in peeringdb. This is a brother to PeerFinder . It will find common possible peering points, even if either of the peering parties is NOT using the same ASN in all locations (like, incidentally, 3557 does). PeerFinder PeerFinder is a python3.7 and beyond script which finds common points of presence between ASNs as reported by PeeringDB. Peering Manager Peering Manager is an open-source BGP management solution built with Python and Django. Designed with features and simplicity in mind, it allows engineers to track and configure BGP sessions on networks without having to copy and paste existing configurations. peeringdb-py peeringdb-py is a Python client for PeeringDB. It features functions to get objects and display them in JSON or YAML format, and provides a whois-like display of records. The client also has an integrated local database sync, and provides a Python library for integration with custom tools. Some examples are available too. rich-traceroute rich-traceroute enhances traceroute output with additional information, like the origin ASNs of the IPs and the name of any Internet Exchange peering LAN that shows up in the path. Search in PeeringDB Search in PeeringDB a Chrome extension to search for ASNs, networks, and IXs in PeeringDB using the context menu. TraceMON TraceMON is a tool for visualizing a network topology generated by traceroutes that provides one-click access to IXP and network information. It also displays PeeringDB information and allows the user to update their record. RIPE Atlas users can access it by selecting a traceroute measurement and clicking on the TraceMON tab","title":"Tools to Help You Get the Best from PeeringDB"},{"location":"tools/#tools-to-help-you-get-the-best-from-peeringdb","text":"Many PeeringDB users develop tools that make use of our API to help you analyze our data and make informed decisions. This page features tools that have been made freely available for anyone to use under permissive licenses. If you have developed a tool and would like to be added to this page, please contact support@peeringdb.com with details and we will follow up with you. Name Function ARouteServer ARouteServer builds and tests feature-rich configurations for BGP route servers. Routing policy information is sourced from PeeringDB. It delivers a templated configuration file for BIRD or OpenBGPD route servers. django-peeringdb Django library with a local PeeringDB database sync. It defines the database schema to create a local database copy. The library is easy to integrate into a common framework for local tools and custom interfaces, and also supports multiple database engines (MySQL, Postgres, SQLite). ixgen Ixgen is yet-another open-source, multi-platform generator for peering configurations on IXs incorporating the global peeringdb api, but also is able to spin up its own \"compatible\" server for faster results. Ixgen is configured by an INI- or JSON-style format, producing custom template-driven or fixed json-style configurations, that can be printed on the terminal, to a file or served by HTTP. IXP Manager IXP Manager is a full stack management platform for Internet eXchange Points (IXPs) which includes an administration and customer portal; provides end to end provisioning; and both teaches and implements best practice. pdb-intersect Find common peering points in peeringdb. This is a brother to PeerFinder . It will find common possible peering points, even if either of the peering parties is NOT using the same ASN in all locations (like, incidentally, 3557 does). PeerFinder PeerFinder is a python3.7 and beyond script which finds common points of presence between ASNs as reported by PeeringDB. Peering Manager Peering Manager is an open-source BGP management solution built with Python and Django. Designed with features and simplicity in mind, it allows engineers to track and configure BGP sessions on networks without having to copy and paste existing configurations. peeringdb-py peeringdb-py is a Python client for PeeringDB. It features functions to get objects and display them in JSON or YAML format, and provides a whois-like display of records. The client also has an integrated local database sync, and provides a Python library for integration with custom tools. Some examples are available too. rich-traceroute rich-traceroute enhances traceroute output with additional information, like the origin ASNs of the IPs and the name of any Internet Exchange peering LAN that shows up in the path. Search in PeeringDB Search in PeeringDB a Chrome extension to search for ASNs, networks, and IXs in PeeringDB using the context menu. TraceMON TraceMON is a tool for visualizing a network topology generated by traceroutes that provides one-click access to IXP and network information. It also displays PeeringDB information and allows the user to update their record. RIPE Atlas users can access it by selecting a traceroute measurement and clicking on the TraceMON tab","title":"Tools to Help You Get the Best from PeeringDB"},{"location":"translation/","text":"Contributing to translations Adding a new locale If you wish to add a new locale, create a new ticket at https://github.com/peeringdb/peeringdb/issues stating your intent and one of the operators / developers will generate the necessary files for your locale and add them to the repository. Translation is done using PeeringDB's Weblate instance at https://translate.peeringdb.com/ . Signing in to Weblate Authentication is done via your PeeringDB credentials. So the only thing you have to do is to register with PeeringDB. Selecting languages Go to https://translate.peeringdb.com/accounts/profile/ to edit your profile and also to select the languages you want to help with. Viewing updates Translations are updated hourly on the beta website https://beta.peeringdb.com/ and daily at 0000 UTC on the production website https://www.peeringdb.com/ . Mailing list The http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-translate mailing list is open to anyone working on, or interested in translations. Thanks to the translators! ar Sara Alamin Mohamed Hassan de Sara Fink Stefan Funke Arnold Nipper jp Yutaro Fujii Norisuke Hirai Yuki Ikuno Chise Kawamura Kaoru Kitauchi Shintaro Kojima Yutaka Kumamoto Ryohey Matsumoto Masataka Mawatari Akira Nakagawa Satoshi Okawa Hideyuki Sasaki Tomocha Katsuyasu Toyama Taiji Tsuchiya Yudai Yamagishi Katsushi Yamaguchi Junpei Yoshino pt Ligio Gomes (NTT Communications) Robert Philips (NTT Communications)","title":"Translations"},{"location":"translation/#contributing-to-translations","text":"","title":"Contributing to translations"},{"location":"translation/#adding-a-new-locale","text":"If you wish to add a new locale, create a new ticket at https://github.com/peeringdb/peeringdb/issues stating your intent and one of the operators / developers will generate the necessary files for your locale and add them to the repository. Translation is done using PeeringDB's Weblate instance at https://translate.peeringdb.com/ .","title":"Adding a new locale"},{"location":"translation/#signing-in-to-weblate","text":"Authentication is done via your PeeringDB credentials. So the only thing you have to do is to register with PeeringDB.","title":"Signing in to Weblate"},{"location":"translation/#selecting-languages","text":"Go to https://translate.peeringdb.com/accounts/profile/ to edit your profile and also to select the languages you want to help with.","title":"Selecting languages"},{"location":"translation/#viewing-updates","text":"Translations are updated hourly on the beta website https://beta.peeringdb.com/ and daily at 0000 UTC on the production website https://www.peeringdb.com/ .","title":"Viewing updates"},{"location":"translation/#mailing-list","text":"The http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-translate mailing list is open to anyone working on, or interested in translations.","title":"Mailing list"},{"location":"translation/#thanks-to-the-translators","text":"","title":"Thanks to the translators!"},{"location":"translation/#ar","text":"Sara Alamin Mohamed Hassan","title":"ar"},{"location":"translation/#de","text":"Sara Fink Stefan Funke Arnold Nipper","title":"de"},{"location":"translation/#jp","text":"Yutaro Fujii Norisuke Hirai Yuki Ikuno Chise Kawamura Kaoru Kitauchi Shintaro Kojima Yutaka Kumamoto Ryohey Matsumoto Masataka Mawatari Akira Nakagawa Satoshi Okawa Hideyuki Sasaki Tomocha Katsuyasu Toyama Taiji Tsuchiya Yudai Yamagishi Katsushi Yamaguchi Junpei Yoshino","title":"jp"},{"location":"translation/#pt","text":"Ligio Gomes (NTT Communications) Robert Philips (NTT Communications)","title":"pt"},{"location":"blog/2022_product_report/","text":"PeeringDB 2022 Product Report Data quality and search were ranked most important by respondents to our last three user surveys. This update looks at improvements we have made to keep data quality high by improving automation, giving users better tools, and making it easier to find and export data in PeeringDB. How to sum up what PeeringDB delivered for its users in 2022? Let's start with some numbers that help describe the scale of the work we\u2019ve done. This year, we put out 10 major releases resolving over 100 issues. These included: Search and export improvements Continued improvements to support for IX-F Member Export Better tools to support organizational admins 10 more HOWTO documents We got contributions from a number of community members, including engineers at Amazon and Google. Search We normalised the names of states and provinces to improve search results. This builds on the improvements to advanced search deployed in 2021, which allow users to drill down to get very specific information and export in structured formats. Managing your organization We improved the way organizational admins can manage their users. Features include the ability to require affiliated users to enable Multi Factor Authentication using authenticator apps or a hardware token, or use a particular email domain. Automation We implemented a process to ensure that old networks are removed from PeeringDB when the RIRs or NIRs deregister their AS Numbers. In combination with regular improvements to our support for the IX-F Member Export Schema, we are ensuring that PeeringDB\u2019s data remains fresh. Operations We built on last year\u2019s improvements to API Key support. We introduced query throttling with authenticated users getting more queries. We also worked with developers of third-party tools that query PeeringDB so that they make efficient queries. We want users to have the best experience they can. So we teamed up with members of the community at the NANOG 86 Hackathon to install our local cache, peeringdb-py , on a wide range of systems. Having tested that we have documented the installation process to make it easier for users to sync PeeringDB to their own infrastructure. Documentation Last year we introduced our HOWTO series . This year we expanded it and have had to organise it into five sections. We probably have an explanation of how to do what you want. If there\u2019s something missing, then please let us know. User support Sometimes users need support. We\u2019ve improved lots of support tools, so we can help users more quickly and effectively. On average, tickets are resolved in under eight hours, with automation managing 40% of this workload. What\u2019s Coming Next? Two major improvements scheduled for early 2023 include further improvements to search, and translation for anonymous web users. We\u2019ll publish a more detailed product roadmap towards the end of January. The improvements we make are only as good as the requests we get from you. We want to make sure that we understand what you need and why. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB 2022 Product Report"},{"location":"blog/2022_product_report/#peeringdb-2022-product-report","text":"Data quality and search were ranked most important by respondents to our last three user surveys. This update looks at improvements we have made to keep data quality high by improving automation, giving users better tools, and making it easier to find and export data in PeeringDB. How to sum up what PeeringDB delivered for its users in 2022? Let's start with some numbers that help describe the scale of the work we\u2019ve done. This year, we put out 10 major releases resolving over 100 issues. These included: Search and export improvements Continued improvements to support for IX-F Member Export Better tools to support organizational admins 10 more HOWTO documents We got contributions from a number of community members, including engineers at Amazon and Google.","title":"PeeringDB 2022 Product Report"},{"location":"blog/2022_product_report/#search","text":"We normalised the names of states and provinces to improve search results. This builds on the improvements to advanced search deployed in 2021, which allow users to drill down to get very specific information and export in structured formats.","title":"Search"},{"location":"blog/2022_product_report/#managing-your-organization","text":"We improved the way organizational admins can manage their users. Features include the ability to require affiliated users to enable Multi Factor Authentication using authenticator apps or a hardware token, or use a particular email domain.","title":"Managing your organization"},{"location":"blog/2022_product_report/#automation","text":"We implemented a process to ensure that old networks are removed from PeeringDB when the RIRs or NIRs deregister their AS Numbers. In combination with regular improvements to our support for the IX-F Member Export Schema, we are ensuring that PeeringDB\u2019s data remains fresh.","title":"Automation"},{"location":"blog/2022_product_report/#operations","text":"We built on last year\u2019s improvements to API Key support. We introduced query throttling with authenticated users getting more queries. We also worked with developers of third-party tools that query PeeringDB so that they make efficient queries. We want users to have the best experience they can. So we teamed up with members of the community at the NANOG 86 Hackathon to install our local cache, peeringdb-py , on a wide range of systems. Having tested that we have documented the installation process to make it easier for users to sync PeeringDB to their own infrastructure.","title":"Operations"},{"location":"blog/2022_product_report/#documentation","text":"Last year we introduced our HOWTO series . This year we expanded it and have had to organise it into five sections. We probably have an explanation of how to do what you want. If there\u2019s something missing, then please let us know.","title":"Documentation"},{"location":"blog/2022_product_report/#user-support","text":"Sometimes users need support. We\u2019ve improved lots of support tools, so we can help users more quickly and effectively. On average, tickets are resolved in under eight hours, with automation managing 40% of this workload.","title":"User support"},{"location":"blog/2022_product_report/#whats-coming-next","text":"Two major improvements scheduled for early 2023 include further improvements to search, and translation for anonymous web users. We\u2019ll publish a more detailed product roadmap towards the end of January. The improvements we make are only as good as the requests we get from you. We want to make sure that we understand what you need and why. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"What\u2019s Coming Next?"},{"location":"blog/2023_product_report/","text":"2023 Product Report PeeringDB users have consistently ranked data quality and search as most important. We worked on improvements to these core aspects of our service alongside others in 2023. We didn\u2019t run a survey at the end of 2023 as we heard the same message consistently. We are in the process of delivering improvements and will survey users again when we have completed their delivery. We deployed 12 releases in 2023, addressing 76 issues, 11 of which were bugs. We also introduced four new features and made some significant improvements that all users will care about. New data We introduced two new objects in 2023. The Carrier object describes networks providing high capacity links between facilities. Now, when you look at a facility you can scroll down and see which carriers have a presence there. We also introduced the Campus object. This is a set object. It describes a group of facilities where inter-buildings cross-connects are available. When you look at a campus's page on our website you'll see which facilities: Are served by each Carrier Where each Ix is present Where each Network is present Data access We also started publishing all our facility data in a .KMZ file, which we update once a day. You can either download it regularly or set it as a network location in Google Earth Pro. You can view facilities in a map view and overlay them with other datasets. We also introduced a new search backend. You can now search for a type of data in a location. It knows the coordinates of facilities and has a radius for each locality. This means you don't need to worry about city names in conurbations \u2013 or rural areas. Data quality We introduced a way for your internal source of truth to propose updates to PeeringDB . You don't need to give your internal source of truth any PeeringDB credentials. You can then log into our website and approve or deny the changes. This helps organizations that are too big for fully manual updates but not big enough to want to automate everything. Improvements We introduced some policy options for organization admins in 2023. PeeringDB Oauth is increasingly relied on for peering and more. Now, organization admins can require their users to: Enable 2FA Use an email address tied to a specific domain Reconfirm their address periodically We also introduced a peering permission . Now admins can control who is able to use PeeringDB Oauth for peering portals. Volunteer developers We're glad that volunteers can contribute to PeeringDB. We improved the development environment a couple of years ago and volunteers use it. We'd like to acknowledge 2023 contributions from: Carlos Aguado Daniel Van Allen Todd Crane kiraum What's coming in 2024? PeeringDB users have told us that they love the simplicity of our web UI. They've also told us that it's outdated and slow. We have developed new designs for our front end and admin interfaces. We'll start rolling these out in parallel soon. You'll be able to test and provide feedback through preview.peeringdb.com. We started that process early in 2024. It didn\u2019t go quite right, so we rolled back the changes and will improve our testing and deployment processes. We'll also be making significant improvements to our .KMZ support. We'll streamline the daily export and make .KMZ available as an export format for Advanced Searches, where that makes sense. We'll also continue to improve support for the carrier and campus objects. People The Admin Committee , the people behind support@peeringdb.com, changed in 2023. Chriztoffer Hansen took the chair, Peter Helmenstine the vice-chair, and new members joined: Budiwijaya Ron Grant Adam Korab Cris\u00f3stomo Mbundu Ryan Williams Ben Ryall recruited new members for the Outreach Committee in 2023: Lynsey Buckingham Tarryn Kidd Jonathan Martone Ester Paal The Product Committee changed for the start of 2024. We have three new members: Jeff Bartig Jack Carrozzo Paul Hoogsteder And Stephen McManus will step down as chair of the committee at the start of March. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"2023 Product Report"},{"location":"blog/2023_product_report/#2023-product-report","text":"PeeringDB users have consistently ranked data quality and search as most important. We worked on improvements to these core aspects of our service alongside others in 2023. We didn\u2019t run a survey at the end of 2023 as we heard the same message consistently. We are in the process of delivering improvements and will survey users again when we have completed their delivery. We deployed 12 releases in 2023, addressing 76 issues, 11 of which were bugs. We also introduced four new features and made some significant improvements that all users will care about.","title":"2023 Product Report"},{"location":"blog/2023_product_report/#new-data","text":"We introduced two new objects in 2023. The Carrier object describes networks providing high capacity links between facilities. Now, when you look at a facility you can scroll down and see which carriers have a presence there. We also introduced the Campus object. This is a set object. It describes a group of facilities where inter-buildings cross-connects are available. When you look at a campus's page on our website you'll see which facilities: Are served by each Carrier Where each Ix is present Where each Network is present","title":"New data"},{"location":"blog/2023_product_report/#data-access","text":"We also started publishing all our facility data in a .KMZ file, which we update once a day. You can either download it regularly or set it as a network location in Google Earth Pro. You can view facilities in a map view and overlay them with other datasets. We also introduced a new search backend. You can now search for a type of data in a location. It knows the coordinates of facilities and has a radius for each locality. This means you don't need to worry about city names in conurbations \u2013 or rural areas.","title":"Data access"},{"location":"blog/2023_product_report/#data-quality","text":"We introduced a way for your internal source of truth to propose updates to PeeringDB . You don't need to give your internal source of truth any PeeringDB credentials. You can then log into our website and approve or deny the changes. This helps organizations that are too big for fully manual updates but not big enough to want to automate everything.","title":"Data quality"},{"location":"blog/2023_product_report/#improvements","text":"We introduced some policy options for organization admins in 2023. PeeringDB Oauth is increasingly relied on for peering and more. Now, organization admins can require their users to: Enable 2FA Use an email address tied to a specific domain Reconfirm their address periodically We also introduced a peering permission . Now admins can control who is able to use PeeringDB Oauth for peering portals.","title":"Improvements"},{"location":"blog/2023_product_report/#volunteer-developers","text":"We're glad that volunteers can contribute to PeeringDB. We improved the development environment a couple of years ago and volunteers use it. We'd like to acknowledge 2023 contributions from: Carlos Aguado Daniel Van Allen Todd Crane kiraum","title":"Volunteer developers"},{"location":"blog/2023_product_report/#whats-coming-in-2024","text":"PeeringDB users have told us that they love the simplicity of our web UI. They've also told us that it's outdated and slow. We have developed new designs for our front end and admin interfaces. We'll start rolling these out in parallel soon. You'll be able to test and provide feedback through preview.peeringdb.com. We started that process early in 2024. It didn\u2019t go quite right, so we rolled back the changes and will improve our testing and deployment processes. We'll also be making significant improvements to our .KMZ support. We'll streamline the daily export and make .KMZ available as an export format for Advanced Searches, where that makes sense. We'll also continue to improve support for the carrier and campus objects.","title":"What's coming in 2024?"},{"location":"blog/2023_product_report/#people","text":"The Admin Committee , the people behind support@peeringdb.com, changed in 2023. Chriztoffer Hansen took the chair, Peter Helmenstine the vice-chair, and new members joined: Budiwijaya Ron Grant Adam Korab Cris\u00f3stomo Mbundu Ryan Williams Ben Ryall recruited new members for the Outreach Committee in 2023: Lynsey Buckingham Tarryn Kidd Jonathan Martone Ester Paal The Product Committee changed for the start of 2024. We have three new members: Jeff Bartig Jack Carrozzo Paul Hoogsteder And Stephen McManus will step down as chair of the committee at the start of March. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"People"},{"location":"blog/advanced_search_1/","text":"Advanced Search (Part 1) You told us in our 2020 survey that improving search was your top priority. That\u2019s why we have been making some database changes to support better search. In a recent release we rolled out changes that significantly improve the performance of our advanced search feature. Advanced search now lets you explicitly filter searches location, network presence, service level and a wide range of other features. You get the results you\u2019re looking for and can export them in structured data formats, so you can import the data into tools that will help you make decisions. We are continuing to work on improvements to the advanced search options. We will then turn our focus to the default search. This set of improvements to search will build on the work we delivered earlier in the year and allow more geographically targeted searches. Take a look at the advanced search feature and try it for yourself! If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Advanced Search (Part 1)"},{"location":"blog/advanced_search_1/#advanced-search-part-1","text":"You told us in our 2020 survey that improving search was your top priority. That\u2019s why we have been making some database changes to support better search. In a recent release we rolled out changes that significantly improve the performance of our advanced search feature. Advanced search now lets you explicitly filter searches location, network presence, service level and a wide range of other features. You get the results you\u2019re looking for and can export them in structured data formats, so you can import the data into tools that will help you make decisions. We are continuing to work on improvements to the advanced search options. We will then turn our focus to the default search. This set of improvements to search will build on the work we delivered earlier in the year and allow more geographically targeted searches. Take a look at the advanced search feature and try it for yourself! If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Advanced Search (Part 1)"},{"location":"blog/advanced_search_2/","text":"Advanced Search (Part 2) We\u2019ve published a couple of recent blogs about how we are improving search, following feedback on its importance in the 2020 user survey . Here\u2019s another one! We introduced two significant improvements in the production release 2.28.0. Our first improvement makes it easier to search based on a partial name. When an organization\u2019s name has two parts, you can now search for just the first part and then select from all the organizations that share that name. Previously, search worked on exact matches. This change makes it easier for users to find the organizations they want. Our second improvement allows users to search for facilities within a given radius, using the Advanced Search interface. Users can search from a country and city, and select a radius in kilometres or miles. Of course, you can achieve the same results using the API or the web interface, which means you can integrate this feature into your own tools. We hope you find these changes make PeeringDB even more useful to you. We prioritized these improvements because of the feedback we hear in 2020. We run out 2021 user survey in September but we\u2019re open to feedback on how to improve PeeringDB at any time. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Advanced Search (Part 2)"},{"location":"blog/advanced_search_2/#advanced-search-part-2","text":"We\u2019ve published a couple of recent blogs about how we are improving search, following feedback on its importance in the 2020 user survey . Here\u2019s another one! We introduced two significant improvements in the production release 2.28.0. Our first improvement makes it easier to search based on a partial name. When an organization\u2019s name has two parts, you can now search for just the first part and then select from all the organizations that share that name. Previously, search worked on exact matches. This change makes it easier for users to find the organizations they want. Our second improvement allows users to search for facilities within a given radius, using the Advanced Search interface. Users can search from a country and city, and select a radius in kilometres or miles. Of course, you can achieve the same results using the API or the web interface, which means you can integrate this feature into your own tools. We hope you find these changes make PeeringDB even more useful to you. We prioritized these improvements because of the feedback we hear in 2020. We run out 2021 user survey in September but we\u2019re open to feedback on how to improve PeeringDB at any time. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Advanced Search (Part 2)"},{"location":"blog/alphabetical_search/","text":"Alphabetical Search Results PeeringDB users have told us that data quality and search are what they value most. We have made changes to improve the search experience: You can search a radius from any address in Advanced Search . You can filter searches using the criteria important to you. You can test our new, faster, v2 Search . We have just improved v2 search to give back results in alphabetical order. It's a small change but has a big impact. If there's an exact match for a search term, it will be shown at the very top of the results. Partial matches are shown in alphabetical order. Try it out! And try out other searches using v2 Search and then let us know what you think. We need your feedback to improve search. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Alphabetical Search Results"},{"location":"blog/alphabetical_search/#alphabetical-search-results","text":"PeeringDB users have told us that data quality and search are what they value most. We have made changes to improve the search experience: You can search a radius from any address in Advanced Search . You can filter searches using the criteria important to you. You can test our new, faster, v2 Search . We have just improved v2 search to give back results in alphabetical order. It's a small change but has a big impact. If there's an exact match for a search term, it will be shown at the very top of the results. Partial matches are shown in alphabetical order. Try it out! And try out other searches using v2 Search and then let us know what you think. We need your feedback to improve search. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Alphabetical Search Results"},{"location":"blog/api_keys/","text":"API Keys How often does one new feature deliver three important improvements? Adding support for API Keys in this week\u2019s beta release does this. API Keys will help organizations improve the security of the data they publish while linking the tools to the org itself and not its people. API Keys allow organizations to have authenticated access directly associated with the org itself and not with individual users. Organizations will now have better control of their data and won\u2019t need to tie automation to their users\u2019 credentials, which will improve robust continuity of operations should individuals leave the organization. Organizations previously faced a problem that if a user left, and their PeeringDB account was closed, any update processes that used the user\u2019s account would end. Organizations can now tie automated processes to role accounts, ensuring continuity of operations even when people change. And if you automate searches to find new peers, your scripts can now be updated to collect contact information as well as other details. As more organizations use API Keys to automate more of their interactions with PeeringDB, we will get a better idea of who is using the API and who is not. This will allow us to engage with them so we can understand what they value. Of course, this does not mean that we\u2019ll be abandoning users who want to focus on using the web interface. Aris Lambrianidis, a senior security engineer with White & Case LLP, says: \u201c The ability to leverage API keys means that programmatic workflows can work reliably using an authentication and authorization model independently of any credentials assigned to humans. Decoupling these access methods should significantly benefit the security and scalability of such operations. \u201d We have published some documentation showing how to generate an API Key, and use that API Key to achieve tasks that will be common to many organizations using PeeringDB. We have also published sample code to help you develop your own automation. Additional examples that others can use are also welcome. Everyone benefits from sharing this kind of code as it means more accurate data quality. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"API Keys"},{"location":"blog/api_keys/#api-keys","text":"How often does one new feature deliver three important improvements? Adding support for API Keys in this week\u2019s beta release does this. API Keys will help organizations improve the security of the data they publish while linking the tools to the org itself and not its people. API Keys allow organizations to have authenticated access directly associated with the org itself and not with individual users. Organizations will now have better control of their data and won\u2019t need to tie automation to their users\u2019 credentials, which will improve robust continuity of operations should individuals leave the organization. Organizations previously faced a problem that if a user left, and their PeeringDB account was closed, any update processes that used the user\u2019s account would end. Organizations can now tie automated processes to role accounts, ensuring continuity of operations even when people change. And if you automate searches to find new peers, your scripts can now be updated to collect contact information as well as other details. As more organizations use API Keys to automate more of their interactions with PeeringDB, we will get a better idea of who is using the API and who is not. This will allow us to engage with them so we can understand what they value. Of course, this does not mean that we\u2019ll be abandoning users who want to focus on using the web interface. Aris Lambrianidis, a senior security engineer with White & Case LLP, says: \u201c The ability to leverage API keys means that programmatic workflows can work reliably using an authentication and authorization model independently of any credentials assigned to humans. Decoupling these access methods should significantly benefit the security and scalability of such operations. \u201d We have published some documentation showing how to generate an API Key, and use that API Key to achieve tasks that will be common to many organizations using PeeringDB. We have also published sample code to help you develop your own automation. Additional examples that others can use are also welcome. Everyone benefits from sharing this kind of code as it means more accurate data quality. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"API Keys"},{"location":"blog/api_writes_need_api_key/","text":"API Writes now Need an API Key You now need to use an API key if you want to update PeeringDB using the API. PeeringDB will continue to support HTTP Basic Authentication (HBA) for queries with the existing API, but transitioning to an API key is strongly recommended for users and organizations who have not already done so, since it is a more secure operational practice. We encourage all users to enable Multi-Factor Authentication (MFA) and to use that when accessing our website from a browser. We encourage anyone that wants to use our API to do so using API keys. We made this change because there is no way to perform MFA with HBA. Removing the ability to update PeeringDB via the API without API keys conforms to security best practices. We support both user and organizational API keys. We have a HOWTO about creating API keys and using them. We have also introduced some organizational policy features this month. Organizations can now require users: To enable MFA To have an email address from a specific domain To revalidate their account on a schedule set by the organization We made this change because of an internal security analysis. We accept security reports to security@peeringdb.com . We have published a HOWTO for making security reports. If you have questions about PeeringDB security, please write to security@peeringdb.com . If you need help configuring API keys, please write to support@peeringdb.com .","title":"API Writes now Need an API Key"},{"location":"blog/api_writes_need_api_key/#api-writes-now-need-an-api-key","text":"You now need to use an API key if you want to update PeeringDB using the API. PeeringDB will continue to support HTTP Basic Authentication (HBA) for queries with the existing API, but transitioning to an API key is strongly recommended for users and organizations who have not already done so, since it is a more secure operational practice. We encourage all users to enable Multi-Factor Authentication (MFA) and to use that when accessing our website from a browser. We encourage anyone that wants to use our API to do so using API keys. We made this change because there is no way to perform MFA with HBA. Removing the ability to update PeeringDB via the API without API keys conforms to security best practices. We support both user and organizational API keys. We have a HOWTO about creating API keys and using them. We have also introduced some organizational policy features this month. Organizations can now require users: To enable MFA To have an email address from a specific domain To revalidate their account on a schedule set by the organization We made this change because of an internal security analysis. We accept security reports to security@peeringdb.com . We have published a HOWTO for making security reports. If you have questions about PeeringDB security, please write to security@peeringdb.com . If you need help configuring API keys, please write to support@peeringdb.com .","title":"API Writes now Need an API Key"},{"location":"blog/automating_configuration/","text":"Automating Configuration - Why We Support the IX-F Member Export Schema We just released 2.29.0-beta and three of the improvements relate to our support for the IX-F Member Export Schema . The last year has seen half a dozen releases with changes to better support it. But why should PeeringDB support this API? Why should exchanges use it? And how can networks benefit from it? It is an agreed standard for which allows IXPs to make their member lists available for automatic consumption by tools like PeeringDB. Exchanges can publish important technical information about their participating networks, including their AS Number and IP address information. There are freely available tools that use this data to build configurations and automate work that would otherwise require tickets, and some copy and paste. So, how can a network take advantage of this if they participate at an exchange using the schema? It\u2019s simple, just select the \u201cAllow IXP Update\u201d radio button in your network configuration page. And if you\u2019re an exchange that sees the advantage of automatically sharing information about your participating networks? If you are using software that can automatically generate the JSON, you just need to configure the URL for us to poll in the LAN configuration panel for your exchange. Our continuing efforts in this area are designed to help exchanges share more accurate information about their participants, and networks to automate configuration. So, take a look at what the schema can do for your organization. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Automating Configuration - Why We Support the IX-F Member Export Schema"},{"location":"blog/automating_configuration/#automating-configuration-why-we-support-the-ix-f-member-export-schema","text":"We just released 2.29.0-beta and three of the improvements relate to our support for the IX-F Member Export Schema . The last year has seen half a dozen releases with changes to better support it. But why should PeeringDB support this API? Why should exchanges use it? And how can networks benefit from it? It is an agreed standard for which allows IXPs to make their member lists available for automatic consumption by tools like PeeringDB. Exchanges can publish important technical information about their participating networks, including their AS Number and IP address information. There are freely available tools that use this data to build configurations and automate work that would otherwise require tickets, and some copy and paste. So, how can a network take advantage of this if they participate at an exchange using the schema? It\u2019s simple, just select the \u201cAllow IXP Update\u201d radio button in your network configuration page. And if you\u2019re an exchange that sees the advantage of automatically sharing information about your participating networks? If you are using software that can automatically generate the JSON, you just need to configure the URL for us to poll in the LAN configuration panel for your exchange. Our continuing efforts in this area are designed to help exchanges share more accurate information about their participants, and networks to automate configuration. So, take a look at what the schema can do for your organization. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Automating Configuration - Why We Support the IX-F Member Export Schema"},{"location":"blog/better_data/","text":"Better Data PeeringDB users told us in surveys that data quality and search results are their two top priorities. Release 2.54.0 has multiple changes to improve data quality and search results. Report inaccurate data One of them is a feature allowing logged in users to report data they believe to be inaccurate. Every page now has a button that lets users report data they believe is inaccurate. The report form lets the user identify the specific element believe to be wrong, along with a reason. If the user knows, they can suggest what the correct data should be. The Admin Committee will review reports. Network types Many networks provide more than one kind of function. You can now select more than one type for each network you run. The Product Committee considered adding more granularity for network types. They decided against it, as not everyone shares the same understanding of terms. Allowing networks to select multiple options is a compromise that doesn't require a breaking change in the API. The Network Type field will probably not be imported into v3 of the API. Power choices The Available Voltage Services field now only shows non-standard power offers. Everyone expects data centers to offer power at the standard voltages for the country or territory they serve. What users find interesting is the non-standard offers. For the time being we only offer three of these non-standard power options. If you offer a different non-standard power option, please let us know. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Better Data"},{"location":"blog/better_data/#better-data","text":"PeeringDB users told us in surveys that data quality and search results are their two top priorities. Release 2.54.0 has multiple changes to improve data quality and search results.","title":"Better Data"},{"location":"blog/better_data/#report-inaccurate-data","text":"One of them is a feature allowing logged in users to report data they believe to be inaccurate. Every page now has a button that lets users report data they believe is inaccurate. The report form lets the user identify the specific element believe to be wrong, along with a reason. If the user knows, they can suggest what the correct data should be. The Admin Committee will review reports.","title":"Report inaccurate data"},{"location":"blog/better_data/#network-types","text":"Many networks provide more than one kind of function. You can now select more than one type for each network you run. The Product Committee considered adding more granularity for network types. They decided against it, as not everyone shares the same understanding of terms. Allowing networks to select multiple options is a compromise that doesn't require a breaking change in the API. The Network Type field will probably not be imported into v3 of the API.","title":"Network types"},{"location":"blog/better_data/#power-choices","text":"The Available Voltage Services field now only shows non-standard power offers. Everyone expects data centers to offer power at the standard voltages for the country or territory they serve. What users find interesting is the non-standard offers. For the time being we only offer three of these non-standard power options. If you offer a different non-standard power option, please let us know. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Power choices"},{"location":"blog/better_search_and_export/","text":"Better Search and Export PeeringDB users tell us that they most value search and data quality. We've been working on improved search for the last year and have made another improvement to it. It now recognizes ISO 3166-1 alpha-2 codes \u2013 the codes used for ccTLDs. This means you can now search for things like all the facilities or IXPs in a country. But sometimes you want to visualize our data. For a while we've been offering a .KMZ file of all the facilities in PeeringDB with a geocode. We've now improved that file. The new format removes unneeded fields, making it small enough for Google Maps to use. And you can export any advanced search based on location in a KMZ format. So take a look at these features on beta.peeringdb.com ahead of their deployment to production. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Better Search and Export"},{"location":"blog/better_search_and_export/#better-search-and-export","text":"PeeringDB users tell us that they most value search and data quality. We've been working on improved search for the last year and have made another improvement to it. It now recognizes ISO 3166-1 alpha-2 codes \u2013 the codes used for ccTLDs. This means you can now search for things like all the facilities or IXPs in a country. But sometimes you want to visualize our data. For a while we've been offering a .KMZ file of all the facilities in PeeringDB with a geocode. We've now improved that file. The new format removes unneeded fields, making it small enough for Google Maps to use. And you can export any advanced search based on location in a KMZ format. So take a look at these features on beta.peeringdb.com ahead of their deployment to production. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Better Search and Export"},{"location":"blog/carrier_object/","text":"Should PeeringDB Create a New \u201cCarrier\u201d Object? That was the question we asked two focus groups on 29 June 2021. Initial discussion Our Product Committee and others have been discussing this issue for about six months now. The one thing we could agree on was that we needed to reach out to more of the people involved in buying and delivering these interconnection services to help make a decision. Focus groups To do that we held two focus groups on 29 June 2021. One was scheduled at a time that is good for people in APAC and the west coast of the Americas. The other was scheduled at a time that was good for people in EMEA and the east coast of the Americas. The discussion included 12 people with significant industry experience in running carriers, exchanges, facilities, and networks. To build a trusted environment we applied the Chatham House Rule, so this blog post describes what was discussed but does not quote anyone or attribute views to any participants. The focus groups began with a description of the problem and then looked at a simple approach to address it: an object to describe the carrier and associated objects listing the facilities and IXs where they have a presence. The focus groups then discussed several questions: Is there an unmet need? Should PeeringDB be the organization to address it? What do you feel about the proposed approach? Should the proposed approach be adapted in some way? Why? There was a strong sense across both sessions that it can be a challenge to find out about connectivity options between locations. While putting information about those options in PeeringDB would not eliminate the need for buyers to perform their own due diligence checks, it would simplify the process of finding out who to contact and what they might be able to offer. There was support for putting this information in PeeringDB because keeping related information in a single database makes things easier for users. Participants favored starting off with a less complex object and adding detail in future iterations. Including information about whether links between locations were L1, L2, or L3, and owned or leased seemed to be the agreed minimum set of information. That said, there were concerns that keeping this information accurate could be a challenge for multiple reasons, including inaccurate internal asset databases and a desire from marketing people to overclaim. Any implementation would need to be well supported by extensions to the API. Despite making it easy for people to rapidly deploy information about new and improved deployments to PeeringDB through the API there was support ensuring that a new object can be created and configured through the web interface. Next steps When the Product Committee has evaluated the feedback we got from these two focus groups it will make a decision on the principle of creating this new object. If the decision is to proceed there is work to be done in both designing and naming it. What is the minimum set of information that would be useful to PeeringDB users? What name would cause least confusion? We\u2019ll keep you updated. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Should PeeringDB Create a New \u201cCarrier\u201d Object?"},{"location":"blog/carrier_object/#should-peeringdb-create-a-new-carrier-object","text":"That was the question we asked two focus groups on 29 June 2021.","title":"Should PeeringDB Create a New \u201cCarrier\u201d Object?"},{"location":"blog/carrier_object/#initial-discussion","text":"Our Product Committee and others have been discussing this issue for about six months now. The one thing we could agree on was that we needed to reach out to more of the people involved in buying and delivering these interconnection services to help make a decision.","title":"Initial discussion"},{"location":"blog/carrier_object/#focus-groups","text":"To do that we held two focus groups on 29 June 2021. One was scheduled at a time that is good for people in APAC and the west coast of the Americas. The other was scheduled at a time that was good for people in EMEA and the east coast of the Americas. The discussion included 12 people with significant industry experience in running carriers, exchanges, facilities, and networks. To build a trusted environment we applied the Chatham House Rule, so this blog post describes what was discussed but does not quote anyone or attribute views to any participants. The focus groups began with a description of the problem and then looked at a simple approach to address it: an object to describe the carrier and associated objects listing the facilities and IXs where they have a presence. The focus groups then discussed several questions: Is there an unmet need? Should PeeringDB be the organization to address it? What do you feel about the proposed approach? Should the proposed approach be adapted in some way? Why? There was a strong sense across both sessions that it can be a challenge to find out about connectivity options between locations. While putting information about those options in PeeringDB would not eliminate the need for buyers to perform their own due diligence checks, it would simplify the process of finding out who to contact and what they might be able to offer. There was support for putting this information in PeeringDB because keeping related information in a single database makes things easier for users. Participants favored starting off with a less complex object and adding detail in future iterations. Including information about whether links between locations were L1, L2, or L3, and owned or leased seemed to be the agreed minimum set of information. That said, there were concerns that keeping this information accurate could be a challenge for multiple reasons, including inaccurate internal asset databases and a desire from marketing people to overclaim. Any implementation would need to be well supported by extensions to the API. Despite making it easy for people to rapidly deploy information about new and improved deployments to PeeringDB through the API there was support ensuring that a new object can be created and configured through the web interface.","title":"Focus groups"},{"location":"blog/carrier_object/#next-steps","text":"When the Product Committee has evaluated the feedback we got from these two focus groups it will make a decision on the principle of creating this new object. If the decision is to proceed there is work to be done in both designing and naming it. What is the minimum set of information that would be useful to PeeringDB users? What name would cause least confusion? We\u2019ll keep you updated. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Next steps"},{"location":"blog/carrier_object_deployed/","text":"Carrier Objects We introduced support for carrier objects in release 2.43.0. This is the first new pillar of data we\u2019ve introduced for several years. Take a look and tell us how we can improve our implementation. A \u201cCarrier\u201d provides high capacity links between facilities. Networks and IXPs use these to connect equipment spread across multiple interconnection facilities in a metro area. They are different from the regular network in PeeringDB because their services run at layers 1 or 2 . Our initial deployment lets carriers show that they have a presence in an interconnection facility. It does not show what services are provided, like wavelengths or fiber. This is a tighter set of features than was suggested by the focus group in 2021 . We want to get a minimal set of features out first and see how they are received before tackling more complicated features. We have started small and will expand based on user demand. If this is a feature that your organization could benefit from, please take a look and tell us what you think. You can contact us on social media, and you can reach the Product Committee on our mailing list . If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Carrier Objects"},{"location":"blog/carrier_object_deployed/#carrier-objects","text":"We introduced support for carrier objects in release 2.43.0. This is the first new pillar of data we\u2019ve introduced for several years. Take a look and tell us how we can improve our implementation. A \u201cCarrier\u201d provides high capacity links between facilities. Networks and IXPs use these to connect equipment spread across multiple interconnection facilities in a metro area. They are different from the regular network in PeeringDB because their services run at layers 1 or 2 . Our initial deployment lets carriers show that they have a presence in an interconnection facility. It does not show what services are provided, like wavelengths or fiber. This is a tighter set of features than was suggested by the focus group in 2021 . We want to get a minimal set of features out first and see how they are received before tackling more complicated features. We have started small and will expand based on user demand. If this is a feature that your organization could benefit from, please take a look and tell us what you think. You can contact us on social media, and you can reach the Product Committee on our mailing list . If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Carrier Objects"},{"location":"blog/contacts_marked_private/","text":"Changes to Contacts Marked as Private We are removing the \u201cPrivate\u201d status from Points of Contact in PeeringDB in Release 2.30.0 . This status was carried over from v1 of PeeringDB but is no longer useful, it just confuses users. It will no longer be available as a status for newly created contacts. And if your organization has one or more contacts marked as \u201cPrivate\u201d in PeeringDB, admin users will be prompted to make a decision between two statuses when they next log in. These are : Users: only other PeeringDB users can see the Point of Contact Public: the record is shown to anonymous users as well as authenticated users If you are an administrator for your organization\u2019s entry in PeeringDB, you need to decide which of the Points of Contact you publish should only be disclosed to authenticated PeeringDB users and which should be published to anonymous users. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Changes to Contacts Marked as Private"},{"location":"blog/contacts_marked_private/#changes-to-contacts-marked-as-private","text":"We are removing the \u201cPrivate\u201d status from Points of Contact in PeeringDB in Release 2.30.0 . This status was carried over from v1 of PeeringDB but is no longer useful, it just confuses users. It will no longer be available as a status for newly created contacts. And if your organization has one or more contacts marked as \u201cPrivate\u201d in PeeringDB, admin users will be prompted to make a decision between two statuses when they next log in. These are : Users: only other PeeringDB users can see the Point of Contact Public: the record is shown to anonymous users as well as authenticated users If you are an administrator for your organization\u2019s entry in PeeringDB, you need to decide which of the Points of Contact you publish should only be disclosed to authenticated PeeringDB users and which should be published to anonymous users. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Changes to Contacts Marked as Private"},{"location":"blog/containerize/","text":"Containerized Deployment We deployed beta.peeringdb.com on a container based platform in release 2.59.0 . We'll be starting integration on www.peeringdb.com in the 2.60 release. PeeringDB started on a bare metal LAMP stack, and was deployed to virtual machines with the release of PeeringDB 2.0 about ten years ago, but technology has advanced since then. By deploying PeeringDB in containers, we will reduce our computing costs and more easily adjust compute resources dynamically based on load. Managing spending is important as PeeringDB is fully funded by our sponsors . It should also help us narrow the scope of work for our volunteer Operations Committee. We have been looking for ways to improve the efficiency of our spending since 2022 and started looking at switching to serving directly from containers in November 2023 . This deployment will complete that process. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Containerized Deployment"},{"location":"blog/containerize/#containerized-deployment","text":"We deployed beta.peeringdb.com on a container based platform in release 2.59.0 . We'll be starting integration on www.peeringdb.com in the 2.60 release. PeeringDB started on a bare metal LAMP stack, and was deployed to virtual machines with the release of PeeringDB 2.0 about ten years ago, but technology has advanced since then. By deploying PeeringDB in containers, we will reduce our computing costs and more easily adjust compute resources dynamically based on load. Managing spending is important as PeeringDB is fully funded by our sponsors . It should also help us narrow the scope of work for our volunteer Operations Committee. We have been looking for ways to improve the efficiency of our spending since 2022 and started looking at switching to serving directly from containers in November 2023 . This deployment will complete that process. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Containerized Deployment"},{"location":"blog/contributing_code/","text":"Contributing Code to PeeringDB Just Got Easier Have you ever wanted to contribute code to improve PeeringDB but found it too challenging to set up a test environment? The good news is that spinning up a development environment is now radically simplified. We have made it much easier for volunteer developers to contribute code to PeeringDB. Until now, even if a code fix was relatively simple, the process for testing it before making the contribution was a challenge. Now, you can spin up a PeeringDB development instance in a couple of minutes. You\u2019ll be able to test changes locally and then submit pull requests when you\u2019re ready to publish your contribution. Andy Davidson, CTO of Asteroid says: \u201c I recently developed some code against the PeeringDB OAuth instance for https://trackbgp.com . But it was hard to get a development environment set up. Now I can spin up a development environment in less time than it takes to boil a kettle. \u201d We have documented the steps needed to get up and running on GitHub. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Contributing Code to PeeringDB Just Got Easier"},{"location":"blog/contributing_code/#contributing-code-to-peeringdb-just-got-easier","text":"Have you ever wanted to contribute code to improve PeeringDB but found it too challenging to set up a test environment? The good news is that spinning up a development environment is now radically simplified. We have made it much easier for volunteer developers to contribute code to PeeringDB. Until now, even if a code fix was relatively simple, the process for testing it before making the contribution was a challenge. Now, you can spin up a PeeringDB development instance in a couple of minutes. You\u2019ll be able to test changes locally and then submit pull requests when you\u2019re ready to publish your contribution. Andy Davidson, CTO of Asteroid says: \u201c I recently developed some code against the PeeringDB OAuth instance for https://trackbgp.com . But it was hard to get a development environment set up. Now I can spin up a development environment in less time than it takes to boil a kettle. \u201d We have documented the steps needed to get up and running on GitHub. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Contributing Code to PeeringDB Just Got Easier"},{"location":"blog/data_quality_improvements/","text":"Data Quality Improvements Rolled Out Each year we run a user survey. Users keep telling us that network configuration data in PeeringDB is a top priority. We have recently added some automation to improve our data quality for networks. We now track the status of each ASN registered in PeeringDB at the RIRs and NIRs. When a network is no longer in the RIR or NIR database we can remove it. Release 2.41.0 completes the deployment of this feature. It will remove about 150 networks, which is only about 0.5%. But over time, it should help us maintain the highest quality data possible. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Data Quality Improvements Rolled Out"},{"location":"blog/data_quality_improvements/#data-quality-improvements-rolled-out","text":"Each year we run a user survey. Users keep telling us that network configuration data in PeeringDB is a top priority. We have recently added some automation to improve our data quality for networks. We now track the status of each ASN registered in PeeringDB at the RIRs and NIRs. When a network is no longer in the RIR or NIR database we can remove it. Release 2.41.0 completes the deployment of this feature. It will remove about 150 networks, which is only about 0.5%. But over time, it should help us maintain the highest quality data possible. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Data Quality Improvements Rolled Out"},{"location":"blog/data_quality_removing_closed_networks/","text":"Data Quality \u2014 Removing Closed Networks We added an \"RIR Status\" field in the data returned for networks a few months ago. The \"ok\" status lets you know that the ASN was assigned by an RIR or NIR. The \"RIR Status Updated\" field lets you know when we last checked. We use these fields to enable automation. In September we\u2019ll remove about 400 networks that have been returned to the RIR. We check the status of the network every day and will only flag it for deletion if the status was \u201cnot assigned\u201d for three months. This automation runs every month. It will improve data quality. You won't see results for networks that aren't operating anymore. And organizations assigned those returned and reissued ASNs will be able to register on PeeringDB without needing support from our volunteer Admin Committee. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Data Quality \u2014 Removing Closed Networks"},{"location":"blog/data_quality_removing_closed_networks/#data-quality-removing-closed-networks","text":"We added an \"RIR Status\" field in the data returned for networks a few months ago. The \"ok\" status lets you know that the ASN was assigned by an RIR or NIR. The \"RIR Status Updated\" field lets you know when we last checked. We use these fields to enable automation. In September we\u2019ll remove about 400 networks that have been returned to the RIR. We check the status of the network every day and will only flag it for deletion if the status was \u201cnot assigned\u201d for three months. This automation runs every month. It will improve data quality. You won't see results for networks that aren't operating anymore. And organizations assigned those returned and reissued ASNs will be able to register on PeeringDB without needing support from our volunteer Admin Committee. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Data Quality \u2014 Removing Closed Networks"},{"location":"blog/faster_queries/","text":"Faster PeeringDB Queries - No Limits Did you know that you can have lightning fast access to PeeringDB's database without query limits? Our web and API services impose query limits. Network latency is sometimes a factor when querying from far away. That's why we have peeringdb-py . This is a cache you can run in your own network or even on a laptop. You synchronize the whole database to a machine you run. Once you've done that you are only limited by your own infrastructure. Re-synchronizing peeringdb-py is efficient - it only syncs changes since the last sync - and is unlikely to trigger any query limits if updated once per hour or less frequently as needed. Are there reasons you should run a local cache other than query limits and latency? Yes. If you populate internal databases or generate configurations with PeeringDB then a local cache adds reliability. You'll have local access instead of having to rely on intermediate networks. Of course, peeringdb-py isn't the only choice. Some organizations have developed their own local caches. If you want a local cache you are welcome to use the peeringdb-py codebase as a reference. And if all you need is to have PeeringDB in a local database, it can be really simple . If your organization is a heavy PeeringDB user then work out the right caching approach for you. We\u2019re happy to answer any questions. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Faster PeeringDB Queries - No Limits"},{"location":"blog/faster_queries/#faster-peeringdb-queries-no-limits","text":"Did you know that you can have lightning fast access to PeeringDB's database without query limits? Our web and API services impose query limits. Network latency is sometimes a factor when querying from far away. That's why we have peeringdb-py . This is a cache you can run in your own network or even on a laptop. You synchronize the whole database to a machine you run. Once you've done that you are only limited by your own infrastructure. Re-synchronizing peeringdb-py is efficient - it only syncs changes since the last sync - and is unlikely to trigger any query limits if updated once per hour or less frequently as needed. Are there reasons you should run a local cache other than query limits and latency? Yes. If you populate internal databases or generate configurations with PeeringDB then a local cache adds reliability. You'll have local access instead of having to rely on intermediate networks. Of course, peeringdb-py isn't the only choice. Some organizations have developed their own local caches. If you want a local cache you are welcome to use the peeringdb-py codebase as a reference. And if all you need is to have PeeringDB in a local database, it can be really simple . If your organization is a heavy PeeringDB user then work out the right caching approach for you. We\u2019re happy to answer any questions. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Faster PeeringDB Queries - No Limits"},{"location":"blog/geographic_search/","text":"Geographic Search Where is it? This isn\u2019t just the plaintive cry of someone wondering where the courier has left their package. Finding facilities in PeeringDB has been a big problem. The database did not associate partial and full names in searches, so if a facility owner had entered Montana but you were searching for MT, their facility might not be found. As new facilities are created in our database they will be linked to geographic coordinates. Changing the way we record authoritative data for locations in our database means that we will be able to introduce a number of helpful features over the next few months. Over time, we will improve the way existing address data is presented in the database. The number of facilities in PeeringDB grew by about a sixth in 2020. As we add entries with new addresses in 2021 we will normalize the primary presentation of addresses and use them as a search key. We\u2019ll add support for additional searches based on these addresses in the coming months and use this experience to help us clean up the data we already have. In the future, we will be able to expand the way we provide searches. For instance, we\u2019ll be able to provide a search for facilities with a distance radius of a chosen coordinate. Other innovative searches will be possible and we will prioritize their development based on user feedback. Tom Paseka, Network Strategy at Cloudflare, says: \u201c Getting location naming right is hugely important. Having D\u00fcsseldorf and Dusseldorf return the same results makes local use of PeeringDB possible, giving more precise data across languages and improving data integrity. This is great!. \u201d If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Geographic Search"},{"location":"blog/geographic_search/#geographic-search","text":"Where is it? This isn\u2019t just the plaintive cry of someone wondering where the courier has left their package. Finding facilities in PeeringDB has been a big problem. The database did not associate partial and full names in searches, so if a facility owner had entered Montana but you were searching for MT, their facility might not be found. As new facilities are created in our database they will be linked to geographic coordinates. Changing the way we record authoritative data for locations in our database means that we will be able to introduce a number of helpful features over the next few months. Over time, we will improve the way existing address data is presented in the database. The number of facilities in PeeringDB grew by about a sixth in 2020. As we add entries with new addresses in 2021 we will normalize the primary presentation of addresses and use them as a search key. We\u2019ll add support for additional searches based on these addresses in the coming months and use this experience to help us clean up the data we already have. In the future, we will be able to expand the way we provide searches. For instance, we\u2019ll be able to provide a search for facilities with a distance radius of a chosen coordinate. Other innovative searches will be possible and we will prioritize their development based on user feedback. Tom Paseka, Network Strategy at Cloudflare, says: \u201c Getting location naming right is hugely important. Having D\u00fcsseldorf and Dusseldorf return the same results makes local use of PeeringDB possible, giving more precise data across languages and improving data integrity. This is great!. \u201d If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Geographic Search"},{"location":"blog/guidelines_for_registering/","text":"Guidelines for Registering in PeeringDB About one third of ASNs are now registered in PeeringDB. While that\u2019s a success it comes with a responsibility to enhance transparency over what is required when registering a network, IXP, or facility in the database. We have just published a set of guidelines that document the criteria our automation uses, or will use when new software is developed. Where we cannot automate, volunteers on our Admin Committee evaluate requests. There are clear criteria for the automatic, or semi-automatic, approval of each type of object. These are illustrated with flowcharts that show the possible paths through the process. What Are They? Networks must have a unique and properly registered ASN. IXP LANs must use unique and properly registered address space. There are some automatic prefix limits but these can be manually overridden when needed. Facilities can automatically be added by organizations that already have a facility, be validated by a web page offering interconnection services there, or be attested to by users that confirm the facility exists. There is also a process to remove empty facilities without registered networks or IXPs present in them. Feedback Loop We know that these guidelines will need to be improved and updated as we learn, so we have built in an \u201cexception\u201d process to help with that. Whenever an easy path is not possible, the requester can ask for more eyes on their registration request. The first step in this process is to get input from all the volunteers on the Admin Committee. If more eyes are needed, the request can be shared with all of PeeringDB\u2019s Stewards, a group made from the committee chairs and board members. Where a formal decision is needed, the board can vote on a request and make a final decision. Each step of this process is an opportunity to learn from experience and feed that back into our published guidelines, our internal processes, and any software that automates them. So, while we\u2019ve published these today, we\u2019ll be updating them as the interconnection environment changes and we need to adapt to it. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Guidelines for Registering in PeeringDB"},{"location":"blog/guidelines_for_registering/#guidelines-for-registering-in-peeringdb","text":"About one third of ASNs are now registered in PeeringDB. While that\u2019s a success it comes with a responsibility to enhance transparency over what is required when registering a network, IXP, or facility in the database. We have just published a set of guidelines that document the criteria our automation uses, or will use when new software is developed. Where we cannot automate, volunteers on our Admin Committee evaluate requests. There are clear criteria for the automatic, or semi-automatic, approval of each type of object. These are illustrated with flowcharts that show the possible paths through the process.","title":"Guidelines for Registering in PeeringDB"},{"location":"blog/guidelines_for_registering/#what-are-they","text":"Networks must have a unique and properly registered ASN. IXP LANs must use unique and properly registered address space. There are some automatic prefix limits but these can be manually overridden when needed. Facilities can automatically be added by organizations that already have a facility, be validated by a web page offering interconnection services there, or be attested to by users that confirm the facility exists. There is also a process to remove empty facilities without registered networks or IXPs present in them.","title":"What Are They?"},{"location":"blog/guidelines_for_registering/#feedback-loop","text":"We know that these guidelines will need to be improved and updated as we learn, so we have built in an \u201cexception\u201d process to help with that. Whenever an easy path is not possible, the requester can ask for more eyes on their registration request. The first step in this process is to get input from all the volunteers on the Admin Committee. If more eyes are needed, the request can be shared with all of PeeringDB\u2019s Stewards, a group made from the committee chairs and board members. Where a formal decision is needed, the board can vote on a request and make a final decision. Each step of this process is an opportunity to learn from experience and feed that back into our published guidelines, our internal processes, and any software that automates them. So, while we\u2019ve published these today, we\u2019ll be updating them as the interconnection environment changes and we need to adapt to it. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Feedback Loop"},{"location":"blog/improving_beta_and_kmz_export/","text":"Making beta.peeringdb.com, Search, and KMZ More Attractive Just over half a percent of users visit beta.peeringdb.com each month. We recognize that there are good and bad reasons for this. On the good side, people are pretty happy with www.peeringdb.com . But on the bad side, we only used to refresh the data in beta.peeringdb.com once a month. We're getting ready to refresh data on our beta site every hour. That will come soon. It will make it an ideal place to test your searches each month \u2013 and get early access to new search features. Of course, you can also test making updates on our beta site. But any changes you make will be wiped at the next refresh. We're also refining our .KMZ export in 2.57.0. The export has tidier entries for each fac , improves the placemark, and drops facilities without location data. And two bugs have been fixed for v2 search, which is now the default search. A problem searching for a \" fac in city name\" has been resolved. And a bug that caused a server error when the last character was a colon has also been fixed. So, head on over to beta.peeringdb.com and test these improvements. Let us know if you see any problems with these improvements. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Making beta.peeringdb.com, Search, and KMZ More Attractive"},{"location":"blog/improving_beta_and_kmz_export/#making-betapeeringdbcom-search-and-kmz-more-attractive","text":"Just over half a percent of users visit beta.peeringdb.com each month. We recognize that there are good and bad reasons for this. On the good side, people are pretty happy with www.peeringdb.com . But on the bad side, we only used to refresh the data in beta.peeringdb.com once a month. We're getting ready to refresh data on our beta site every hour. That will come soon. It will make it an ideal place to test your searches each month \u2013 and get early access to new search features. Of course, you can also test making updates on our beta site. But any changes you make will be wiped at the next refresh. We're also refining our .KMZ export in 2.57.0. The export has tidier entries for each fac , improves the placemark, and drops facilities without location data. And two bugs have been fixed for v2 search, which is now the default search. A problem searching for a \" fac in city name\" has been resolved. And a bug that caused a server error when the last character was a colon has also been fixed. So, head on over to beta.peeringdb.com and test these improvements. Let us know if you see any problems with these improvements. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Making beta.peeringdb.com, Search, and KMZ More Attractive"},{"location":"blog/installing_peeringdb-py/","text":"Installing peeringdb-py at NANOG 86 NANOG 86 participants installed peeringdb-py on Linux, macOS, and Windows Subsystem for Linux. We have used what they learned to publish a new HOWTO document to help more users install it. peeringdb-py is our reference implementation of a local cache of our database. You can install it on your own infrastructure. That means you can avoid query limits and get the best response time. Our new HOWTO document explains when you'll need an API Key and what kind of API Key to create. It also lists the packages you'll need installed to get peeringdb-py up and running. Finally, it provides guidance on how you can automatically refresh the database. We improved the installation guide to help users keep their installation current. Better documentation makes it easier for everyone to install peeringdb-py . If you need to make a lot of PeeringDB queries then we encourage you to query a local cache. If you do this, you'll want to run API queries against it using our software library. The API will remain stable while the database structure could change. The API will remain stable and our library will ensure you don't need to rewrite your queries. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Installing peeringdb-py at NANOG 86"},{"location":"blog/installing_peeringdb-py/#installing-peeringdb-py-at-nanog-86","text":"NANOG 86 participants installed peeringdb-py on Linux, macOS, and Windows Subsystem for Linux. We have used what they learned to publish a new HOWTO document to help more users install it. peeringdb-py is our reference implementation of a local cache of our database. You can install it on your own infrastructure. That means you can avoid query limits and get the best response time. Our new HOWTO document explains when you'll need an API Key and what kind of API Key to create. It also lists the packages you'll need installed to get peeringdb-py up and running. Finally, it provides guidance on how you can automatically refresh the database. We improved the installation guide to help users keep their installation current. Better documentation makes it easier for everyone to install peeringdb-py . If you need to make a lot of PeeringDB queries then we encourage you to query a local cache. If you do this, you'll want to run API queries against it using our software library. The API will remain stable while the database structure could change. The API will remain stable and our library will ensure you don't need to rewrite your queries. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Installing peeringdb-py at NANOG 86"},{"location":"blog/introducing_analytics/","text":"Introducing Analytics Until now, we have not had any analytics about PeeringDB usage. This is a problem. It means we can't make informed decisions that will help us deliver a better service to users. Users have often told us that they want improvements to the website. We know what some of these are but not all. Introducing analytics will help us learn more about the problems some users face. We can then develop improvements to meet their needs. The Product Committee has decided to test Google Analytics. The first step is to deploy it on beta.peeringdb.com. We'll use this as a learning experience. When we are happy with the analytics, we want to deploy an analytics service on www.peeringdb.com. What's next? We know that analytics only provides some of the information we need. We are developing plans to help users give more timely and targeted feedback. We can use that feedback to design and implement the improvements that will be most valuable to users. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Introducing Analytics"},{"location":"blog/introducing_analytics/#introducing-analytics","text":"Until now, we have not had any analytics about PeeringDB usage. This is a problem. It means we can't make informed decisions that will help us deliver a better service to users. Users have often told us that they want improvements to the website. We know what some of these are but not all. Introducing analytics will help us learn more about the problems some users face. We can then develop improvements to meet their needs. The Product Committee has decided to test Google Analytics. The first step is to deploy it on beta.peeringdb.com. We'll use this as a learning experience. When we are happy with the analytics, we want to deploy an analytics service on www.peeringdb.com.","title":"Introducing Analytics"},{"location":"blog/introducing_analytics/#whats-next","text":"We know that analytics only provides some of the information we need. We are developing plans to help users give more timely and targeted feedback. We can use that feedback to design and implement the improvements that will be most valuable to users. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"What's next?"},{"location":"blog/more_details_facilities/","text":"More Details on Facilities We\u2019ve been working hard on improving search this year. In release 2.30.0 we have an improvement that will help data centers and their users. Organizations running facilities can now share information about ownership status, power availability, diversity and resilience. These can all be used as filters in the advanced search page . You will need to be logged in to take advantage of these features. These improvements build on improvements delivered in 2.27.1 and 2.28.0 . We have additional search improvements scheduled for development in upcoming releases. If you run a facility you\u2019ll want to login and update its entry, so it can be found when users take advantage of these new searches. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"More Details on Facilities"},{"location":"blog/more_details_facilities/#more-details-on-facilities","text":"We\u2019ve been working hard on improving search this year. In release 2.30.0 we have an improvement that will help data centers and their users. Organizations running facilities can now share information about ownership status, power availability, diversity and resilience. These can all be used as filters in the advanced search page . You will need to be logged in to take advantage of these features. These improvements build on improvements delivered in 2.27.1 and 2.28.0 . We have additional search improvements scheduled for development in upcoming releases. If you run a facility you\u2019ll want to login and update its entry, so it can be found when users take advantage of these new searches. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"More Details on Facilities"},{"location":"blog/nanog_85_hackathon/","text":"NANOG 85 Hackathon Project We\u2019re bringing a project to the NANOG 85 Hackathon on June 4 - 5, 2022. This time we\u2019re looking for your help in developing a proof of concept we can later develop into a full implementation. In exchange, we\u2019ll walk you through what PeeringDB does. We\u2019ll explain how we support different parts of the Internet community. And you can choose some PeeringDB swag as a thank you! We\u2019re looking for help both from people who want to help turn a flowchart into a designed tool and those who can code ( Python and Django ) and. If you can see yourself in one of those roles then let us know at productcom@lists.peeringdb.com and register for the Hackathon . What\u2019s the project? When we published our updated guidelines for registering in PeeringDB we noted that some of the processes would need to be automated. We want to automate the attestation process for confirming new interconnection facilities. This is a new process to let users confirm that an interconnection facility is real and offers relevant services. It\u2019s a simple workflow. What will you learn? We\u2019ll make sure that you have a good understanding of PeeringDB\u2019s structure. You\u2019ll learn what a network is - in PeeringDB. And we\u2019ll also explain about Internet Exchange Points and interconnection facilities. And you\u2019ll get a good understanding of how and why people use PeeringDB. What will we test together? We want to look at ways that facility operators could activate the process. How should they get the unique URL? Do we need to implement ways for them to share it? What should PeeringDB users see when they visit the URL? Should we implement #1156 ? What will success look like? Success is helping people understand PeeringDB and using that to work out how our tool needs to work. Getting some proof of concept code running would be nice. But identifying issues to take account of in a future feature design would be a win, too. Introducing new people to PeeringDB and getting them involved in extending it is a win for us! If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"NANOG 85 Hackathon Project"},{"location":"blog/nanog_85_hackathon/#nanog-85-hackathon-project","text":"We\u2019re bringing a project to the NANOG 85 Hackathon on June 4 - 5, 2022. This time we\u2019re looking for your help in developing a proof of concept we can later develop into a full implementation. In exchange, we\u2019ll walk you through what PeeringDB does. We\u2019ll explain how we support different parts of the Internet community. And you can choose some PeeringDB swag as a thank you! We\u2019re looking for help both from people who want to help turn a flowchart into a designed tool and those who can code ( Python and Django ) and. If you can see yourself in one of those roles then let us know at productcom@lists.peeringdb.com and register for the Hackathon .","title":"NANOG 85 Hackathon Project"},{"location":"blog/nanog_85_hackathon/#whats-the-project","text":"When we published our updated guidelines for registering in PeeringDB we noted that some of the processes would need to be automated. We want to automate the attestation process for confirming new interconnection facilities. This is a new process to let users confirm that an interconnection facility is real and offers relevant services. It\u2019s a simple workflow.","title":"What\u2019s the project?"},{"location":"blog/nanog_85_hackathon/#what-will-you-learn","text":"We\u2019ll make sure that you have a good understanding of PeeringDB\u2019s structure. You\u2019ll learn what a network is - in PeeringDB. And we\u2019ll also explain about Internet Exchange Points and interconnection facilities. And you\u2019ll get a good understanding of how and why people use PeeringDB.","title":"What will you learn?"},{"location":"blog/nanog_85_hackathon/#what-will-we-test-together","text":"We want to look at ways that facility operators could activate the process. How should they get the unique URL? Do we need to implement ways for them to share it? What should PeeringDB users see when they visit the URL? Should we implement #1156 ?","title":"What will we test together?"},{"location":"blog/nanog_85_hackathon/#what-will-success-look-like","text":"Success is helping people understand PeeringDB and using that to work out how our tool needs to work. Getting some proof of concept code running would be nice. But identifying issues to take account of in a future feature design would be a win, too. Introducing new people to PeeringDB and getting them involved in extending it is a win for us! If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"What will success look like?"},{"location":"blog/nanog_87_hackathon_proof_of_concept/","text":"Do You Want Your Configuration Management System to Update PeeringDB? The theme for NANOG 87's Hackathon was interacting with sources of truth. Our project focused on identifying the difference between what's in a configuration system and PeeringDB - then sending an update. Developers from FullCtl and Peering Manager worked together to develop a proof of concept feature. It lets users know when PeeringDB did not reflect the internal configuration. It then made it easy to send PeeringDB an update. Users tell us that network configuration data is what they value most. So developing ways to help users identify what to update could be valuable. And offering a way to tie that to an update mechanism could make updating PeeringDB much faster. We've created an issue describing this on GitHub . If you or your organization would benefit from a feature like this, please let us know. You can comment on the issue, write to the Product Committee's list , or chat with a PC member. If this is something our users want then we'll need to answer some questions. One example is how to manage multiple updates. How should web users be invited to review multiple updates, so they can approve or reject as needed? We also need to think about how to keep parity between the website and the API. The API supports write operations but is not interactive. So it might be important to add in a feature to show orgs the changes made to their objects. And we might want to add the ability to add a comment alongside updates, so admins can later review logs of what changed and why. We want to speak with people who develop tools that might implement this feature. If you develop a tool that could benefit from a feature like this then let us know. We'd like to speak. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Do You Want Your Configuration Management System to Update PeeringDB?"},{"location":"blog/nanog_87_hackathon_proof_of_concept/#do-you-want-your-configuration-management-system-to-update-peeringdb","text":"The theme for NANOG 87's Hackathon was interacting with sources of truth. Our project focused on identifying the difference between what's in a configuration system and PeeringDB - then sending an update. Developers from FullCtl and Peering Manager worked together to develop a proof of concept feature. It lets users know when PeeringDB did not reflect the internal configuration. It then made it easy to send PeeringDB an update. Users tell us that network configuration data is what they value most. So developing ways to help users identify what to update could be valuable. And offering a way to tie that to an update mechanism could make updating PeeringDB much faster. We've created an issue describing this on GitHub . If you or your organization would benefit from a feature like this, please let us know. You can comment on the issue, write to the Product Committee's list , or chat with a PC member. If this is something our users want then we'll need to answer some questions. One example is how to manage multiple updates. How should web users be invited to review multiple updates, so they can approve or reject as needed? We also need to think about how to keep parity between the website and the API. The API supports write operations but is not interactive. So it might be important to add in a feature to show orgs the changes made to their objects. And we might want to add the ability to add a comment alongside updates, so admins can later review logs of what changed and why. We want to speak with people who develop tools that might implement this feature. If you develop a tool that could benefit from a feature like this then let us know. We'd like to speak. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Do You Want Your Configuration Management System to Update PeeringDB?"},{"location":"blog/network_type_what_you_told_us/","text":"Network Type \u2013 What did you tell us? We invited PeeringDB users to tell us what they thought about the Network Type setting. This is the setting that describes your network to other PeeringDB users. It's OK 162 people participated and their core message was that the field is largely working for both those sharing and reading the data. Just over half of respondents use the field to make decisions. About two thirds think it is accurate or very accurate. About three quarters think the current range of options is useful or very useful. About half think the level of granularity is about right, while almost a third would like more nuance. Comments Lots of people told us how they use the Network Type field in the comments. Some reinforced their responses to the other questions with calls to remove the field, add additional options, or restrict the options to \u201ceyeball\u201d, \u201ccontent\u201d, and \u201chybrid\u201d. There was also a call to allow networks to select multiple categories. Next steps The Product Committee has decided to keep the Network Type field. We will not change the types of networks but will implement the ability to select multiple types. This will be implemented in the website and v2 API now deployed. We will plan a more radical update of the field for a future v3 API. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Network Type \u2013 What did you tell us?"},{"location":"blog/network_type_what_you_told_us/#network-type-what-did-you-tell-us","text":"We invited PeeringDB users to tell us what they thought about the Network Type setting. This is the setting that describes your network to other PeeringDB users.","title":"Network Type \u2013 What did you tell us?"},{"location":"blog/network_type_what_you_told_us/#its-ok","text":"162 people participated and their core message was that the field is largely working for both those sharing and reading the data. Just over half of respondents use the field to make decisions. About two thirds think it is accurate or very accurate. About three quarters think the current range of options is useful or very useful. About half think the level of granularity is about right, while almost a third would like more nuance.","title":"It's OK"},{"location":"blog/network_type_what_you_told_us/#comments","text":"Lots of people told us how they use the Network Type field in the comments. Some reinforced their responses to the other questions with calls to remove the field, add additional options, or restrict the options to \u201ceyeball\u201d, \u201ccontent\u201d, and \u201chybrid\u201d. There was also a call to allow networks to select multiple categories.","title":"Comments"},{"location":"blog/network_type_what_you_told_us/#next-steps","text":"The Product Committee has decided to keep the Network Type field. We will not change the types of networks but will implement the ability to select multiple types. This will be implemented in the website and v2 API now deployed. We will plan a more radical update of the field for a future v3 API. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Next steps"},{"location":"blog/network_type_your_input_sought/","text":"Network Type \u2013 Your Input Sought You can select from 10 options to describe your network in PeeringDB. We want to know if these options are useful. If we need to improve this part of PeeringDB, how should we improve it ? Please take our four question survey . We need your input to inform our decision. One option we're discussing is to clarify what each category means . Another is to deprecate the field . We know that not everyone understands the current categories in the same way. We don't know if anyone actually relies on this data to make decisions. Please take the survey and tell us if you use this data, how reliable you think it is, and how it should change if you think it needs improvement. The improvements we make are only as good as the requests we get from you. We want to make sure that we understand what you need and why. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Network Type \u2013 Your Input Sought"},{"location":"blog/network_type_your_input_sought/#network-type-your-input-sought","text":"You can select from 10 options to describe your network in PeeringDB. We want to know if these options are useful. If we need to improve this part of PeeringDB, how should we improve it ? Please take our four question survey . We need your input to inform our decision. One option we're discussing is to clarify what each category means . Another is to deprecate the field . We know that not everyone understands the current categories in the same way. We don't know if anyone actually relies on this data to make decisions. Please take the survey and tell us if you use this data, how reliable you think it is, and how it should change if you think it needs improvement. The improvements we make are only as good as the requests we get from you. We want to make sure that we understand what you need and why. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Network Type \u2013 Your Input Sought"},{"location":"blog/new_permission_manage_peering_sessions/","text":"New Permission: Manage Peering Sessions Last November, Maximilian Wilhelm suggested that we add a 'manage peering sessions' permission. Some networks let you request peering using our OAuth service . You don't have to rely on someone to read your email message. They get the ability to pull structured information about your network through our API. Automation. Everyone can win. Today, in 2.47.0 , we\u2019re introducing a new permission that lets organizations limit who can \"manage peering sessions\" via peering portals. It will default to \u2018on\u2019 for organizational admins. But other users won\u2019t get this permission by default. If you need this permission you\u2019ll need to speak with the admins for your organization\u2019s presence on PeeringDB. \" Today many peering portals leverage PeeringDB's OAuth to make managing peerings easier and remove the need to manage separate accounts with every network you peer with. The new \"manage peerings\" permission lets organisations control which of their teams can represent them to external organisations instead of relying on admin privileges in PeeringDB, providing safer and more secure access. \" Maximilian Wilhelm, Network Automation Engineer, Cloudflare Take a look at these new permissions if you use PeeringDB OAuth to manage peering sessions. If you operate a peering portal using our OAuth, you should make sure you check the new permission when authenticating users. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"New Permission: Manage Peering Sessions"},{"location":"blog/new_permission_manage_peering_sessions/#new-permission-manage-peering-sessions","text":"Last November, Maximilian Wilhelm suggested that we add a 'manage peering sessions' permission. Some networks let you request peering using our OAuth service . You don't have to rely on someone to read your email message. They get the ability to pull structured information about your network through our API. Automation. Everyone can win. Today, in 2.47.0 , we\u2019re introducing a new permission that lets organizations limit who can \"manage peering sessions\" via peering portals. It will default to \u2018on\u2019 for organizational admins. But other users won\u2019t get this permission by default. If you need this permission you\u2019ll need to speak with the admins for your organization\u2019s presence on PeeringDB. \" Today many peering portals leverage PeeringDB's OAuth to make managing peerings easier and remove the need to manage separate accounts with every network you peer with. The new \"manage peerings\" permission lets organisations control which of their teams can represent them to external organisations instead of relying on admin privileges in PeeringDB, providing safer and more secure access. \" Maximilian Wilhelm, Network Automation Engineer, Cloudflare Take a look at these new permissions if you use PeeringDB OAuth to manage peering sessions. If you operate a peering portal using our OAuth, you should make sure you check the new permission when authenticating users. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"New Permission: Manage Peering Sessions"},{"location":"blog/oauth_users/","text":"PeeringDB Can Bring Users to Your Application One of the most challenging parts of developing a new service or expanding an existing one is to get users to register for an account. That\u2019s one of the advantages of using PeeringDB\u2019s OAuth service. We\u2019ve already got plenty of users. But why would you want to enable PeeringDB\u2019s OAuth service with your application? Well, if it\u2019s focused on people at networks who engage in managing interconnections then you have a readymade audience. Take Facebook\u2019s example . They are now using PeeringDB OAuth as a part of the process they use to automate peering requests. \u201c We wanted to offer our partners an easy way to request and manage their peering with Facebook. Thanks to PeeringDB OAuth, our partner networks can submit peering requests and see their existing peering sessions with Facebook without having to login to their Facebook accounts! \u201d Jakub Heichman & Jenny Ramseyer @ Facebook Almost 150 applications have registered with PeeringDB and we\u2019re authenticating over 1,500 sessions each quarter. We expect that to grow. If you\u2019d like to learn how you can register your application with PeeringDB\u2019s OAuth service, take a look at our documentation . If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB Can Bring Users to Your Application"},{"location":"blog/oauth_users/#peeringdb-can-bring-users-to-your-application","text":"One of the most challenging parts of developing a new service or expanding an existing one is to get users to register for an account. That\u2019s one of the advantages of using PeeringDB\u2019s OAuth service. We\u2019ve already got plenty of users. But why would you want to enable PeeringDB\u2019s OAuth service with your application? Well, if it\u2019s focused on people at networks who engage in managing interconnections then you have a readymade audience. Take Facebook\u2019s example . They are now using PeeringDB OAuth as a part of the process they use to automate peering requests. \u201c We wanted to offer our partners an easy way to request and manage their peering with Facebook. Thanks to PeeringDB OAuth, our partner networks can submit peering requests and see their existing peering sessions with Facebook without having to login to their Facebook accounts! \u201d Jakub Heichman & Jenny Ramseyer @ Facebook Almost 150 applications have registered with PeeringDB and we\u2019re authenticating over 1,500 sessions each quarter. We expect that to grow. If you\u2019d like to learn how you can register your application with PeeringDB\u2019s OAuth service, take a look at our documentation . If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB Can Bring Users to Your Application"},{"location":"blog/october_2024_retrospective/","text":"October 2024 PeeringDB Product Update Strategy We reviewed and updated our strategy earlier in the year. We will be publishing overviews of product changes in April and October. We've had a blog for a few years but it\u2019s focused on details. These updates will give a bigger picture. People and process Terry Sweetser from APNIC has recently joined the Product Committee (PC). The PC now has members from Africa, Asia Pacific, Europe, and North America. Our committee\u2019s geographic diversity is matched by a diversity in expertise. We have updated our processes because our members live around the globe. We are using asynchronous work methods more. And we will focus on planning out sets of related issues to improve PeeringDB more quickly. We still encourage users to submit feature requests and bug reports in GitHub. We want to understand how feature developments can help our users. Please tell us whether you'd use a feature and how it would help. You can do this in GitHub, on our mailing list, or when you meet us at industry events. Last six months We've been rounding out support for Carrier objects. Organizations can now set user permissions for carriers. We\u2019ve also been working to improve data quality. We now enforce state naming. For instance, Queensland in Australia is now always QLD. We also normalize city names in responses but accept popular versions in the search request. So, a search for \"fac in M\u00fcnchen\" returns results for facilities within 34 km of Munich, Germany. The radius search is managed in the backend by the new search. It's different for each city. You can control the radius in Advanced Search, or just look on a map when you download our KMZ. The full KMZ download was popular. So, we tidied up the data in the export, added a watermark, so users know that they have PeeringDB data, and integrated KMZ support into other features. You can now download a .KMZ file of exchanges or facilities in a city, state, or country. This keeps the file size small, making it easier to integrate it with other data sources. Once you\u2019ve found the carrier, exchange, facility, or network you are interested in you can now export all their data in structured formats. Previously, this was only available for Advanced Search results. These data quality, search and extract features are one part of the work we've been doing. We've also put more effort into peeringdb-py, our local cache. We encourage anyone who wants to make heavy use of PeeringDB to run a local cache. There are no usage limits and no latency. If you often hit query limits then it could be worth installing. It is resource light, so it can run on a laptop as well as a server. If you sync it once an hour, the changes are normally under 100kb of data. We\u2019ve also made improvements behind the scenes. We\u2019ve switched to deploying PeeringDB in containers. This change will reduce the work needed by our volunteer Operations Committee. It will also help us manage costs better by adjusting compute resources dynamically based on load. Security A user made two security reports. Our Operations team also noticed one issue. Based on these reports, we will be making 2FA mandatory for all user accounts. We will also make some minor improvements to other elements of account security. We\u2019ll share more details after deploying changes. If you notice a security issue, please let us know! https://docs.peeringdb.com/howto/make-a-security-report/ Coming up and engagement Over the next six months we'd like to deploy improvements to our web design. These won't just make it look better. Once we have them in place we can implement lazy loading, to improve the user experience. We can also start to develop some key feature improvements, including saved searches, notifications, and comparison tools. Your input on how you'd use these and other feature improvements are welcome. You can create or comment on issues in GitHub. But we'd love to speak with you, too. We actively attend industry events around the world, so look for us there. Or send mail so we can schedule a conversation! If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"October 2024 PeeringDB Product Update"},{"location":"blog/october_2024_retrospective/#october-2024-peeringdb-product-update","text":"","title":"October 2024 PeeringDB Product Update"},{"location":"blog/october_2024_retrospective/#strategy","text":"We reviewed and updated our strategy earlier in the year. We will be publishing overviews of product changes in April and October. We've had a blog for a few years but it\u2019s focused on details. These updates will give a bigger picture.","title":"Strategy"},{"location":"blog/october_2024_retrospective/#people-and-process","text":"Terry Sweetser from APNIC has recently joined the Product Committee (PC). The PC now has members from Africa, Asia Pacific, Europe, and North America. Our committee\u2019s geographic diversity is matched by a diversity in expertise. We have updated our processes because our members live around the globe. We are using asynchronous work methods more. And we will focus on planning out sets of related issues to improve PeeringDB more quickly. We still encourage users to submit feature requests and bug reports in GitHub. We want to understand how feature developments can help our users. Please tell us whether you'd use a feature and how it would help. You can do this in GitHub, on our mailing list, or when you meet us at industry events.","title":"People and process"},{"location":"blog/october_2024_retrospective/#last-six-months","text":"We've been rounding out support for Carrier objects. Organizations can now set user permissions for carriers. We\u2019ve also been working to improve data quality. We now enforce state naming. For instance, Queensland in Australia is now always QLD. We also normalize city names in responses but accept popular versions in the search request. So, a search for \"fac in M\u00fcnchen\" returns results for facilities within 34 km of Munich, Germany. The radius search is managed in the backend by the new search. It's different for each city. You can control the radius in Advanced Search, or just look on a map when you download our KMZ. The full KMZ download was popular. So, we tidied up the data in the export, added a watermark, so users know that they have PeeringDB data, and integrated KMZ support into other features. You can now download a .KMZ file of exchanges or facilities in a city, state, or country. This keeps the file size small, making it easier to integrate it with other data sources. Once you\u2019ve found the carrier, exchange, facility, or network you are interested in you can now export all their data in structured formats. Previously, this was only available for Advanced Search results. These data quality, search and extract features are one part of the work we've been doing. We've also put more effort into peeringdb-py, our local cache. We encourage anyone who wants to make heavy use of PeeringDB to run a local cache. There are no usage limits and no latency. If you often hit query limits then it could be worth installing. It is resource light, so it can run on a laptop as well as a server. If you sync it once an hour, the changes are normally under 100kb of data. We\u2019ve also made improvements behind the scenes. We\u2019ve switched to deploying PeeringDB in containers. This change will reduce the work needed by our volunteer Operations Committee. It will also help us manage costs better by adjusting compute resources dynamically based on load.","title":"Last six months"},{"location":"blog/october_2024_retrospective/#security","text":"A user made two security reports. Our Operations team also noticed one issue. Based on these reports, we will be making 2FA mandatory for all user accounts. We will also make some minor improvements to other elements of account security. We\u2019ll share more details after deploying changes. If you notice a security issue, please let us know! https://docs.peeringdb.com/howto/make-a-security-report/","title":"Security"},{"location":"blog/october_2024_retrospective/#coming-up-and-engagement","text":"Over the next six months we'd like to deploy improvements to our web design. These won't just make it look better. Once we have them in place we can implement lazy loading, to improve the user experience. We can also start to develop some key feature improvements, including saved searches, notifications, and comparison tools. Your input on how you'd use these and other feature improvements are welcome. You can create or comment on issues in GitHub. But we'd love to speak with you, too. We actively attend industry events around the world, so look for us there. Or send mail so we can schedule a conversation! If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Coming up and engagement"},{"location":"blog/organizational_policy/","text":"Organizational Policy Features and More We want administrators for organizations in PeeringDB to log in and to look around. We have created some new settings to help you manage users affiliated with your organization in PeeringDB. There are three key changes you'll want to look at. You can now require your users to use a specific email domain. For example, if your company email uses example.com, you could require them to have an example.com email address for their PeeringDB account. You can now force users to revalidate their PeeringDB account periodically. You can set the period that fits with your organization's needs. Your users can now have multiple email addresses for their PeeringDB account. We have published a HOWTO that walks administrators through the details of how to configure these features. This release also includes improvements contributed by developers at Amazon and Google. We are grateful for their contributions. Take a look at our HOWTO about developing for PeeringDB if you'd like to contribute. This release also has several small feature improvements and changes that allow us to provide users with better support. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Organizational Policy Features and More"},{"location":"blog/organizational_policy/#organizational-policy-features-and-more","text":"We want administrators for organizations in PeeringDB to log in and to look around. We have created some new settings to help you manage users affiliated with your organization in PeeringDB. There are three key changes you'll want to look at. You can now require your users to use a specific email domain. For example, if your company email uses example.com, you could require them to have an example.com email address for their PeeringDB account. You can now force users to revalidate their PeeringDB account periodically. You can set the period that fits with your organization's needs. Your users can now have multiple email addresses for their PeeringDB account. We have published a HOWTO that walks administrators through the details of how to configure these features. This release also includes improvements contributed by developers at Amazon and Google. We are grateful for their contributions. Take a look at our HOWTO about developing for PeeringDB if you'd like to contribute. This release also has several small feature improvements and changes that allow us to provide users with better support. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Organizational Policy Features and More"},{"location":"blog/peeringdb_2020_satisfaction_survey/","text":"PeeringDB 2020 Satisfaction Survey PeeringDB wants input from network operators, exchange operators, facility providers, content distributors and anyone who uses our interconnection database. We are running an anonymous satisfaction survey until 23:59 UTC on 20 November 2020 and would like your feedback to help us make PeeringDB more useful to everyone involved in connecting networks. We haven\u2019t had the diversity of input we\u2019d like in previous surveys, so we are making an extra effort to reach parts of the community who weren\u2019t aware of our previous surveys. We're telling you here and we are teaming up with partners around the world to get the message out. Steve McManus, PeeringDB Product Committee Chair, says: \"Input from all PeeringDB users on what is important and what needs improving is essential. Telling us what you value and what you need us to improve will help us make PeeringDB better for you and make peering easier for all.\" The survey will help us understand what is important to you and how satisfied you are with what we are doing. We will use your responses to focus our product roadmap on the improvements that will make things better for you. If you have specific comments or suggestions we\u2019d love you to leave them along with your ratings. This is the first survey we are making available in multiple languages. In this survey we are using the six UN languages for the questions. That said, we\u2019re happy with people providing free text comments in whichever language they are happiest expressing themselves. We\u2019ll share the results and the new product roadmap early in 2021. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB 2020 Satisfaction Survey"},{"location":"blog/peeringdb_2020_satisfaction_survey/#peeringdb-2020-satisfaction-survey","text":"PeeringDB wants input from network operators, exchange operators, facility providers, content distributors and anyone who uses our interconnection database. We are running an anonymous satisfaction survey until 23:59 UTC on 20 November 2020 and would like your feedback to help us make PeeringDB more useful to everyone involved in connecting networks. We haven\u2019t had the diversity of input we\u2019d like in previous surveys, so we are making an extra effort to reach parts of the community who weren\u2019t aware of our previous surveys. We're telling you here and we are teaming up with partners around the world to get the message out. Steve McManus, PeeringDB Product Committee Chair, says: \"Input from all PeeringDB users on what is important and what needs improving is essential. Telling us what you value and what you need us to improve will help us make PeeringDB better for you and make peering easier for all.\" The survey will help us understand what is important to you and how satisfied you are with what we are doing. We will use your responses to focus our product roadmap on the improvements that will make things better for you. If you have specific comments or suggestions we\u2019d love you to leave them along with your ratings. This is the first survey we are making available in multiple languages. In this survey we are using the six UN languages for the questions. That said, we\u2019re happy with people providing free text comments in whichever language they are happiest expressing themselves. We\u2019ll share the results and the new product roadmap early in 2021. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB 2020 Satisfaction Survey"},{"location":"blog/peeringdb_2020_survey_2021_roadmap/","text":"2020 Survey Results and 2021 Product Roadmap Last November we asked you for input through our anonymous satisfaction survey, so we could use it to guide our product roadmap for 2021. Today, we are sharing what you told us through the survey and how we\u2019ll be improving PeeringDB and your experience of it in 2021. We had over 200 responses to the survey. Respondents identified themselves as connected with organizations operating on every continent and in every part of our industry. 99% of respondents described themselves as very or somewhat satisfied with PeeringDB overall. When we asked about specific service categories, we were told that Network Configuration Data and Search and Discovery capabilities were the most important. These service categories had lower, though still high, levels of satisfaction, with 95% and 96% of respondents describing themselves as very or somewhat satisfied with these aspects of PeeringDB. Although we saw higher satisfaction with the User Experience and Web Interface, at 97%, this service category both had the most responses and the most divided feedback. One user described the current web interface as \u201c clean and simple \u201d while others said it was \u201c showing its age .\u201d Documentation quality was also an area with lower specific satisfaction, at 93%. One comment homed in on a key problem, noting: \" Needs a top-level overview document/intro. Or if it exists, I need to find it. \" We have used your feedback to guide our product roadmap for 2021. The four key focus areas will be: Improving geographic search Developing a structured framework for user documentation Improving the web site\u2019s responsiveness Introducing a communications framework to alert users to developments and support future tooling Our first steps to accomplish this have been to add database support for coordinates of facilities. All new facilities will be located by their latitude and longitude, with street addresses as human friendly search terms instead of authoritative data. This is a major project and we will share more on this work in a future blog post. Another key change is the publication of our first HOWTO document . This document is designed to help new networks register with PeeringDB using our website. We will be publishing more documents in this series and developing a broader documentation framework to support API and web users equally. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"2020 Survey Results and 2021 Product Roadmap"},{"location":"blog/peeringdb_2020_survey_2021_roadmap/#2020-survey-results-and-2021-product-roadmap","text":"Last November we asked you for input through our anonymous satisfaction survey, so we could use it to guide our product roadmap for 2021. Today, we are sharing what you told us through the survey and how we\u2019ll be improving PeeringDB and your experience of it in 2021. We had over 200 responses to the survey. Respondents identified themselves as connected with organizations operating on every continent and in every part of our industry. 99% of respondents described themselves as very or somewhat satisfied with PeeringDB overall. When we asked about specific service categories, we were told that Network Configuration Data and Search and Discovery capabilities were the most important. These service categories had lower, though still high, levels of satisfaction, with 95% and 96% of respondents describing themselves as very or somewhat satisfied with these aspects of PeeringDB. Although we saw higher satisfaction with the User Experience and Web Interface, at 97%, this service category both had the most responses and the most divided feedback. One user described the current web interface as \u201c clean and simple \u201d while others said it was \u201c showing its age .\u201d Documentation quality was also an area with lower specific satisfaction, at 93%. One comment homed in on a key problem, noting: \" Needs a top-level overview document/intro. Or if it exists, I need to find it. \" We have used your feedback to guide our product roadmap for 2021. The four key focus areas will be: Improving geographic search Developing a structured framework for user documentation Improving the web site\u2019s responsiveness Introducing a communications framework to alert users to developments and support future tooling Our first steps to accomplish this have been to add database support for coordinates of facilities. All new facilities will be located by their latitude and longitude, with street addresses as human friendly search terms instead of authoritative data. This is a major project and we will share more on this work in a future blog post. Another key change is the publication of our first HOWTO document . This document is designed to help new networks register with PeeringDB using our website. We will be publishing more documents in this series and developing a broader documentation framework to support API and web users equally. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"2020 Survey Results and 2021 Product Roadmap"},{"location":"blog/peeringdb_2021_survey_2022_roadmap/","text":"2021 Survey Results and 2022 Product Roadmap Last September we asked you for input through our anonymous satisfaction survey, so we could use it to guide our product roadmap for 2022. Today, we are sharing what you told us through the survey and how we\u2019ll be improving PeeringDB and your experience of it in 2022. Highlights We had almost 250 responses to the survey, a 25% increase on last year. As with last year, respondents identified themselves as connected with organizations operating on every continent and in every part of our industry. Overall satisfaction remains unchanged from last year. We asked a few new questions in 2021 and learned: Almost 70% of respondents use PeeringDB every day or every week. Most of the rest use it every month. Under half of respondents use PeeringDB on a mobile device. About 70% of respondents want a way to be notified about changes that are relevant to them. From the questions that were repeated from 2021 we learned that Network Configuration Data and Search and Discovery capabilities remained the most important to our users. The User Experience and Web Interface remained the service categories with the lowest satisfaction, although 85% of respondents were still somewhat or very satisfied. The other lower performing area was Documentation Quality, which is an area that we started to address later in 2021 and some respondents won't have known about. Work on improving our documentation will continue in 2022. We hope that these improvements drive satisfaction in 2022. Roadmap We have used your feedback, in combination with a focus group consultation , to guide our product roadmap for 2022. The three key focus areas will be: Introduce a new \u201cCarrier\u201d object This object will describe providers of high capacity links between interconnection facilities. It was named \u201cCarrier\u201d during the discussion but that is a placeholder that could be changed if it is considered confusing or inappropriate. We are developing a design which will be circulated with the focus group before developing this new feature. As a new object, we\u2019ll make sure that it is well documented so users can get the most value from it. Improving the web site\u2019s responsiveness We recognize that the overall visual design needs some improvement. But perhaps more importantly we need to improve page load times. We plan to bring PeeringDB nearer to its users by completing deployment to a CDN. We have already tested this by deploying beta.peeringdb.com there and we will be moving www.peeringdb.com to it in 2022. We will also introduce modular page rendering, so each element loads via a separate connection, speeding the overall experience. We will use the CDN metrics to learn more about how www.peeringdb.com is used and that will inform improvements to the visual design. Continue improving search 2021 saw significant improvements to advanced search and simple search. We will continue to make improvements to search and help users keep the underlying data more accurate. One example of this is work that\u2019s going on, as I type, at the NANOG 84 Hackathon where volunteer developers are introducing intersection searches . That means you\u2019ll be able to make a single query to find out which IXPs or interconnection facilities have two networks present, such as your own and a desired peer\u2019s. This is an example of how PeeringDB is developed by its users as well as the core team. What else? Data accuracy We know that we need to do work to improve the quality of data in PeeringDB as it plays such an important role in configuration. We last looked at this in 2019\u2019s Data Ownership Task Force , whose report acknowledged the shared responsibility for data describing the interconnected nature of separately managed parts of our Internet. We plan to work with PeeringDB users to renew our work in this area so we can continue to improve the quality of data we publish. We are also setting course towards increased data accuracy by using the RPKI and Resource Signed Checklists (RSC). We want to use RSC validation to cryptographically validate our users\u2019 ability to control specific Internet Number Resources. Call to action We just deployed two user developed features: improvements to simple search and OpenID Connect integration. We are keen to include more user developed code. If you\u2019d like to contribute to PeeringDB then let me know and we can help you. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"2021 Survey Results and 2022 Product Roadmap"},{"location":"blog/peeringdb_2021_survey_2022_roadmap/#2021-survey-results-and-2022-product-roadmap","text":"Last September we asked you for input through our anonymous satisfaction survey, so we could use it to guide our product roadmap for 2022. Today, we are sharing what you told us through the survey and how we\u2019ll be improving PeeringDB and your experience of it in 2022.","title":"2021 Survey Results and 2022 Product Roadmap"},{"location":"blog/peeringdb_2021_survey_2022_roadmap/#highlights","text":"We had almost 250 responses to the survey, a 25% increase on last year. As with last year, respondents identified themselves as connected with organizations operating on every continent and in every part of our industry. Overall satisfaction remains unchanged from last year. We asked a few new questions in 2021 and learned: Almost 70% of respondents use PeeringDB every day or every week. Most of the rest use it every month. Under half of respondents use PeeringDB on a mobile device. About 70% of respondents want a way to be notified about changes that are relevant to them. From the questions that were repeated from 2021 we learned that Network Configuration Data and Search and Discovery capabilities remained the most important to our users. The User Experience and Web Interface remained the service categories with the lowest satisfaction, although 85% of respondents were still somewhat or very satisfied. The other lower performing area was Documentation Quality, which is an area that we started to address later in 2021 and some respondents won't have known about. Work on improving our documentation will continue in 2022. We hope that these improvements drive satisfaction in 2022.","title":"Highlights"},{"location":"blog/peeringdb_2021_survey_2022_roadmap/#roadmap","text":"We have used your feedback, in combination with a focus group consultation , to guide our product roadmap for 2022. The three key focus areas will be:","title":"Roadmap"},{"location":"blog/peeringdb_2021_survey_2022_roadmap/#introduce-a-new-carrier-object","text":"This object will describe providers of high capacity links between interconnection facilities. It was named \u201cCarrier\u201d during the discussion but that is a placeholder that could be changed if it is considered confusing or inappropriate. We are developing a design which will be circulated with the focus group before developing this new feature. As a new object, we\u2019ll make sure that it is well documented so users can get the most value from it.","title":"Introduce a new \u201cCarrier\u201d object"},{"location":"blog/peeringdb_2021_survey_2022_roadmap/#improving-the-web-sites-responsiveness","text":"We recognize that the overall visual design needs some improvement. But perhaps more importantly we need to improve page load times. We plan to bring PeeringDB nearer to its users by completing deployment to a CDN. We have already tested this by deploying beta.peeringdb.com there and we will be moving www.peeringdb.com to it in 2022. We will also introduce modular page rendering, so each element loads via a separate connection, speeding the overall experience. We will use the CDN metrics to learn more about how www.peeringdb.com is used and that will inform improvements to the visual design.","title":"Improving the web site\u2019s responsiveness"},{"location":"blog/peeringdb_2021_survey_2022_roadmap/#continue-improving-search","text":"2021 saw significant improvements to advanced search and simple search. We will continue to make improvements to search and help users keep the underlying data more accurate. One example of this is work that\u2019s going on, as I type, at the NANOG 84 Hackathon where volunteer developers are introducing intersection searches . That means you\u2019ll be able to make a single query to find out which IXPs or interconnection facilities have two networks present, such as your own and a desired peer\u2019s. This is an example of how PeeringDB is developed by its users as well as the core team.","title":"Continue improving search"},{"location":"blog/peeringdb_2021_survey_2022_roadmap/#what-else-data-accuracy","text":"We know that we need to do work to improve the quality of data in PeeringDB as it plays such an important role in configuration. We last looked at this in 2019\u2019s Data Ownership Task Force , whose report acknowledged the shared responsibility for data describing the interconnected nature of separately managed parts of our Internet. We plan to work with PeeringDB users to renew our work in this area so we can continue to improve the quality of data we publish. We are also setting course towards increased data accuracy by using the RPKI and Resource Signed Checklists (RSC). We want to use RSC validation to cryptographically validate our users\u2019 ability to control specific Internet Number Resources.","title":"What else? Data accuracy"},{"location":"blog/peeringdb_2021_survey_2022_roadmap/#call-to-action","text":"We just deployed two user developed features: improvements to simple search and OpenID Connect integration. We are keen to include more user developed code. If you\u2019d like to contribute to PeeringDB then let me know and we can help you. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Call to action"},{"location":"blog/peeringdb_2021_user_survey/","text":"PeeringDB 2021 User Survey PeeringDB wants input from network operators, exchange operators, facility providers, content distributors and anyone who uses our interconnection database. We are running an anonymous satisfaction survey until 23:59 UTC on Friday, 8 October 2021 and would like your feedback to help us make PeeringDB more useful to everyone involved in connecting networks. We had over 200 responses to last year\u2019s survey and those responses helped guide our product development. We\u2019ve made significant improvements to search based on user input, introduced a HOWTO documentation series , and are developing a documentation architecture directly as a result of your input. We\u2019d like more input, in 2021, so we can keep up with the industry\u2019s evolving needs. Steve McManus, PeeringDB Product Committee Chair, says: \" User comments in the 2020 survey helped us focus development where it was most needed. It directly influenced our roadmap and highlighted the need for specific expertise in documentation and user experience design to solve users\u2019 most pressing needs. Thanks to everyone who gives a few moments of their time to help us make PeeringDB a better service! \u201d In addition to the questions we asked last year, we have three extra questions about documentation priorities, notifications, and user experience on mobile devices. We are particularly keen to improve our understanding of people\u2019s needs for the website as this was the area with the most divided responses last year. The survey is available in the six UN languages and Portuguese. We\u2019re happy with people providing free text comments in whichever language they are happiest expressing themselves. We\u2019ll share the results and the new product roadmap early in 2022. So CLICK HERE to help guide PeeringDB\u2019s future development. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB 2021 User Survey"},{"location":"blog/peeringdb_2021_user_survey/#peeringdb-2021-user-survey","text":"PeeringDB wants input from network operators, exchange operators, facility providers, content distributors and anyone who uses our interconnection database. We are running an anonymous satisfaction survey until 23:59 UTC on Friday, 8 October 2021 and would like your feedback to help us make PeeringDB more useful to everyone involved in connecting networks. We had over 200 responses to last year\u2019s survey and those responses helped guide our product development. We\u2019ve made significant improvements to search based on user input, introduced a HOWTO documentation series , and are developing a documentation architecture directly as a result of your input. We\u2019d like more input, in 2021, so we can keep up with the industry\u2019s evolving needs. Steve McManus, PeeringDB Product Committee Chair, says: \" User comments in the 2020 survey helped us focus development where it was most needed. It directly influenced our roadmap and highlighted the need for specific expertise in documentation and user experience design to solve users\u2019 most pressing needs. Thanks to everyone who gives a few moments of their time to help us make PeeringDB a better service! \u201d In addition to the questions we asked last year, we have three extra questions about documentation priorities, notifications, and user experience on mobile devices. We are particularly keen to improve our understanding of people\u2019s needs for the website as this was the area with the most divided responses last year. The survey is available in the six UN languages and Portuguese. We\u2019re happy with people providing free text comments in whichever language they are happiest expressing themselves. We\u2019ll share the results and the new product roadmap early in 2022. So CLICK HERE to help guide PeeringDB\u2019s future development. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB 2021 User Survey"},{"location":"blog/peeringdb_2022_user_survey/","text":"PeeringDB 2022 User Survey PeeringDB wants input from everyone who uses our interconnection database. Our anonymous survey is now open until 23:59 UTC on 16 October 2022. We would like your feedback to help us make PeeringDB more useful to everyone involved in connecting networks. We had about 250 responses to last year\u2019s survey which helped guide our product development. Key changes delivered so far in 2022 include: Added API Key support to peeringdb-py Added FIDO U2F 2FA support to www.peeringdb.com Normalized place names We\u2019ve also published more documents in our HOWTO documentation series . Steve McManus, PeeringDB Product Committee Chair, says: \" The 2021 survey helped us focus development where it was most needed. We used it to develop our roadmap. We are still implementing things we have learned from previous surveys but want your input on how we should adapt. Please take a few moments of their time to help us make PeeringDB a better service! \u201d In 2022 we have added a couple of extra questions. We'd like to know how many people use PeeringDB at your organization. We'd also like to know how you use it: web, API, or via a local cache. We will use your answers to focus development work where it is most needed. The survey is available in the six UN languages, Portuguese and Ukrainian. Please provide comments in whatever language you want to express yourself. We\u2019ll share the results and the new product roadmap early in 2023. So CLICK HERE to help guide PeeringDB\u2019s future development. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB 2022 User Survey"},{"location":"blog/peeringdb_2022_user_survey/#peeringdb-2022-user-survey","text":"PeeringDB wants input from everyone who uses our interconnection database. Our anonymous survey is now open until 23:59 UTC on 16 October 2022. We would like your feedback to help us make PeeringDB more useful to everyone involved in connecting networks. We had about 250 responses to last year\u2019s survey which helped guide our product development. Key changes delivered so far in 2022 include: Added API Key support to peeringdb-py Added FIDO U2F 2FA support to www.peeringdb.com Normalized place names We\u2019ve also published more documents in our HOWTO documentation series . Steve McManus, PeeringDB Product Committee Chair, says: \" The 2021 survey helped us focus development where it was most needed. We used it to develop our roadmap. We are still implementing things we have learned from previous surveys but want your input on how we should adapt. Please take a few moments of their time to help us make PeeringDB a better service! \u201d In 2022 we have added a couple of extra questions. We'd like to know how many people use PeeringDB at your organization. We'd also like to know how you use it: web, API, or via a local cache. We will use your answers to focus development work where it is most needed. The survey is available in the six UN languages, Portuguese and Ukrainian. Please provide comments in whatever language you want to express yourself. We\u2019ll share the results and the new product roadmap early in 2023. So CLICK HERE to help guide PeeringDB\u2019s future development. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB 2022 User Survey"},{"location":"blog/peeringdb_2023_roadmap/","text":"PeeringDB's Product Roadmap for 2023 We want to build more agility into our Product Management process in 2023. This blog post describes what we have planned for the start of the year. It also describes how we want to work over the whole year, and how you can help us make good choices. We are starting the year with features that open new paths to us. Your input will help us choose how we move down them. Our roundup of 2022 noted that we have some big things planned for the start of 2023. The two biggest are two new objects. We deployed the first in our January release. The new carrier object is a way for providers of high capacity links to show which interconnection facilities they are in. We\u2019ve deployed the minimal possible structure for this new object. We want users to tell us what additional features they cannot do without. The next big new addition is a campus object. This will be a way for interconnection facilities to show that inter-building cross-connects are available with the same ease as those within a building. This will help buyers understand when they don't need to be in the same building as something they want to connect to. We can expand either or both of these objects. We need your feedback to help us decide what would make them more valuable. Respondents to our annual surveys have consistently told us that Network Configuration Data is what they value most. They are also quite divided about the website design. Some people love its simplicity and others want something more modern. We knew that we didn't have enough information to make good decisions on how to improve things for the people who want change without disappointing those who like it the way it is. We have deployed Google Analytics for beta.peeringdb.com and would like to deploy it to www.peeringdb.com and docs.peeringdb.com . This will give us important information about how people use our site. We\u2019ll use this information to understand the problems people experience and develop ways to solve them. We also have lots of users who rely on our API or a local cache of PeeringDB data. So, we want to make it easier for users to identify the deltas between what they have in PeeringDB and their local configuration management. This is the focus on the projects we're taking to the NANOG 87 Hackathon . We want to work with tool developers and anyone who relies on PeeringDB as a source of network configuration data. Ultimately, we'd like to offer a way for users to automatically identify deltas, the changes that could be made, and ways to make or approve those changes. Across the rest of the year, we'd like to focus on one theme at a time and deliver a set of significant improvements there. Then we can move on to the next relevant theme. So please let us know how we could make PeeringDB more valuable for your organization. As always, you can submit an issue, or comment on existing issues in GitHub . But you can also send us email or chat to us at various community events. PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB's Product Roadmap for 2023"},{"location":"blog/peeringdb_2023_roadmap/#peeringdbs-product-roadmap-for-2023","text":"We want to build more agility into our Product Management process in 2023. This blog post describes what we have planned for the start of the year. It also describes how we want to work over the whole year, and how you can help us make good choices. We are starting the year with features that open new paths to us. Your input will help us choose how we move down them. Our roundup of 2022 noted that we have some big things planned for the start of 2023. The two biggest are two new objects. We deployed the first in our January release. The new carrier object is a way for providers of high capacity links to show which interconnection facilities they are in. We\u2019ve deployed the minimal possible structure for this new object. We want users to tell us what additional features they cannot do without. The next big new addition is a campus object. This will be a way for interconnection facilities to show that inter-building cross-connects are available with the same ease as those within a building. This will help buyers understand when they don't need to be in the same building as something they want to connect to. We can expand either or both of these objects. We need your feedback to help us decide what would make them more valuable. Respondents to our annual surveys have consistently told us that Network Configuration Data is what they value most. They are also quite divided about the website design. Some people love its simplicity and others want something more modern. We knew that we didn't have enough information to make good decisions on how to improve things for the people who want change without disappointing those who like it the way it is. We have deployed Google Analytics for beta.peeringdb.com and would like to deploy it to www.peeringdb.com and docs.peeringdb.com . This will give us important information about how people use our site. We\u2019ll use this information to understand the problems people experience and develop ways to solve them. We also have lots of users who rely on our API or a local cache of PeeringDB data. So, we want to make it easier for users to identify the deltas between what they have in PeeringDB and their local configuration management. This is the focus on the projects we're taking to the NANOG 87 Hackathon . We want to work with tool developers and anyone who relies on PeeringDB as a source of network configuration data. Ultimately, we'd like to offer a way for users to automatically identify deltas, the changes that could be made, and ways to make or approve those changes. Across the rest of the year, we'd like to focus on one theme at a time and deliver a set of significant improvements there. Then we can move on to the next relevant theme. So please let us know how we could make PeeringDB more valuable for your organization. As always, you can submit an issue, or comment on existing issues in GitHub . But you can also send us email or chat to us at various community events. PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB's Product Roadmap for 2023"},{"location":"blog/peeringdb_in_your_preferred_language/","text":"PeeringDB in Your Preferred Language Volunteers translate PeeringDB into 17 different languages . Some of those translations, like Romanian, are complete. Others, like Indonesian, have only just started. Translation is important in making PeeringDB accessible to people around the world. But until now, you had to create an account \u2013 using the English language interface \u2013 to set your preferred language. We realized that this was not a perfect solution. We are grateful to Daniel Van Allen of Google. He developed the code to make translations available to anonymous web users. Now, you can land on the homepage and select the language you want to use from the dropdown menu. We hope that this will make PeeringDB accessible to more users. We also hope it will inspire people to volunteer to translate PeeringDB. If you want to volunteer, you can contact us . If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB in Your Preferred Language"},{"location":"blog/peeringdb_in_your_preferred_language/#peeringdb-in-your-preferred-language","text":"Volunteers translate PeeringDB into 17 different languages . Some of those translations, like Romanian, are complete. Others, like Indonesian, have only just started. Translation is important in making PeeringDB accessible to people around the world. But until now, you had to create an account \u2013 using the English language interface \u2013 to set your preferred language. We realized that this was not a perfect solution. We are grateful to Daniel Van Allen of Google. He developed the code to make translations available to anonymous web users. Now, you can land on the homepage and select the language you want to use from the dropdown menu. We hope that this will make PeeringDB accessible to more users. We also hope it will inspire people to volunteer to translate PeeringDB. If you want to volunteer, you can contact us . If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB in Your Preferred Language"},{"location":"blog/peeringdb_is_developed_by_its_community/","text":"PeeringDB is Developed by its Community PeeringDB community members have contributed two significant improvements that were deployed into production this month. Simple Search is Smarter Search As reported by NANOG last week, we have deployed code developed by Brad Schwyzer, James Lamanna, and Jeff Kala that significantly improves the accuracy of what we call Simple Search. This is the main search box on the front page or the basic API call. Until this month it provided an enthusiastic number of responses when searching for things like small AS Numbers. While the answers weren\u2019t wrong, our users needed to pay extra attention to find what they needed. Brad, James, and Jeff developed logic to work out what users are likely to be searching for and give them the most relevant results. Simple Search now knows about the difference between an AS Number, an IPv4 address, and an IPv6 address. It will only respond with IP address information if at least two segments of the address are included in the search. They turned this: Into this: We are grateful to them and to NANOG, who hosted the Hackathon where this code was developed. We are keen to participate in more Hackathons in the future. OpenID Connect We also deployed code developed by Carlos Aguado to implement OpenID Connect . This builds on our existing support for OAuth to enable identity federation with managed services. The code Carlos developed means that PeeringDB can be used as an OpenID Authorization Server so that any PeeringDB user can sign in to other websites. Your Code If you are a software developer who needs something from PeeringDB we might be able to deploy code you develop. We have a tested development environment and are keen to make PeeringDB service the interconnection community\u2019s needs. So please create an issue on GitHub or let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB is Developed by its Community"},{"location":"blog/peeringdb_is_developed_by_its_community/#peeringdb-is-developed-by-its-community","text":"PeeringDB community members have contributed two significant improvements that were deployed into production this month.","title":"PeeringDB is Developed by its Community"},{"location":"blog/peeringdb_is_developed_by_its_community/#simple-search-is-smarter-search","text":"As reported by NANOG last week, we have deployed code developed by Brad Schwyzer, James Lamanna, and Jeff Kala that significantly improves the accuracy of what we call Simple Search. This is the main search box on the front page or the basic API call. Until this month it provided an enthusiastic number of responses when searching for things like small AS Numbers. While the answers weren\u2019t wrong, our users needed to pay extra attention to find what they needed. Brad, James, and Jeff developed logic to work out what users are likely to be searching for and give them the most relevant results. Simple Search now knows about the difference between an AS Number, an IPv4 address, and an IPv6 address. It will only respond with IP address information if at least two segments of the address are included in the search. They turned this: Into this: We are grateful to them and to NANOG, who hosted the Hackathon where this code was developed. We are keen to participate in more Hackathons in the future.","title":"Simple Search is Smarter Search"},{"location":"blog/peeringdb_is_developed_by_its_community/#openid-connect","text":"We also deployed code developed by Carlos Aguado to implement OpenID Connect . This builds on our existing support for OAuth to enable identity federation with managed services. The code Carlos developed means that PeeringDB can be used as an OpenID Authorization Server so that any PeeringDB user can sign in to other websites.","title":"OpenID Connect"},{"location":"blog/peeringdb_is_developed_by_its_community/#your-code","text":"If you are a software developer who needs something from PeeringDB we might be able to deploy code you develop. We have a tested development environment and are keen to make PeeringDB service the interconnection community\u2019s needs. So please create an issue on GitHub or let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Your Code"},{"location":"blog/peeringdb_map_with_kmz/","text":"See Locations in PeeringDB on a Map We're making it easier for you to see where facilities are. It\u2019s good to know how close facilities are to each other and anything else that\u2019s important to you, like who and what is present there. We have coordinates for every facility in PeeringDB. For instance, One Wilshire in Los Angeles is at 34.047942, -118.255564. When you click on the coordinates on our site, you go to a map view. But that just shows you that one facility. Anyone who wants could use our API to extract the coordinates for all facilities. They could then populate any map they want. But that can be hard to do from raw data. We now produce a .KMZ file every day. It's ideal if you want to populate a map or GIS tool with PeeringDB facility data. We have linked to the file from the footer of every page on the site. If you want fresh data on interconnection facilities around the world, grab a copy every day. If you want to explore a new area, grab a copy and open it in your favorite .KMZ viewer. We have ideas for ways to improve the visualization of data in PeeringDB. But we want your input to guide us. Let us know what's most important to you, or the problems you need to solve. Contact the Product Committee , share it on our low traffic mailing lists , or have a chat when you meet us at an event. Or create an issue describing your need on GitHub. If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"See Locations in PeeringDB on a Map"},{"location":"blog/peeringdb_map_with_kmz/#see-locations-in-peeringdb-on-a-map","text":"We're making it easier for you to see where facilities are. It\u2019s good to know how close facilities are to each other and anything else that\u2019s important to you, like who and what is present there. We have coordinates for every facility in PeeringDB. For instance, One Wilshire in Los Angeles is at 34.047942, -118.255564. When you click on the coordinates on our site, you go to a map view. But that just shows you that one facility. Anyone who wants could use our API to extract the coordinates for all facilities. They could then populate any map they want. But that can be hard to do from raw data. We now produce a .KMZ file every day. It's ideal if you want to populate a map or GIS tool with PeeringDB facility data. We have linked to the file from the footer of every page on the site. If you want fresh data on interconnection facilities around the world, grab a copy every day. If you want to explore a new area, grab a copy and open it in your favorite .KMZ viewer. We have ideas for ways to improve the visualization of data in PeeringDB. But we want your input to guide us. Let us know what's most important to you, or the problems you need to solve. Contact the Product Committee , share it on our low traffic mailing lists , or have a chat when you meet us at an event. Or create an issue describing your need on GitHub. If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"See Locations in PeeringDB on a Map"},{"location":"blog/peeringdb_release_v2.23.0/","text":"PeeringDB Release v2.23.0 PeeringDB is pleased to announce the release of v2.23.0. Summary release notes are published on the release notes page . This release includes a key feature that comes out of the Data Ownership Task Force , which was established to clarify who is authoritative for data about networks where multiple members participate, like IXPs. This change means that all networks will need to have a technical POC when they publish a connection to an exchange network. This change will help all the parties on the exchange resolve technical issues efficiently. It was proposed and discussed in GitHub issues #826 . Stefan Wahl, Senior Ambassador ECIX, Megaport, says: \"This new feature is a great improvement allowing users to correctly identify the authoritative contact of a network. I enjoyed collaborating with the PeeringDB Task Force on this project.\" If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB Release v2.23.0"},{"location":"blog/peeringdb_release_v2.23.0/#peeringdb-release-v2230","text":"PeeringDB is pleased to announce the release of v2.23.0. Summary release notes are published on the release notes page . This release includes a key feature that comes out of the Data Ownership Task Force , which was established to clarify who is authoritative for data about networks where multiple members participate, like IXPs. This change means that all networks will need to have a technical POC when they publish a connection to an exchange network. This change will help all the parties on the exchange resolve technical issues efficiently. It was proposed and discussed in GitHub issues #826 . Stefan Wahl, Senior Ambassador ECIX, Megaport, says: \"This new feature is a great improvement allowing users to correctly identify the authoritative contact of a network. I enjoyed collaborating with the PeeringDB Task Force on this project.\" If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB Release v2.23.0"},{"location":"blog/peeringdb_release_v2.24.0/","text":"PeeringDB Release v2.24.0 PeeringDB is pleased to announce the release of v2.24.0. Summary release notes are published on the release notes page . This release focuses on improving data quality in the database by improving the way networks can identify themselves and making the user interface clearer where people misunderstood what was meant. Specialist networks can now identify themselves better. Governments, Route Collectors and organizations providing specialized Network Services, such as DNS, RDAP, or DDoS Protection can say so in their network type. We have cleaned up the data to reflect this for existing networks. Some users misunderstood the maximum prefix limit to mean the maximum prefix length. The tooltip now makes it clear that this refers to the maximum number of prefixes and not the prefix length. While our anonymous 2020 User Satisfaction Survey is still open, we can already see that we\u2019ll need to make more improvements along these lines. If you have not yet completed the survey, please do. It takes under three minutes and will help us build our product roadmap for the next year. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB Release v2.24.0"},{"location":"blog/peeringdb_release_v2.24.0/#peeringdb-release-v2240","text":"PeeringDB is pleased to announce the release of v2.24.0. Summary release notes are published on the release notes page . This release focuses on improving data quality in the database by improving the way networks can identify themselves and making the user interface clearer where people misunderstood what was meant. Specialist networks can now identify themselves better. Governments, Route Collectors and organizations providing specialized Network Services, such as DNS, RDAP, or DDoS Protection can say so in their network type. We have cleaned up the data to reflect this for existing networks. Some users misunderstood the maximum prefix limit to mean the maximum prefix length. The tooltip now makes it clear that this refers to the maximum number of prefixes and not the prefix length. While our anonymous 2020 User Satisfaction Survey is still open, we can already see that we\u2019ll need to make more improvements along these lines. If you have not yet completed the survey, please do. It takes under three minutes and will help us build our product roadmap for the next year. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB Release v2.24.0"},{"location":"blog/search_gets_better/","text":"Search Gets Better Users tell us that search and the quality of the data in PeeringDB are their two top priorities. We've previously written about using automation to improve data quality. We're now beta testing some improvements to search. You can test our new search interface now on beta.peeringdb.com . You can use natural language words, like \"near\" and \"in\", when you query PeeringDB. That means you're not forced to use the radius feature in Advanced Search. Martin Levy gave a use case when he opened issue #479 . The radius search improved things. This is a further improvement. In any of the countries where we\u2019ve normalized address data, you can search using a state name or its abbreviation. \" In my retirement, I finally had the time to visit and enjoy Montana. It's a wonderful state replete with interesting wildlife and absolutely-stunning landscapes. The fact that you can now find an IXP in Montana with an easy search on PeeringDB's website makes me very happy. I don't think I need to do that search anymore; however, I'm glad others active in the industry can now do that style of search. I wish PeeringDB and the whole industry all the best! I'm happy that my April 2019 issue on GitHub (You can\u2019t find an IXP in Montana; but you should be able to!) is now banished into the history books! \" Martin Levy When you search for facilities near New York, you\u2019ll get results for relevant locations in nearby New Jersey, just across the river. Similarly, searches for facilities near Los Angeles will extend south into Orange County. None of this takes away the Advanced Search tools . They are staying. But you can now find out about the scale of opportunities in a new area nice and quickly. As our first image shows, we\u2019re testing this new interface side-by-side with the old one. We\u2019d like you to try it and tell us what you think. There\u2019s a link to a feedback form at the top of the page. Please tell us what you like, what you'd like improved, or where our new search tool doesn't work properly. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Search Gets Better"},{"location":"blog/search_gets_better/#search-gets-better","text":"Users tell us that search and the quality of the data in PeeringDB are their two top priorities. We've previously written about using automation to improve data quality. We're now beta testing some improvements to search. You can test our new search interface now on beta.peeringdb.com . You can use natural language words, like \"near\" and \"in\", when you query PeeringDB. That means you're not forced to use the radius feature in Advanced Search. Martin Levy gave a use case when he opened issue #479 . The radius search improved things. This is a further improvement. In any of the countries where we\u2019ve normalized address data, you can search using a state name or its abbreviation. \" In my retirement, I finally had the time to visit and enjoy Montana. It's a wonderful state replete with interesting wildlife and absolutely-stunning landscapes. The fact that you can now find an IXP in Montana with an easy search on PeeringDB's website makes me very happy. I don't think I need to do that search anymore; however, I'm glad others active in the industry can now do that style of search. I wish PeeringDB and the whole industry all the best! I'm happy that my April 2019 issue on GitHub (You can\u2019t find an IXP in Montana; but you should be able to!) is now banished into the history books! \" Martin Levy When you search for facilities near New York, you\u2019ll get results for relevant locations in nearby New Jersey, just across the river. Similarly, searches for facilities near Los Angeles will extend south into Orange County. None of this takes away the Advanced Search tools . They are staying. But you can now find out about the scale of opportunities in a new area nice and quickly. As our first image shows, we\u2019re testing this new interface side-by-side with the old one. We\u2019d like you to try it and tell us what you think. There\u2019s a link to a feedback form at the top of the page. Please tell us what you like, what you'd like improved, or where our new search tool doesn't work properly. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Search Gets Better"},{"location":"blog/structured_data_and_more/","text":"Structured Data and More With PeeringDB This article describes our latest improvements and puts them in the context of recent feature developments. PeeringDB users have told us that their top priorities are data quality and search. These priorities have guided recent improvements. We want to make it easier to keep PeeringDB current. We want users to be able to analyze data. And we want to make the data available to users in the way that works best for them. Our API has enabled you to automate updates and get data in structured formats. And peeringdb-py , our local cache, lets you keep a local copy of our data. That makes it easy to keep queries local and integrate PeeringDB with other data sources. But we've been working to add key features for web users. Your internal source of truth can suggest updates to PeeringDB . Once you set that up, you can review and approve or deny suggestions. You can get PeeringDB data about facilities as a .KMZ file as well as CSV or JSON. So you can import it into Google Earth and other GIS tools. Simple search understands a wide range of geographic terms. For instance, you can just search for an ix in berlin or a fac in ke . Yes, PeeringDB understands ISO 3166-2 country codes. And now you can export data from any page. Of course, you could always copy and paste. But copying and pasting the list of peers at IX.br (PTT.br) S\u00e3o Paulo is a big job. Grabbing its data as a CSV or JSON removes copy/paste errors. You can import it straight into a business analytics engine.x Of course, it\u2019s not all feature changes. We know that we need to update the web design, too. We have a preview of the design available for you to look at and comment on: https://preview.beta.peeringdb.com Take a look and tell us what you like and what needs to be updated before we deploy this into production. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Structured Data and More With PeeringDB"},{"location":"blog/structured_data_and_more/#structured-data-and-more-with-peeringdb","text":"This article describes our latest improvements and puts them in the context of recent feature developments. PeeringDB users have told us that their top priorities are data quality and search. These priorities have guided recent improvements. We want to make it easier to keep PeeringDB current. We want users to be able to analyze data. And we want to make the data available to users in the way that works best for them. Our API has enabled you to automate updates and get data in structured formats. And peeringdb-py , our local cache, lets you keep a local copy of our data. That makes it easy to keep queries local and integrate PeeringDB with other data sources. But we've been working to add key features for web users. Your internal source of truth can suggest updates to PeeringDB . Once you set that up, you can review and approve or deny suggestions. You can get PeeringDB data about facilities as a .KMZ file as well as CSV or JSON. So you can import it into Google Earth and other GIS tools. Simple search understands a wide range of geographic terms. For instance, you can just search for an ix in berlin or a fac in ke . Yes, PeeringDB understands ISO 3166-2 country codes. And now you can export data from any page. Of course, you could always copy and paste. But copying and pasting the list of peers at IX.br (PTT.br) S\u00e3o Paulo is a big job. Grabbing its data as a CSV or JSON removes copy/paste errors. You can import it straight into a business analytics engine.x Of course, it\u2019s not all feature changes. We know that we need to update the web design, too. We have a preview of the design available for you to look at and comment on: https://preview.beta.peeringdb.com Take a look and tell us what you like and what needs to be updated before we deploy this into production. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Structured Data and More With PeeringDB"},{"location":"blog/u2f_and_url/","text":"Improve Your Account Security - And Check Our URL We completed our support for FIDO U2F hardware tokens this month and have made www.peeringdb.com the canonical URL for our service. We\u2019d like you to take advantage of two-factor security for your PeeringDB account. We also want to ensure you adjust any automation aimed at https://peeringdb.com so that it connects to https://www.peeringdb.com instead. This will ensure continuity of service for API users. Your listing in PeeringDB is how you present your network, IXP, or facility to the world. If a miscreant gains access to your account they can misrepresent you. Reclaiming control of the objects you look after and undoing any changes the miscreant has made could be a lot of work. You can protect yourself against this risk by enabling two-factor authentication on your account. We have supported industry standard Time-based One-Time Passwords, as defined in RFC 6238 for a while now. This is the protocol used by popular smartphone authenticator apps. We added support for FIDO U2F hardware tokens in Q1 2022. You enable 2FA in the Account Security section of your account settings. Click on the green button to Manage Two-Factor Authentication and you\u2019ll be guided through the process. Just be aware that you\u2019ll need a secure place to store your backup codes, so you can gain access to your account if you ever lose access to your authenticator app or U2F hardware token. What are you waiting for? Improve the protection for your organization\u2019s listing in PeeringDB today by enabling 2FA. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Improve Your Account Security - And Check Our URL"},{"location":"blog/u2f_and_url/#improve-your-account-security-and-check-our-url","text":"We completed our support for FIDO U2F hardware tokens this month and have made www.peeringdb.com the canonical URL for our service. We\u2019d like you to take advantage of two-factor security for your PeeringDB account. We also want to ensure you adjust any automation aimed at https://peeringdb.com so that it connects to https://www.peeringdb.com instead. This will ensure continuity of service for API users. Your listing in PeeringDB is how you present your network, IXP, or facility to the world. If a miscreant gains access to your account they can misrepresent you. Reclaiming control of the objects you look after and undoing any changes the miscreant has made could be a lot of work. You can protect yourself against this risk by enabling two-factor authentication on your account. We have supported industry standard Time-based One-Time Passwords, as defined in RFC 6238 for a while now. This is the protocol used by popular smartphone authenticator apps. We added support for FIDO U2F hardware tokens in Q1 2022. You enable 2FA in the Account Security section of your account settings. Click on the green button to Manage Two-Factor Authentication and you\u2019ll be guided through the process. Just be aware that you\u2019ll need a secure place to store your backup codes, so you can gain access to your account if you ever lose access to your authenticator app or U2F hardware token. What are you waiting for? Improve the protection for your organization\u2019s listing in PeeringDB today by enabling 2FA. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Improve Your Account Security - And Check Our URL"},{"location":"blog/updates_from_an_internal_source_of_truth/","text":"Your Internal Source of Truth Can Now Push Updates to PeeringDB We have an API . You can use our API to update PeeringDB as well as make queries. But most people don't want to hand craft API updates. Very few organizations have the scale that demands automating updates. Until now, that left a gap. If your network connects at many facilities and IXPs, there might be a gap between a change happening and appearing in PeeringDB. Our users value the quality of configuration data in PeeringDB, so we wanted to fill that gap. We used the NANOG 87 Hackathon as an opportunity to test a proof of concept. It went well, so we've put it into production. Your internal source of truth can now suggest updates to PeeringDB. You then log in to our web interface and approve or reject those changes. FullCtl, who participated in the Hackathon challenge , has already implemented support for this new feature. This new feature means you can have automation monitor the gap between your internal source of truth and PeeringDB. And you don't need to give that tool credentials to push updates to PeeringDB. Benefits include: Simplified user interface for changes Human oversight Third party tools do not need to be given credentials with write permission \" It's great when you see a project that's become as important and successful as PeeringDB continue to innovate and improve. We're super stoked to be the first of what I'm sure will be many apps to support this new feature - which is sure to increase the already amazing amount of high quality interconnection data available in PeeringDB, supporting global interconnection. \" Chris Grundemann, Co-Founder & CEO, FullCtl We\u2019d love to see more updates coming in from more sources of truth! If you have suggestions, contact the Product Committee , share them on our low traffic mailing lists , or have a chat when you meet us at an event. Or create an issue describing your need on GitHub. If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Your Internal Source of Truth Can Now Push Updates to PeeringDB"},{"location":"blog/updates_from_an_internal_source_of_truth/#your-internal-source-of-truth-can-now-push-updates-to-peeringdb","text":"We have an API . You can use our API to update PeeringDB as well as make queries. But most people don't want to hand craft API updates. Very few organizations have the scale that demands automating updates. Until now, that left a gap. If your network connects at many facilities and IXPs, there might be a gap between a change happening and appearing in PeeringDB. Our users value the quality of configuration data in PeeringDB, so we wanted to fill that gap. We used the NANOG 87 Hackathon as an opportunity to test a proof of concept. It went well, so we've put it into production. Your internal source of truth can now suggest updates to PeeringDB. You then log in to our web interface and approve or reject those changes. FullCtl, who participated in the Hackathon challenge , has already implemented support for this new feature. This new feature means you can have automation monitor the gap between your internal source of truth and PeeringDB. And you don't need to give that tool credentials to push updates to PeeringDB. Benefits include: Simplified user interface for changes Human oversight Third party tools do not need to be given credentials with write permission \" It's great when you see a project that's become as important and successful as PeeringDB continue to innovate and improve. We're super stoked to be the first of what I'm sure will be many apps to support this new feature - which is sure to increase the already amazing amount of high quality interconnection data available in PeeringDB, supporting global interconnection. \" Chris Grundemann, Co-Founder & CEO, FullCtl We\u2019d love to see more updates coming in from more sources of truth! If you have suggestions, contact the Product Committee , share them on our low traffic mailing lists , or have a chat when you meet us at an event. Or create an issue describing your need on GitHub. If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Your Internal Source of Truth Can Now Push Updates to PeeringDB"},{"location":"blog/updating_our_webUI/","text":"We're Updating our Web UI PeeringDB users have told us that they both love the simplicity of our web UI but want it improved. We have started on a project to update it. We must update it to fully integrate the new carrier and campus objects. Carrier objects describe providers of high capacity L1 and L2 links into facilities. A campus is a group of interconnected facilities under common ownership. Our priorities are: Improve tabular data available for Campus and Carrier pages Mobile UI optimization Personalization features for logged in users Visualization of metro areas in a dynamic map Wizard framework for supporting creation and editing of objects Lazy loading of object data We'll start with ways to make it easier for users to get the data they want and need. Then we'll look at making it easier for users to update their own data in PeeringDB. We'll share some of the design options to check they meet users\u2019 needs. Watch out for future announcements, so you can give us feedback. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"We're Updating our Web UI"},{"location":"blog/updating_our_webUI/#were-updating-our-web-ui","text":"PeeringDB users have told us that they both love the simplicity of our web UI but want it improved. We have started on a project to update it. We must update it to fully integrate the new carrier and campus objects. Carrier objects describe providers of high capacity L1 and L2 links into facilities. A campus is a group of interconnected facilities under common ownership. Our priorities are: Improve tabular data available for Campus and Carrier pages Mobile UI optimization Personalization features for logged in users Visualization of metro areas in a dynamic map Wizard framework for supporting creation and editing of objects Lazy loading of object data We'll start with ways to make it easier for users to get the data they want and need. Then we'll look at making it easier for users to update their own data in PeeringDB. We'll share some of the design options to check they meet users\u2019 needs. Watch out for future announcements, so you can give us feedback. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"We're Updating our Web UI"},{"location":"blog/user_developed_tools/","text":"Getting the Most from PeeringDB with User Developed Tools We develop PeeringDB based on user demand. Users tell us what they want through a survey and by opening issues describing the problems they face on GitHub. But sometimes, users\u2019 needs go beyond what we can do and that\u2019s when user developed tools come in. We have recently refreshed and updated our listing of user developed and maintained tools . It now has its own page and features eight tools that help you: Sync PeeringDB data to a local repository Find common peering points Find and manage peers, and Use PeeringDB from the search bar on your browser \u201c I'm glad to see Peering Manager listed on PeeringDB's new tools page. PeeringDB's API and data are a huge asset to Peering Manager, helping users to autofill and keep up-to-date a lot of details. Accessing the API is both simple and reliable, keeping development simple. \u201d Guillaume Mazoyer, developer of Peering Manager If you develop a tool that uses PeeringDB and would like to share it with others, please let us know and we\u2019ll link to it from our tools page, so other people can thank you for sharing. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Getting the Most from PeeringDB with User Developed Tools"},{"location":"blog/user_developed_tools/#getting-the-most-from-peeringdb-with-user-developed-tools","text":"We develop PeeringDB based on user demand. Users tell us what they want through a survey and by opening issues describing the problems they face on GitHub. But sometimes, users\u2019 needs go beyond what we can do and that\u2019s when user developed tools come in. We have recently refreshed and updated our listing of user developed and maintained tools . It now has its own page and features eight tools that help you: Sync PeeringDB data to a local repository Find common peering points Find and manage peers, and Use PeeringDB from the search bar on your browser \u201c I'm glad to see Peering Manager listed on PeeringDB's new tools page. PeeringDB's API and data are a huge asset to Peering Manager, helping users to autofill and keep up-to-date a lot of details. Accessing the API is both simple and reliable, keeping development simple. \u201d Guillaume Mazoyer, developer of Peering Manager If you develop a tool that uses PeeringDB and would like to share it with others, please let us know and we\u2019ll link to it from our tools page, so other people can thank you for sharing. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Getting the Most from PeeringDB with User Developed Tools"},{"location":"blog/user_suggestions_improve_PeeringDB_usability/","text":"User Suggestions Improve PeeringDB Usability Some people are heavy PeeringDB users. They research and compare options, with many PeeringDB tabs open at once. But finding the PeeringDB tab you want meant looking at each one. But no more. Marco d'Itri wrote to the Product Committee and suggested an improvement: I believe that it would be great to have the HTML tag of the pages show more that just \"PeeringDB\", e.g. \"PeeringDB: AS65454\". This simple change would allow to find previously visited pages in the browser history and search box. We deployed this feature in our March release . Each page now has its key feature set as a search term. That's the AS Number for networks, or the name elsewhere. We set the whole search string as the page title for advanced searches. We hope this improves your PeeringDB web experience. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"User Suggestions Improve PeeringDB Usability"},{"location":"blog/user_suggestions_improve_PeeringDB_usability/#user-suggestions-improve-peeringdb-usability","text":"Some people are heavy PeeringDB users. They research and compare options, with many PeeringDB tabs open at once. But finding the PeeringDB tab you want meant looking at each one. But no more. Marco d'Itri wrote to the Product Committee and suggested an improvement: I believe that it would be great to have the HTML <title> tag of the pages show more that just \"PeeringDB\", e.g. \"PeeringDB: AS65454\". This simple change would allow to find previously visited pages in the browser history and search box. We deployed this feature in our March release . Each page now has its key feature set as a search term. That's the AS Number for networks, or the name elsewhere. We set the whole search string as the page title for advanced searches. We hope this improves your PeeringDB web experience. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"User Suggestions Improve PeeringDB Usability"},{"location":"blog/what_happened_to_our_web_ui/","text":"What happened to our web UI? We released 2.54.0 to production on 24 January 2024. PeeringDB users quickly made us aware of issues with the release. The problems centered on the impact of web UI changes on search: Users needed to click on the magnifying glass icon to open the search bar Some in page searches resulted in a CSRF error Other search attempts did not work We focused on four issues describing problems and developed fixes that addressed them in development and then beta environments. Ultimately, we decided that it was better to rollback the UI changes, so that\u2019s what we did. 2.54.2 is now in production. It has all the features from 2.54.0 except the web UI changes. Why did it happen? Our own internal testing missed the impact of these changes. We thought they were relatively small and planned to make an incremental improvement before introducing our updated design on preview.peeringdb.com . That was a mistake. Also, we\u2019ve had a remarkably good run of stable releases. We think this has contributed to a drop in testing on beta.peeringdb.com . Only about 0.25 percent of users visited beta.peeringdb.com in January 2024. How will we improve? We will be changing our process for introducing big changes. The first part is to improve our internal testing process. But we are also considering changes to the beta testing process. Instead of relying on users to speak up if they find a problem on beta.peeringdb.com we could do the reverse. We would only release major changes to production after we have had positive comments from users who have tested on beta.peeringdb.com . In some cases, we might need to delay a release \u2013 or part of it \u2013 until we had that positive input from users. What do you think? Would you prefer us to require more active involvement from users in beta testing? Let us know on our user-discuss mailing list , through our social media channels, or speak with our volunteers to share your thoughts. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"What happened to our web UI?"},{"location":"blog/what_happened_to_our_web_ui/#what-happened-to-our-web-ui","text":"We released 2.54.0 to production on 24 January 2024. PeeringDB users quickly made us aware of issues with the release. The problems centered on the impact of web UI changes on search: Users needed to click on the magnifying glass icon to open the search bar Some in page searches resulted in a CSRF error Other search attempts did not work We focused on four issues describing problems and developed fixes that addressed them in development and then beta environments. Ultimately, we decided that it was better to rollback the UI changes, so that\u2019s what we did. 2.54.2 is now in production. It has all the features from 2.54.0 except the web UI changes.","title":"What happened to our web UI?"},{"location":"blog/what_happened_to_our_web_ui/#why-did-it-happen","text":"Our own internal testing missed the impact of these changes. We thought they were relatively small and planned to make an incremental improvement before introducing our updated design on preview.peeringdb.com . That was a mistake. Also, we\u2019ve had a remarkably good run of stable releases. We think this has contributed to a drop in testing on beta.peeringdb.com . Only about 0.25 percent of users visited beta.peeringdb.com in January 2024.","title":"Why did it happen?"},{"location":"blog/what_happened_to_our_web_ui/#how-will-we-improve","text":"We will be changing our process for introducing big changes. The first part is to improve our internal testing process. But we are also considering changes to the beta testing process. Instead of relying on users to speak up if they find a problem on beta.peeringdb.com we could do the reverse. We would only release major changes to production after we have had positive comments from users who have tested on beta.peeringdb.com . In some cases, we might need to delay a release \u2013 or part of it \u2013 until we had that positive input from users. What do you think? Would you prefer us to require more active involvement from users in beta testing? Let us know on our user-discuss mailing list , through our social media channels, or speak with our volunteers to share your thoughts. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"How will we improve?"},{"location":"blog/whois_to_close/","text":"PeeringDB Whois Service to Close We will close down the whois.peeringdb.com service at the end of January 2024. The PeeringDB whois service is a relic of PeeringDB v1, where there was no API to query the database. PeeringDB v2 can be queried and updated through our API as well as the web. The whois service is just another way to get data from our API that is less supported and infrequently used. Keeping the service incurs a maintenance cost. We believe that closing the service is the best use of PeeringDB resources. User comments are welcome on the user-discuss list , or direct to the Product Committee . If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB Whois Service to Close"},{"location":"blog/whois_to_close/#peeringdb-whois-service-to-close","text":"We will close down the whois.peeringdb.com service at the end of January 2024. The PeeringDB whois service is a relic of PeeringDB v1, where there was no API to query the database. PeeringDB v2 can be queried and updated through our API as well as the web. The whois service is just another way to get data from our API that is less supported and infrequently used. Keeping the service incurs a maintenance cost. We believe that closing the service is the best use of PeeringDB resources. User comments are welcome on the user-discuss list , or direct to the Product Committee . If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB Whois Service to Close"},{"location":"blog/your_logo_goes_here/","text":"Your Logo Goes Here! We\u2019ve just deployed 2.31.0-beta and it\u2019s an opportunity to test out how your logo will look alongside your organization\u2019s name. Make sure you have your logo ready. Logos can have a height of up to 75 pixels and a width of up to 150. They must be uploaded in JPG, JPEG, or PNG. Log in to beta.peeringdb.com , upload your logo and check that it shows up well. This release didn\u2019t just add one feature. We have also made improvements for search, ix\u2019s, and facilities. Facilities can now specify a continental region, so searchers don\u2019t need to specify countries one at a time on the advanced search page. We added dynamic summaries and facilities. ASNs are now displayed at the top of search results for numeric queries. Sales contacts can now be added to IX objects If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Your Logo Goes Here!"},{"location":"blog/your_logo_goes_here/#your-logo-goes-here","text":"We\u2019ve just deployed 2.31.0-beta and it\u2019s an opportunity to test out how your logo will look alongside your organization\u2019s name. Make sure you have your logo ready. Logos can have a height of up to 75 pixels and a width of up to 150. They must be uploaded in JPG, JPEG, or PNG. Log in to beta.peeringdb.com , upload your logo and check that it shows up well. This release didn\u2019t just add one feature. We have also made improvements for search, ix\u2019s, and facilities. Facilities can now specify a continental region, so searchers don\u2019t need to specify countries one at a time on the advanced search page. We added dynamic summaries and facilities. ASNs are now displayed at the top of search results for numeric queries. Sales contacts can now be added to IX objects If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Your Logo Goes Here!"},{"location":"committee/common/","text":"PeeringDB Common Committee Charter Provisions: Dispute resolution If the committee handles an issue in a manner in which a user believes that their view has not been adequately considered, their first action should be to raise the concern with the Committee Chair for further consideration. If the dispute is between the user and the Committee Chair then the issue may alternatively be raised with the Committee Vice Chair. If the dispute cannot be resolved the matter may be brought forward to the PeeringDB Board. The decision by the PeeringDB Board shall be final. Committee Chair and Vice Chair The committee elects their Chair and Vice Chair from among their members, subject to PeeringDB Board approval. The Chair and Vice Chair work as a team and distribute the workload between themselves as they deem appropriate. Decisions should be unanimous, however the final decision on any matter is with the Chair. In case the Chair becomes unavailable, the Vice Chair may assume the position of Acting Chair. If the Chair or Vice Chair become permanently unavailable, replacement(s) are elected from the remaining committee members, subject to PeeringDB Board approval.","title":"Common"},{"location":"committee/common/#dispute-resolution","text":"If the committee handles an issue in a manner in which a user believes that their view has not been adequately considered, their first action should be to raise the concern with the Committee Chair for further consideration. If the dispute is between the user and the Committee Chair then the issue may alternatively be raised with the Committee Vice Chair. If the dispute cannot be resolved the matter may be brought forward to the PeeringDB Board. The decision by the PeeringDB Board shall be final.","title":"Dispute resolution"},{"location":"committee/common/#committee-chair-and-vice-chair","text":"The committee elects their Chair and Vice Chair from among their members, subject to PeeringDB Board approval. The Chair and Vice Chair work as a team and distribute the workload between themselves as they deem appropriate. Decisions should be unanimous, however the final decision on any matter is with the Chair. In case the Chair becomes unavailable, the Vice Chair may assume the position of Acting Chair. If the Chair or Vice Chair become permanently unavailable, replacement(s) are elected from the remaining committee members, subject to PeeringDB Board approval.","title":"Committee Chair and Vice Chair"},{"location":"committee/admin/","text":"PeeringDB Admin Committee Purpose is to oversee the administrator mission and volunteers. Interested in volunteering? Contact admincom@lists.peeringdb.com . Documentation Admin Committee Guidelines and Criteria for Approving Networks, IXPs, and Facilities PeeringDB Admin Committee Charter Approved by Board July 9th, 2020 Scope The PeeringDB Admin Committee (AC) is responsible for the day to day end-user support of PeeringDB. The Admin Committee functions as the first point of contact for any inquiries to PeeringDB. The Admin Committee produces definitions for enhancements to the workflow and Admin GUI and works with the Product Committee to plan a coherent roadmap for the PeeringDB software. Out of scope Work covered in the charter of the Operations, Outreach, Product, and further to be established Committees Deliverables Take care of support tickets, the Admin Committee strives to answer tickets within 24 hours Gather input from end-users regarding the improvement of PeeringDB in terms of bugs and product features and channel them towards the Product Committee via GitHub Improve PeeringDB Admin GUI to help expedient resolution of support tickets Collaboration The Admin Committee works with other PeeringDB committees to ensure an equitable division of development resources in recognition of the volunteer efforts that are ensuring the daily operations. Participation The PeeringDB Admin Committee members serve a one-year renewable term. Volunteers can submit their candidacy to the Admin Committee Chair. The Chair and Vice Chair will choose a new Admin Committee member at any time they see the necessity to ensure the continuity of the Admin Committee. There is a trial period of one month. New members are onboarded by a more experienced committee member (WebEx / Google Hangouts / 3 example tickets). After the trial period appointment is confirmed by the Chair and Vice Chair for one year. Expectations Individual committee members should do their fair share of tickets measured over a month If a committee member is away for an extended period of time, inform the Chair, Vice Chair, and a notification sent to the Admin Committee mailing list One month probation where they get taught/mentored by an experienced admin, and where if they do not do the work, they get booted Chairs perform a quarterly review. If you don't meet a fair portion of the work you'll be nudged. Also, three months of inactivity is an automatic ejection Communication Questions and suggestions for the Admin Committee can be sent to the Admincom Mailing List On- and de-boarding is handled via the Admincom GitHub All other issues, also for Admin GUI bugs and features must go to the regular GitHub Any support questions should be directed to the Support Address Admin Committee uses slack and emails for internal communication Regular (4-6 week interval) conference calls are used to stay synced and discuss issues Decision policy Admin Committee members will decide on their own when handling support tickets according to the Admin Committee BCP laid out in the Admin Committee How-To Folder. Otherwise, they will decide by simple majority vote on contested issues called by the Admin Committee Chair. If there is a tie the Chair's vote is counted double. Workflow Admincom uses DeskPRO and GitHub as well as direct communication with the main service contractor 20C to achieve its deliverables. In communicating with 3rd parties the Admin Committee should be kept in the loop if the issue is of general interest. PeeringDB Common Committee Charter Provisions: Dispute resolution If the committee handles an issue in a manner in which a user believes that their view has not been adequately considered, their first action should be to raise the concern with the Committee Chair for further consideration. If the dispute is between the user and the Committee Chair then the issue may alternatively be raised with the Committee Vice Chair. If the dispute cannot be resolved the matter may be brought forward to the PeeringDB Board. The decision by the PeeringDB Board shall be final. Committee Chair and Vice Chair The committee elects their Chair and Vice Chair from among their members, subject to PeeringDB Board approval. The Chair and Vice Chair work as a team and distribute the workload between themselves as they deem appropriate. Decisions should be unanimous, however the final decision on any matter is with the Chair. In case the Chair becomes unavailable, the Vice Chair may assume the position of Acting Chair. If the Chair or Vice Chair become permanently unavailable, replacement(s) are elected from the remaining committee members, subject to PeeringDB Board approval. Meeting notes June 23rd, 2020: Meeting Notes May 12th, 2020: Meeting Notes November 21st, 2019: Meeting Notes July 18th, 2019: Meeting Notes May 2nd, 2019: Meeting Notes Members Ankesh Anand Austin Brower John Brown Budiwijaya Shaun Coffey Ron Grant Chriztoffer Hansen - Chair Peter Helmenstine - Vice Chair Ga\u00ebl Hernandez Adam Korab Christopher Malayter - Board Liaison Aquinas Masakha Cris\u00f3stomo Mbundu Julimar Lunguinho Mendes Laura Yepes","title":"Admin Committee"},{"location":"committee/admin/#peeringdb-admin-committee","text":"Purpose is to oversee the administrator mission and volunteers. Interested in volunteering? Contact admincom@lists.peeringdb.com .","title":"PeeringDB Admin Committee"},{"location":"committee/admin/#documentation","text":"Admin Committee Guidelines and Criteria for Approving Networks, IXPs, and Facilities","title":"Documentation"},{"location":"committee/admin/#peeringdb-admin-committee-charter","text":"Approved by Board July 9th, 2020","title":"PeeringDB Admin Committee Charter"},{"location":"committee/admin/#scope","text":"The PeeringDB Admin Committee (AC) is responsible for the day to day end-user support of PeeringDB. The Admin Committee functions as the first point of contact for any inquiries to PeeringDB. The Admin Committee produces definitions for enhancements to the workflow and Admin GUI and works with the Product Committee to plan a coherent roadmap for the PeeringDB software.","title":"Scope"},{"location":"committee/admin/#out-of-scope","text":"Work covered in the charter of the Operations, Outreach, Product, and further to be established Committees","title":"Out of scope"},{"location":"committee/admin/#deliverables","text":"Take care of support tickets, the Admin Committee strives to answer tickets within 24 hours Gather input from end-users regarding the improvement of PeeringDB in terms of bugs and product features and channel them towards the Product Committee via GitHub Improve PeeringDB Admin GUI to help expedient resolution of support tickets","title":"Deliverables"},{"location":"committee/admin/#collaboration","text":"The Admin Committee works with other PeeringDB committees to ensure an equitable division of development resources in recognition of the volunteer efforts that are ensuring the daily operations.","title":"Collaboration"},{"location":"committee/admin/#participation","text":"The PeeringDB Admin Committee members serve a one-year renewable term. Volunteers can submit their candidacy to the Admin Committee Chair. The Chair and Vice Chair will choose a new Admin Committee member at any time they see the necessity to ensure the continuity of the Admin Committee. There is a trial period of one month. New members are onboarded by a more experienced committee member (WebEx / Google Hangouts / 3 example tickets). After the trial period appointment is confirmed by the Chair and Vice Chair for one year.","title":"Participation"},{"location":"committee/admin/#expectations","text":"Individual committee members should do their fair share of tickets measured over a month If a committee member is away for an extended period of time, inform the Chair, Vice Chair, and a notification sent to the Admin Committee mailing list One month probation where they get taught/mentored by an experienced admin, and where if they do not do the work, they get booted Chairs perform a quarterly review. If you don't meet a fair portion of the work you'll be nudged. Also, three months of inactivity is an automatic ejection","title":"Expectations"},{"location":"committee/admin/#communication","text":"Questions and suggestions for the Admin Committee can be sent to the Admincom Mailing List On- and de-boarding is handled via the Admincom GitHub All other issues, also for Admin GUI bugs and features must go to the regular GitHub Any support questions should be directed to the Support Address Admin Committee uses slack and emails for internal communication Regular (4-6 week interval) conference calls are used to stay synced and discuss issues","title":"Communication"},{"location":"committee/admin/#decision-policy","text":"Admin Committee members will decide on their own when handling support tickets according to the Admin Committee BCP laid out in the Admin Committee How-To Folder. Otherwise, they will decide by simple majority vote on contested issues called by the Admin Committee Chair. If there is a tie the Chair's vote is counted double.","title":"Decision policy"},{"location":"committee/admin/#workflow","text":"Admincom uses DeskPRO and GitHub as well as direct communication with the main service contractor 20C to achieve its deliverables. In communicating with 3rd parties the Admin Committee should be kept in the loop if the issue is of general interest. PeeringDB Common Committee Charter Provisions:","title":"Workflow"},{"location":"committee/admin/#dispute-resolution","text":"If the committee handles an issue in a manner in which a user believes that their view has not been adequately considered, their first action should be to raise the concern with the Committee Chair for further consideration. If the dispute is between the user and the Committee Chair then the issue may alternatively be raised with the Committee Vice Chair. If the dispute cannot be resolved the matter may be brought forward to the PeeringDB Board. The decision by the PeeringDB Board shall be final.","title":"Dispute resolution"},{"location":"committee/admin/#committee-chair-and-vice-chair","text":"The committee elects their Chair and Vice Chair from among their members, subject to PeeringDB Board approval. The Chair and Vice Chair work as a team and distribute the workload between themselves as they deem appropriate. Decisions should be unanimous, however the final decision on any matter is with the Chair. In case the Chair becomes unavailable, the Vice Chair may assume the position of Acting Chair. If the Chair or Vice Chair become permanently unavailable, replacement(s) are elected from the remaining committee members, subject to PeeringDB Board approval.","title":"Committee Chair and Vice Chair"},{"location":"committee/admin/#meeting-notes","text":"June 23rd, 2020: Meeting Notes May 12th, 2020: Meeting Notes November 21st, 2019: Meeting Notes July 18th, 2019: Meeting Notes May 2nd, 2019: Meeting Notes","title":"Meeting notes"},{"location":"committee/admin/#members","text":"Ankesh Anand Austin Brower John Brown Budiwijaya Shaun Coffey Ron Grant Chriztoffer Hansen - Chair Peter Helmenstine - Vice Chair Ga\u00ebl Hernandez Adam Korab Christopher Malayter - Board Liaison Aquinas Masakha Cris\u00f3stomo Mbundu Julimar Lunguinho Mendes Laura Yepes","title":"Members"},{"location":"committee/admin/approval-guidelines/","text":"Admin Committee Guidelines and Criteria for Approving Networks, IXPs, and Facilities Authors Chris Malayter Arnold Nipper Job Snijders Document history v1. Initial document. v2. Added multiple mechanisms to validate IXP and Network. v3. Added mechanism to validate facility. v4. Added draft flowcharts and placed explanatory text in an appendix. Minor readability revisions. Guideline goals This guide does not seek to define what an Internet Exchange, or Network operator, or Facility is. PeeringDB is a registry of information. What people do with the information is up to them. In these guidelines, we attempt to merely document PeeringDB\u2019s approval process. Key goals include: The Admin Committee can use multiple to validate and facilitate the creation of objects. Workflows are shown and always include the option to fall back to an exception process. This process brings more eyes and helps PeeringDB identify areas for improvement. Provide a few tangible examples of how to apply the guidelines. Definitions User - a person submitting a new object to the PeeringDB database RIR - A Regional Internet Registry (AFRINIC, APNIC, ARIN, LACNIC or the RIPE NCC) NIR - A National Internet Registry recognized by one of the RIRs Additional terminology is described in Section 4 of the PeeringDB Data Ownership Policy Document . Approving Network ( net ) objects The key to approving Network objects is to confirm the User has a relationship to the specified Autonomous System Number (ASN) and is authorized to represent that ASN in some form. PeeringDB follows industry best practices and has the following requirements for the Autonomous System numbers, regardless of who the User is: ASNs must be registered through an RIR or NIR The ASN must not already be registered in PeeringDB This means that \u201cPrivate\u201d ASNs, as listed in the IANA Autonomous System (AS) Numbers Registry or \u201cBogon\u201d ASNs, those which have not yet been assigned by an RIR or NIR, cannot be registered in PeeringDB. Flowchart There are various mechanisms to verify the relationship between the User and a given Autonomous System number: The registration details listed in WHOIS match the registration details in the sign-up request (same email domain) The registration details listed in RDAP match the registration details in the sign-up request (same email domain) The user can confirm the relationship to the ASN through a RPKI based challenge/response (work in progress: draft-ietf-sidrops-rpki-rsc) The user can confirm the relationship to the ASN by entering a PeeringDB suggested random string in their WHOIS record in a comments/remarks field (not yet implemented, a similar strategy to how Amazon AWS does BYOIP) Exception approval follows the standard process PeeringDB encourages but does not require its users to follow industry best practices. This means we recommend: Making a BGP looking glass publicly available, or A website listing the Network services, and a publicly documented Routing Policy Approving IXP ( ix ) objects The key to approving IXP objects is to confirm the User has a relationship to the specified Peering LAN Prefix, and is authorized to represent this IP block in some form. Flowchart Globally unique IP prefix requirements IP prefix must be registered through an RIR or NIR. The prefix must not overlap with any existing IXP object in PeeringDB IPv4 prefixes must not be longer than a /27 or shorter than /19 IPv6 prefixes must not be shorter than /64 but may be longer i.e. a /120 is allowed but a /63 is not Users can verify their relationship to an IP prefix in several ways: The registration details listed in WHOIS match the registration details in the sign-up request (same email domain). The registration details listed in RDAP match the registration details in the sign-up request (same email domain). The user can confirm the relationship to the IP prefix through a RPKI based challenge/response (work in progress - draft-ietf-sidrops-rpki-rsc). The user can confirm the relationship to the IP prefix by entering a PeeringDB suggested random string in their inetnum record in the authoritative RIR or NIR database in a comments/remarks field (note: IRR route/route6 objects cannot be used for this purpose). RDAP should be used to discover which RIR or NIR is authoritative For Legacy IPv4 space, a PeeringDB suggested random string can be placed in a TXT record for the reverse DNS label representing the first IPv4 address in the prefix. (This is a variant of the Amazon AWS BYOIP process). The assumption is that if someone controls Reverse DNS for a given prefix, they have full control over the prefix. Exception approval follows the standard process PeeringDB encourages but does not require its users to follow industry best practices. This means we recommend: A website detailing the IXP service A public overview of connected members and locations, service level, and terms of membership. Approving Facility ( fac ) objects A \u201cfacility\u201d is a physical location where two or more IP Networks or IXPs interconnect with each other. The key to approving Facility objects is to confirm with multiple existing PeeringDB users that a facility exists. Note: We will need to extend PeeringDB's software to support the workflow described here. Note: The IP addresses used in the attestation process will be logged. Validation mechanisms The owner of the facility is an existing PeeringDB user, and adds the facility to their record themselves. In this approval flow the facility is \u2018claimed\u2019. For this workflow the facility owner should already have one facility previously validated via one of the following mechanisms: The owner of the facility is not a PeeringDB user, but interested parties (who are PeeringDB users) wish the Facility object to be registered. The result is an unclaimed Facility object. The building has a website that has an interconnection or colocation section or One user will suggest the facility (peeringdb.com/suggest/fac), after filling in the details the form will generate a unique URL where the attestations can be collected. The user then distributes the URL (which can only be accessed by logged-in users) to the other interested parties, who can then attest or disprove the facility. When 3 PeeringDB users positively attest the facility exists, the facility is approved. The owner of the facility is a new peeringdb user and does not have any objects associated with their account. There are two mechanisms to claim a Facility object. The building has a website that has an interconnection or colocation section or An attestation process similar to how new facilities are suggested by existing users is followed, where the attempting-to-claim PeeringDB user must collect 3 positive attestations from three existing PeeringDB users. Exception approval follows the standard process Flowchart - Facility Flowchart - Attestation Flagging as \"junk\" PeeringDB users can flag a facility as \u201cjunk\u201d. This puts the Facility object in a review queue. The Admin Committee can resolve in the following ways: The facility owner becomes a PeeringDB user and claims the facility. The 3 people who attested that the facility exists can point at two existing PeeringDB IXP or Network object owners who are willing to attest they are present in the facility. The Admin Committee contacts the IXP or Network object owners and asks them to confirm their presence in the facility. At this point the facility record will list at least two network and/or IXP objects. A facility without networks or IXPs is considered potential \u201cjunk\u201d. Empty facilities will be deleted after 90 days. This happens when neither the owner of the facility, nor any other PeeringDB users were willing to indicate a relationship to the facility. The \u201cjunk\u201d button only appears in the UI for objects which are both unclaimed, and where no networks or IXPs indicate a presence. Checklist to help find entities present at the facility and or understand who the facility owner is Website operated by the facility owner: recommended and SHOULD list colocation or interconnection as a service Government or Industry Association website listing facilities. (Example: CLLI locators in the United States) Website of IXPs or Networks publishing they operate in the building Example facility object approval scenarios Facility approval example 1 Facility located at 100 W Main Street, Nowhere, WV, USA. Facility has four ISPs that interconnect in the basement of the building. Three out of the four ISPs have staff with PeeringDB accounts. Building owner has provided a closet for this to occur. Building has no website, the building owner does not know anything about interconnection, and has no plans to market the building as an interconnection location. Start ISP operator A files a request to suggest a Facility object to be entered into PeeringDB. Validation Process The facility owner is not a PeeringDB user, so the mechanism of the facility owner themselves suggesting the facility cannot be applied. The act of suggesting the facility in the PeeringDB user interface generates a unique URL which ISP Operator A can share with the fellow ISPs. If at least 2 other PeeringDB users attest the facility exists, the Facility object is created and marked as \u201cunclaimed\u201d. Facility approval example 2 A PeeringDB user noticed the Facility object created (as a result of Example 1), and reports it as \u201cjunk\u201d. The object continues to exist, but is added to a review queue for the PeeringDB Admin Committee to help resolve the situation. The Admin Committee\u2019s task is to find positive proof the facility exists and interconnection happens. Validation Process The AC committee first contacts the original PeeringDB users that provided attestations the facility exists. (Note: these PeeringDB users themselves might not be present in the facility). The AC can request the original attesters to provide a list of ISPs or IXPs they think are present in the facility. The AC can then contact the ISPs and/or IXPs who were suggested to have a presence in the facility and ask them to either attest the facility exists, or to add themselves as \u2018present\u2019 in the facility. It is possible these ISPs and/or IXPs are not yet PeeringDB users. If the AC can\u2019t collect the attestations the facility will be deleted in 90 days. Facility approval example 3 A Facility owner is a PeeringDB user and wishes to add its facility to PeeringDB using the \u201cSuggest a Facility\u201d function. The building owner is leasing suites to carriers in the basement of his facility, but primarily focuses on leasing office space. The building has a webpage, but data center/interconnection services are not listed on the webpage. The building owner has provided a list of four carriers who have leased space in the building. Validation Process The building owner can add webpage showing that they provide interconnection services. The attestation process can be used to demonstrate the building is used for interconnection. Facility approval example 4 An existing facility operator with other facilities listed in PeeringDB submits a new facility that does not yet have any customers. Validation Process None - The facility should be immediately added. After the Facility object has been added, networks and IXPs can indicate their presence. Exception process We know that these guidelines will need to be improved and updated as we learn, so we have built in an \u201cexception\u201d process to help with that. Whenever an easy path is not possible, the requester can ask for more review of their registration request. The first step in this process is to get input from all the volunteers on the Admin Committee. If more eyes are needed, the request can be shared with all of PeeringDB\u2019s Stewards, a group made from the committee chairs and board members. Where a formal decision is needed, the board can vote on a request and make a final decision. Flowchart Appendix Why must peering LANs be between /27 and /19 (IPv4) and not shorter than /64 (IPv6)? This limit is intended to reduce the likelihood of a typo that goes undetected and causes operational issues. Where a peering LAN uses a /28 or a /18 (IPv4) the Admin Committee can manually process the prefix after verifying its prefix length is correct. The technical standards do not allow LANs to have prefixes shorter than a /64, so a /63 would be rejected to avoid causing operational issues to operator equipment that is standards compliant.","title":"Admin Committee Guidelines and Criteria for Approving Networks, IXPs, and Facilities"},{"location":"committee/admin/approval-guidelines/#admin-committee-guidelines-and-criteria-for-approving-networks-ixps-and-facilities","text":"","title":"Admin Committee Guidelines and Criteria for Approving Networks, IXPs, and Facilities"},{"location":"committee/admin/approval-guidelines/#authors","text":"Chris Malayter Arnold Nipper Job Snijders","title":"Authors"},{"location":"committee/admin/approval-guidelines/#document-history","text":"v1. Initial document. v2. Added multiple mechanisms to validate IXP and Network. v3. Added mechanism to validate facility. v4. Added draft flowcharts and placed explanatory text in an appendix. Minor readability revisions.","title":"Document history"},{"location":"committee/admin/approval-guidelines/#guideline-goals","text":"This guide does not seek to define what an Internet Exchange, or Network operator, or Facility is. PeeringDB is a registry of information. What people do with the information is up to them. In these guidelines, we attempt to merely document PeeringDB\u2019s approval process. Key goals include: The Admin Committee can use multiple to validate and facilitate the creation of objects. Workflows are shown and always include the option to fall back to an exception process. This process brings more eyes and helps PeeringDB identify areas for improvement. Provide a few tangible examples of how to apply the guidelines.","title":"Guideline goals"},{"location":"committee/admin/approval-guidelines/#definitions","text":"User - a person submitting a new object to the PeeringDB database RIR - A Regional Internet Registry (AFRINIC, APNIC, ARIN, LACNIC or the RIPE NCC) NIR - A National Internet Registry recognized by one of the RIRs Additional terminology is described in Section 4 of the PeeringDB Data Ownership Policy Document .","title":"Definitions"},{"location":"committee/admin/approval-guidelines/#approving-network-net-objects","text":"The key to approving Network objects is to confirm the User has a relationship to the specified Autonomous System Number (ASN) and is authorized to represent that ASN in some form. PeeringDB follows industry best practices and has the following requirements for the Autonomous System numbers, regardless of who the User is: ASNs must be registered through an RIR or NIR The ASN must not already be registered in PeeringDB This means that \u201cPrivate\u201d ASNs, as listed in the IANA Autonomous System (AS) Numbers Registry or \u201cBogon\u201d ASNs, those which have not yet been assigned by an RIR or NIR, cannot be registered in PeeringDB.","title":"Approving Network (net) objects"},{"location":"committee/admin/approval-guidelines/#flowchart","text":"There are various mechanisms to verify the relationship between the User and a given Autonomous System number: The registration details listed in WHOIS match the registration details in the sign-up request (same email domain) The registration details listed in RDAP match the registration details in the sign-up request (same email domain) The user can confirm the relationship to the ASN through a RPKI based challenge/response (work in progress: draft-ietf-sidrops-rpki-rsc) The user can confirm the relationship to the ASN by entering a PeeringDB suggested random string in their WHOIS record in a comments/remarks field (not yet implemented, a similar strategy to how Amazon AWS does BYOIP) Exception approval follows the standard process PeeringDB encourages but does not require its users to follow industry best practices. This means we recommend: Making a BGP looking glass publicly available, or A website listing the Network services, and a publicly documented Routing Policy","title":"Flowchart"},{"location":"committee/admin/approval-guidelines/#approving-ixp-ix-objects","text":"The key to approving IXP objects is to confirm the User has a relationship to the specified Peering LAN Prefix, and is authorized to represent this IP block in some form.","title":"Approving IXP (ix) objects"},{"location":"committee/admin/approval-guidelines/#flowchart_1","text":"","title":"Flowchart"},{"location":"committee/admin/approval-guidelines/#globally-unique-ip-prefix-requirements","text":"IP prefix must be registered through an RIR or NIR. The prefix must not overlap with any existing IXP object in PeeringDB IPv4 prefixes must not be longer than a /27 or shorter than /19 IPv6 prefixes must not be shorter than /64 but may be longer i.e. a /120 is allowed but a /63 is not Users can verify their relationship to an IP prefix in several ways: The registration details listed in WHOIS match the registration details in the sign-up request (same email domain). The registration details listed in RDAP match the registration details in the sign-up request (same email domain). The user can confirm the relationship to the IP prefix through a RPKI based challenge/response (work in progress - draft-ietf-sidrops-rpki-rsc). The user can confirm the relationship to the IP prefix by entering a PeeringDB suggested random string in their inetnum record in the authoritative RIR or NIR database in a comments/remarks field (note: IRR route/route6 objects cannot be used for this purpose). RDAP should be used to discover which RIR or NIR is authoritative For Legacy IPv4 space, a PeeringDB suggested random string can be placed in a TXT record for the reverse DNS label representing the first IPv4 address in the prefix. (This is a variant of the Amazon AWS BYOIP process). The assumption is that if someone controls Reverse DNS for a given prefix, they have full control over the prefix. Exception approval follows the standard process PeeringDB encourages but does not require its users to follow industry best practices. This means we recommend: A website detailing the IXP service A public overview of connected members and locations, service level, and terms of membership.","title":"Globally unique IP prefix requirements"},{"location":"committee/admin/approval-guidelines/#approving-facility-fac-objects","text":"A \u201cfacility\u201d is a physical location where two or more IP Networks or IXPs interconnect with each other. The key to approving Facility objects is to confirm with multiple existing PeeringDB users that a facility exists. Note: We will need to extend PeeringDB's software to support the workflow described here. Note: The IP addresses used in the attestation process will be logged.","title":"Approving Facility (fac) objects"},{"location":"committee/admin/approval-guidelines/#validation-mechanisms","text":"The owner of the facility is an existing PeeringDB user, and adds the facility to their record themselves. In this approval flow the facility is \u2018claimed\u2019. For this workflow the facility owner should already have one facility previously validated via one of the following mechanisms: The owner of the facility is not a PeeringDB user, but interested parties (who are PeeringDB users) wish the Facility object to be registered. The result is an unclaimed Facility object. The building has a website that has an interconnection or colocation section or One user will suggest the facility (peeringdb.com/suggest/fac), after filling in the details the form will generate a unique URL where the attestations can be collected. The user then distributes the URL (which can only be accessed by logged-in users) to the other interested parties, who can then attest or disprove the facility. When 3 PeeringDB users positively attest the facility exists, the facility is approved. The owner of the facility is a new peeringdb user and does not have any objects associated with their account. There are two mechanisms to claim a Facility object. The building has a website that has an interconnection or colocation section or An attestation process similar to how new facilities are suggested by existing users is followed, where the attempting-to-claim PeeringDB user must collect 3 positive attestations from three existing PeeringDB users. Exception approval follows the standard process","title":"Validation mechanisms"},{"location":"committee/admin/approval-guidelines/#flowchart-facility","text":"","title":"Flowchart - Facility"},{"location":"committee/admin/approval-guidelines/#flowchart-attestation","text":"","title":"Flowchart - Attestation"},{"location":"committee/admin/approval-guidelines/#flagging-as-junk","text":"PeeringDB users can flag a facility as \u201cjunk\u201d. This puts the Facility object in a review queue. The Admin Committee can resolve in the following ways: The facility owner becomes a PeeringDB user and claims the facility. The 3 people who attested that the facility exists can point at two existing PeeringDB IXP or Network object owners who are willing to attest they are present in the facility. The Admin Committee contacts the IXP or Network object owners and asks them to confirm their presence in the facility. At this point the facility record will list at least two network and/or IXP objects. A facility without networks or IXPs is considered potential \u201cjunk\u201d. Empty facilities will be deleted after 90 days. This happens when neither the owner of the facility, nor any other PeeringDB users were willing to indicate a relationship to the facility. The \u201cjunk\u201d button only appears in the UI for objects which are both unclaimed, and where no networks or IXPs indicate a presence.","title":"Flagging as \"junk\""},{"location":"committee/admin/approval-guidelines/#checklist-to-help-find-entities-present-at-the-facility-and-or-understand-who-the-facility-owner-is","text":"Website operated by the facility owner: recommended and SHOULD list colocation or interconnection as a service Government or Industry Association website listing facilities. (Example: CLLI locators in the United States) Website of IXPs or Networks publishing they operate in the building","title":"Checklist to help find entities present at the facility and or understand who the facility owner is"},{"location":"committee/admin/approval-guidelines/#example-facility-object-approval-scenarios","text":"","title":"Example facility object approval scenarios"},{"location":"committee/admin/approval-guidelines/#facility-approval-example-1","text":"Facility located at 100 W Main Street, Nowhere, WV, USA. Facility has four ISPs that interconnect in the basement of the building. Three out of the four ISPs have staff with PeeringDB accounts. Building owner has provided a closet for this to occur. Building has no website, the building owner does not know anything about interconnection, and has no plans to market the building as an interconnection location. Start ISP operator A files a request to suggest a Facility object to be entered into PeeringDB. Validation Process The facility owner is not a PeeringDB user, so the mechanism of the facility owner themselves suggesting the facility cannot be applied. The act of suggesting the facility in the PeeringDB user interface generates a unique URL which ISP Operator A can share with the fellow ISPs. If at least 2 other PeeringDB users attest the facility exists, the Facility object is created and marked as \u201cunclaimed\u201d.","title":"Facility approval example 1"},{"location":"committee/admin/approval-guidelines/#facility-approval-example-2","text":"A PeeringDB user noticed the Facility object created (as a result of Example 1), and reports it as \u201cjunk\u201d. The object continues to exist, but is added to a review queue for the PeeringDB Admin Committee to help resolve the situation. The Admin Committee\u2019s task is to find positive proof the facility exists and interconnection happens. Validation Process The AC committee first contacts the original PeeringDB users that provided attestations the facility exists. (Note: these PeeringDB users themselves might not be present in the facility). The AC can request the original attesters to provide a list of ISPs or IXPs they think are present in the facility. The AC can then contact the ISPs and/or IXPs who were suggested to have a presence in the facility and ask them to either attest the facility exists, or to add themselves as \u2018present\u2019 in the facility. It is possible these ISPs and/or IXPs are not yet PeeringDB users. If the AC can\u2019t collect the attestations the facility will be deleted in 90 days.","title":"Facility approval example 2"},{"location":"committee/admin/approval-guidelines/#facility-approval-example-3","text":"A Facility owner is a PeeringDB user and wishes to add its facility to PeeringDB using the \u201cSuggest a Facility\u201d function. The building owner is leasing suites to carriers in the basement of his facility, but primarily focuses on leasing office space. The building has a webpage, but data center/interconnection services are not listed on the webpage. The building owner has provided a list of four carriers who have leased space in the building. Validation Process The building owner can add webpage showing that they provide interconnection services. The attestation process can be used to demonstrate the building is used for interconnection.","title":"Facility approval example 3"},{"location":"committee/admin/approval-guidelines/#facility-approval-example-4","text":"An existing facility operator with other facilities listed in PeeringDB submits a new facility that does not yet have any customers. Validation Process None - The facility should be immediately added. After the Facility object has been added, networks and IXPs can indicate their presence.","title":"Facility approval example 4"},{"location":"committee/admin/approval-guidelines/#exception-process","text":"We know that these guidelines will need to be improved and updated as we learn, so we have built in an \u201cexception\u201d process to help with that. Whenever an easy path is not possible, the requester can ask for more review of their registration request. The first step in this process is to get input from all the volunteers on the Admin Committee. If more eyes are needed, the request can be shared with all of PeeringDB\u2019s Stewards, a group made from the committee chairs and board members. Where a formal decision is needed, the board can vote on a request and make a final decision.","title":"Exception process"},{"location":"committee/admin/approval-guidelines/#flowchart_2","text":"","title":"Flowchart"},{"location":"committee/admin/approval-guidelines/#appendix","text":"","title":"Appendix"},{"location":"committee/admin/approval-guidelines/#why-must-peering-lans-be-between-27-and-19-ipv4-and-not-shorter-than-64-ipv6","text":"This limit is intended to reduce the likelihood of a typo that goes undetected and causes operational issues. Where a peering LAN uses a /28 or a /18 (IPv4) the Admin Committee can manually process the prefix after verifying its prefix length is correct. The technical standards do not allow LANs to have prefixes shorter than a /64, so a /63 would be rejected to avoid causing operational issues to operator equipment that is standards compliant.","title":"Why must peering LANs be between /27 and /19 (IPv4) and not shorter than /64 (IPv6)?"},{"location":"committee/admin/charter/","text":"PeeringDB Admin Committee Charter Approved by Board July 9th, 2020 Scope The PeeringDB Admin Committee (AC) is responsible for the day to day end-user support of PeeringDB. The Admin Committee functions as the first point of contact for any inquiries to PeeringDB. The Admin Committee produces definitions for enhancements to the workflow and Admin GUI and works with the Product Committee to plan a coherent roadmap for the PeeringDB software. Out of scope Work covered in the charter of the Operations, Outreach, Product, and further to be established Committees Deliverables Take care of support tickets, the Admin Committee strives to answer tickets within 24 hours Gather input from end-users regarding the improvement of PeeringDB in terms of bugs and product features and channel them towards the Product Committee via GitHub Improve PeeringDB Admin GUI to help expedient resolution of support tickets Collaboration The Admin Committee works with other PeeringDB committees to ensure an equitable division of development resources in recognition of the volunteer efforts that are ensuring the daily operations. Participation The PeeringDB Admin Committee members serve a one-year renewable term. Volunteers can submit their candidacy to the Admin Committee Chair. The Chair and Vice Chair will choose a new Admin Committee member at any time they see the necessity to ensure the continuity of the Admin Committee. There is a trial period of one month. New members are onboarded by a more experienced committee member (WebEx / Google Hangouts / 3 example tickets). After the trial period appointment is confirmed by the Chair and Vice Chair for one year. Expectations Individual committee members should do their fair share of tickets measured over a month If a committee member is away for an extended period of time, inform the Chair, Vice Chair, and a notification sent to the Admin Committee mailing list One month probation where they get taught/mentored by an experienced admin, and where if they do not do the work, they get booted Chairs perform a quarterly review. If you don't meet a fair portion of the work you'll be nudged. Also, three months of inactivity is an automatic ejection Communication Questions and suggestions for the Admin Committee can be sent to the Admincom Mailing List On- and de-boarding is handled via the Admincom GitHub All other issues, also for Admin GUI bugs and features must go to the regular GitHub Any support questions should be directed to the Support Address Admin Committee uses slack and emails for internal communication Regular (4-6 week interval) conference calls are used to stay synced and discuss issues Decision policy Admin Committee members will decide on their own when handling support tickets according to the Admin Committee BCP laid out in the Admin Committee How-To Folder. Otherwise, they will decide by simple majority vote on contested issues called by the Admin Committee Chair. If there is a tie the Chair's vote is counted double. Workflow Admincom uses DeskPRO and GitHub as well as direct communication with the main service contractor 20C to achieve its deliverables. In communicating with 3rd parties the Admin Committee should be kept in the loop if the issue is of general interest. PeeringDB Common Committee Charter Provisions: Dispute resolution If the committee handles an issue in a manner in which a user believes that their view has not been adequately considered, their first action should be to raise the concern with the Committee Chair for further consideration. If the dispute is between the user and the Committee Chair then the issue may alternatively be raised with the Committee Vice Chair. If the dispute cannot be resolved the matter may be brought forward to the PeeringDB Board. The decision by the PeeringDB Board shall be final. Committee Chair and Vice Chair The committee elects their Chair and Vice Chair from among their members, subject to PeeringDB Board approval. The Chair and Vice Chair work as a team and distribute the workload between themselves as they deem appropriate. Decisions should be unanimous, however the final decision on any matter is with the Chair. In case the Chair becomes unavailable, the Vice Chair may assume the position of Acting Chair. If the Chair or Vice Chair become permanently unavailable, replacement(s) are elected from the remaining committee members, subject to PeeringDB Board approval.","title":"Charter"},{"location":"committee/admin/charter/#peeringdb-admin-committee-charter","text":"Approved by Board July 9th, 2020","title":"PeeringDB Admin Committee Charter"},{"location":"committee/admin/charter/#scope","text":"The PeeringDB Admin Committee (AC) is responsible for the day to day end-user support of PeeringDB. The Admin Committee functions as the first point of contact for any inquiries to PeeringDB. The Admin Committee produces definitions for enhancements to the workflow and Admin GUI and works with the Product Committee to plan a coherent roadmap for the PeeringDB software.","title":"Scope"},{"location":"committee/admin/charter/#out-of-scope","text":"Work covered in the charter of the Operations, Outreach, Product, and further to be established Committees","title":"Out of scope"},{"location":"committee/admin/charter/#deliverables","text":"Take care of support tickets, the Admin Committee strives to answer tickets within 24 hours Gather input from end-users regarding the improvement of PeeringDB in terms of bugs and product features and channel them towards the Product Committee via GitHub Improve PeeringDB Admin GUI to help expedient resolution of support tickets","title":"Deliverables"},{"location":"committee/admin/charter/#collaboration","text":"The Admin Committee works with other PeeringDB committees to ensure an equitable division of development resources in recognition of the volunteer efforts that are ensuring the daily operations.","title":"Collaboration"},{"location":"committee/admin/charter/#participation","text":"The PeeringDB Admin Committee members serve a one-year renewable term. Volunteers can submit their candidacy to the Admin Committee Chair. The Chair and Vice Chair will choose a new Admin Committee member at any time they see the necessity to ensure the continuity of the Admin Committee. There is a trial period of one month. New members are onboarded by a more experienced committee member (WebEx / Google Hangouts / 3 example tickets). After the trial period appointment is confirmed by the Chair and Vice Chair for one year.","title":"Participation"},{"location":"committee/admin/charter/#expectations","text":"Individual committee members should do their fair share of tickets measured over a month If a committee member is away for an extended period of time, inform the Chair, Vice Chair, and a notification sent to the Admin Committee mailing list One month probation where they get taught/mentored by an experienced admin, and where if they do not do the work, they get booted Chairs perform a quarterly review. If you don't meet a fair portion of the work you'll be nudged. Also, three months of inactivity is an automatic ejection","title":"Expectations"},{"location":"committee/admin/charter/#communication","text":"Questions and suggestions for the Admin Committee can be sent to the Admincom Mailing List On- and de-boarding is handled via the Admincom GitHub All other issues, also for Admin GUI bugs and features must go to the regular GitHub Any support questions should be directed to the Support Address Admin Committee uses slack and emails for internal communication Regular (4-6 week interval) conference calls are used to stay synced and discuss issues","title":"Communication"},{"location":"committee/admin/charter/#decision-policy","text":"Admin Committee members will decide on their own when handling support tickets according to the Admin Committee BCP laid out in the Admin Committee How-To Folder. Otherwise, they will decide by simple majority vote on contested issues called by the Admin Committee Chair. If there is a tie the Chair's vote is counted double.","title":"Decision policy"},{"location":"committee/admin/charter/#workflow","text":"Admincom uses DeskPRO and GitHub as well as direct communication with the main service contractor 20C to achieve its deliverables. In communicating with 3rd parties the Admin Committee should be kept in the loop if the issue is of general interest. PeeringDB Common Committee Charter Provisions:","title":"Workflow"},{"location":"committee/admin/charter/#dispute-resolution","text":"If the committee handles an issue in a manner in which a user believes that their view has not been adequately considered, their first action should be to raise the concern with the Committee Chair for further consideration. If the dispute is between the user and the Committee Chair then the issue may alternatively be raised with the Committee Vice Chair. If the dispute cannot be resolved the matter may be brought forward to the PeeringDB Board. The decision by the PeeringDB Board shall be final.","title":"Dispute resolution"},{"location":"committee/admin/charter/#committee-chair-and-vice-chair","text":"The committee elects their Chair and Vice Chair from among their members, subject to PeeringDB Board approval. The Chair and Vice Chair work as a team and distribute the workload between themselves as they deem appropriate. Decisions should be unanimous, however the final decision on any matter is with the Chair. In case the Chair becomes unavailable, the Vice Chair may assume the position of Acting Chair. If the Chair or Vice Chair become permanently unavailable, replacement(s) are elected from the remaining committee members, subject to PeeringDB Board approval.","title":"Committee Chair and Vice Chair"},{"location":"committee/outreach/","text":"PeeringDB Outreach Committee Purpose is to coordinate outreach and evangelism in the community. Interested in volunteering? Contact outreachcom@lists.peeringdb.com . PeeringDB Outreach Committee Charter Approved by Board July 9th, 2020 Scope The PeeringDB Outreach Committee (OC) is charged with the marketing efforts and running the organization's external engagement to continuously improve the value that PeeringDB delivers to the organizations registered with PeeringDB, and the broader community. Out of scope The OC Committee does not work on other areas, such as product development, as these are managed by the other respective committees and defined in their respective charters. Deliverables Gather inputs from the other respective PeeringDB committees on developments and significant updates and ensure these are communicated the community Coordinate with partner committees and prepare presentations with relevant PeeringDB updates Identify and attend relevant community events to publicize PeeringDB developments and engage the community to drive additional records to be created Identify marketing opportunities for relevant PeeringDB activities Share key milestones and engage with the community through social media channels Participation The PeeringDB Outreach Committee members serve a one-year renewable term. Volunteers can submit their candidacy to the Outreach Committee Chair. The Chair and Vice Chair will choose a new Outreach Committee member at any time they see the necessity to ensure the continuity of the Outreach Committee. Communication Questions and suggestions for the Outreach Committee can be sent to outreachcom@lists.peeringdb.com Decision policy Outreach Committee members will decide by simple majority vote on contested issues called by the Outreach Committee Chair. PeeringDB Common Committee Charter Provisions: Dispute resolution If the committee handles an issue in a manner in which a user believes that their view has not been adequately considered, their first action should be to raise the concern with the Committee Chair for further consideration. If the dispute is between the user and the Committee Chair then the issue may alternatively be raised with the Committee Vice Chair. If the dispute cannot be resolved the matter may be brought forward to the PeeringDB Board. The decision by the PeeringDB Board shall be final. Committee Chair and Vice Chair The committee elects their Chair and Vice Chair from among their members, subject to PeeringDB Board approval. The Chair and Vice Chair work as a team and distribute the workload between themselves as they deem appropriate. Decisions should be unanimous, however the final decision on any matter is with the Chair. In case the Chair becomes unavailable, the Vice Chair may assume the position of Acting Chair. If the Chair or Vice Chair become permanently unavailable, replacement(s) are elected from the remaining committee members, subject to PeeringDB Board approval. Meeting notes 2024 October 9th, 2024: Meeting Notes September 19th, 2024: Meeting Notes August 13th, 2024: Meeting Notes July 9th, 2024: Meeting Notes June 17th, 2024: Meeting Notes May 14th, 2024: Meeting Notes April 9th, 2024: Meeting Notes 2021 No formal meeting in December 2021 November 2nd, 2021: Meeting Notes October 5th, 2021: Meeting Notes September 7th, 2021: Meeting Notes No formal meeting in August 2021 July 6th, 2021: Meeting Notes June 1st, 2021: Meeting Notes May 5th, 2021: Meeting Notes April 6th, 2021: Meeting Notes March 1st, 2021: Meeting Notes February 8th, 2021: Meeting Notes January 12th, 2021: Meeting Notes 2020 No formal meeting in December 2020 November 12th, 2020: Meeting Notes No formal meeting in October 2020 No formal meeting in September 2020 August 4th, 2020: Meeting Notes July 7th, 2020: Meeting Notes June 2nd, 2020: Meeting Notes May 7th, 2020: Meeting Notes April 7th, 2020: Meeting Notes March 17th, 2020: Meeting Notes February 4th, 2020: Meeting Notes January 7th, 2020: Meeting Notes 2019 December 3rd, 2019: Meeting Notes Members Obinna Adumike Lynsey Buckingham Yana Glaub Greg Hankins Aaron Hughes - Board Liaison Tarryn Kidd Livio Morina Arnold Nipper Ester Paal Ben Ryall - Chair Leo Vegoda - Product Manager","title":"Outreach Committee"},{"location":"committee/outreach/#peeringdb-outreach-committee","text":"Purpose is to coordinate outreach and evangelism in the community. Interested in volunteering? Contact outreachcom@lists.peeringdb.com .","title":"PeeringDB Outreach Committee"},{"location":"committee/outreach/#peeringdb-outreach-committee-charter","text":"Approved by Board July 9th, 2020","title":"PeeringDB Outreach Committee Charter"},{"location":"committee/outreach/#scope","text":"The PeeringDB Outreach Committee (OC) is charged with the marketing efforts and running the organization's external engagement to continuously improve the value that PeeringDB delivers to the organizations registered with PeeringDB, and the broader community.","title":"Scope"},{"location":"committee/outreach/#out-of-scope","text":"The OC Committee does not work on other areas, such as product development, as these are managed by the other respective committees and defined in their respective charters.","title":"Out of scope"},{"location":"committee/outreach/#deliverables","text":"Gather inputs from the other respective PeeringDB committees on developments and significant updates and ensure these are communicated the community Coordinate with partner committees and prepare presentations with relevant PeeringDB updates Identify and attend relevant community events to publicize PeeringDB developments and engage the community to drive additional records to be created Identify marketing opportunities for relevant PeeringDB activities Share key milestones and engage with the community through social media channels","title":"Deliverables"},{"location":"committee/outreach/#participation","text":"The PeeringDB Outreach Committee members serve a one-year renewable term. Volunteers can submit their candidacy to the Outreach Committee Chair. The Chair and Vice Chair will choose a new Outreach Committee member at any time they see the necessity to ensure the continuity of the Outreach Committee.","title":"Participation"},{"location":"committee/outreach/#communication","text":"Questions and suggestions for the Outreach Committee can be sent to outreachcom@lists.peeringdb.com","title":"Communication"},{"location":"committee/outreach/#decision-policy","text":"Outreach Committee members will decide by simple majority vote on contested issues called by the Outreach Committee Chair. PeeringDB Common Committee Charter Provisions:","title":"Decision policy"},{"location":"committee/outreach/#dispute-resolution","text":"If the committee handles an issue in a manner in which a user believes that their view has not been adequately considered, their first action should be to raise the concern with the Committee Chair for further consideration. If the dispute is between the user and the Committee Chair then the issue may alternatively be raised with the Committee Vice Chair. If the dispute cannot be resolved the matter may be brought forward to the PeeringDB Board. The decision by the PeeringDB Board shall be final.","title":"Dispute resolution"},{"location":"committee/outreach/#committee-chair-and-vice-chair","text":"The committee elects their Chair and Vice Chair from among their members, subject to PeeringDB Board approval. The Chair and Vice Chair work as a team and distribute the workload between themselves as they deem appropriate. Decisions should be unanimous, however the final decision on any matter is with the Chair. In case the Chair becomes unavailable, the Vice Chair may assume the position of Acting Chair. If the Chair or Vice Chair become permanently unavailable, replacement(s) are elected from the remaining committee members, subject to PeeringDB Board approval.","title":"Committee Chair and Vice Chair"},{"location":"committee/outreach/#meeting-notes","text":"","title":"Meeting notes"},{"location":"committee/outreach/#2024","text":"October 9th, 2024: Meeting Notes September 19th, 2024: Meeting Notes August 13th, 2024: Meeting Notes July 9th, 2024: Meeting Notes June 17th, 2024: Meeting Notes May 14th, 2024: Meeting Notes April 9th, 2024: Meeting Notes","title":"2024"},{"location":"committee/outreach/#2021","text":"No formal meeting in December 2021 November 2nd, 2021: Meeting Notes October 5th, 2021: Meeting Notes September 7th, 2021: Meeting Notes No formal meeting in August 2021 July 6th, 2021: Meeting Notes June 1st, 2021: Meeting Notes May 5th, 2021: Meeting Notes April 6th, 2021: Meeting Notes March 1st, 2021: Meeting Notes February 8th, 2021: Meeting Notes January 12th, 2021: Meeting Notes","title":"2021"},{"location":"committee/outreach/#2020","text":"No formal meeting in December 2020 November 12th, 2020: Meeting Notes No formal meeting in October 2020 No formal meeting in September 2020 August 4th, 2020: Meeting Notes July 7th, 2020: Meeting Notes June 2nd, 2020: Meeting Notes May 7th, 2020: Meeting Notes April 7th, 2020: Meeting Notes March 17th, 2020: Meeting Notes February 4th, 2020: Meeting Notes January 7th, 2020: Meeting Notes","title":"2020"},{"location":"committee/outreach/#2019","text":"December 3rd, 2019: Meeting Notes","title":"2019"},{"location":"committee/outreach/#members","text":"Obinna Adumike Lynsey Buckingham Yana Glaub Greg Hankins Aaron Hughes - Board Liaison Tarryn Kidd Livio Morina Arnold Nipper Ester Paal Ben Ryall - Chair Leo Vegoda - Product Manager","title":"Members"},{"location":"committee/outreach/charter/","text":"PeeringDB Outreach Committee Charter Approved by Board July 9th, 2020 Scope The PeeringDB Outreach Committee (OC) is charged with the marketing efforts and running the organization's external engagement to continuously improve the value that PeeringDB delivers to the organizations registered with PeeringDB, and the broader community. Out of scope The OC Committee does not work on other areas, such as product development, as these are managed by the other respective committees and defined in their respective charters. Deliverables Gather inputs from the other respective PeeringDB committees on developments and significant updates and ensure these are communicated the community Coordinate with partner committees and prepare presentations with relevant PeeringDB updates Identify and attend relevant community events to publicize PeeringDB developments and engage the community to drive additional records to be created Identify marketing opportunities for relevant PeeringDB activities Share key milestones and engage with the community through social media channels Participation The PeeringDB Outreach Committee members serve a one-year renewable term. Volunteers can submit their candidacy to the Outreach Committee Chair. The Chair and Vice Chair will choose a new Outreach Committee member at any time they see the necessity to ensure the continuity of the Outreach Committee. Communication Questions and suggestions for the Outreach Committee can be sent to outreachcom@lists.peeringdb.com Decision policy Outreach Committee members will decide by simple majority vote on contested issues called by the Outreach Committee Chair. PeeringDB Common Committee Charter Provisions: Dispute resolution If the committee handles an issue in a manner in which a user believes that their view has not been adequately considered, their first action should be to raise the concern with the Committee Chair for further consideration. If the dispute is between the user and the Committee Chair then the issue may alternatively be raised with the Committee Vice Chair. If the dispute cannot be resolved the matter may be brought forward to the PeeringDB Board. The decision by the PeeringDB Board shall be final. Committee Chair and Vice Chair The committee elects their Chair and Vice Chair from among their members, subject to PeeringDB Board approval. The Chair and Vice Chair work as a team and distribute the workload between themselves as they deem appropriate. Decisions should be unanimous, however the final decision on any matter is with the Chair. In case the Chair becomes unavailable, the Vice Chair may assume the position of Acting Chair. If the Chair or Vice Chair become permanently unavailable, replacement(s) are elected from the remaining committee members, subject to PeeringDB Board approval.","title":"Charter"},{"location":"committee/outreach/charter/#peeringdb-outreach-committee-charter","text":"Approved by Board July 9th, 2020","title":"PeeringDB Outreach Committee Charter"},{"location":"committee/outreach/charter/#scope","text":"The PeeringDB Outreach Committee (OC) is charged with the marketing efforts and running the organization's external engagement to continuously improve the value that PeeringDB delivers to the organizations registered with PeeringDB, and the broader community.","title":"Scope"},{"location":"committee/outreach/charter/#out-of-scope","text":"The OC Committee does not work on other areas, such as product development, as these are managed by the other respective committees and defined in their respective charters.","title":"Out of scope"},{"location":"committee/outreach/charter/#deliverables","text":"Gather inputs from the other respective PeeringDB committees on developments and significant updates and ensure these are communicated the community Coordinate with partner committees and prepare presentations with relevant PeeringDB updates Identify and attend relevant community events to publicize PeeringDB developments and engage the community to drive additional records to be created Identify marketing opportunities for relevant PeeringDB activities Share key milestones and engage with the community through social media channels","title":"Deliverables"},{"location":"committee/outreach/charter/#participation","text":"The PeeringDB Outreach Committee members serve a one-year renewable term. Volunteers can submit their candidacy to the Outreach Committee Chair. The Chair and Vice Chair will choose a new Outreach Committee member at any time they see the necessity to ensure the continuity of the Outreach Committee.","title":"Participation"},{"location":"committee/outreach/charter/#communication","text":"Questions and suggestions for the Outreach Committee can be sent to outreachcom@lists.peeringdb.com","title":"Communication"},{"location":"committee/outreach/charter/#decision-policy","text":"Outreach Committee members will decide by simple majority vote on contested issues called by the Outreach Committee Chair. PeeringDB Common Committee Charter Provisions:","title":"Decision policy"},{"location":"committee/outreach/charter/#dispute-resolution","text":"If the committee handles an issue in a manner in which a user believes that their view has not been adequately considered, their first action should be to raise the concern with the Committee Chair for further consideration. If the dispute is between the user and the Committee Chair then the issue may alternatively be raised with the Committee Vice Chair. If the dispute cannot be resolved the matter may be brought forward to the PeeringDB Board. The decision by the PeeringDB Board shall be final.","title":"Dispute resolution"},{"location":"committee/outreach/charter/#committee-chair-and-vice-chair","text":"The committee elects their Chair and Vice Chair from among their members, subject to PeeringDB Board approval. The Chair and Vice Chair work as a team and distribute the workload between themselves as they deem appropriate. Decisions should be unanimous, however the final decision on any matter is with the Chair. In case the Chair becomes unavailable, the Vice Chair may assume the position of Acting Chair. If the Chair or Vice Chair become permanently unavailable, replacement(s) are elected from the remaining committee members, subject to PeeringDB Board approval.","title":"Committee Chair and Vice Chair"},{"location":"committee/product/","text":"PeeringDB Product Committee Purpose is to study and recommend feature needs. Interested in volunteering? Contact productcom@lists.peeringdb.com . PeeringDB Product Committee Charter Approved by Board July 7th, 2017 Scope The PeeringDB Product Committee (PC) is charged with steering the future product development and running the market outreach efforts to continuously improve the value that PeeringDB delivers to the networks registered with PeeringDB, and the broader community. Out of scope The PC does not drive PeeringDB improvements related to the administrative interfaces & functions used by the PeeringDB Admin Committee. The PC does not consider PeeringDB improvements related to the server, storage, hosting or network infrastructure. Deliverables Gather inputs from stakeholders regarding the evolution of PeeringDB in terms of product features and overall long term objectives. Formulate the long term objectives and validate them with the PeeringDB Board and the members of the PeeringDB Governance mailing list. Document and maintain workflow process to handle requests and issues. Maintain the product roadmap and feature request backlog and makes them publicly accessible. Create and maintain PeeringDB product documentation and presentation materials. Develop market outreach and evangelization to increase the uptake of PeeringDB use and improve data quality. Propose new features or enhancements based on the long term objectives and validates significant product evolutions with key stakeholders. Collaboration The PC shall work with other PeeringDB committees to ensure an equitable division of development resources in recognition of the volunteer efforts that are ensuring the daily operations. Participation The PeeringDB Product Committee members serve a 2 years renewable term, potential volunteers may submit their candidacy to the PeeringDB Board. The product committee will select their own Chair and Vice Chair by simple majority vote. The Board may add or remove members at any time it deems necessary. Communication Questions and suggestions for the Product Committee can be sent to productcom@lists.peeringdb.com The committee will use a range of mechanisms for communication and community input gathering efforts, including the PeeringDB Governance Mailinglist pdb-gov@lists.peeringdb.com Decisions, including their rationale, will be documented in GitHub issues All issues and the product roadmap and feature backlog can be found at in GitHub issues Decision policy Product Committee members will decide by simple majority vote on contested issues called by the Product Committee Chair. PeeringDB Common Committee Charter Provisions: Dispute resolution If the committee handles an issue in a manner in which a user believes that their view has not been adequately considered, their first action should be to raise the concern with the Committee Chair for further consideration. If the dispute is between the user and the Committee Chair then the issue may alternatively be raised with the Committee Vice Chair. If the dispute cannot be resolved the matter may be brought forward to the PeeringDB Board. The decision by the PeeringDB Board shall be final. Committee Chair and Vice Chair The committee elects their Chair and Vice Chair from among their members, subject to PeeringDB Board approval. The Chair and Vice Chair work as a team and distribute the workload between themselves as they deem appropriate. Decisions should be unanimous, however the final decision on any matter is with the Chair. In case the Chair becomes unavailable, the Vice Chair may assume the position of Acting Chair. If the Chair or Vice Chair become permanently unavailable, replacement(s) are elected from the remaining committee members, subject to PeeringDB Board approval. Decision making process and workflow Product Committee members are responsible for driving the development of PeeringDB. To do this, GitHub issues are used to track proposed and in progress work. Product Committee members play two roles in driving forward work: 1) As a shepherd - responsible for driving consensus for a given issue 2) As a stakeholder - voting on a consensus that has been reached Each Product Committee member will choose issues to shepherd to a decision. They will indicate responsibility for this task by assigning the issue to themselves and placing it in the Decide queue. To decide whether we act on a given issue that has been reported, a stakeholder group will be formed. This group will consist of Product Committee members, who are responsible for representing the users of PeeringDB. A stakeholder group on a given issue must consist of at least three Product Committee members, including the shepherding member. Any Product Committee member can be a stakeholder in the decision on an issue. They become a stakeholder on a given issue by either commenting on the issue on GitHub or participating in discussion of the issue on the Product Committee Mailing list. It is up to the shepherding member to help reach a unanimous consensus within the stakeholder group on what should be done with the issue - including not acting on it. If and only if there are opposing views on how to proceed, and unanimous consensus cannot be reached by the stakeholder committee members, decisions fall to the entire Product Committee (see below). The final proposal of how to resolve each issue, along with votes from stakeholders must be documented in the GitHub issue to be considered to have reached consensus. Product Committee members must document any offline discussion in the GitHub issue to ensure transparency of the discussion process. Issues in the Decide queue are regularly reviewed by the Product Committee to make sure the most impactful issues are being moved along to resolution. All issues in the Decide queue will be reviewed in the monthly Product Committee call to ensure stakeholders have reached consensus and to give members who have not participated in the issue an opportunity to participate. After an issue with consensus has been reviewed, Product Committee members who disagree with the proposal have five days after the monthly Product Committee call to vote against the proposed solution, otherwise the issue will move to the backlog. For any issues where consensus cannot be reached, an issue may move forward only if a quorum of 50% or more of the Product Committee has no more than 25% of the quorum in opposition to the issue. Meeting notes 2024 November 7th, 2024: Meeting Notes October 3rd, 2024: Meeting Notes September 5th, 2024: Meeting Notes August 1st, 2024: Meeting Notes July 11th, 2024: Meeting Notes June 6th, 2024: Meeting Notes May 2nd, 2024: Meeting Notes April 4th, 2024: Meeting Notes March 14th, 2024: Meeting Notes February 1st, 2024: Meeting Notes January 4th, 2024: Meeting Notes 2023 December 7th, 2023: Meeting Notes November 2nd, 2023: Meeting Notes October 5th, 2023: Meeting Notes September 7th, 2023: Meeting Notes August 3rd, 2023: Meeting Notes July 6th, 2023: Meeting Notes June 1st, 2023: Meeting Notes May 4th, 2023: Meeting Notes April 6th, 2023: Meeting Notes March 2nd, 2023: Meeting Notes February 14th, 2023: Meeting Notes February 2nd, 2023: Meeting Notes January 5th, 2023: Meeting Notes 2022 No formal meeting in December 2022 November 3rd, 2022: Meeting Notes October 17th, 2022: Meeting Notes October 6th, 2022: Meeting Notes September 8th, 2022: Meeting Notes August 4th, 2022: Meeting Notes July 7th, 2022: Meeting Notes June 2nd, 2022: Meeting Notes May 5th, 2022: Meeting Notes April 7th, 2022: Meeting Notes March 3rd, 2022: Meeting Notes February 3rd, 2022: Meeting Notes January 6th, 2022: Meeting Notes 2021 December 2nd, 2021: Meeting Notes No formal meeting in November 2021 October 7th, 2021: Meeting Notes No formal meeting in September 2021 No formal meeting in August 2021 No formal meeting in July 2021 No formal meeting in June 2021 May 6th, 2021: Meeting Notes April 1st, 2021: Meeting Notes March 11th, 2021: Meeting Notes February 4th, 2021: Meeting Notes January 7th, 2021: Meeting Notes 2020 December 3rd, 2020: Meeting Notes November 5th, 2020: Meeting Notes October 1st, 2020: Meeting Notes September 3rd, 2020: Meeting Notes August 6th, 2020: Meeting Notes July 2nd, 2020: Meeting Notes June 4th, 2020: Meeting Notes May 7th, 2020: Meeting Notes April 2nd, 2020: Meeting Notes No formal meeting in March 2020 February 6th, 2020: Meeting Notes January 9th, 2020: Meeting Notes 2019 No formal meeting in December 2019 November 14th, 2019: Meeting Notes October 3rd, 2019: Meeting Notes September 5th, 2019: Meeting Notes August 8th, 2019: Meeting Notes July 11th, 2019: Meeting Notes June 7th, 2019: Meeting Notes May 2nd, 2019: Meeting Notes No formal meeting in April 2019 March 7th, 2019: Meeting Notes February 7th, 2019: Meeting Notes January 3rd, 2019: Meeting Notes 2018 December 6th, 2018: Meeting Notes November 1st, 2018: Meeting Notes October 4th, 2018: Meeting Notes September 6th, 2018: Meeting Notes No formal meeting in August 2018 July 5th, 2018: Meeting Notes June 7th, 2018: Meeting Notes No formal meeting in May 2018 April 5th, 2018: Meeting Notes March 14th, 2018: Meeting Notes No formal meeting in February 2018 January 4th, 2018: Meeting Notes 2017 December 7th, 2017: Meeting Notes No formal meeting in November 2017 October 12th, 2017: Meeting Notes No formal meeting in September 2017 August 3rd, 2017: Meeting Notes July 6th, 2017: Meeting Notes June 1st, 2017: Meeting Notes No formal meeting in May 2017 April 13th, 2017: Meeting Notes March 21st, 2017: Meeting Notes Members Jeff Bartig Yan Berthier Jack Carrozzo - Chair Yolandi Cloete Matt Griswold - Vice Chair Martin Hannigan Peter Helmenstine Paul Hoogsteder Aaron Hughes - Board Liaison Laurent Jarbinet Stephen McManus Arnold Nipper Terry Sweetser Leo Vegoda - Product Manager","title":"Product Committee"},{"location":"committee/product/#peeringdb-product-committee","text":"Purpose is to study and recommend feature needs. Interested in volunteering? Contact productcom@lists.peeringdb.com .","title":"PeeringDB Product Committee"},{"location":"committee/product/#peeringdb-product-committee-charter","text":"Approved by Board July 7th, 2017","title":"PeeringDB Product Committee Charter"},{"location":"committee/product/#scope","text":"The PeeringDB Product Committee (PC) is charged with steering the future product development and running the market outreach efforts to continuously improve the value that PeeringDB delivers to the networks registered with PeeringDB, and the broader community.","title":"Scope"},{"location":"committee/product/#out-of-scope","text":"The PC does not drive PeeringDB improvements related to the administrative interfaces & functions used by the PeeringDB Admin Committee. The PC does not consider PeeringDB improvements related to the server, storage, hosting or network infrastructure.","title":"Out of scope"},{"location":"committee/product/#deliverables","text":"Gather inputs from stakeholders regarding the evolution of PeeringDB in terms of product features and overall long term objectives. Formulate the long term objectives and validate them with the PeeringDB Board and the members of the PeeringDB Governance mailing list. Document and maintain workflow process to handle requests and issues. Maintain the product roadmap and feature request backlog and makes them publicly accessible. Create and maintain PeeringDB product documentation and presentation materials. Develop market outreach and evangelization to increase the uptake of PeeringDB use and improve data quality. Propose new features or enhancements based on the long term objectives and validates significant product evolutions with key stakeholders.","title":"Deliverables"},{"location":"committee/product/#collaboration","text":"The PC shall work with other PeeringDB committees to ensure an equitable division of development resources in recognition of the volunteer efforts that are ensuring the daily operations.","title":"Collaboration"},{"location":"committee/product/#participation","text":"The PeeringDB Product Committee members serve a 2 years renewable term, potential volunteers may submit their candidacy to the PeeringDB Board. The product committee will select their own Chair and Vice Chair by simple majority vote. The Board may add or remove members at any time it deems necessary.","title":"Participation"},{"location":"committee/product/#communication","text":"Questions and suggestions for the Product Committee can be sent to productcom@lists.peeringdb.com The committee will use a range of mechanisms for communication and community input gathering efforts, including the PeeringDB Governance Mailinglist pdb-gov@lists.peeringdb.com Decisions, including their rationale, will be documented in GitHub issues All issues and the product roadmap and feature backlog can be found at in GitHub issues","title":"Communication"},{"location":"committee/product/#decision-policy","text":"Product Committee members will decide by simple majority vote on contested issues called by the Product Committee Chair. PeeringDB Common Committee Charter Provisions:","title":"Decision policy"},{"location":"committee/product/#dispute-resolution","text":"If the committee handles an issue in a manner in which a user believes that their view has not been adequately considered, their first action should be to raise the concern with the Committee Chair for further consideration. If the dispute is between the user and the Committee Chair then the issue may alternatively be raised with the Committee Vice Chair. If the dispute cannot be resolved the matter may be brought forward to the PeeringDB Board. The decision by the PeeringDB Board shall be final.","title":"Dispute resolution"},{"location":"committee/product/#committee-chair-and-vice-chair","text":"The committee elects their Chair and Vice Chair from among their members, subject to PeeringDB Board approval. The Chair and Vice Chair work as a team and distribute the workload between themselves as they deem appropriate. Decisions should be unanimous, however the final decision on any matter is with the Chair. In case the Chair becomes unavailable, the Vice Chair may assume the position of Acting Chair. If the Chair or Vice Chair become permanently unavailable, replacement(s) are elected from the remaining committee members, subject to PeeringDB Board approval.","title":"Committee Chair and Vice Chair"},{"location":"committee/product/#decision-making-process-and-workflow","text":"Product Committee members are responsible for driving the development of PeeringDB. To do this, GitHub issues are used to track proposed and in progress work. Product Committee members play two roles in driving forward work: 1) As a shepherd - responsible for driving consensus for a given issue 2) As a stakeholder - voting on a consensus that has been reached Each Product Committee member will choose issues to shepherd to a decision. They will indicate responsibility for this task by assigning the issue to themselves and placing it in the Decide queue. To decide whether we act on a given issue that has been reported, a stakeholder group will be formed. This group will consist of Product Committee members, who are responsible for representing the users of PeeringDB. A stakeholder group on a given issue must consist of at least three Product Committee members, including the shepherding member. Any Product Committee member can be a stakeholder in the decision on an issue. They become a stakeholder on a given issue by either commenting on the issue on GitHub or participating in discussion of the issue on the Product Committee Mailing list. It is up to the shepherding member to help reach a unanimous consensus within the stakeholder group on what should be done with the issue - including not acting on it. If and only if there are opposing views on how to proceed, and unanimous consensus cannot be reached by the stakeholder committee members, decisions fall to the entire Product Committee (see below). The final proposal of how to resolve each issue, along with votes from stakeholders must be documented in the GitHub issue to be considered to have reached consensus. Product Committee members must document any offline discussion in the GitHub issue to ensure transparency of the discussion process. Issues in the Decide queue are regularly reviewed by the Product Committee to make sure the most impactful issues are being moved along to resolution. All issues in the Decide queue will be reviewed in the monthly Product Committee call to ensure stakeholders have reached consensus and to give members who have not participated in the issue an opportunity to participate. After an issue with consensus has been reviewed, Product Committee members who disagree with the proposal have five days after the monthly Product Committee call to vote against the proposed solution, otherwise the issue will move to the backlog. For any issues where consensus cannot be reached, an issue may move forward only if a quorum of 50% or more of the Product Committee has no more than 25% of the quorum in opposition to the issue.","title":"Decision making process and workflow"},{"location":"committee/product/#meeting-notes","text":"","title":"Meeting notes"},{"location":"committee/product/#2024","text":"November 7th, 2024: Meeting Notes October 3rd, 2024: Meeting Notes September 5th, 2024: Meeting Notes August 1st, 2024: Meeting Notes July 11th, 2024: Meeting Notes June 6th, 2024: Meeting Notes May 2nd, 2024: Meeting Notes April 4th, 2024: Meeting Notes March 14th, 2024: Meeting Notes February 1st, 2024: Meeting Notes January 4th, 2024: Meeting Notes","title":"2024"},{"location":"committee/product/#2023","text":"December 7th, 2023: Meeting Notes November 2nd, 2023: Meeting Notes October 5th, 2023: Meeting Notes September 7th, 2023: Meeting Notes August 3rd, 2023: Meeting Notes July 6th, 2023: Meeting Notes June 1st, 2023: Meeting Notes May 4th, 2023: Meeting Notes April 6th, 2023: Meeting Notes March 2nd, 2023: Meeting Notes February 14th, 2023: Meeting Notes February 2nd, 2023: Meeting Notes January 5th, 2023: Meeting Notes","title":"2023"},{"location":"committee/product/#2022","text":"No formal meeting in December 2022 November 3rd, 2022: Meeting Notes October 17th, 2022: Meeting Notes October 6th, 2022: Meeting Notes September 8th, 2022: Meeting Notes August 4th, 2022: Meeting Notes July 7th, 2022: Meeting Notes June 2nd, 2022: Meeting Notes May 5th, 2022: Meeting Notes April 7th, 2022: Meeting Notes March 3rd, 2022: Meeting Notes February 3rd, 2022: Meeting Notes January 6th, 2022: Meeting Notes","title":"2022"},{"location":"committee/product/#2021","text":"December 2nd, 2021: Meeting Notes No formal meeting in November 2021 October 7th, 2021: Meeting Notes No formal meeting in September 2021 No formal meeting in August 2021 No formal meeting in July 2021 No formal meeting in June 2021 May 6th, 2021: Meeting Notes April 1st, 2021: Meeting Notes March 11th, 2021: Meeting Notes February 4th, 2021: Meeting Notes January 7th, 2021: Meeting Notes","title":"2021"},{"location":"committee/product/#2020","text":"December 3rd, 2020: Meeting Notes November 5th, 2020: Meeting Notes October 1st, 2020: Meeting Notes September 3rd, 2020: Meeting Notes August 6th, 2020: Meeting Notes July 2nd, 2020: Meeting Notes June 4th, 2020: Meeting Notes May 7th, 2020: Meeting Notes April 2nd, 2020: Meeting Notes No formal meeting in March 2020 February 6th, 2020: Meeting Notes January 9th, 2020: Meeting Notes","title":"2020"},{"location":"committee/product/#2019","text":"No formal meeting in December 2019 November 14th, 2019: Meeting Notes October 3rd, 2019: Meeting Notes September 5th, 2019: Meeting Notes August 8th, 2019: Meeting Notes July 11th, 2019: Meeting Notes June 7th, 2019: Meeting Notes May 2nd, 2019: Meeting Notes No formal meeting in April 2019 March 7th, 2019: Meeting Notes February 7th, 2019: Meeting Notes January 3rd, 2019: Meeting Notes","title":"2019"},{"location":"committee/product/#2018","text":"December 6th, 2018: Meeting Notes November 1st, 2018: Meeting Notes October 4th, 2018: Meeting Notes September 6th, 2018: Meeting Notes No formal meeting in August 2018 July 5th, 2018: Meeting Notes June 7th, 2018: Meeting Notes No formal meeting in May 2018 April 5th, 2018: Meeting Notes March 14th, 2018: Meeting Notes No formal meeting in February 2018 January 4th, 2018: Meeting Notes","title":"2018"},{"location":"committee/product/#2017","text":"December 7th, 2017: Meeting Notes No formal meeting in November 2017 October 12th, 2017: Meeting Notes No formal meeting in September 2017 August 3rd, 2017: Meeting Notes July 6th, 2017: Meeting Notes June 1st, 2017: Meeting Notes No formal meeting in May 2017 April 13th, 2017: Meeting Notes March 21st, 2017: Meeting Notes","title":"2017"},{"location":"committee/product/#members","text":"Jeff Bartig Yan Berthier Jack Carrozzo - Chair Yolandi Cloete Matt Griswold - Vice Chair Martin Hannigan Peter Helmenstine Paul Hoogsteder Aaron Hughes - Board Liaison Laurent Jarbinet Stephen McManus Arnold Nipper Terry Sweetser Leo Vegoda - Product Manager","title":"Members"},{"location":"committee/product/charter/","text":"PeeringDB Product Committee Charter Approved by Board July 7th, 2017 Scope The PeeringDB Product Committee (PC) is charged with steering the future product development and running the market outreach efforts to continuously improve the value that PeeringDB delivers to the networks registered with PeeringDB, and the broader community. Out of scope The PC does not drive PeeringDB improvements related to the administrative interfaces & functions used by the PeeringDB Admin Committee. The PC does not consider PeeringDB improvements related to the server, storage, hosting or network infrastructure. Deliverables Gather inputs from stakeholders regarding the evolution of PeeringDB in terms of product features and overall long term objectives. Formulate the long term objectives and validate them with the PeeringDB Board and the members of the PeeringDB Governance mailing list. Document and maintain workflow process to handle requests and issues. Maintain the product roadmap and feature request backlog and makes them publicly accessible. Create and maintain PeeringDB product documentation and presentation materials. Develop market outreach and evangelization to increase the uptake of PeeringDB use and improve data quality. Propose new features or enhancements based on the long term objectives and validates significant product evolutions with key stakeholders. Collaboration The PC shall work with other PeeringDB committees to ensure an equitable division of development resources in recognition of the volunteer efforts that are ensuring the daily operations. Participation The PeeringDB Product Committee members serve a 2 years renewable term, potential volunteers may submit their candidacy to the PeeringDB Board. The product committee will select their own Chair and Vice Chair by simple majority vote. The Board may add or remove members at any time it deems necessary. Communication Questions and suggestions for the Product Committee can be sent to productcom@lists.peeringdb.com The committee will use a range of mechanisms for communication and community input gathering efforts, including the PeeringDB Governance Mailinglist pdb-gov@lists.peeringdb.com Decisions, including their rationale, will be documented in GitHub issues All issues and the product roadmap and feature backlog can be found at in GitHub issues Decision policy Product Committee members will decide by simple majority vote on contested issues called by the Product Committee Chair. PeeringDB Common Committee Charter Provisions: Dispute resolution If the committee handles an issue in a manner in which a user believes that their view has not been adequately considered, their first action should be to raise the concern with the Committee Chair for further consideration. If the dispute is between the user and the Committee Chair then the issue may alternatively be raised with the Committee Vice Chair. If the dispute cannot be resolved the matter may be brought forward to the PeeringDB Board. The decision by the PeeringDB Board shall be final. Committee Chair and Vice Chair The committee elects their Chair and Vice Chair from among their members, subject to PeeringDB Board approval. The Chair and Vice Chair work as a team and distribute the workload between themselves as they deem appropriate. Decisions should be unanimous, however the final decision on any matter is with the Chair. In case the Chair becomes unavailable, the Vice Chair may assume the position of Acting Chair. If the Chair or Vice Chair become permanently unavailable, replacement(s) are elected from the remaining committee members, subject to PeeringDB Board approval.","title":"Charter"},{"location":"committee/product/charter/#peeringdb-product-committee-charter","text":"Approved by Board July 7th, 2017","title":"PeeringDB Product Committee Charter"},{"location":"committee/product/charter/#scope","text":"The PeeringDB Product Committee (PC) is charged with steering the future product development and running the market outreach efforts to continuously improve the value that PeeringDB delivers to the networks registered with PeeringDB, and the broader community.","title":"Scope"},{"location":"committee/product/charter/#out-of-scope","text":"The PC does not drive PeeringDB improvements related to the administrative interfaces & functions used by the PeeringDB Admin Committee. The PC does not consider PeeringDB improvements related to the server, storage, hosting or network infrastructure.","title":"Out of scope"},{"location":"committee/product/charter/#deliverables","text":"Gather inputs from stakeholders regarding the evolution of PeeringDB in terms of product features and overall long term objectives. Formulate the long term objectives and validate them with the PeeringDB Board and the members of the PeeringDB Governance mailing list. Document and maintain workflow process to handle requests and issues. Maintain the product roadmap and feature request backlog and makes them publicly accessible. Create and maintain PeeringDB product documentation and presentation materials. Develop market outreach and evangelization to increase the uptake of PeeringDB use and improve data quality. Propose new features or enhancements based on the long term objectives and validates significant product evolutions with key stakeholders.","title":"Deliverables"},{"location":"committee/product/charter/#collaboration","text":"The PC shall work with other PeeringDB committees to ensure an equitable division of development resources in recognition of the volunteer efforts that are ensuring the daily operations.","title":"Collaboration"},{"location":"committee/product/charter/#participation","text":"The PeeringDB Product Committee members serve a 2 years renewable term, potential volunteers may submit their candidacy to the PeeringDB Board. The product committee will select their own Chair and Vice Chair by simple majority vote. The Board may add or remove members at any time it deems necessary.","title":"Participation"},{"location":"committee/product/charter/#communication","text":"Questions and suggestions for the Product Committee can be sent to productcom@lists.peeringdb.com The committee will use a range of mechanisms for communication and community input gathering efforts, including the PeeringDB Governance Mailinglist pdb-gov@lists.peeringdb.com Decisions, including their rationale, will be documented in GitHub issues All issues and the product roadmap and feature backlog can be found at in GitHub issues","title":"Communication"},{"location":"committee/product/charter/#decision-policy","text":"Product Committee members will decide by simple majority vote on contested issues called by the Product Committee Chair. PeeringDB Common Committee Charter Provisions:","title":"Decision policy"},{"location":"committee/product/charter/#dispute-resolution","text":"If the committee handles an issue in a manner in which a user believes that their view has not been adequately considered, their first action should be to raise the concern with the Committee Chair for further consideration. If the dispute is between the user and the Committee Chair then the issue may alternatively be raised with the Committee Vice Chair. If the dispute cannot be resolved the matter may be brought forward to the PeeringDB Board. The decision by the PeeringDB Board shall be final.","title":"Dispute resolution"},{"location":"committee/product/charter/#committee-chair-and-vice-chair","text":"The committee elects their Chair and Vice Chair from among their members, subject to PeeringDB Board approval. The Chair and Vice Chair work as a team and distribute the workload between themselves as they deem appropriate. Decisions should be unanimous, however the final decision on any matter is with the Chair. In case the Chair becomes unavailable, the Vice Chair may assume the position of Acting Chair. If the Chair or Vice Chair become permanently unavailable, replacement(s) are elected from the remaining committee members, subject to PeeringDB Board approval.","title":"Committee Chair and Vice Chair"},{"location":"committee/product/workflow/","text":"Decision making process and workflow Product Committee members are responsible for driving the development of PeeringDB. To do this, GitHub issues are used to track proposed and in progress work. Product Committee members play two roles in driving forward work: 1) As a shepherd - responsible for driving consensus for a given issue 2) As a stakeholder - voting on a consensus that has been reached Each Product Committee member will choose issues to shepherd to a decision. They will indicate responsibility for this task by assigning the issue to themselves and placing it in the Decide queue. To decide whether we act on a given issue that has been reported, a stakeholder group will be formed. This group will consist of Product Committee members, who are responsible for representing the users of PeeringDB. A stakeholder group on a given issue must consist of at least three Product Committee members, including the shepherding member. Any Product Committee member can be a stakeholder in the decision on an issue. They become a stakeholder on a given issue by either commenting on the issue on GitHub or participating in discussion of the issue on the Product Committee Mailing list. It is up to the shepherding member to help reach a unanimous consensus within the stakeholder group on what should be done with the issue - including not acting on it. If and only if there are opposing views on how to proceed, and unanimous consensus cannot be reached by the stakeholder committee members, decisions fall to the entire Product Committee (see below). The final proposal of how to resolve each issue, along with votes from stakeholders must be documented in the GitHub issue to be considered to have reached consensus. Product Committee members must document any offline discussion in the GitHub issue to ensure transparency of the discussion process. Issues in the Decide queue are regularly reviewed by the Product Committee to make sure the most impactful issues are being moved along to resolution. All issues in the Decide queue will be reviewed in the monthly Product Committee call to ensure stakeholders have reached consensus and to give members who have not participated in the issue an opportunity to participate. After an issue with consensus has been reviewed, Product Committee members who disagree with the proposal have five days after the monthly Product Committee call to vote against the proposed solution, otherwise the issue will move to the backlog. For any issues where consensus cannot be reached, an issue may move forward only if a quorum of 50% or more of the Product Committee has no more than 25% of the quorum in opposition to the issue.","title":"Workflow"},{"location":"committee/product/workflow/#decision-making-process-and-workflow","text":"Product Committee members are responsible for driving the development of PeeringDB. To do this, GitHub issues are used to track proposed and in progress work. Product Committee members play two roles in driving forward work: 1) As a shepherd - responsible for driving consensus for a given issue 2) As a stakeholder - voting on a consensus that has been reached Each Product Committee member will choose issues to shepherd to a decision. They will indicate responsibility for this task by assigning the issue to themselves and placing it in the Decide queue. To decide whether we act on a given issue that has been reported, a stakeholder group will be formed. This group will consist of Product Committee members, who are responsible for representing the users of PeeringDB. A stakeholder group on a given issue must consist of at least three Product Committee members, including the shepherding member. Any Product Committee member can be a stakeholder in the decision on an issue. They become a stakeholder on a given issue by either commenting on the issue on GitHub or participating in discussion of the issue on the Product Committee Mailing list. It is up to the shepherding member to help reach a unanimous consensus within the stakeholder group on what should be done with the issue - including not acting on it. If and only if there are opposing views on how to proceed, and unanimous consensus cannot be reached by the stakeholder committee members, decisions fall to the entire Product Committee (see below). The final proposal of how to resolve each issue, along with votes from stakeholders must be documented in the GitHub issue to be considered to have reached consensus. Product Committee members must document any offline discussion in the GitHub issue to ensure transparency of the discussion process. Issues in the Decide queue are regularly reviewed by the Product Committee to make sure the most impactful issues are being moved along to resolution. All issues in the Decide queue will be reviewed in the monthly Product Committee call to ensure stakeholders have reached consensus and to give members who have not participated in the issue an opportunity to participate. After an issue with consensus has been reviewed, Product Committee members who disagree with the proposal have five days after the monthly Product Committee call to vote against the proposed solution, otherwise the issue will move to the backlog. For any issues where consensus cannot be reached, an issue may move forward only if a quorum of 50% or more of the Product Committee has no more than 25% of the quorum in opposition to the issue.","title":"Decision making process and workflow"},{"location":"howto/api_keys/","text":"HOWTO: Get Started with API Keys 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, which prevents the database from 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. API What is our API? An Application Programming Interface (API) is a way for computer software to communicate with other computers software. Our API allows PeeringDB users to query and update PeeringDB programmatically. That means they can automate work instead of using the website. What Are API keys? An API key is a secret token for identifying and authenticating a user. That user can be an individual or an organization. That\u2019s why we support both user and organizational API keys. PeeringDB offers API keys for authenticating API requests. There are two main forms of API keys: User-level Organizational-level User-level API keys These API keys are tied to an individual user account and can be created from the user profile page. There are only two permission levels: a normal key will mirror the same permissions of the user, while a readonly key will have read only permissions to all the same namespaces as the user. Organization-level API keys These API keys are created and revoked from the organization admin panel. Each key gets its own custom permissions, which can be modified from the API Key Permissions panel. Each key must have an email attached to it. This is because keys may be allowed to create and modify data in PeeringDB, and we need a contact to reach out to in case of questions. You should use an organization-level API key for automation that should not be tied to individual users. Copy or write down keys immediately The full API key string is only ever exposed to the user or organization at its moment of creation . If this string is lost, then the user or organization should revoke that key and create and permission a new one. Command line example using Python and requests API keys allow developers to interact with their PeeringDB account programmatically, rather than through the website. Here is an example script in Python. It uses the module Requests to GET data about a particular Facility, and then sends a PUT request to modify that data. This example assumes we have an environment variable set with our API key. To do that from the command line, we can run: export API_KEY=\"[created api key string]\" Then the Python script would look like the following. First we get the API key from the environment: import os import requests API_KEY = os.environ.get(\"API_KEY\") We set the url for the Facility we want to interact with. Note the /api in the URL, which signals we are making calls to the REST API. URL = \"https://www.peeringdb.com/api/fac/1\" We set the headers to include our API key as authorization. Printing the headers variable should allow us to see the API key. headers = {\"Authorization\": \"Api-Key \" + API_KEY} print(headers) First we make a GET request, to simply get data about example Facility number 1 response = requests.get(URL, headers=headers) data = response.json()[\"data\"][0] print(data) Printing this data allows us to see what fields we would like to change. Let's say we decide to change the name of this facility. We overwrite the value for key \"name\" data[\"name\"] = \"Newly decided name\" Then we use a PUT request to send that modified data back to PeeringDB. Note that this time, we must provide data to the API, using the keyword argument \"data\" put_response = requests.put(URL, headers=headers, data=data) We can print the status code to see if our request was successful. print(put_response.status_code) This will return a code 200 to signal success. Additionally the content of the request should include data for the now modified Facility print(put_response.json()) Would return a dictionary of the values of the now modified Facility. Command line example using curl API keys provide a cleaner way to authenticate API requests. PeeringDB recommends the command line user creates a API_KEY variable like so export API_KEY=\"[created api key string]\" then requests can be made with Curl like in the following examples: GET The following request would return JSON data coresponding to the ChiX Internet Exchange. curl -H \"Authorization: Api-Key $API_KEY\" -H \"Content-Type: application/json\" -X GET https://www.peeringdb.com/api/ix/239 POST The following request would create a new Network under the organization United IX . curl -H \"Authorization: Api-Key $API_KEY\" -H \"Content-Type: application/json\" -X POST --data \"{\\\"\"org_id\"\\\":\\\"10843\\\", \\\"\"name\"\\\":\\\"Brand New Network\\\", \\\"\"asn\"\\\":\\\"63311\\\"}\" https://www.peeringdb.com/api/net PUT The following request would update the data about a particular Network, ChIX Route Servers , in particular changing the name to \"Edited Name\". curl -H \"Authorization: Api-Key $API_KEY\" -H \"Content-Type: application/json\" -X PUT --data \"{\\\"\"org_id\"\\\":\\\"10843\\\", \\\"\"name\"\\\":\\\"Edited Name\\\", \\\"\"asn\"\\\":\\\"33713\\\"}\" https://www.peeringdb.com/api/net/7889 DELETE The following request would delete the ChiX Internet Exchange. The API key holder would need delete privileges to that particular Exchange. curl -H \"Authorization: Api-Key $API_KEY\" -H \"Content-Type: application/json\" -X DELETE https://www.peeringdb.com/api/ix/239","title":"HOWTO: Get Started with API Keys"},{"location":"howto/api_keys/#howto-get-started-with-api-keys","text":"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, which prevents the database from 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.","title":"HOWTO: Get Started with API Keys"},{"location":"howto/api_keys/#api","text":"","title":"API"},{"location":"howto/api_keys/#what-is-our-api","text":"An Application Programming Interface (API) is a way for computer software to communicate with other computers software. Our API allows PeeringDB users to query and update PeeringDB programmatically. That means they can automate work instead of using the website.","title":"What is our API?"},{"location":"howto/api_keys/#what-are-api-keys","text":"An API key is a secret token for identifying and authenticating a user. That user can be an individual or an organization. That\u2019s why we support both user and organizational API keys. PeeringDB offers API keys for authenticating API requests. There are two main forms of API keys: User-level Organizational-level","title":"What Are API keys?"},{"location":"howto/api_keys/#user-level-api-keys","text":"These API keys are tied to an individual user account and can be created from the user profile page. There are only two permission levels: a normal key will mirror the same permissions of the user, while a readonly key will have read only permissions to all the same namespaces as the user.","title":"User-level API keys"},{"location":"howto/api_keys/#organization-level-api-keys","text":"These API keys are created and revoked from the organization admin panel. Each key gets its own custom permissions, which can be modified from the API Key Permissions panel. Each key must have an email attached to it. This is because keys may be allowed to create and modify data in PeeringDB, and we need a contact to reach out to in case of questions. You should use an organization-level API key for automation that should not be tied to individual users.","title":"Organization-level API keys"},{"location":"howto/api_keys/#copy-or-write-down-keys-immediately","text":"The full API key string is only ever exposed to the user or organization at its moment of creation . If this string is lost, then the user or organization should revoke that key and create and permission a new one.","title":"Copy or write down keys immediately"},{"location":"howto/api_keys/#command-line-example-using-python-and-requests","text":"API keys allow developers to interact with their PeeringDB account programmatically, rather than through the website. Here is an example script in Python. It uses the module Requests to GET data about a particular Facility, and then sends a PUT request to modify that data. This example assumes we have an environment variable set with our API key. To do that from the command line, we can run: export API_KEY=\"[created api key string]\" Then the Python script would look like the following. First we get the API key from the environment: import os import requests API_KEY = os.environ.get(\"API_KEY\") We set the url for the Facility we want to interact with. Note the /api in the URL, which signals we are making calls to the REST API. URL = \"https://www.peeringdb.com/api/fac/1\" We set the headers to include our API key as authorization. Printing the headers variable should allow us to see the API key. headers = {\"Authorization\": \"Api-Key \" + API_KEY} print(headers) First we make a GET request, to simply get data about example Facility number 1 response = requests.get(URL, headers=headers) data = response.json()[\"data\"][0] print(data) Printing this data allows us to see what fields we would like to change. Let's say we decide to change the name of this facility. We overwrite the value for key \"name\" data[\"name\"] = \"Newly decided name\" Then we use a PUT request to send that modified data back to PeeringDB. Note that this time, we must provide data to the API, using the keyword argument \"data\" put_response = requests.put(URL, headers=headers, data=data) We can print the status code to see if our request was successful. print(put_response.status_code) This will return a code 200 to signal success. Additionally the content of the request should include data for the now modified Facility print(put_response.json()) Would return a dictionary of the values of the now modified Facility.","title":"Command line example using Python and requests"},{"location":"howto/api_keys/#command-line-example-using-curl","text":"API keys provide a cleaner way to authenticate API requests. PeeringDB recommends the command line user creates a API_KEY variable like so export API_KEY=\"[created api key string]\" then requests can be made with Curl like in the following examples:","title":"Command line example using curl"},{"location":"howto/api_keys/#get","text":"The following request would return JSON data coresponding to the ChiX Internet Exchange. curl -H \"Authorization: Api-Key $API_KEY\" -H \"Content-Type: application/json\" -X GET https://www.peeringdb.com/api/ix/239","title":"GET"},{"location":"howto/api_keys/#post","text":"The following request would create a new Network under the organization United IX . curl -H \"Authorization: Api-Key $API_KEY\" -H \"Content-Type: application/json\" -X POST --data \"{\\\"\"org_id\"\\\":\\\"10843\\\", \\\"\"name\"\\\":\\\"Brand New Network\\\", \\\"\"asn\"\\\":\\\"63311\\\"}\" https://www.peeringdb.com/api/net","title":"POST"},{"location":"howto/api_keys/#put","text":"The following request would update the data about a particular Network, ChIX Route Servers , in particular changing the name to \"Edited Name\". curl -H \"Authorization: Api-Key $API_KEY\" -H \"Content-Type: application/json\" -X PUT --data \"{\\\"\"org_id\"\\\":\\\"10843\\\", \\\"\"name\"\\\":\\\"Edited Name\\\", \\\"\"asn\"\\\":\\\"33713\\\"}\" https://www.peeringdb.com/api/net/7889","title":"PUT"},{"location":"howto/api_keys/#delete","text":"The following request would delete the ChiX Internet Exchange. The API key holder would need delete privileges to that particular Exchange. curl -H \"Authorization: Api-Key $API_KEY\" -H \"Content-Type: application/json\" -X DELETE https://www.peeringdb.com/api/ix/239","title":"DELETE"},{"location":"howto/authenticate/","text":"HOWTO: Authenticate to PeeringDB This article explains the authentication mechanisms we offer. It also explains how organizations can apply policies for their affiliated users. Why authenticate? You don't need to login to make single queries to PeeringDB. But some features do require you to authenticate. Update the database If you want to make updates then you need to authenticate. You can update PeeringDB via the API if you want. So you can either login to the website to make changes, or automate them with tools if you prefer. Access contact data We encourage you to publish contact information for your facility, IXP, or network. You can choose to make contact information public but many organizations limit it to other PeeringDB users. So you\u2019ll need to authenticate if you want access to most contact information. Higher query limits Authenticated users are allowed more frequent API queries. They are also able to repeat an identical API query more frequently without being throttled. Help PeeringDB\u2019s operations team If you authenticate when you send queries, we can contact you if your PeeringDB use starts to cause an unexpected problem. If you don\u2019t authenticate then all we can do is restrict queries from your IP address. Password You can use password authentication. We recommend adding MFA to password authentication. Multi-factor authentication We support two MFA methods. You can either use a time-based one-time password, as defined in RFC 6238 or a FIDO U2F hardware token. You can configure these in your account profile. OAuth Some external services allow or require you to authenticate using your PeeringDB account. One example is networks' peering portals. They might use PeeringDB's OAuth service to ensure they can automate configuration. We have a guide to implementing PeeringDB's OAuth service for your application. Automating PeeringDB access API keys We support both user and organizational API keys. You should use organizational API keys when you don't want to tie your application to an individual. We have a detailed guide on how to create, configure, and use API keys. Authentication HTTP header The HTTP authentication header must use the same character set the connection is using. This example shows a request and HTTP response: $ curl -v -sG https://www.peeringdb.com/api/net/416 -H 'Authorization: Api-Key example.valid_apikey' 2>&1 | grep \\<\\ HTTP < HTTP/2 200 This example shows what happens if the API key is not authorized: $ curl -v -sG https://www.peeringdb.com/api/net/416 -H 'Authorization: Api-Key example.invalid_apikey' 2>&1 | grep \\<\\ HTTP < HTTP/2 401 Canonical URL The canonical URL for PeeringDB is https://www.peeringdb.com . There is a redirect from https://peeringdb.com but we strongly encourage use of the canonical URL since industry practice in software packages is to drop the authentication header upon redirect, as a safety precaution. Password authentication Using an API key for command line access is simple and more secure. Our guide on API keys explains how to create and manage keys, including setting read-only permissions, with examples.","title":"HOWTO: Authenticate to PeeringDB"},{"location":"howto/authenticate/#howto-authenticate-to-peeringdb","text":"This article explains the authentication mechanisms we offer. It also explains how organizations can apply policies for their affiliated users.","title":"HOWTO: Authenticate to PeeringDB"},{"location":"howto/authenticate/#why-authenticate","text":"You don't need to login to make single queries to PeeringDB. But some features do require you to authenticate.","title":"Why authenticate?"},{"location":"howto/authenticate/#update-the-database","text":"If you want to make updates then you need to authenticate. You can update PeeringDB via the API if you want. So you can either login to the website to make changes, or automate them with tools if you prefer.","title":"Update the database"},{"location":"howto/authenticate/#access-contact-data","text":"We encourage you to publish contact information for your facility, IXP, or network. You can choose to make contact information public but many organizations limit it to other PeeringDB users. So you\u2019ll need to authenticate if you want access to most contact information.","title":"Access contact data"},{"location":"howto/authenticate/#higher-query-limits","text":"Authenticated users are allowed more frequent API queries. They are also able to repeat an identical API query more frequently without being throttled.","title":"Higher query limits"},{"location":"howto/authenticate/#help-peeringdbs-operations-team","text":"If you authenticate when you send queries, we can contact you if your PeeringDB use starts to cause an unexpected problem. If you don\u2019t authenticate then all we can do is restrict queries from your IP address.","title":"Help PeeringDB\u2019s operations team"},{"location":"howto/authenticate/#password","text":"You can use password authentication. We recommend adding MFA to password authentication.","title":"Password"},{"location":"howto/authenticate/#multi-factor-authentication","text":"We support two MFA methods. You can either use a time-based one-time password, as defined in RFC 6238 or a FIDO U2F hardware token. You can configure these in your account profile.","title":"Multi-factor authentication"},{"location":"howto/authenticate/#oauth","text":"Some external services allow or require you to authenticate using your PeeringDB account. One example is networks' peering portals. They might use PeeringDB's OAuth service to ensure they can automate configuration. We have a guide to implementing PeeringDB's OAuth service for your application.","title":"OAuth"},{"location":"howto/authenticate/#automating-peeringdb-access","text":"","title":"Automating PeeringDB access"},{"location":"howto/authenticate/#api-keys","text":"We support both user and organizational API keys. You should use organizational API keys when you don't want to tie your application to an individual. We have a detailed guide on how to create, configure, and use API keys.","title":"API keys"},{"location":"howto/authenticate/#authentication-http-header","text":"The HTTP authentication header must use the same character set the connection is using. This example shows a request and HTTP response: $ curl -v -sG https://www.peeringdb.com/api/net/416 -H 'Authorization: Api-Key example.valid_apikey' 2>&1 | grep \\<\\ HTTP < HTTP/2 200 This example shows what happens if the API key is not authorized: $ curl -v -sG https://www.peeringdb.com/api/net/416 -H 'Authorization: Api-Key example.invalid_apikey' 2>&1 | grep \\<\\ HTTP < HTTP/2 401","title":"Authentication HTTP header"},{"location":"howto/authenticate/#canonical-url","text":"The canonical URL for PeeringDB is https://www.peeringdb.com . There is a redirect from https://peeringdb.com but we strongly encourage use of the canonical URL since industry practice in software packages is to drop the authentication header upon redirect, as a safety precaution.","title":"Canonical URL"},{"location":"howto/authenticate/#password-authentication","text":"Using an API key for command line access is simple and more secure. Our guide on API keys explains how to create and manage keys, including setting read-only permissions, with examples.","title":"Password authentication"},{"location":"howto/enable_require_2fa/","text":"HOWTO: Turn on 2FA and Require Users to Enable It What is 2FA? 2FA is two-factor authentication. Enabling 2FA for PeeringDB means you must both have an account password and another factor. We support both TOTP and U2F tokens as additional factors. There are many popular software and hardware devices supporting these standards. How do users enable 2FA? Click on your account name. Then click on the green \"Manage Two-Factor Authentication\" box and follow the instructions. How do organizations require users to enable it? In the Manage panel at the bottom of the screen, select the Users tab and check the box \"Require users in your organization to enable 2FA.\"","title":"HOWTO: Turn on 2FA and Require Users to Enable It"},{"location":"howto/enable_require_2fa/#howto-turn-on-2fa-and-require-users-to-enable-it","text":"","title":"HOWTO: Turn on 2FA and Require Users to Enable It"},{"location":"howto/enable_require_2fa/#what-is-2fa","text":"2FA is two-factor authentication. Enabling 2FA for PeeringDB means you must both have an account password and another factor. We support both TOTP and U2F tokens as additional factors. There are many popular software and hardware devices supporting these standards.","title":"What is 2FA?"},{"location":"howto/enable_require_2fa/#how-do-users-enable-2fa","text":"Click on your account name. Then click on the green \"Manage Two-Factor Authentication\" box and follow the instructions.","title":"How do users enable 2FA?"},{"location":"howto/enable_require_2fa/#how-do-organizations-require-users-to-enable-it","text":"In the Manage panel at the bottom of the screen, select the Users tab and check the box \"Require users in your organization to enable 2FA.\"","title":"How do organizations require users to enable it?"},{"location":"howto/get-started-carrier/","text":"HOWTO: Get Started with PeeringDB as a Carrier Operator About PeeringDB 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, which prevents the database from 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. Why? PeeringDB is the interconnection database. Registering information about your carrier in PeeringDB makes it visible to IXPs and network operators who want to use your services to bring in peer or connect to other parts of their own network. Getting started Routine use of PeeringDB can be automated using our API but this document is intended to help new carrier administrators get started. Carriers are set up using the web interface. Once this is done you can use the API to automate things that change regularly. This document focuses on the key steps for establishing your presence in PeeringDB and assumes you are using the web interface, which is available in 14 languages. If you need additional help getting started, please contact us at: support@peeringdb.com . What is a Carrier? The carrier object is used to describe providers offering L1 or L2 services in a facility . It is different from a net because that describes services provided at L3 and is linked to its autonomous system number. Information required You will need to create several database records, known as objects, to establish your presence in PeeringDB. Database objects organize relevant information. Most information is optional but sharing all the relevant information maximizes the benefit you get from listing in PeeringDB. You can create your entry with the minimum required data and add and update the information you share over time. To maximize the value of your entry in PeeringDB you\u2019ll probably want to include more than the minimum required information. Your company name is required. This information is not required but is useful: AKA - If your carrier has an alternative name you can show it here to improve visibility in searches Long name - If your carrier has a long name, you can show it here to improve visibility in searches Notes - this field, which supports Markdown , can be used to describe the characteristics of your carrier that would be most useful to PeeringDB users You can look at the information shared by other PeeringDB users to work out what your organization should be sharing. Database records to create User The org is the parent for the carrier but you will need to start the process by creating a user account. If you use a role account for a PeeringDB user you should update the password when people who had access to the role account leave your organization. If you use a ticketing system, please make sure it does not auto-respond in a way that generates a slew of new tickets. Org The org object is your organization\u2019s core record in PeeringDB. All it needs is an organization name but you can add extra value by including information about where your organization is located. You could specify as little as a country name or as much as a full postal address. Your org object will be assigned a numeric identifier, called its id . This is what will be referenced by any child carrier object. Carrier Once you have created your organization you may add the carrier object. You do this by using the Add Carrier tab in the \u201cManage\u201d menu below your organization. You then click the edit button in the top right of the carrier screen and indicate which facilities your carrier has a presence in. The manager of the facility needs to approve the association. Next steps This short document describes the first steps for getting set up in PeeringDB. Once you have established your presence you should consider sharing information that would be helpful to potential new participants.","title":"HOWTO: Get Started with PeeringDB as a Carrier Operator"},{"location":"howto/get-started-carrier/#howto-get-started-with-peeringdb-as-a-carrier-operator","text":"","title":"HOWTO: Get Started with PeeringDB as a Carrier Operator"},{"location":"howto/get-started-carrier/#about-peeringdb","text":"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, which prevents the database from 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.","title":"About PeeringDB"},{"location":"howto/get-started-carrier/#why","text":"PeeringDB is the interconnection database. Registering information about your carrier in PeeringDB makes it visible to IXPs and network operators who want to use your services to bring in peer or connect to other parts of their own network.","title":"Why?"},{"location":"howto/get-started-carrier/#getting-started","text":"Routine use of PeeringDB can be automated using our API but this document is intended to help new carrier administrators get started. Carriers are set up using the web interface. Once this is done you can use the API to automate things that change regularly. This document focuses on the key steps for establishing your presence in PeeringDB and assumes you are using the web interface, which is available in 14 languages. If you need additional help getting started, please contact us at: support@peeringdb.com .","title":"Getting started"},{"location":"howto/get-started-carrier/#what-is-a-carrier","text":"The carrier object is used to describe providers offering L1 or L2 services in a facility . It is different from a net because that describes services provided at L3 and is linked to its autonomous system number.","title":"What is a Carrier?"},{"location":"howto/get-started-carrier/#information-required","text":"You will need to create several database records, known as objects, to establish your presence in PeeringDB. Database objects organize relevant information. Most information is optional but sharing all the relevant information maximizes the benefit you get from listing in PeeringDB. You can create your entry with the minimum required data and add and update the information you share over time. To maximize the value of your entry in PeeringDB you\u2019ll probably want to include more than the minimum required information. Your company name is required. This information is not required but is useful: AKA - If your carrier has an alternative name you can show it here to improve visibility in searches Long name - If your carrier has a long name, you can show it here to improve visibility in searches Notes - this field, which supports Markdown , can be used to describe the characteristics of your carrier that would be most useful to PeeringDB users You can look at the information shared by other PeeringDB users to work out what your organization should be sharing.","title":"Information required"},{"location":"howto/get-started-carrier/#database-records-to-create","text":"","title":"Database records to create"},{"location":"howto/get-started-carrier/#user","text":"The org is the parent for the carrier but you will need to start the process by creating a user account. If you use a role account for a PeeringDB user you should update the password when people who had access to the role account leave your organization. If you use a ticketing system, please make sure it does not auto-respond in a way that generates a slew of new tickets.","title":"User"},{"location":"howto/get-started-carrier/#org","text":"The org object is your organization\u2019s core record in PeeringDB. All it needs is an organization name but you can add extra value by including information about where your organization is located. You could specify as little as a country name or as much as a full postal address. Your org object will be assigned a numeric identifier, called its id . This is what will be referenced by any child carrier object.","title":"Org"},{"location":"howto/get-started-carrier/#carrier","text":"Once you have created your organization you may add the carrier object. You do this by using the Add Carrier tab in the \u201cManage\u201d menu below your organization. You then click the edit button in the top right of the carrier screen and indicate which facilities your carrier has a presence in. The manager of the facility needs to approve the association.","title":"Carrier"},{"location":"howto/get-started-carrier/#next-steps","text":"This short document describes the first steps for getting set up in PeeringDB. Once you have established your presence you should consider sharing information that would be helpful to potential new participants.","title":"Next steps"},{"location":"howto/get-started-developing/","text":"HOWTO: Get Started with Developing for PeeringDB Technology We use Python with Django and MySQL. Django manages interaction with the database. We publish all our code on GitHub. We have documented how to set up our development environment. What to develop PeeringDB users can request features and report bugs by creating issues on GitHub . Review open issues to either find a project you\u2019d like to work on, or to see if there\u2019s an existing issue for the feature you want. If you want to develop a feature that has not been discussed on GitHub, you should either create an issue or contact us to discuss what you need. You can send a message to productcom@lists.peeringdb.com or contact any of the members of the Product Committee . If you want to develop code for an issue that has achieved consensus on GitHub, we suggest starting with issues labeled as \"Good first issue\". These are simple issues that will help you get a feel for PeeringDB. Style Before you start developing code look at how similar functions have been implemented. Use the same design as existing functions and develop unit tests for your code. We aim for 80% unit test coverage. You also need to run black on your code before submitting a pull request. We use black to ensure that all of our code has the same formatting. Reusing designs, developing unit tests, and using consistent formatting makes it easier for us to maintain the code over time. We keep the feature parity between the web interface and the API. A feature added to one needs to be added to the other. The implementation details documented in issues should be detailed enough to use as documentation for the web interface. Documentation is also needed for the API. The minimum we need for API documentation is an example of how to format the request and a pointer to the document section to update. Pull requests It's good to let us know which issues you are working on when you start work. It's also helpful if you include the issues being fixed in your pull request. Please include \"Fixes #issue\" for each issue addressed in your pull request. We can then close those issues when we deploy your code. What happens next? When you submit your pull request we will run continuous integration tests on the code. We'll also review it ourselves. We'll report on the output of the tests in comments on the pull request and let you know if you need to make any changes.","title":"HOWTO: Get Started with Developing for PeeringDB"},{"location":"howto/get-started-developing/#howto-get-started-with-developing-for-peeringdb","text":"","title":"HOWTO: Get Started with Developing for PeeringDB"},{"location":"howto/get-started-developing/#technology","text":"We use Python with Django and MySQL. Django manages interaction with the database. We publish all our code on GitHub. We have documented how to set up our development environment.","title":"Technology"},{"location":"howto/get-started-developing/#what-to-develop","text":"PeeringDB users can request features and report bugs by creating issues on GitHub . Review open issues to either find a project you\u2019d like to work on, or to see if there\u2019s an existing issue for the feature you want. If you want to develop a feature that has not been discussed on GitHub, you should either create an issue or contact us to discuss what you need. You can send a message to productcom@lists.peeringdb.com or contact any of the members of the Product Committee . If you want to develop code for an issue that has achieved consensus on GitHub, we suggest starting with issues labeled as \"Good first issue\". These are simple issues that will help you get a feel for PeeringDB.","title":"What to develop"},{"location":"howto/get-started-developing/#style","text":"Before you start developing code look at how similar functions have been implemented. Use the same design as existing functions and develop unit tests for your code. We aim for 80% unit test coverage. You also need to run black on your code before submitting a pull request. We use black to ensure that all of our code has the same formatting. Reusing designs, developing unit tests, and using consistent formatting makes it easier for us to maintain the code over time. We keep the feature parity between the web interface and the API. A feature added to one needs to be added to the other. The implementation details documented in issues should be detailed enough to use as documentation for the web interface. Documentation is also needed for the API. The minimum we need for API documentation is an example of how to format the request and a pointer to the document section to update.","title":"Style"},{"location":"howto/get-started-developing/#pull-requests","text":"It's good to let us know which issues you are working on when you start work. It's also helpful if you include the issues being fixed in your pull request. Please include \"Fixes #issue\" for each issue addressed in your pull request. We can then close those issues when we deploy your code.","title":"Pull requests"},{"location":"howto/get-started-developing/#what-happens-next","text":"When you submit your pull request we will run continuous integration tests on the code. We'll also review it ourselves. We'll report on the output of the tests in comments on the pull request and let you know if you need to make any changes.","title":"What happens next?"},{"location":"howto/get-started-exchange/","text":"HOWTO: Get Started with PeeringDB as an Exchange Operator About PeeringDB 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, which prevents the database from 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. Why? PeeringDB is the interconnection database. Registering information about your exchange in PeeringDB makes it visible to network operators who want to peer with others across your fabric. Getting started Routine use of PeeringDB can be automated using our API but this document is intended to help new exchange operators get started. Most exchange networks get set up using the web interface and then use the API to automate things that change regularly. This document focuses on the key steps for establishing your exchange\u2019s presence in PeeringDB and assumes you are using the web interface, which is available in 14 languages. If you need additional help getting started, please contact us at: support@peeringdb.com . Information required You will need to create several database records, known as objects, to establish your presence in PeeringDB. Database objects organize relevant information and document your exchange\u2019s current participants, making it attractive to new ones. Most information is optional but sharing all the relevant information maximises the benefit you get from listing in PeeringDB. You can create your entry with the minimum required data and add and update the information you share over time. To maximize the value of your entry in PeeringDB you\u2019ll probably want to include more than the minimum required information. This information is required: Company Name IPv4 and IPv6 Prefixes Contact information This information is not required but is useful: Facilities, where your service is available Link to traffic statistics Geographical information: city/country/continental region. That will help networks locate your exchange. Some exchanges share additional information. You can look at the information shared by other exchange operators to work out what your organization should be sharing. Database records to create User The org is the parent for the IX but you will need to start the process by creating a user account. If you use a role account for a PeeringDB user you should update the password when people who had access to the role account leave your organization. If you use a ticketing system, please make sure it does not auto-respond in a way that generates a slew of new tickets. Org The org object is your organization\u2019s core record in PeeringDB. All it needs is an organization name but you can add extra value by including information about where your organization is located. You could specify as little as a country name or as much as a full postal address. Your org object will be assigned a numeric identifier, called its id. This is what will be referenced by any child net objects. Ix Once you have created your organization you may add the ix object. You do this by using the Add Exchange tab in the \u201cManage\u201d menu below your organization. You\u2019ll be able to input either your IPv4 or IPv6 LAN prefix through this form and will then need to add the other by editing the object once it is created. Prefixes An IPv4 or IPv6 prefix is needed to register your IX. Once your IX is approved, please also provide the other prefix. For the IPv6 prefix a /64 mask is highly recommended. Please talk to support if you would like to use another mask. The prefix information is used to verify connections from your participants. Next steps This short document describes the first steps for getting set up in PeeringDB. Once you have established your presence you should consider sharing information that would be helpful to potential new participants. Things to consider sharing: Encourage your exchange participants to add PeeringDB entries when they join, leave or upgrade the capacity they have with the exchange We recommend you automate the process of publishing details about networks that peer at your exchange using an IX-F JSON export . For that provide an URL at \u201cIX-F Member Export URL\u201d and enable the import. The visibility flag lets you set who is able to see your URL. And the \u201cPreview\u201d button pops a new window showing what actions the next import causes. Many networks are building automation that relies on PeeringDB. If networks peering at your exchange don't have an up to date PeeringDB record this might stop their automation configuring sessions. Use the \u201cMTU\u201d field to specify the MTU at your exchange. The field \u201cDOT1Q\u201d may go away, so it is not recommended to use it. More information The PeeringDB Data Ownership Policy describes all the objects in PeeringDB.","title":"HOWTO: Get Started with PeeringDB as an Exchange Operator"},{"location":"howto/get-started-exchange/#howto-get-started-with-peeringdb-as-an-exchange-operator","text":"","title":"HOWTO: Get Started with PeeringDB as an Exchange Operator"},{"location":"howto/get-started-exchange/#about-peeringdb","text":"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, which prevents the database from 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.","title":"About PeeringDB"},{"location":"howto/get-started-exchange/#why","text":"PeeringDB is the interconnection database. Registering information about your exchange in PeeringDB makes it visible to network operators who want to peer with others across your fabric.","title":"Why?"},{"location":"howto/get-started-exchange/#getting-started","text":"Routine use of PeeringDB can be automated using our API but this document is intended to help new exchange operators get started. Most exchange networks get set up using the web interface and then use the API to automate things that change regularly. This document focuses on the key steps for establishing your exchange\u2019s presence in PeeringDB and assumes you are using the web interface, which is available in 14 languages. If you need additional help getting started, please contact us at: support@peeringdb.com .","title":"Getting started"},{"location":"howto/get-started-exchange/#information-required","text":"You will need to create several database records, known as objects, to establish your presence in PeeringDB. Database objects organize relevant information and document your exchange\u2019s current participants, making it attractive to new ones. Most information is optional but sharing all the relevant information maximises the benefit you get from listing in PeeringDB. You can create your entry with the minimum required data and add and update the information you share over time. To maximize the value of your entry in PeeringDB you\u2019ll probably want to include more than the minimum required information. This information is required: Company Name IPv4 and IPv6 Prefixes Contact information This information is not required but is useful: Facilities, where your service is available Link to traffic statistics Geographical information: city/country/continental region. That will help networks locate your exchange. Some exchanges share additional information. You can look at the information shared by other exchange operators to work out what your organization should be sharing.","title":"Information required"},{"location":"howto/get-started-exchange/#database-records-to-create","text":"","title":"Database records to create"},{"location":"howto/get-started-exchange/#user","text":"The org is the parent for the IX but you will need to start the process by creating a user account. If you use a role account for a PeeringDB user you should update the password when people who had access to the role account leave your organization. If you use a ticketing system, please make sure it does not auto-respond in a way that generates a slew of new tickets.","title":"User"},{"location":"howto/get-started-exchange/#org","text":"The org object is your organization\u2019s core record in PeeringDB. All it needs is an organization name but you can add extra value by including information about where your organization is located. You could specify as little as a country name or as much as a full postal address. Your org object will be assigned a numeric identifier, called its id. This is what will be referenced by any child net objects.","title":"Org"},{"location":"howto/get-started-exchange/#ix","text":"Once you have created your organization you may add the ix object. You do this by using the Add Exchange tab in the \u201cManage\u201d menu below your organization. You\u2019ll be able to input either your IPv4 or IPv6 LAN prefix through this form and will then need to add the other by editing the object once it is created.","title":"Ix"},{"location":"howto/get-started-exchange/#prefixes","text":"An IPv4 or IPv6 prefix is needed to register your IX. Once your IX is approved, please also provide the other prefix. For the IPv6 prefix a /64 mask is highly recommended. Please talk to support if you would like to use another mask. The prefix information is used to verify connections from your participants.","title":"Prefixes"},{"location":"howto/get-started-exchange/#next-steps","text":"This short document describes the first steps for getting set up in PeeringDB. Once you have established your presence you should consider sharing information that would be helpful to potential new participants. Things to consider sharing: Encourage your exchange participants to add PeeringDB entries when they join, leave or upgrade the capacity they have with the exchange We recommend you automate the process of publishing details about networks that peer at your exchange using an IX-F JSON export . For that provide an URL at \u201cIX-F Member Export URL\u201d and enable the import. The visibility flag lets you set who is able to see your URL. And the \u201cPreview\u201d button pops a new window showing what actions the next import causes. Many networks are building automation that relies on PeeringDB. If networks peering at your exchange don't have an up to date PeeringDB record this might stop their automation configuring sessions. Use the \u201cMTU\u201d field to specify the MTU at your exchange. The field \u201cDOT1Q\u201d may go away, so it is not recommended to use it.","title":"Next steps"},{"location":"howto/get-started-exchange/#more-information","text":"The PeeringDB Data Ownership Policy describes all the objects in PeeringDB.","title":"More information"},{"location":"howto/get-started-facility/","text":"HOWTO: Get Started with PeeringDB as a Facility or Campus Operator About PeeringDB 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, which prevents the database from 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. Why? PeeringDB is the interconnection database. Registering information about your facility in PeeringDB makes it visible to network operators who want to connect to exchanges or other networks in your facility. Getting started Routine use of PeeringDB can be automated using our API but this document is intended to help new facility administrators get started. Facilities are set up using the web interface. Once this is done you can use the API to automate things that change regularly. This document focuses on the key steps for establishing your facility's presence in PeeringDB and assumes you are using the web interface, which is available in 14 languages. If you need additional help getting started, please contact us at: support@peeringdb.com . Information required You will need to create several database records, known as objects, to establish your presence in PeeringDB. Database objects organize relevant information. Your facility\u2019s current participants can add their presence in your facility, making it attractive to others. Most information is optional but sharing all the relevant information maximizes the benefit you get from listing in PeeringDB. You can create your entry with the minimum required data and add and update the information you share over time. To maximize the value of your entry in PeeringDB you\u2019ll probably want to include more than the minimum required information. This information is required: Company Name Full street address This information is not required but is useful: AKA - If your facility has an alternative name you can show it here to improve visibility in searches Long name - If your facility has a long name, you can show it here to improve visibility in searches Floor - If your facility does not fill an entire building Suite - If your facility does not fill an entire building CLLI - this is a location code used in parts of the US telecommunications industry and is most useful to facilities located in the USA Notes - this field, which supports Markdown , can be used to describe the characteristics of your facility that would be most useful to PeeringDB users You can look at the information shared by other facility managers to work out what your organization should be sharing. Database records to create User The org is the parent for the facility but you will need to start the process by creating a user account. If you use a role account for a PeeringDB user you should update the password when people who had access to the role account leave your organization. If you use a ticketing system, please make sure it does not auto-respond in a way that generates a slew of new tickets. Org The org object is your organization\u2019s core record in PeeringDB. All it needs is an organization name but you can add extra value by including information about where your organization is located. You could specify as little as a country name or as much as a full postal address. Your org object will be assigned a numeric identifier, called its id . This is what will be referenced by any child facility object. Facility Once you have created your organization you may add the facility object. You do this by using the Add Facility tab in the \u201cManage\u201d menu below your organization. Campus A campus is two or more facilities owned by the same organization where customers can get inter-facility cross-connects. When you have two facilities you can create a campus using the Add Campus tab in the \u201cManage\u201d menu below your organization. PeeringDB relies on facility operators to decide whether their interconnected facilities should be listed as a campus. Facilities need to be within 50 kilometers of each other. The software enforces this limit to help users avoid configuration mistakes. Next steps This short document describes the first steps for getting set up in PeeringDB. Once you have established your presence you should consider sharing information that would be helpful to potential new participants. Things to consider sharing: Encourage the networks and Internet Exchanges to also register with PeeringDB, and to indicate their presence in your facility. Thus making their presence visible to others and so increasing the possibility of interconnection with other networks. More information The PeeringDB Data Ownership Policy describes all the objects in PeeringDB.","title":"HOWTO: Get Started with PeeringDB as a Facility or Campus Operator"},{"location":"howto/get-started-facility/#howto-get-started-with-peeringdb-as-a-facility-or-campus-operator","text":"","title":"HOWTO: Get Started with PeeringDB as a Facility or Campus Operator"},{"location":"howto/get-started-facility/#about-peeringdb","text":"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, which prevents the database from 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.","title":"About PeeringDB"},{"location":"howto/get-started-facility/#why","text":"PeeringDB is the interconnection database. Registering information about your facility in PeeringDB makes it visible to network operators who want to connect to exchanges or other networks in your facility.","title":"Why?"},{"location":"howto/get-started-facility/#getting-started","text":"Routine use of PeeringDB can be automated using our API but this document is intended to help new facility administrators get started. Facilities are set up using the web interface. Once this is done you can use the API to automate things that change regularly. This document focuses on the key steps for establishing your facility's presence in PeeringDB and assumes you are using the web interface, which is available in 14 languages. If you need additional help getting started, please contact us at: support@peeringdb.com .","title":"Getting started"},{"location":"howto/get-started-facility/#information-required","text":"You will need to create several database records, known as objects, to establish your presence in PeeringDB. Database objects organize relevant information. Your facility\u2019s current participants can add their presence in your facility, making it attractive to others. Most information is optional but sharing all the relevant information maximizes the benefit you get from listing in PeeringDB. You can create your entry with the minimum required data and add and update the information you share over time. To maximize the value of your entry in PeeringDB you\u2019ll probably want to include more than the minimum required information. This information is required: Company Name Full street address This information is not required but is useful: AKA - If your facility has an alternative name you can show it here to improve visibility in searches Long name - If your facility has a long name, you can show it here to improve visibility in searches Floor - If your facility does not fill an entire building Suite - If your facility does not fill an entire building CLLI - this is a location code used in parts of the US telecommunications industry and is most useful to facilities located in the USA Notes - this field, which supports Markdown , can be used to describe the characteristics of your facility that would be most useful to PeeringDB users You can look at the information shared by other facility managers to work out what your organization should be sharing.","title":"Information required"},{"location":"howto/get-started-facility/#database-records-to-create","text":"","title":"Database records to create"},{"location":"howto/get-started-facility/#user","text":"The org is the parent for the facility but you will need to start the process by creating a user account. If you use a role account for a PeeringDB user you should update the password when people who had access to the role account leave your organization. If you use a ticketing system, please make sure it does not auto-respond in a way that generates a slew of new tickets.","title":"User"},{"location":"howto/get-started-facility/#org","text":"The org object is your organization\u2019s core record in PeeringDB. All it needs is an organization name but you can add extra value by including information about where your organization is located. You could specify as little as a country name or as much as a full postal address. Your org object will be assigned a numeric identifier, called its id . This is what will be referenced by any child facility object.","title":"Org"},{"location":"howto/get-started-facility/#facility","text":"Once you have created your organization you may add the facility object. You do this by using the Add Facility tab in the \u201cManage\u201d menu below your organization.","title":"Facility"},{"location":"howto/get-started-facility/#campus","text":"A campus is two or more facilities owned by the same organization where customers can get inter-facility cross-connects. When you have two facilities you can create a campus using the Add Campus tab in the \u201cManage\u201d menu below your organization. PeeringDB relies on facility operators to decide whether their interconnected facilities should be listed as a campus. Facilities need to be within 50 kilometers of each other. The software enforces this limit to help users avoid configuration mistakes.","title":"Campus"},{"location":"howto/get-started-facility/#next-steps","text":"This short document describes the first steps for getting set up in PeeringDB. Once you have established your presence you should consider sharing information that would be helpful to potential new participants. Things to consider sharing: Encourage the networks and Internet Exchanges to also register with PeeringDB, and to indicate their presence in your facility. Thus making their presence visible to others and so increasing the possibility of interconnection with other networks.","title":"Next steps"},{"location":"howto/get-started-facility/#more-information","text":"The PeeringDB Data Ownership Policy describes all the objects in PeeringDB.","title":"More information"},{"location":"howto/get-started-operator/","text":"HOWTO: Get Started with PeeringDB as a Network Operator About PeeringDB 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, which prevents the database from 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. Why should I add my network? Almost one-third of Autonomous System Numbers (ASNs) register their interconnection data in the PeeringDB database. That means, by using PeeringDB and adding your own interconnection data, you\u2019ll be able to confidently find information about networks looking to interconnect, where and how to connect with them, and they\u2019ll be able to find the same information about your network. Since the database is user-maintained and validated by our volunteers, you can trust that the information is accurate and up-to-date. This data will help you to accelerate the process of finding and connecting with other networks while supporting a faster and more decisive deployment of your own network expansion and development plans. Many networks are building automation that relies on PeeringDB. If you don't have an up to date PeeringDB record this might stop their automation configuring sessions. Getting started Routine use of PeeringDB can be automated using our API but this document is intended to help new networks get started. Most networks get set up using the web interface and then use the API to automate things that change regularly. This document focuses on the key steps for establishing your network\u2019s presence in PeeringDB and assumes you are using the web interface, which is available in 14 languages. If you need additional help getting started, please contact us at: support@peeringdb.com . Information required You will need to create several database records, known as objects, to establish your presence in PeeringDB. Database objects organize relevant information and document the connections making your network attractive to potential peers. Most information is optional but the less you share the less likely your network will benefit from listing itself in PeeringDB. You can create your entry with the minimum required data and add and update the information you share over time. To maximize the value of your entry in PeeringDB you\u2019ll probably want to include more than the minimum required information. This information is required: Company name AS number Contact information (mandatory for networks with a connection to an Internet Exchange) This information is not required but is useful: IRR information Network type Network operational area (so-called geographic scope) Some networks share additional information. You can look at the information shared by your peers and potential peers to work out what your network should be sharing. Database records to create Some objects have a notes field to share additional information. You can use Markdown formatting for the notes to make them more readable. User The org is the parent for the network but you will need to start the process by creating a user account. We recommend that you use an e-mail address that exists in the publicly available contact information for the network\u2019s ASN so that we can automatically validate your affiliation with the network. If you use a role account for a PeeringDB user you should update the password when people who had access to the role account leave your organization. If you use a ticketing system, please make sure it does not auto-respond in a way that generates a slew of new tickets. Org The org object is your organization\u2019s core record in PeeringDB. All it needs is an organization name but you can add extra value by including information about where your organization is located. You could specify as little as a country name or as much as a full postal address. Your org object will be assigned a numeric identifier, called its id . This is what will be referenced by any child net objects. Net Basic network information is automatically retrieved from the RIR or NIR\u2019s database based on the AS Number. Brand names or other identifiers can be listed in the aka field. For example: name: Example Org Legal Entity aka: Example Superfast Networks, Example Reliable Hosting Permissions to grant Once you are up and running you can create POC (Point of Contact) objects for functional contacts with your network. Not all networks need all POCs. These are: Abuse Maintenance NOC Policy Public Relations Sales Technical The information for each type of contact is the same, with optional telephone numbers, e-mail addresses, and URLs. Visibility of the POC information can be different for each POC. Each of the POCs associated with your network can have different visibility permissions. The options are: Users (meaning that only other PeeringDB users can see the POC), and Public (meaning that the record is shown to anonymous users as well as authenticated users). Some organizations will want to make their Abuse, Public Relations, and/or Sales POCs Public but limit the visibility of other POCs to authenticated Users . If your network will be present at Public Peering Exchange Points you can grant them permission to add and modify entries for your network via their ixp_member data . You grant permission using the \u201cAllow IXP Update\u201d box, which will show when you add a Public Peering Exchange Point. Next steps This short document describes the first steps for getting set up in PeeringDB. Once you have established your presence you should consider sharing information with current and potential peers about your network(s). Things to consider sharing: We recommend you include the name of your AS-SET or ROUTE-SET if you have multiple net objects. Edit your network object to provide information about your routing policy, traffic ratios and more. What is the maximum number of IPv4 and/or IPv6 prefixes should peers expect to see advertised by your network? You can use the info_prefixes4 and info_prefixes6 with integer values to share this information. How much traffic crosses your network and in which direction? You can share this information using the info_traffic and info_ratio attributes in your net object. You can enter numbers or pre-defined ranges for both attributes. Do you have a peering policy? If you do you can use the various policy attributes on your net object to communicate it to potential peers. More information The PeeringDB Data Ownership Policy describes all the objects in PeeringDB.","title":"HOWTO: Get Started with PeeringDB as a Network Operator"},{"location":"howto/get-started-operator/#howto-get-started-with-peeringdb-as-a-network-operator","text":"","title":"HOWTO: Get Started with PeeringDB as a Network Operator"},{"location":"howto/get-started-operator/#about-peeringdb","text":"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, which prevents the database from 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.","title":"About PeeringDB"},{"location":"howto/get-started-operator/#why-should-i-add-my-network","text":"Almost one-third of Autonomous System Numbers (ASNs) register their interconnection data in the PeeringDB database. That means, by using PeeringDB and adding your own interconnection data, you\u2019ll be able to confidently find information about networks looking to interconnect, where and how to connect with them, and they\u2019ll be able to find the same information about your network. Since the database is user-maintained and validated by our volunteers, you can trust that the information is accurate and up-to-date. This data will help you to accelerate the process of finding and connecting with other networks while supporting a faster and more decisive deployment of your own network expansion and development plans. Many networks are building automation that relies on PeeringDB. If you don't have an up to date PeeringDB record this might stop their automation configuring sessions.","title":"Why should I add my network?"},{"location":"howto/get-started-operator/#getting-started","text":"Routine use of PeeringDB can be automated using our API but this document is intended to help new networks get started. Most networks get set up using the web interface and then use the API to automate things that change regularly. This document focuses on the key steps for establishing your network\u2019s presence in PeeringDB and assumes you are using the web interface, which is available in 14 languages. If you need additional help getting started, please contact us at: support@peeringdb.com .","title":"Getting started"},{"location":"howto/get-started-operator/#information-required","text":"You will need to create several database records, known as objects, to establish your presence in PeeringDB. Database objects organize relevant information and document the connections making your network attractive to potential peers. Most information is optional but the less you share the less likely your network will benefit from listing itself in PeeringDB. You can create your entry with the minimum required data and add and update the information you share over time. To maximize the value of your entry in PeeringDB you\u2019ll probably want to include more than the minimum required information. This information is required: Company name AS number Contact information (mandatory for networks with a connection to an Internet Exchange) This information is not required but is useful: IRR information Network type Network operational area (so-called geographic scope) Some networks share additional information. You can look at the information shared by your peers and potential peers to work out what your network should be sharing.","title":"Information required"},{"location":"howto/get-started-operator/#database-records-to-create","text":"Some objects have a notes field to share additional information. You can use Markdown formatting for the notes to make them more readable.","title":"Database records to create"},{"location":"howto/get-started-operator/#user","text":"The org is the parent for the network but you will need to start the process by creating a user account. We recommend that you use an e-mail address that exists in the publicly available contact information for the network\u2019s ASN so that we can automatically validate your affiliation with the network. If you use a role account for a PeeringDB user you should update the password when people who had access to the role account leave your organization. If you use a ticketing system, please make sure it does not auto-respond in a way that generates a slew of new tickets.","title":"User"},{"location":"howto/get-started-operator/#org","text":"The org object is your organization\u2019s core record in PeeringDB. All it needs is an organization name but you can add extra value by including information about where your organization is located. You could specify as little as a country name or as much as a full postal address. Your org object will be assigned a numeric identifier, called its id . This is what will be referenced by any child net objects.","title":"Org"},{"location":"howto/get-started-operator/#net","text":"Basic network information is automatically retrieved from the RIR or NIR\u2019s database based on the AS Number. Brand names or other identifiers can be listed in the aka field. For example: name: Example Org Legal Entity aka: Example Superfast Networks, Example Reliable Hosting","title":"Net"},{"location":"howto/get-started-operator/#permissions-to-grant","text":"Once you are up and running you can create POC (Point of Contact) objects for functional contacts with your network. Not all networks need all POCs. These are: Abuse Maintenance NOC Policy Public Relations Sales Technical The information for each type of contact is the same, with optional telephone numbers, e-mail addresses, and URLs. Visibility of the POC information can be different for each POC. Each of the POCs associated with your network can have different visibility permissions. The options are: Users (meaning that only other PeeringDB users can see the POC), and Public (meaning that the record is shown to anonymous users as well as authenticated users). Some organizations will want to make their Abuse, Public Relations, and/or Sales POCs Public but limit the visibility of other POCs to authenticated Users . If your network will be present at Public Peering Exchange Points you can grant them permission to add and modify entries for your network via their ixp_member data . You grant permission using the \u201cAllow IXP Update\u201d box, which will show when you add a Public Peering Exchange Point.","title":"Permissions to grant"},{"location":"howto/get-started-operator/#next-steps","text":"This short document describes the first steps for getting set up in PeeringDB. Once you have established your presence you should consider sharing information with current and potential peers about your network(s). Things to consider sharing: We recommend you include the name of your AS-SET or ROUTE-SET if you have multiple net objects. Edit your network object to provide information about your routing policy, traffic ratios and more. What is the maximum number of IPv4 and/or IPv6 prefixes should peers expect to see advertised by your network? You can use the info_prefixes4 and info_prefixes6 with integer values to share this information. How much traffic crosses your network and in which direction? You can share this information using the info_traffic and info_ratio attributes in your net object. You can enter numbers or pre-defined ranges for both attributes. Do you have a peering policy? If you do you can use the various policy attributes on your net object to communicate it to potential peers.","title":"Next steps"},{"location":"howto/get-started-operator/#more-information","text":"The PeeringDB Data Ownership Policy describes all the objects in PeeringDB.","title":"More information"},{"location":"howto/make-a-security-report/","text":"HOWTO: Report a Security Issue to PeeringDB PeeringDB works hard to keep its systems and data as secure as possible. If you are a security researcher and have discovered a security vulnerability in one of our services, we appreciate your help in disclosing it to us in a responsible manner. Our responsible disclosure policy is not an invitation to actively hack and potentially disrupt our system and services. We reserve the right to sue researchers for penetrating or attempting to penetrate our systems. PeeringDB does not permit the following types of security research While we encourage you to discover and report to us any vulnerabilities you find in a responsible manner, the following conduct is prohibited: Performing actions that may negatively affect PeeringDB or its users (e.g. any form of Denial of Service attacks) Accessing, or attempting to access, data or information that does not belong to you Destroying or corrupting, or attempting to destroy or corrupt, data or information that does not belong to you Conducting any kind of physical or electronic attack on PeeringDB personnel, property or data centers Using social engineering to target any PeeringDB team member Violating any laws or breaching any agreements to discover vulnerabilities Scope of the network The following is in scope: The www.peeringdb.com website and any of its sub-domains, services, APIs and infrastructure. Any (internet-facing) infrastructure owned and operated by PeeringDB. Exclusions The following list of issues have already been reported to our Security team, reviewed, and deemed out of scope for the purposes of this program. Please do not report any of the following classes of issues. Unless there are exceptional circumstances or novel attacks, these issues will be rejected: Missing, or not 'properly' configured SPF, DKIM or DMARC records. The presence of public services such as robots.txt or FTP. The availability of DNS zone transfers. Reports of old software versions without a working Proof of Concept of an exploit. This is not an exclusive list. If you report a vulnerability that has already been reported by someone else, we will let you know. In that case you are not eligible for our Security Hall of Fame or swag. What we request from you Please do not share the issue with others until it has been resolved. Please do not publish anything about the resolved issue unless this has been discussed with us. Email your findings to security@peeringdb.com. You may submit a notification under a pseudonym. Please provide enough information for us to reproduce the issue so that we can resolve it as soon as possible. Please delete all confidential information obtained through the vulnerability as soon as possible after reporting it. Please do this after consulting us to make sure that we can reproduce the issue. What we promise We will act with urgency and necessary resources to resolve the issue. We will strive to respond to your report within three business days with our evaluation of the report and an expected resolution date. We will handle your report with strict confidentiality and not pass on your personal details to third parties without your permission. After a major security issue has been solved, we will publish a report on our website explaining the vulnerability discovered and how we fixed it. If you agree to have your name used in the report, we will credit you. Note that we will only credit the first person that reported a specific vulnerability to us. After your vulnerability report is verified, the security team will inform you if you are eligible. We will send you a unique token of our gratitude, such as a personalized cup, hat, or hoodie. We do not issue monetary rewards for reported vulnerabilities.","title":"HOWTO: Report a Security Issue to PeeringDB"},{"location":"howto/make-a-security-report/#howto-report-a-security-issue-to-peeringdb","text":"PeeringDB works hard to keep its systems and data as secure as possible. If you are a security researcher and have discovered a security vulnerability in one of our services, we appreciate your help in disclosing it to us in a responsible manner. Our responsible disclosure policy is not an invitation to actively hack and potentially disrupt our system and services. We reserve the right to sue researchers for penetrating or attempting to penetrate our systems.","title":"HOWTO: Report a Security Issue to PeeringDB"},{"location":"howto/make-a-security-report/#peeringdb-does-not-permit-the-following-types-of-security-research","text":"While we encourage you to discover and report to us any vulnerabilities you find in a responsible manner, the following conduct is prohibited: Performing actions that may negatively affect PeeringDB or its users (e.g. any form of Denial of Service attacks) Accessing, or attempting to access, data or information that does not belong to you Destroying or corrupting, or attempting to destroy or corrupt, data or information that does not belong to you Conducting any kind of physical or electronic attack on PeeringDB personnel, property or data centers Using social engineering to target any PeeringDB team member Violating any laws or breaching any agreements to discover vulnerabilities","title":"PeeringDB does not permit the following types of security research"},{"location":"howto/make-a-security-report/#scope-of-the-network","text":"The following is in scope: The www.peeringdb.com website and any of its sub-domains, services, APIs and infrastructure. Any (internet-facing) infrastructure owned and operated by PeeringDB.","title":"Scope of the network"},{"location":"howto/make-a-security-report/#exclusions","text":"The following list of issues have already been reported to our Security team, reviewed, and deemed out of scope for the purposes of this program. Please do not report any of the following classes of issues. Unless there are exceptional circumstances or novel attacks, these issues will be rejected: Missing, or not 'properly' configured SPF, DKIM or DMARC records. The presence of public services such as robots.txt or FTP. The availability of DNS zone transfers. Reports of old software versions without a working Proof of Concept of an exploit. This is not an exclusive list. If you report a vulnerability that has already been reported by someone else, we will let you know. In that case you are not eligible for our Security Hall of Fame or swag.","title":"Exclusions"},{"location":"howto/make-a-security-report/#what-we-request-from-you","text":"Please do not share the issue with others until it has been resolved. Please do not publish anything about the resolved issue unless this has been discussed with us. Email your findings to security@peeringdb.com. You may submit a notification under a pseudonym. Please provide enough information for us to reproduce the issue so that we can resolve it as soon as possible. Please delete all confidential information obtained through the vulnerability as soon as possible after reporting it. Please do this after consulting us to make sure that we can reproduce the issue.","title":"What we request from you"},{"location":"howto/make-a-security-report/#what-we-promise","text":"We will act with urgency and necessary resources to resolve the issue. We will strive to respond to your report within three business days with our evaluation of the report and an expected resolution date. We will handle your report with strict confidentiality and not pass on your personal details to third parties without your permission. After a major security issue has been solved, we will publish a report on our website explaining the vulnerability discovered and how we fixed it. If you agree to have your name used in the report, we will credit you. Note that we will only credit the first person that reported a specific vulnerability to us. After your vulnerability report is verified, the security team will inform you if you are eligible. We will send you a unique token of our gratitude, such as a personalized cup, hat, or hoodie. We do not issue monetary rewards for reported vulnerabilities.","title":"What we promise"},{"location":"howto/manage-permissions/","text":"HOWTO: Manage User Permissions Do I need a PeeringDB account? You only need a PeeringDB user account if you want to do one of three things: Access contact information Create, update, or delete entries in PeeringDB Use PeeringDB to login to external services, using the PeeringDB OAuth service . If you just want to look up information about networks, exchanges, or facilities in PeeringDB, you can do that without an account using the web interface or the API . How can I manage permissions for users affiliated with my organization? Unless you want your users to manage parts of the data your organization publishes, they don\u2019t need to be affiliated with your organization. When you allow a user account to affiliate with your organization, you can delegate some permissions to it. You can delegate them permissions related to exchanges, facilities, and networks. For each type of entry you can delegate permissions to create, update, or delete. The table below shows an example for an affiliated user who has only been delegated permission to update the organization\u2019s net object. Create Update Delete Campus No No No Carriers No No No Exchanges No No No Facilities No No No Networks No Yes No Admin users for an organization can do all these things and can delegate granular permissions to users based on the needs of their organization. How do I give permissions to a user who is already affiliated with other organizations? User accounts can be associated with multiple organizations. For instance, a consultant could be associated with each of their client\u2019s organizations. Similarly, a large organization composed of several operating companies could have a different organization for each operating company in PeeringDB and have some users affiliated with those instead of trying to centralize control. The user just needs to request, and be granted affiliation with each organization whose data they will be updating in PeeringDB. How do I authenticate at external services using my PeeringDB account? If your organization operates a network and has the Autonomous System registered with PeeringDB, your users can use their PeeringDB accounts to authenticate at external services that have enabled PeeringDB\u2019s OAuth service. In mid-2021 about 150 applications had enabled PeeringDB OAuth. It is used to facilitate peering requests, use network telemetry services, and more.","title":"HOWTO: Manage User Permissions"},{"location":"howto/manage-permissions/#howto-manage-user-permissions","text":"","title":"HOWTO: Manage User Permissions"},{"location":"howto/manage-permissions/#do-i-need-a-peeringdb-account","text":"You only need a PeeringDB user account if you want to do one of three things: Access contact information Create, update, or delete entries in PeeringDB Use PeeringDB to login to external services, using the PeeringDB OAuth service . If you just want to look up information about networks, exchanges, or facilities in PeeringDB, you can do that without an account using the web interface or the API .","title":"Do I need a PeeringDB account?"},{"location":"howto/manage-permissions/#how-can-i-manage-permissions-for-users-affiliated-with-my-organization","text":"Unless you want your users to manage parts of the data your organization publishes, they don\u2019t need to be affiliated with your organization. When you allow a user account to affiliate with your organization, you can delegate some permissions to it. You can delegate them permissions related to exchanges, facilities, and networks. For each type of entry you can delegate permissions to create, update, or delete. The table below shows an example for an affiliated user who has only been delegated permission to update the organization\u2019s net object. Create Update Delete Campus No No No Carriers No No No Exchanges No No No Facilities No No No Networks No Yes No Admin users for an organization can do all these things and can delegate granular permissions to users based on the needs of their organization.","title":"How can I manage permissions for users affiliated with my organization?"},{"location":"howto/manage-permissions/#how-do-i-give-permissions-to-a-user-who-is-already-affiliated-with-other-organizations","text":"User accounts can be associated with multiple organizations. For instance, a consultant could be associated with each of their client\u2019s organizations. Similarly, a large organization composed of several operating companies could have a different organization for each operating company in PeeringDB and have some users affiliated with those instead of trying to centralize control. The user just needs to request, and be granted affiliation with each organization whose data they will be updating in PeeringDB.","title":"How do I give permissions to a user who is already affiliated with other organizations?"},{"location":"howto/manage-permissions/#how-do-i-authenticate-at-external-services-using-my-peeringdb-account","text":"If your organization operates a network and has the Autonomous System registered with PeeringDB, your users can use their PeeringDB accounts to authenticate at external services that have enabled PeeringDB\u2019s OAuth service. In mid-2021 about 150 applications had enabled PeeringDB OAuth. It is used to facilitate peering requests, use network telemetry services, and more.","title":"How do I authenticate at external services using my PeeringDB account?"},{"location":"howto/member_vote/","text":"HOWTO: Become a PeeringDB Member and Vote PeeringDB is a membership organization. We do not charge for membership. You become a member when you have data in PeeringDB and subscribe to our governance mailing list. When you are a member, you may attend Members\u2019 Meetings and vote in elections. How is PeeringDB governed? PeeringDB members elect our board. The board elects officers (President, Vice President, Secretary/Treasurer) and appoints committees. The board, the officers, the chairs of the committees, and the Product Manager are the PeeringDB Stewards. Non-board Stewards are responsible for keeping the board informed. The board and officers hold fiduciary responsibility for PeeringDB as a legal entity. How do I become a member? Make sure you have data in PeeringDB (see other HOWTOs ). Join the pdb-gov mailing list . You are now a member. How can I vote? Each member is entitled to one vote. Members who are affiliated with each other share a single vote. For instance, if Big Company owns Small Company they may only have one vote between them, not one vote each. At the start of the election process, the Secretary/Treasurer will ask each member to nominate a single authorized voter. The Secretary will send each authorized voter an invitation to vote. Can I join a committee? Yes! Volunteers run our committees. They are: Admin \u2013 provides support to our users Operations \u2013 keeps PeeringDB services running smoothly Outreach \u2013 keeps the interconnection community aware of PeeringDB activity Product \u2013 reviews and refines PeeringDB\u2019s product design If you want to join a committee, send a message to stewards@peeringdb.com . Where can I learn more? We publish detailed governance documentation and records on our governance website .","title":"HOWTO: Become a PeeringDB Member and Vote"},{"location":"howto/member_vote/#howto-become-a-peeringdb-member-and-vote","text":"PeeringDB is a membership organization. We do not charge for membership. You become a member when you have data in PeeringDB and subscribe to our governance mailing list. When you are a member, you may attend Members\u2019 Meetings and vote in elections.","title":"HOWTO: Become a PeeringDB Member and Vote"},{"location":"howto/member_vote/#how-is-peeringdb-governed","text":"PeeringDB members elect our board. The board elects officers (President, Vice President, Secretary/Treasurer) and appoints committees. The board, the officers, the chairs of the committees, and the Product Manager are the PeeringDB Stewards. Non-board Stewards are responsible for keeping the board informed. The board and officers hold fiduciary responsibility for PeeringDB as a legal entity.","title":"How is PeeringDB governed?"},{"location":"howto/member_vote/#how-do-i-become-a-member","text":"Make sure you have data in PeeringDB (see other HOWTOs ). Join the pdb-gov mailing list . You are now a member.","title":"How do I become a member?"},{"location":"howto/member_vote/#how-can-i-vote","text":"Each member is entitled to one vote. Members who are affiliated with each other share a single vote. For instance, if Big Company owns Small Company they may only have one vote between them, not one vote each. At the start of the election process, the Secretary/Treasurer will ask each member to nominate a single authorized voter. The Secretary will send each authorized voter an invitation to vote.","title":"How can I vote?"},{"location":"howto/member_vote/#can-i-join-a-committee","text":"Yes! Volunteers run our committees. They are: Admin \u2013 provides support to our users Operations \u2013 keeps PeeringDB services running smoothly Outreach \u2013 keeps the interconnection community aware of PeeringDB activity Product \u2013 reviews and refines PeeringDB\u2019s product design If you want to join a committee, send a message to stewards@peeringdb.com .","title":"Can I join a committee?"},{"location":"howto/member_vote/#where-can-i-learn-more","text":"We publish detailed governance documentation and records on our governance website .","title":"Where can I learn more?"},{"location":"howto/organizational_policy/","text":"HOWTO: Manage Organizational Policy Your organization can apply policies for its users in the Manage section of the organization profile. Restrict email domains You can set a policy that only allows users to affiliate when their email address uses a specific domain. You can set a list of the domains your organization allows. If users do not meet the policy when it is configured they will not lose their affiliation. You will be notified so you can manage the change with your users. A user with multiple email addresses associated with their account only needs one address to match. For instance, if the policy requires users to have an example.com address and the user has both an example.com and an example.net address, the user can affiliate. Periodic validation of user\u2019s contact information You can require users to validate the contact information for their PeeringDB user account. You set the time after which the validation process will be run. The default is 1 year but you can set it as short as 1 week. This options is managed in the same control panel shown in the image above. When an unvalidated user tries to login a link will be sent to their email address. They will need to go to that web page to validate their contact information before they can login. Some users are affiliated with multiple organizations. When this is the case, the link will be sent to the most suitable address for that organization. When a user is affiliated with multiple organizations, those organizations can set different revalidation periods. The user\u2019s affiliation is suspended at the end of the validation counter only for that organization. For example, Alice is affiliated to Example Networks and Example Facilities. Example Networks requires users to validate after 90 days but Example Facilities requires users to revalidate after a year. If Alice validates to both organizations on 1 January, she will remain a valid user for Example Facilities until the end of the year but will need to validate for Example Networks on 1 April. Multiple email addresses per user Users may have multiple email addresses associated with their account. They must select one address as the primary address and this will be used for notifications. This is managed in each user's own profile, which is located in the hamburger menu by the user's username. Each email address can only be associated with one user. When a user with multiple email addresses associated with their account wants to remove the primary address, they will have to select another address as the primary address.","title":"HOWTO: Manage Organizational Policy"},{"location":"howto/organizational_policy/#howto-manage-organizational-policy","text":"Your organization can apply policies for its users in the Manage section of the organization profile.","title":"HOWTO: Manage Organizational Policy"},{"location":"howto/organizational_policy/#restrict-email-domains","text":"You can set a policy that only allows users to affiliate when their email address uses a specific domain. You can set a list of the domains your organization allows. If users do not meet the policy when it is configured they will not lose their affiliation. You will be notified so you can manage the change with your users. A user with multiple email addresses associated with their account only needs one address to match. For instance, if the policy requires users to have an example.com address and the user has both an example.com and an example.net address, the user can affiliate.","title":"Restrict email domains"},{"location":"howto/organizational_policy/#periodic-validation-of-users-contact-information","text":"You can require users to validate the contact information for their PeeringDB user account. You set the time after which the validation process will be run. The default is 1 year but you can set it as short as 1 week. This options is managed in the same control panel shown in the image above. When an unvalidated user tries to login a link will be sent to their email address. They will need to go to that web page to validate their contact information before they can login. Some users are affiliated with multiple organizations. When this is the case, the link will be sent to the most suitable address for that organization. When a user is affiliated with multiple organizations, those organizations can set different revalidation periods. The user\u2019s affiliation is suspended at the end of the validation counter only for that organization. For example, Alice is affiliated to Example Networks and Example Facilities. Example Networks requires users to validate after 90 days but Example Facilities requires users to revalidate after a year. If Alice validates to both organizations on 1 January, she will remain a valid user for Example Facilities until the end of the year but will need to validate for Example Networks on 1 April.","title":"Periodic validation of user\u2019s contact information"},{"location":"howto/organizational_policy/#multiple-email-addresses-per-user","text":"Users may have multiple email addresses associated with their account. They must select one address as the primary address and this will be used for notifications. This is managed in each user's own profile, which is located in the hamburger menu by the user's username. Each email address can only be associated with one user. When a user with multiple email addresses associated with their account wants to remove the primary address, they will have to select another address as the primary address.","title":"Multiple email addresses per user"},{"location":"howto/peeringdb-py/","text":"HOWTO: Install peeringdb-py You can install peeringdb-py on a wide selection of operating systems. Users have installed it on several Linux distributions, macOS, and Windows Subsystem for Linux. It will give you a local version of PeeringDB\u2019s SQL database. Unlike the PeeringDB API, the SQL data structure might change without notice. Please do not build tools that make SQL queries. We suggest using our library to make API calls on your local cache. We maintain the library and commit to maintaining the API functionality, even if the underlying database structure changes. Please let us know if you find a query that is only possible with SQL and not via the API. Either create an issue in GitHub , or send a mail describing the problems to support@peeringdb.com . PeeringDB credentials You only need a PeeringDB account if you want to synchronize the contact information to your peeringdb-py cache. If you want to synchronize the whole database, including the contact data, you will need an API Key. If you are installing peeringdb-py for organizational use you should use an organizational API Key. You can use an API Key tied to a user account for personal use. We have a HOWTO guide for API Keys . Software requirements You must ensure these these packages are installed to install and use peeringdb-py : - git - pip - python - virtualenv You will also need to have a database installed. The configuration defaults to using SQLite. Database peeringdb-py \u2019s defaults to an SQLite3 database. You can choose to use a different database. If you want to do this you must adjust the database engine statement in the config.yaml , which is placed in your .peeringdb/config.yaml , which sits in your home directory. Whichever database you choose, it must use UTF-8 as the character set. Installation instructions for peeringdb-py Create a directory for peeringdb-py and go there mkdir ~/peeringdb-py && cd ~/peeringdb-py Create a virtual environment virtualenv --python=python3 pdbvenv Activate the virtual environment source pdbvenv/bin/activate Install peeringdb-py Run pip to install the local cache and Django. sh pip install --upgrade pip setuptools pip install peeringdb django-peeringdb # check for which version of django suits you # when in doubt use the LTS version from https://www.djangoproject.com/download/ pip install \"django>=3.2,<3.3\" Create a peeringdb-py configuration file peeringdb config set -n Edit your configuration edit [HOME]/.peeringdb/config.yaml . Make sure you adjust the directory name. Replace [HOME] with the relevant file path. Replace [CENSORED] with your own API Key, if you are authenticating. Remove [CENSORED] if you choose to remain anonymous. Anonymous users cannot see some contact information. orm: backend: django_peeringdb database: engine: sqlite3 host: '' name: [HOME]/peeringdb-py/peeringdb.sqlite3 password: '' port: 0 user: '' migrate: true secret_key: '' sync: api_key: [CENSORED] only: [] password: '' strip_tz: 1 timeout: 0 url: https://www.peeringdb.com/api user: '' Check that the software is installed This will confirm that peeringdb-py is running by showing you the software version: peeringdb --version You will see something like: peeringdb 1.2.1.1 This will confirm that Django is running by showing you the software version: django-admin --version You will see something like: 2.2.28 This will show that you have django-peeringdb installed and what version it is. pip freeze | grep django-peeringdb You will see something like this: django-peeringdb==2.14.1 Synchronize your new local cache This will synchronize your local cache with the server and tell you how long it took. time peeringdb sync You will see something like this: real 14m47.515s user 14m27.077s sys 0m1.939s If you wait and then synchronize again you'll get the changes since your initial sync. The process does not pull the full database, making it a very efficient update process. You will see a faster synchronization for updates than the initial pull. time peeringdb sync The times you see will look something like this: real 0m3.110s user 0m1.074s sys 0m0.088s Fetch private data The initial sync will happen from the public cache, which does not contain data that isn't available to unauthenticated requests, such as network contacts that are set to Users visibility. In order to fetch this data you can pass the --fetch-private argument. Note that you will need to have valid authentication set up for this (preferably with an API key), for example: peeringdb sync --fetch-private Automatically refreshing data You can schedule automatic database updates by creating an entry in your crontab. We recommend synchronizing every hour. You should not synchronize on the hour but offset at a random minute in the hour. This distributes users across the hour and reduces the burden on the server. This will open your default editor and allow you to create a scheduled task. crontab -e Place this entry in your crontab and save the file, changing [HOME] to the relevant file path. 00 * * * * sleep $[RANDOM\\%300] ; cd [HOME]/peeringdb-py ; touch peeringdb.sync.log ; date >> peeringdb.sync.log ; ./pdbvenv/bin/peeringdb sync >> peeringdb.sync.log 2>&1 Confirm what is scheduled: crontab -l Upgrade peeringdb-py to the latest version sh pip install --upgrade peeringdb django-peeringdb Example usage The SQL data structure might change without notice. Please do not build tools that make SQL queries. We suggest using our library to make API calls on your local cache. We maintain the library and commit to maintaining the API functionality, even if the underlying database structure changes.","title":"HOWTO: Install peeringdb-py"},{"location":"howto/peeringdb-py/#howto-install-peeringdb-py","text":"You can install peeringdb-py on a wide selection of operating systems. Users have installed it on several Linux distributions, macOS, and Windows Subsystem for Linux. It will give you a local version of PeeringDB\u2019s SQL database. Unlike the PeeringDB API, the SQL data structure might change without notice. Please do not build tools that make SQL queries. We suggest using our library to make API calls on your local cache. We maintain the library and commit to maintaining the API functionality, even if the underlying database structure changes. Please let us know if you find a query that is only possible with SQL and not via the API. Either create an issue in GitHub , or send a mail describing the problems to support@peeringdb.com .","title":"HOWTO: Install peeringdb-py"},{"location":"howto/peeringdb-py/#peeringdb-credentials","text":"You only need a PeeringDB account if you want to synchronize the contact information to your peeringdb-py cache. If you want to synchronize the whole database, including the contact data, you will need an API Key. If you are installing peeringdb-py for organizational use you should use an organizational API Key. You can use an API Key tied to a user account for personal use. We have a HOWTO guide for API Keys .","title":"PeeringDB credentials"},{"location":"howto/peeringdb-py/#software-requirements","text":"You must ensure these these packages are installed to install and use peeringdb-py : - git - pip - python - virtualenv You will also need to have a database installed. The configuration defaults to using SQLite.","title":"Software requirements"},{"location":"howto/peeringdb-py/#database","text":"peeringdb-py \u2019s defaults to an SQLite3 database. You can choose to use a different database. If you want to do this you must adjust the database engine statement in the config.yaml , which is placed in your .peeringdb/config.yaml , which sits in your home directory. Whichever database you choose, it must use UTF-8 as the character set.","title":"Database"},{"location":"howto/peeringdb-py/#installation-instructions-for-peeringdb-py","text":"","title":"Installation instructions for peeringdb-py"},{"location":"howto/peeringdb-py/#create-a-directory-for-peeringdb-py-and-go-there","text":"mkdir ~/peeringdb-py && cd ~/peeringdb-py","title":"Create a directory for peeringdb-py and go there"},{"location":"howto/peeringdb-py/#create-a-virtual-environment","text":"virtualenv --python=python3 pdbvenv","title":"Create a virtual environment"},{"location":"howto/peeringdb-py/#activate-the-virtual-environment","text":"source pdbvenv/bin/activate","title":"Activate the virtual environment"},{"location":"howto/peeringdb-py/#install-peeringdb-py","text":"Run pip to install the local cache and Django. sh pip install --upgrade pip setuptools pip install peeringdb django-peeringdb # check for which version of django suits you # when in doubt use the LTS version from https://www.djangoproject.com/download/ pip install \"django>=3.2,<3.3\"","title":"Install peeringdb-py"},{"location":"howto/peeringdb-py/#create-a-peeringdb-py-configuration-file","text":"peeringdb config set -n","title":"Create a peeringdb-py configuration file"},{"location":"howto/peeringdb-py/#edit-your-configuration","text":"edit [HOME]/.peeringdb/config.yaml . Make sure you adjust the directory name. Replace [HOME] with the relevant file path. Replace [CENSORED] with your own API Key, if you are authenticating. Remove [CENSORED] if you choose to remain anonymous. Anonymous users cannot see some contact information. orm: backend: django_peeringdb database: engine: sqlite3 host: '' name: [HOME]/peeringdb-py/peeringdb.sqlite3 password: '' port: 0 user: '' migrate: true secret_key: '' sync: api_key: [CENSORED] only: [] password: '' strip_tz: 1 timeout: 0 url: https://www.peeringdb.com/api user: ''","title":"Edit your configuration"},{"location":"howto/peeringdb-py/#check-that-the-software-is-installed","text":"This will confirm that peeringdb-py is running by showing you the software version: peeringdb --version You will see something like: peeringdb 1.2.1.1 This will confirm that Django is running by showing you the software version: django-admin --version You will see something like: 2.2.28 This will show that you have django-peeringdb installed and what version it is. pip freeze | grep django-peeringdb You will see something like this: django-peeringdb==2.14.1","title":"Check that the software is installed"},{"location":"howto/peeringdb-py/#synchronize-your-new-local-cache","text":"This will synchronize your local cache with the server and tell you how long it took. time peeringdb sync You will see something like this: real 14m47.515s user 14m27.077s sys 0m1.939s If you wait and then synchronize again you'll get the changes since your initial sync. The process does not pull the full database, making it a very efficient update process. You will see a faster synchronization for updates than the initial pull. time peeringdb sync The times you see will look something like this: real 0m3.110s user 0m1.074s sys 0m0.088s","title":"Synchronize your new local cache"},{"location":"howto/peeringdb-py/#fetch-private-data","text":"The initial sync will happen from the public cache, which does not contain data that isn't available to unauthenticated requests, such as network contacts that are set to Users visibility. In order to fetch this data you can pass the --fetch-private argument. Note that you will need to have valid authentication set up for this (preferably with an API key), for example: peeringdb sync --fetch-private","title":"Fetch private data"},{"location":"howto/peeringdb-py/#automatically-refreshing-data","text":"You can schedule automatic database updates by creating an entry in your crontab. We recommend synchronizing every hour. You should not synchronize on the hour but offset at a random minute in the hour. This distributes users across the hour and reduces the burden on the server. This will open your default editor and allow you to create a scheduled task. crontab -e Place this entry in your crontab and save the file, changing [HOME] to the relevant file path. 00 * * * * sleep $[RANDOM\\%300] ; cd [HOME]/peeringdb-py ; touch peeringdb.sync.log ; date >> peeringdb.sync.log ; ./pdbvenv/bin/peeringdb sync >> peeringdb.sync.log 2>&1 Confirm what is scheduled: crontab -l","title":"Automatically refreshing data"},{"location":"howto/peeringdb-py/#upgrade-peeringdb-py-to-the-latest-version","text":"sh pip install --upgrade peeringdb django-peeringdb","title":"Upgrade peeringdb-py to the latest version"},{"location":"howto/peeringdb-py/#example-usage","text":"The SQL data structure might change without notice. Please do not build tools that make SQL queries. We suggest using our library to make API calls on your local cache. We maintain the library and commit to maintaining the API functionality, even if the underlying database structure changes.","title":"Example usage"},{"location":"howto/run_development_container/","text":"HOWTO: Setup a PeeringDB Development Environment Install and run Docker PeeringDB runs inside a Docker container. Docker Compose is used to build both the PeeringDB container and a MySQL server container for testing. Make sure the docker and docker-compose commands are installed on your system, and that the Docker Engine is running. Docker Desktop for Mac/Windows (>=2.5.0.1) includes these tools and they are also available for various POSIX systems. Ensure that docker-compose version indicates at least version 1.25.4, and that docker version indicates Engine version at least 19.03.5 and does not report any connection errors to Docker Engine. Connection errors may indicate a need to start the engine. Fork the PeeringDB repository, clone it, set upstream Your development and experimentation with the PeeringDB code base should take place in a fork of the project . When you have improvements or fixes to share, you will be able to point other developers to your code, or submit a pull request. Navigate to https://github.com/peeringdb/peeringdb . In the top-right corner of the page, click Fork . On GitHub, navigate to your fork of the PeeringDB repository. Above the list of files, click Code . Copy the HTTPS URL. It will be something like: https://github.com/YOUR-USERNAME/peeringdb.git Perform the following: PDBHOME=~/src/peeringdb # Adjust as appropriate to your environment. mkdir -p $PDBHOME && cd $PDBHOME git clone https://github.com/YOUR-USERNAME/peeringdb.git cd $PDBHOME/peeringdb # Henceforth commands on this page assume you are in this working directory. git remote add upstream https://github.com/peeringdb/peeringdb.git git remote -v > origin https://github.com/YOUR-USERNAME/peeringdb.git (fetch) > origin https://github.com/YOUR-USERNAME/peeringdb.git (push) > upstream https://github.com/peeringdb/peeringdb.git (fetch) > upstream https://github.com/peeringdb/peeringdb.git (push) Keep your fork up-to-date with the upstream repository: https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/syncing-a-fork git fetch upstream git checkout master # or other branch you are working on git merge upstream/master Create environment variable override file Environment variables for the server config can be added in Ctl/dev/.env . This file can be empty which will make the django SECRET_KEY ephemeral, but the file does need to exist. Empty file: touch Ctl/dev/.env Alternatively, create a SECRET_KEY using uuidgen or replace with something similar on your system: echo SECRET_KEY=\\\"$(uuidgen)\\\" > Ctl/dev/.env If you are serving from anywhere but localhost you will also need to specify the SESSION_COOKIE_DOMAIN echo \"SESSION_COOKIE_DOMAIN=example.com\" >> Ctl/dev/.env If you want to enable OIDC's JWT RS256 token signing, you need to specify the file with the RSA secret key found inside the container with the OIDC_RSA_PRIVATE_KEY_ACTIVE_PATH variable. You can create the key with open ssl and place it in Ctl/dev/jwks/filename.key or let the build system auto generated from the path specified with the variable. echo \"OIDC_RSA_PRIVATE_KEY_ACTIVE_PATH=/srv/www.peeringdb.com/var/jwks/oidc.key\" >> Ctl/dev/.env Build the container and set up your developement instance ./Ctl/dev/compose.sh build peeringdb ./Ctl/dev/compose.sh up -d database ./Ctl/dev/run.sh migrate # Re-run if there are errors. The database may not yet have started. ./Ctl/dev/run.sh loaddata fixtures/initial_data.json ./Ctl/dev/run.sh createsuperuser ./Ctl/dev/run.sh createcachetable ./Ctl/dev/compose.sh up -d peeringdb On some docker versions build can fail with a ERROR: Service 'peeringdb' failed to build: failed to export image: failed to create image: failed to get layer error. Simply running it again should fix the issue. If you want a copy of the current public production data, run this command which often takes more than 15 minutes: ./Ctl/dev/run.sh pdb_load_data --commit After it is done you should have a PeeringDB instance exposed on port :8000 : http://localhost:8000/ (should you want to change this port you can do so by setting the environment variable DJANGO_PORT ) Migration notes Organization management of OAuth applications Once migration 0085 has been applied you should override the OAUTH2_PROVIDER_APPLICATION_MODEL environment variable to \"peeringdb_server.OAuthApplication\" in order to enable organization management of oauth applications. Warning: Overriding before migration 0085 has been applied will result in the following migration error and a broken migration state. Related model 'peeringdb_server.oauthapplication` cannot be resolved Stop and start the containers ./Ctl/dev/compose.sh down ./Ctl/dev/compose.sh up -d Environment variables Edit Ctl/dev/.env and then stop and start the containers. PDB_NO_MIGRATE : If set to anything, will skip migrations when running the uwsgi command, otherwise, migrations will always be applied first thing while running uwsgi . DATABASE_ENGINE default \"mysql\" DATABASE_HOST default \"127.0.0.1\" DATABASE_PORT default \"\" DATABASE_NAME default \"peeringdb\" DATABASE_USER default \"peeringdb\" DATABASE_PASSWORD default \"\" EMAIL_HOST default \"localhost\" EMAIL_PORT default \"25\" EMAIL_HOST_USERHOST default \"\" EMAIL_HOST_PASSWORD default \"\" Mount points /srv/www.peeringdb.com/api-cache : api cache /srv/www.peeringdb.com/locale : translations /srv/www.peeringdb.com/mainsite : site settings /srv/www.peeringdb.com/media : media files /srv/www.peeringdb.com/peeringdb_server : server code /srv/www.peeringdb.com/static : static files /srv/www.peeringdb.com/var/log : log files Entry point With the exception of some specific commands (see below) the entry point will pass directly to django's manage script. ./Ctl/dev/run.sh help Other options: migrate apply database migrations run_tests run unit tests uwsgi start the uwsgi process /bin/sh to drop to shell inetd run the inetd whois server Contributing your code After testing and carefully code-reviewing your changes, commit and push them to your repository. You can then share the changes with other developers, such as those on the pdb-tech@lists.peeringdb.com mailing list: https://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech . When ready to contribute the change to the project, create a pull request to the main repository along with a description of your goals for the change and/or what you are fixing.","title":"HOWTO: Setup a PeeringDB Development Environment"},{"location":"howto/run_development_container/#howto-setup-a-peeringdb-development-environment","text":"","title":"HOWTO: Setup a PeeringDB Development Environment"},{"location":"howto/run_development_container/#install-and-run-docker","text":"PeeringDB runs inside a Docker container. Docker Compose is used to build both the PeeringDB container and a MySQL server container for testing. Make sure the docker and docker-compose commands are installed on your system, and that the Docker Engine is running. Docker Desktop for Mac/Windows (>=2.5.0.1) includes these tools and they are also available for various POSIX systems. Ensure that docker-compose version indicates at least version 1.25.4, and that docker version indicates Engine version at least 19.03.5 and does not report any connection errors to Docker Engine. Connection errors may indicate a need to start the engine.","title":"Install and run Docker"},{"location":"howto/run_development_container/#fork-the-peeringdb-repository-clone-it-set-upstream","text":"Your development and experimentation with the PeeringDB code base should take place in a fork of the project . When you have improvements or fixes to share, you will be able to point other developers to your code, or submit a pull request. Navigate to https://github.com/peeringdb/peeringdb . In the top-right corner of the page, click Fork . On GitHub, navigate to your fork of the PeeringDB repository. Above the list of files, click Code . Copy the HTTPS URL. It will be something like: https://github.com/YOUR-USERNAME/peeringdb.git Perform the following: PDBHOME=~/src/peeringdb # Adjust as appropriate to your environment. mkdir -p $PDBHOME && cd $PDBHOME git clone https://github.com/YOUR-USERNAME/peeringdb.git cd $PDBHOME/peeringdb # Henceforth commands on this page assume you are in this working directory. git remote add upstream https://github.com/peeringdb/peeringdb.git git remote -v > origin https://github.com/YOUR-USERNAME/peeringdb.git (fetch) > origin https://github.com/YOUR-USERNAME/peeringdb.git (push) > upstream https://github.com/peeringdb/peeringdb.git (fetch) > upstream https://github.com/peeringdb/peeringdb.git (push) Keep your fork up-to-date with the upstream repository: https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/syncing-a-fork git fetch upstream git checkout master # or other branch you are working on git merge upstream/master","title":"Fork the PeeringDB repository, clone it, set upstream"},{"location":"howto/run_development_container/#create-environment-variable-override-file","text":"Environment variables for the server config can be added in Ctl/dev/.env . This file can be empty which will make the django SECRET_KEY ephemeral, but the file does need to exist. Empty file: touch Ctl/dev/.env Alternatively, create a SECRET_KEY using uuidgen or replace with something similar on your system: echo SECRET_KEY=\\\"$(uuidgen)\\\" > Ctl/dev/.env If you are serving from anywhere but localhost you will also need to specify the SESSION_COOKIE_DOMAIN echo \"SESSION_COOKIE_DOMAIN=example.com\" >> Ctl/dev/.env If you want to enable OIDC's JWT RS256 token signing, you need to specify the file with the RSA secret key found inside the container with the OIDC_RSA_PRIVATE_KEY_ACTIVE_PATH variable. You can create the key with open ssl and place it in Ctl/dev/jwks/filename.key or let the build system auto generated from the path specified with the variable. echo \"OIDC_RSA_PRIVATE_KEY_ACTIVE_PATH=/srv/www.peeringdb.com/var/jwks/oidc.key\" >> Ctl/dev/.env","title":"Create environment variable override file"},{"location":"howto/run_development_container/#build-the-container-and-set-up-your-developement-instance","text":"./Ctl/dev/compose.sh build peeringdb ./Ctl/dev/compose.sh up -d database ./Ctl/dev/run.sh migrate # Re-run if there are errors. The database may not yet have started. ./Ctl/dev/run.sh loaddata fixtures/initial_data.json ./Ctl/dev/run.sh createsuperuser ./Ctl/dev/run.sh createcachetable ./Ctl/dev/compose.sh up -d peeringdb On some docker versions build can fail with a ERROR: Service 'peeringdb' failed to build: failed to export image: failed to create image: failed to get layer error. Simply running it again should fix the issue. If you want a copy of the current public production data, run this command which often takes more than 15 minutes: ./Ctl/dev/run.sh pdb_load_data --commit After it is done you should have a PeeringDB instance exposed on port :8000 : http://localhost:8000/ (should you want to change this port you can do so by setting the environment variable DJANGO_PORT )","title":"Build the container and set up your developement instance"},{"location":"howto/run_development_container/#migration-notes","text":"","title":"Migration notes"},{"location":"howto/run_development_container/#organization-management-of-oauth-applications","text":"Once migration 0085 has been applied you should override the OAUTH2_PROVIDER_APPLICATION_MODEL environment variable to \"peeringdb_server.OAuthApplication\" in order to enable organization management of oauth applications. Warning: Overriding before migration 0085 has been applied will result in the following migration error and a broken migration state. Related model 'peeringdb_server.oauthapplication` cannot be resolved","title":"Organization management of OAuth applications"},{"location":"howto/run_development_container/#stop-and-start-the-containers","text":"./Ctl/dev/compose.sh down ./Ctl/dev/compose.sh up -d","title":"Stop and start the containers"},{"location":"howto/run_development_container/#environment-variables","text":"Edit Ctl/dev/.env and then stop and start the containers. PDB_NO_MIGRATE : If set to anything, will skip migrations when running the uwsgi command, otherwise, migrations will always be applied first thing while running uwsgi . DATABASE_ENGINE default \"mysql\" DATABASE_HOST default \"127.0.0.1\" DATABASE_PORT default \"\" DATABASE_NAME default \"peeringdb\" DATABASE_USER default \"peeringdb\" DATABASE_PASSWORD default \"\" EMAIL_HOST default \"localhost\" EMAIL_PORT default \"25\" EMAIL_HOST_USERHOST default \"\" EMAIL_HOST_PASSWORD default \"\"","title":"Environment variables"},{"location":"howto/run_development_container/#mount-points","text":"/srv/www.peeringdb.com/api-cache : api cache /srv/www.peeringdb.com/locale : translations /srv/www.peeringdb.com/mainsite : site settings /srv/www.peeringdb.com/media : media files /srv/www.peeringdb.com/peeringdb_server : server code /srv/www.peeringdb.com/static : static files /srv/www.peeringdb.com/var/log : log files","title":"Mount points"},{"location":"howto/run_development_container/#entry-point","text":"With the exception of some specific commands (see below) the entry point will pass directly to django's manage script. ./Ctl/dev/run.sh help Other options: migrate apply database migrations run_tests run unit tests uwsgi start the uwsgi process /bin/sh to drop to shell inetd run the inetd whois server","title":"Entry point"},{"location":"howto/run_development_container/#contributing-your-code","text":"After testing and carefully code-reviewing your changes, commit and push them to your repository. You can then share the changes with other developers, such as those on the pdb-tech@lists.peeringdb.com mailing list: https://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech . When ready to contribute the change to the project, create a pull request to the main repository along with a description of your goals for the change and/or what you are fixing.","title":"Contributing your code"},{"location":"howto/search/","text":"HOWTO: Get Started with Search in PeeringDB Introduction to PeeringDB PeeringDB is a publicly available network database that is the go-to location for interconnection data. The database facilitates global network connections at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and it serves as a starting point for interconnection decisions. This online database is a non-profit, community-driven effort that encourages the exchange of Peering-related information and is totally managed and maintained by volunteers. It's a tool for the Internet's growth and enhancement. Why use PeeringDB to search for networks, exchange and data centers? About a third of networks (Autonomous Systems) use PeeringDB to share information about how they interconnect. You can use PeeringDB to find information about other networks, exchanges, and more. You make your services easier to find when you contribute your data to PeeringDB. You don't need an account to use the basic search functionality. But if you want to access private contact information and use advanced search features, like radius search, you'll need to sign up for an account. How to search for campuses, carriers, exchanges, facilities and networks in PeeringDB There is a s simple search box on the front page of PeeringDB. You can use it to search for campuses, carriers, exchanges, facilities and networks listed in PeeringDB by simply entering the name you want. Let\u2019s demonstrate with some examples to see how this works. Place name normalization PeeringDB normalizes place names at the presentation layer. For example, M\u00fcnchen will always be normalized to Munich in search output. This ensures that users can get all the results for Munich in a single search. Users can search using multiple names. As long as the name selected is well known, the search will be centered on the correct place. Networks For this example, we have this network KENET which is a non-profit operator for education and research and we want to search for it on PeeringDB. There are two ways to search for networks in PeeringDB: Name search You can search for networks by using the name of the networks by: - Entering the name of the network as seen below - From the search result, under the Networks section, locate the network you have searched - It would be visible if it is in the PeeringDB database ASN search You can search for networks using their ASN by: - Entering the name of the network as seen below, for the example below the ASN is (36914) - From the search result, under the Networks section, locate the network you have searched Note : Either of the two methods will get the same search results. Exchanges For this example, let\u2019s consider this exchange UNY-IX which is an open Internet exchange located in Universitas Negeri Yogyakarta. To search for an exchange: - Enter the name of the exchange as shown below - From the search result, under the exchanges section, locate the exchange you have searched Facilities Data centers are also referred to as facilities. For this example, let\u2019s consider this university University of Oslo which is an institution in Oslo. To search for a facility: - Enter the name of the data center or facility as shown below - From the search result, under the facilities section, locate the facility or data center you have searched How to search for your own organization If your organization already uses PeeringDB, when you are logged in to the website you can always find your own information using the self search. If you are not logged in, these links will take you to some PeeringDB examples objects. Organization Campus Carrier Facility Internet Exchange Point Network The self identifier also works for queries made using our API. We encourage the use of multi-factor authentication . This means using an API Key instead of basic authentication for API queries. How to use the search in PeeringDB extension The PeeringDB search extension is a free to use Google Chrome extension with which you can use to search for ASNs, networks, and exchanges in PeeringDB. To get started, go to the Chrome Web Store and download the extension, then enable it and add it to your extension bar. There are two ways to use the extension once it has been enabled: Using the Extension Bar Icon : Click the icon and type your search term into the box. The search will open in a new tab with the search result. Below is the result: Using the Context Menu : Right-click on any text on a page and select \"Search in PeeringDB\". The search will open in a new tab with the search result. Below is the result: If the query or highlighted text contains a number, the extension will attempt to find an ASN. How to search based on a partial name You can search based on a partial name. When an organization, network, facility or exchange name has two parts, you can search for just the first or second part and then select from all the organizations that share that name. This makes it easier to find the organization you want. This can also be helpful in a situation where you can not remember the name of the organization in full. In the example below, we want to search for \u201cinternet archive\u201d. We will search for it with a single part and not with the full name. In the search box, input \u201carchive''. This brings out a search result that have similar parts in their names. You can now search through the results to find the what you want. What is an advanced search? Advanced search in PeeringDB lets you explicitly filter a search location, network presence, service level and a wide range of other features. You get the results you\u2019re looking for and can export them in structured data formats (JSON or CSV), so you can import the data into tools that will help you make decisions. Note : You need to be logged in to PeeringDB in order to use some of the advanced search features, including the radius search. Let\u2019s take a look at this example below to demonstrate how advanced search works. We are going to search for an exchange within a particular region. On the front page of PeeringDB you will see the Advanced Search box which you can use to search for campuses, exchanges, facilities and networks that are in PeeringDB. Click on the Advanced Search link. This takes you to the advanced search landing page. The search page shows the campus, exchanges, facilities, networks, and organizations tabs. Go to the Exchanges tab, in the country field select a country of your choice by scrolling through the different options. On the right hand side, in the Network Presence field, enter the name of the network. You can follow the example shown below and add KENET. Click on the drop down list that appears as you input the network name. Click on Search. Scroll down to view information regarding the exchange that you searched for. Click on JSON or CSV to download the information in a structured format. Geographic search As new facilities are created in our database they will be linked to geographic coordinates. PeeringDB has improved search by changing the way it records data for location in its database. You can now search for facilities with a distance radius of a chosen coordinate. How to search for a campus You can search for a campus of facilities using the Advanced Search interface. Users can search from a country and city, and select a radius in kilometers or miles. Of course, you can achieve the same results using the API or the web interface, which means you can integrate this feature into your own tools. Note : You need to be logged in to PeeringDB in order to search for a campus of facilities. How to search for facilities within a given radius You can search for facilities within a given radius, using the Advanced Search interface. Users can search from a country and city, and select a radius in kilometers or miles. Of course, you can achieve the same results using the API or the web interface, which means you can integrate this feature into your own tools. Note : You need to be logged in to PeeringDB in order to search for facilities within a given radius. Login in or register an account on PeeringDB. On the front page of PeeringDB, click on the Advanced Search link. Go to the Facilities Tab and in the city/postal field add a city or postal of your choice. In the country field select a country of your choice. In the Within Distance field add a specified distance of your choice. On the right hand side of the page, click on search. Scroll down to view the information you searched for. The search result will bring up facilities which are in that country, city and state. You can download your information in a JSON or CSV format. Querying with the PeeringDB API Throughout this article up to this point, we have been talking on how to use PeeringDB to find information about potential peers, and then after peering has been arranged, using PeeringDB to obtain the peering details. The PeeringDB website is very helpful in these regards, but using the website still requires a lot of manual work. It\u2019s also possible to use the PeeringDB API to automate some parts of this. Why use the PeeringDB API? The PeeringDB API makes it easy to integrate PeeringDB in your environment. The PeeringDB database can be queried using a REST API. REST allows a client to request information from a server over HTTP or HTTPS. The server then returns the requested information in JSON format. Object types Each object has an associated shorthand tag you can use. Object types are not case sensitive and the output is an array. For example: https://www.peeringdb.com/api/OBJ . The endpoint is: /api/OBJ . Below are the categories of objects types (OBJ) in PeeringDB: - Basic Objects : org, fac, ix, net, poc - Derived Objects : ixlan, ixpfx, netixlan, netfac Basic objects Below is a description of what each of the object types mean and what information they return org : Root object for fac, ix, net, this holds information about an organization. fac : Describes a facility / colocation record, more useful information are in derived records netfac. ix : Describes an exchange, more useful information are in derived records ixlan, ixpfx and netixlan. net : Describes a network / ASN, more useful information are in netfac and netixlan. poc : Describes various role accounts (point of contact), this is currently only for net objects. as_set : Array of all AS-SETs corresponding to a network / ASN, this was introduced recently. Derived objects Below is a description of what each of the object types mean and what information they return. Ixlan : Describes the LAN of an ix, one ix may have multiple ixlan. This feature may go away in PeeringDB 3.0. ixpfx : Describes the IP range (IPv4 and IPv6) for an ixlan, one ixlan may have multiple ixpfx. netixlan : Describes the presence of a network at an exchange. netfac : Describes the presence of a network at a facility. Authentication Authentication is done through basic HTTP authorization. People who are accessing the API as a guest do not need any authentication. For example: curl -sG https://username:password@www.peeringdb.com/api/net/961 curl -u username:password https://www.peeringdb.com/api/net/961 Note : Access to contact information may be restricted if you are using the API as a guest without authentication. API usage is subject to query limits and these are set at a lower threshold for unauthenticated users. Making a request When making a request, the URL base is added with /api/ , followed by the object type and, if applicable, the object primary key (if applicable). For example: https://www.peeringdb.com/api/OBJ/id . If you want to select the output format, either use the Accept: HTTP header or use the extension type parameter: - Accept Header: Accept: application/json - Extension type: https://www.peeringdb.com/api/network/42.json Operations Using the GET operation you can retrieve information from the PeeringDB database. You can retrieve both a single object and multiple objects in an array. Let\u2019s look at each of them individually. Single object To retrieve a single object you need to use this URL: https://www.peeringdb.com/api/OBJ/ID with this endpoint GET: /api/OBJ/id . The ID is a unique identifier and should be added to the URL when retrieving a single object. Let\u2019s look at an example: - HTTP: GET /api/OBJ/38 where 38 is the ID - curl: curl -H \"Accept: application/json\" -X GET https://<username>:<password>@peeringdb.com/api/OBJ/38 There are optional parameters you can add to your URL: - str : which retrieves a comma separated list of field names - only matching fields will be returned in the data - int : which retrieves two nested sets and objects Nested sets and objects A nested set or object is any field ending in the suffix: set. For example: net_set will hold network objects. The naming schema of the field will always tell you which type of object the set is holding and will correspond with the object's endpoint on the API <object_type>_set . So a set called net_set will hold network objects (API endpoint /net). Note : unlike GET multiple, depth here will also expand single relationships in addition to sets. So net_id would get expanded into a network object. Unexpanded { ... \"net_id\" : 1 } Expanded { ... \"net_id\" : 1 \"net\" : { ... network object ... } } Depth - 0: don't expand anything (default) - 1: expand all first level sets to ids - 2: expand all first level sets to objects Multiple objects To retrieve a single object you need to use this URL: https://www.peeringdb.com/api/OBJ/ with this endpoint GET: /api/OBJ/ . Let\u2019s look at an example: - HTTP: GET /api/OBJ/ which is the endpoint - curl: curl -X GET https://<username>:<password>@www.peeringdb.com/api/OBJ There are optional parameters you can add to your URL: - limit : int limits rows in the result set - skip : int skips n rows in the result set - depth : int nested sets will be loaded (slow) - fields : str comma separated list of field names - only matching fields will be returned in the data - since : int retrieve all objects updated since specified time (unix timestamp, seconds) - [field_name] : int|string queries for fields with matching value Real world use cases We will show you different use cases on how to use the PeeringDB API. How do I query by ASN? To query for an ASN using the PeeringDB API, you will need to use this URL: GET https://www.peeringdb.com/api/net?asn=42 , where asn=42 is the query parameter. How do I query for an IXs in a particular state? To query for IXs based in a state (in countries with a state system), you will need to use a URL like this: GET https://www.peeringdb.com/api/ixfac?fac__state=NSW , where fac__state tells the API to look at the state field in the facility record and NSW is the normalized code for the state. In this example, NSW is the Australian state of New South Wales. Similarly, https://www.peeringdb.com/api/ixfac?fac__state=NV gets IXs in facilities in the US state of Nevada. Using curl Use this curl example to get this specific network. Copy and paste the following to your command line interface: curl GET https://www.peeringdb.com/api/net?asn=42 . Using Python To make use of this Python code, first, you\u2019ll have to first install Python if you don\u2019t have it installed. Then, install pip and requests . After that create a Python file and copy and paste the following code. import requests r = requests.get('https://www.peeringdb.com/api/net?asn=42') print(r.text) with open('output.csv', 'w+') as f: f.write(r.text) From the above code, we make a request to the API using the request module and print out the response which would be in a JSON format. However, reading a JSON file can be quite hectic and tasking so we convert the JSON file to a CSV file. Our CSV file will open in output.csv. Using jq You can use jq to make a request to your API and get your output in a CSV format. First, you need to install Jq . Next, we use this curl command to prepare our JSON file. Change to a directory and copy and paste this code on your terminal: curl https://www.peeringdb.com/api/net?asn=42 > test.json . This creates a new file named test.json. To convert the JSON input file to the CSV format, copy and paste the following command: jq -r '(.data[0] | keys_unsorted), (.data[] | to_entries | map(.value))|@csv' test.json Using an online converter Alternatively you can use an online tool such as https://www.convertcsv.com/json-to-csv.htm to convert the raw JSON file to CSV. Note : For the purpose of this article we will focus on the curl method but you can conveniently try out the other proposed methods. How to get all the objects owned by https://www.peeringdb.com/net/961 and convert the data to CSV? To get all the objects owned by this https://www.peeringdb.com/net/961 using the PeeringDB API. Copy and paste the following to your command line interface: curl GET https://www.peeringdb.com/net/961 . I want the list of networks and their 'type' peering at MICE in Minneapolis. To get the list of networks and their type peering at Mice in Minneapolis, copy and paste the following command in your terminal: curl -s -X GET https://www.peeringdb.com/api/net?ix=446&__in=Minneapolis | jq '.data[] . How to find all the exchanges where my organization has a presence? Use this curl example. Copy and paste the following to your command line interface: curl -s -X GET https://www.peeringdb.com/api/netixlan\\?ixlan_id=62 | jq '.data[]' .","title":"HOWTO: Get Started with Search in PeeringDB"},{"location":"howto/search/#howto-get-started-with-search-in-peeringdb","text":"","title":"HOWTO: Get Started with Search in PeeringDB"},{"location":"howto/search/#introduction-to-peeringdb","text":"PeeringDB is a publicly available network database that is the go-to location for interconnection data. The database facilitates global network connections at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and it serves as a starting point for interconnection decisions. This online database is a non-profit, community-driven effort that encourages the exchange of Peering-related information and is totally managed and maintained by volunteers. It's a tool for the Internet's growth and enhancement.","title":"Introduction to PeeringDB"},{"location":"howto/search/#why-use-peeringdb-to-search-for-networks-exchange-and-data-centers","text":"About a third of networks (Autonomous Systems) use PeeringDB to share information about how they interconnect. You can use PeeringDB to find information about other networks, exchanges, and more. You make your services easier to find when you contribute your data to PeeringDB. You don't need an account to use the basic search functionality. But if you want to access private contact information and use advanced search features, like radius search, you'll need to sign up for an account.","title":"Why use PeeringDB to search for networks, exchange and data centers?"},{"location":"howto/search/#how-to-search-for-campuses-carriers-exchanges-facilities-and-networks-in-peeringdb","text":"There is a s simple search box on the front page of PeeringDB. You can use it to search for campuses, carriers, exchanges, facilities and networks listed in PeeringDB by simply entering the name you want. Let\u2019s demonstrate with some examples to see how this works.","title":"How to search for campuses, carriers, exchanges, facilities and networks in PeeringDB"},{"location":"howto/search/#place-name-normalization","text":"PeeringDB normalizes place names at the presentation layer. For example, M\u00fcnchen will always be normalized to Munich in search output. This ensures that users can get all the results for Munich in a single search. Users can search using multiple names. As long as the name selected is well known, the search will be centered on the correct place.","title":"Place name normalization"},{"location":"howto/search/#networks","text":"For this example, we have this network KENET which is a non-profit operator for education and research and we want to search for it on PeeringDB. There are two ways to search for networks in PeeringDB:","title":"Networks"},{"location":"howto/search/#name-search","text":"You can search for networks by using the name of the networks by: - Entering the name of the network as seen below - From the search result, under the Networks section, locate the network you have searched - It would be visible if it is in the PeeringDB database","title":"Name search"},{"location":"howto/search/#asn-search","text":"You can search for networks using their ASN by: - Entering the name of the network as seen below, for the example below the ASN is (36914) - From the search result, under the Networks section, locate the network you have searched Note : Either of the two methods will get the same search results.","title":"ASN search"},{"location":"howto/search/#exchanges","text":"For this example, let\u2019s consider this exchange UNY-IX which is an open Internet exchange located in Universitas Negeri Yogyakarta. To search for an exchange: - Enter the name of the exchange as shown below - From the search result, under the exchanges section, locate the exchange you have searched","title":"Exchanges"},{"location":"howto/search/#facilities","text":"Data centers are also referred to as facilities. For this example, let\u2019s consider this university University of Oslo which is an institution in Oslo. To search for a facility: - Enter the name of the data center or facility as shown below - From the search result, under the facilities section, locate the facility or data center you have searched","title":"Facilities"},{"location":"howto/search/#how-to-search-for-your-own-organization","text":"If your organization already uses PeeringDB, when you are logged in to the website you can always find your own information using the self search. If you are not logged in, these links will take you to some PeeringDB examples objects. Organization Campus Carrier Facility Internet Exchange Point Network The self identifier also works for queries made using our API. We encourage the use of multi-factor authentication . This means using an API Key instead of basic authentication for API queries.","title":"How to search for your own organization"},{"location":"howto/search/#how-to-use-the-search-in-peeringdb-extension","text":"The PeeringDB search extension is a free to use Google Chrome extension with which you can use to search for ASNs, networks, and exchanges in PeeringDB. To get started, go to the Chrome Web Store and download the extension, then enable it and add it to your extension bar. There are two ways to use the extension once it has been enabled: Using the Extension Bar Icon : Click the icon and type your search term into the box. The search will open in a new tab with the search result. Below is the result: Using the Context Menu : Right-click on any text on a page and select \"Search in PeeringDB\". The search will open in a new tab with the search result. Below is the result: If the query or highlighted text contains a number, the extension will attempt to find an ASN.","title":"How to use the search in PeeringDB extension"},{"location":"howto/search/#how-to-search-based-on-a-partial-name","text":"You can search based on a partial name. When an organization, network, facility or exchange name has two parts, you can search for just the first or second part and then select from all the organizations that share that name. This makes it easier to find the organization you want. This can also be helpful in a situation where you can not remember the name of the organization in full. In the example below, we want to search for \u201cinternet archive\u201d. We will search for it with a single part and not with the full name. In the search box, input \u201carchive''. This brings out a search result that have similar parts in their names. You can now search through the results to find the what you want.","title":"How to search based on a partial name"},{"location":"howto/search/#what-is-an-advanced-search","text":"Advanced search in PeeringDB lets you explicitly filter a search location, network presence, service level and a wide range of other features. You get the results you\u2019re looking for and can export them in structured data formats (JSON or CSV), so you can import the data into tools that will help you make decisions. Note : You need to be logged in to PeeringDB in order to use some of the advanced search features, including the radius search. Let\u2019s take a look at this example below to demonstrate how advanced search works. We are going to search for an exchange within a particular region. On the front page of PeeringDB you will see the Advanced Search box which you can use to search for campuses, exchanges, facilities and networks that are in PeeringDB. Click on the Advanced Search link. This takes you to the advanced search landing page. The search page shows the campus, exchanges, facilities, networks, and organizations tabs. Go to the Exchanges tab, in the country field select a country of your choice by scrolling through the different options. On the right hand side, in the Network Presence field, enter the name of the network. You can follow the example shown below and add KENET. Click on the drop down list that appears as you input the network name. Click on Search. Scroll down to view information regarding the exchange that you searched for. Click on JSON or CSV to download the information in a structured format.","title":"What is an advanced search?"},{"location":"howto/search/#geographic-search","text":"As new facilities are created in our database they will be linked to geographic coordinates. PeeringDB has improved search by changing the way it records data for location in its database. You can now search for facilities with a distance radius of a chosen coordinate.","title":"Geographic search"},{"location":"howto/search/#how-to-search-for-a-campus","text":"You can search for a campus of facilities using the Advanced Search interface. Users can search from a country and city, and select a radius in kilometers or miles. Of course, you can achieve the same results using the API or the web interface, which means you can integrate this feature into your own tools. Note : You need to be logged in to PeeringDB in order to search for a campus of facilities.","title":"How to search for a campus"},{"location":"howto/search/#how-to-search-for-facilities-within-a-given-radius","text":"You can search for facilities within a given radius, using the Advanced Search interface. Users can search from a country and city, and select a radius in kilometers or miles. Of course, you can achieve the same results using the API or the web interface, which means you can integrate this feature into your own tools. Note : You need to be logged in to PeeringDB in order to search for facilities within a given radius. Login in or register an account on PeeringDB. On the front page of PeeringDB, click on the Advanced Search link. Go to the Facilities Tab and in the city/postal field add a city or postal of your choice. In the country field select a country of your choice. In the Within Distance field add a specified distance of your choice. On the right hand side of the page, click on search. Scroll down to view the information you searched for. The search result will bring up facilities which are in that country, city and state. You can download your information in a JSON or CSV format.","title":"How to search for facilities within a given radius"},{"location":"howto/search/#querying-with-the-peeringdb-api","text":"Throughout this article up to this point, we have been talking on how to use PeeringDB to find information about potential peers, and then after peering has been arranged, using PeeringDB to obtain the peering details. The PeeringDB website is very helpful in these regards, but using the website still requires a lot of manual work. It\u2019s also possible to use the PeeringDB API to automate some parts of this. Why use the PeeringDB API? The PeeringDB API makes it easy to integrate PeeringDB in your environment. The PeeringDB database can be queried using a REST API. REST allows a client to request information from a server over HTTP or HTTPS. The server then returns the requested information in JSON format.","title":"Querying with the PeeringDB API"},{"location":"howto/search/#object-types","text":"Each object has an associated shorthand tag you can use. Object types are not case sensitive and the output is an array. For example: https://www.peeringdb.com/api/OBJ . The endpoint is: /api/OBJ . Below are the categories of objects types (OBJ) in PeeringDB: - Basic Objects : org, fac, ix, net, poc - Derived Objects : ixlan, ixpfx, netixlan, netfac","title":"Object types"},{"location":"howto/search/#basic-objects","text":"Below is a description of what each of the object types mean and what information they return org : Root object for fac, ix, net, this holds information about an organization. fac : Describes a facility / colocation record, more useful information are in derived records netfac. ix : Describes an exchange, more useful information are in derived records ixlan, ixpfx and netixlan. net : Describes a network / ASN, more useful information are in netfac and netixlan. poc : Describes various role accounts (point of contact), this is currently only for net objects. as_set : Array of all AS-SETs corresponding to a network / ASN, this was introduced recently.","title":"Basic objects"},{"location":"howto/search/#derived-objects","text":"Below is a description of what each of the object types mean and what information they return. Ixlan : Describes the LAN of an ix, one ix may have multiple ixlan. This feature may go away in PeeringDB 3.0. ixpfx : Describes the IP range (IPv4 and IPv6) for an ixlan, one ixlan may have multiple ixpfx. netixlan : Describes the presence of a network at an exchange. netfac : Describes the presence of a network at a facility.","title":"Derived objects"},{"location":"howto/search/#authentication","text":"Authentication is done through basic HTTP authorization. People who are accessing the API as a guest do not need any authentication. For example: curl -sG https://username:password@www.peeringdb.com/api/net/961 curl -u username:password https://www.peeringdb.com/api/net/961 Note : Access to contact information may be restricted if you are using the API as a guest without authentication. API usage is subject to query limits and these are set at a lower threshold for unauthenticated users.","title":"Authentication"},{"location":"howto/search/#making-a-request","text":"When making a request, the URL base is added with /api/ , followed by the object type and, if applicable, the object primary key (if applicable). For example: https://www.peeringdb.com/api/OBJ/id . If you want to select the output format, either use the Accept: HTTP header or use the extension type parameter: - Accept Header: Accept: application/json - Extension type: https://www.peeringdb.com/api/network/42.json","title":"Making a request"},{"location":"howto/search/#operations","text":"Using the GET operation you can retrieve information from the PeeringDB database. You can retrieve both a single object and multiple objects in an array. Let\u2019s look at each of them individually.","title":"Operations"},{"location":"howto/search/#single-object","text":"To retrieve a single object you need to use this URL: https://www.peeringdb.com/api/OBJ/ID with this endpoint GET: /api/OBJ/id . The ID is a unique identifier and should be added to the URL when retrieving a single object. Let\u2019s look at an example: - HTTP: GET /api/OBJ/38 where 38 is the ID - curl: curl -H \"Accept: application/json\" -X GET https://<username>:<password>@peeringdb.com/api/OBJ/38 There are optional parameters you can add to your URL: - str : which retrieves a comma separated list of field names - only matching fields will be returned in the data - int : which retrieves two nested sets and objects","title":"Single object"},{"location":"howto/search/#nested-sets-and-objects","text":"A nested set or object is any field ending in the suffix: set. For example: net_set will hold network objects. The naming schema of the field will always tell you which type of object the set is holding and will correspond with the object's endpoint on the API <object_type>_set . So a set called net_set will hold network objects (API endpoint /net). Note : unlike GET multiple, depth here will also expand single relationships in addition to sets. So net_id would get expanded into a network object. Unexpanded { ... \"net_id\" : 1 } Expanded { ... \"net_id\" : 1 \"net\" : { ... network object ... } } Depth - 0: don't expand anything (default) - 1: expand all first level sets to ids - 2: expand all first level sets to objects","title":"Nested sets and objects"},{"location":"howto/search/#multiple-objects","text":"To retrieve a single object you need to use this URL: https://www.peeringdb.com/api/OBJ/ with this endpoint GET: /api/OBJ/ . Let\u2019s look at an example: - HTTP: GET /api/OBJ/ which is the endpoint - curl: curl -X GET https://<username>:<password>@www.peeringdb.com/api/OBJ There are optional parameters you can add to your URL: - limit : int limits rows in the result set - skip : int skips n rows in the result set - depth : int nested sets will be loaded (slow) - fields : str comma separated list of field names - only matching fields will be returned in the data - since : int retrieve all objects updated since specified time (unix timestamp, seconds) - [field_name] : int|string queries for fields with matching value","title":"Multiple objects"},{"location":"howto/search/#real-world-use-cases","text":"We will show you different use cases on how to use the PeeringDB API.","title":"Real world use cases"},{"location":"howto/search/#how-do-i-query-by-asn","text":"To query for an ASN using the PeeringDB API, you will need to use this URL: GET https://www.peeringdb.com/api/net?asn=42 , where asn=42 is the query parameter.","title":"How do I query by ASN?"},{"location":"howto/search/#how-do-i-query-for-an-ixs-in-a-particular-state","text":"To query for IXs based in a state (in countries with a state system), you will need to use a URL like this: GET https://www.peeringdb.com/api/ixfac?fac__state=NSW , where fac__state tells the API to look at the state field in the facility record and NSW is the normalized code for the state. In this example, NSW is the Australian state of New South Wales. Similarly, https://www.peeringdb.com/api/ixfac?fac__state=NV gets IXs in facilities in the US state of Nevada.","title":"How do I query for an IXs in a particular state?"},{"location":"howto/search/#using-curl","text":"Use this curl example to get this specific network. Copy and paste the following to your command line interface: curl GET https://www.peeringdb.com/api/net?asn=42 .","title":"Using curl"},{"location":"howto/search/#using-python","text":"To make use of this Python code, first, you\u2019ll have to first install Python if you don\u2019t have it installed. Then, install pip and requests . After that create a Python file and copy and paste the following code. import requests r = requests.get('https://www.peeringdb.com/api/net?asn=42') print(r.text) with open('output.csv', 'w+') as f: f.write(r.text) From the above code, we make a request to the API using the request module and print out the response which would be in a JSON format. However, reading a JSON file can be quite hectic and tasking so we convert the JSON file to a CSV file. Our CSV file will open in output.csv.","title":"Using Python"},{"location":"howto/search/#using-jq","text":"You can use jq to make a request to your API and get your output in a CSV format. First, you need to install Jq . Next, we use this curl command to prepare our JSON file. Change to a directory and copy and paste this code on your terminal: curl https://www.peeringdb.com/api/net?asn=42 > test.json . This creates a new file named test.json. To convert the JSON input file to the CSV format, copy and paste the following command: jq -r '(.data[0] | keys_unsorted), (.data[] | to_entries | map(.value))|@csv' test.json","title":"Using jq"},{"location":"howto/search/#using-an-online-converter","text":"Alternatively you can use an online tool such as https://www.convertcsv.com/json-to-csv.htm to convert the raw JSON file to CSV. Note : For the purpose of this article we will focus on the curl method but you can conveniently try out the other proposed methods.","title":"Using an online converter"},{"location":"howto/search/#how-to-get-all-the-objects-owned-by-httpswwwpeeringdbcomnet961-and-convert-the-data-to-csv","text":"To get all the objects owned by this https://www.peeringdb.com/net/961 using the PeeringDB API. Copy and paste the following to your command line interface: curl GET https://www.peeringdb.com/net/961 .","title":"How to get all the objects owned by https://www.peeringdb.com/net/961 and convert the data to CSV?"},{"location":"howto/search/#i-want-the-list-of-networks-and-their-type-peering-at-mice-in-minneapolis","text":"To get the list of networks and their type peering at Mice in Minneapolis, copy and paste the following command in your terminal: curl -s -X GET https://www.peeringdb.com/api/net?ix=446&__in=Minneapolis | jq '.data[] .","title":"I want the list of networks and their 'type' peering at MICE in Minneapolis."},{"location":"howto/search/#how-to-find-all-the-exchanges-where-my-organization-has-a-presence","text":"Use this curl example. Copy and paste the following to your command line interface: curl -s -X GET https://www.peeringdb.com/api/netixlan\\?ixlan_id=62 | jq '.data[]' .","title":"How to find all the exchanges where my organization has a presence?"},{"location":"howto/updates-for-as112/","text":"HOWTO: What is AS112? Many networks using private address space ( RFC 1918 ) leak the reverse DNS lookups instead of running a local DNS server to respond to them. To stop this traffic from overwhelming root nameservers, volunteers run AS112 nameservers , which provide authoritative, local answers. What is PeeringDB? PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions. The database is a non-profit, community-driven initiative run and promoted by volunteers. It is a public tool for the growth and good of the Internet. Join the community and support the continued development of the Internet. How Does PeeringDB Visibility Help? The listing for AS112 in PeeringDB contains the peering LAN IP addresses of the routers for the network. This can be used as a source of configuration information for the peering routers of other networks at the same IXP. What you need to do IXPs sharing technical information using the IX-F Member Export Schema When an IXP shares technical information about its infrastructure using the IX-F Member Export Schema the existence of the AS112 node, and its peering LAN address, will automatically be populated in PeeringDB. You, as the operators of the node do not need to do anything. This is because AS112 has enabled the option to allow the IXPs' IX-F data to automatically populate its entry in PeeringDB. IXPs not sharing technical information using the IX-F Member Export Schema If your IXP does not share technical information about its infrastructure using the IX-F Member Export Schema you can ask them to do so. You can also reach out to ops@as112.net and the PeeringDB entry for AS112 will be manually updated.","title":"HOWTO: What is AS112?"},{"location":"howto/updates-for-as112/#howto-what-is-as112","text":"Many networks using private address space ( RFC 1918 ) leak the reverse DNS lookups instead of running a local DNS server to respond to them. To stop this traffic from overwhelming root nameservers, volunteers run AS112 nameservers , which provide authoritative, local answers.","title":"HOWTO: What is AS112?"},{"location":"howto/updates-for-as112/#what-is-peeringdb","text":"PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions. The database is a non-profit, community-driven initiative run and promoted by volunteers. It is a public tool for the growth and good of the Internet. Join the community and support the continued development of the Internet.","title":"What is PeeringDB?"},{"location":"howto/updates-for-as112/#how-does-peeringdb-visibility-help","text":"The listing for AS112 in PeeringDB contains the peering LAN IP addresses of the routers for the network. This can be used as a source of configuration information for the peering routers of other networks at the same IXP.","title":"How Does PeeringDB Visibility Help?"},{"location":"howto/updates-for-as112/#what-you-need-to-do","text":"","title":"What you need to do"},{"location":"howto/updates-for-as112/#ixps-sharing-technical-information-using-the-ix-f-member-export-schema","text":"When an IXP shares technical information about its infrastructure using the IX-F Member Export Schema the existence of the AS112 node, and its peering LAN address, will automatically be populated in PeeringDB. You, as the operators of the node do not need to do anything. This is because AS112 has enabled the option to allow the IXPs' IX-F data to automatically populate its entry in PeeringDB.","title":"IXPs sharing technical information using the IX-F Member Export Schema"},{"location":"howto/updates-for-as112/#ixps-not-sharing-technical-information-using-the-ix-f-member-export-schema","text":"If your IXP does not share technical information about its infrastructure using the IX-F Member Export Schema you can ask them to do so. You can also reach out to ops@as112.net and the PeeringDB entry for AS112 will be manually updated.","title":"IXPs not sharing technical information using the IX-F Member Export Schema"},{"location":"howto/v2_search/","text":"HOWTO: v2 Search We are testing v2 search in parallel with our production v1 search tools. We encourage you to test it and give us feedback . Is it faster? Does it simplify the search process? Does it give you the results you expect? Your input helps us deliver the tools you want. When you click one the link for v2 search , you just type your query in the box and hit enter, like normal. Concept v2 lets you use some natural language queries in combination with the name for an area. It helps you get the results in fewer searches, ideally just one! Search for a network Searches for numbers can be interpreted as a search for a location as well as a network. When searching for a network prefixed with 'AS', partial matches show all relevant networks while direct matches take you straight to the network's page. Fig 1: A search for as333 shows results for AS3330 and AS33309 Support for metro sizes For many areas it will automatically set an appropriate radius. When a common business area crosses a jurisdictional boundary, the search is based on the common business area and not limited to the named metro area. Fig 2: A search for fac near new york includes results for facilities in Jersey City, NJ When you want a different radius, our Advanced Search tool lets you manually set a specific radius based on any street address. Searching directly for IXs v2 search finds exchanges based on the facilities they are in. You don\u2019t need to search for facilities in a metro area and then find the exchanges they host. You can do it in a single search. Fig 3: A search for ix in tokyo finds exchanges at facilities we know about in Tokyo Support for campus v2 search knows about campus objects \u2013 interconnected facilities under common ownership \u2013 so you can find campuses for an area as well a getting a full list of facilities. Fig 4: Searching for a campus in amsterdam shows just three entries Fig 5: Searching for a fac in amsterdam shows many more results","title":"HOWTO: v2 Search"},{"location":"howto/v2_search/#howto-v2-search","text":"We are testing v2 search in parallel with our production v1 search tools. We encourage you to test it and give us feedback . Is it faster? Does it simplify the search process? Does it give you the results you expect? Your input helps us deliver the tools you want. When you click one the link for v2 search , you just type your query in the box and hit enter, like normal.","title":"HOWTO: v2 Search"},{"location":"howto/v2_search/#concept","text":"v2 lets you use some natural language queries in combination with the name for an area. It helps you get the results in fewer searches, ideally just one!","title":"Concept"},{"location":"howto/v2_search/#search-for-a-network","text":"Searches for numbers can be interpreted as a search for a location as well as a network. When searching for a network prefixed with 'AS', partial matches show all relevant networks while direct matches take you straight to the network's page. Fig 1: A search for as333 shows results for AS3330 and AS33309","title":"Search for a network"},{"location":"howto/v2_search/#support-for-metro-sizes","text":"For many areas it will automatically set an appropriate radius. When a common business area crosses a jurisdictional boundary, the search is based on the common business area and not limited to the named metro area. Fig 2: A search for fac near new york includes results for facilities in Jersey City, NJ When you want a different radius, our Advanced Search tool lets you manually set a specific radius based on any street address.","title":"Support for metro sizes"},{"location":"howto/v2_search/#searching-directly-for-ixs","text":"v2 search finds exchanges based on the facilities they are in. You don\u2019t need to search for facilities in a metro area and then find the exchanges they host. You can do it in a single search. Fig 3: A search for ix in tokyo finds exchanges at facilities we know about in Tokyo","title":"Searching directly for IXs"},{"location":"howto/v2_search/#support-for-campus","text":"v2 search knows about campus objects \u2013 interconnected facilities under common ownership \u2013 so you can find campuses for an area as well a getting a full list of facilities. Fig 4: Searching for a campus in amsterdam shows just three entries Fig 5: Searching for a fac in amsterdam shows many more results","title":"Support for campus"},{"location":"howto/work_within_peeringdbs_query_limits/","text":"HOWTO: Work Within PeeringDB\u2019s Query Limits PeeringDB implements query throttling to encourage efficiently formatted queries and/or local caching. Many popular tools have been upgraded to use PeeringDB more efficiently. Query limits Duplicate queries: Repeated anonymous identical requests with a response size above 100kb are being limited to 1/hour Repeated anonymous identical requests of any size are being limited to 2/minute Query rate limit: Anonymous queries limited to 20/minute per IP address Authenticated queries limited to 40/minute per user or organization (when an organizational API key is used) Efficient queries We encourage users to make fewer, larger queries instead of making many small queries. Instead of sending each ASN you want to learn about as a separate query, create a list of ASNs and send them in a single query. The query element would look like this: asn__in=$list_of_ASN_separated_by_comma We encourage sending lists of up to 150 ASNs in a single query. We have a HOWTO article describing the basics of using our API using popular command line tools such as curl, Python, and jq. Please use API Keys when automating queries to PeeringDB and set a User-Agent header that identifies the unique software you are using, rather than just a generic query library name. We also encourage you to leave at least two seconds between queries. Local cache We encourage you to use a local cache and synchronize it every hour or less frequently in accordance with your organization's needs. When you use a local cache you will only be sent changes since the last sync. We publish peeringdb-py, which can be used directly or as a reference implementation. Code is here and documentation is here . Use of an API key with peeringdb-py is highly recommended. If you want to implement a local cache using different tools and would like advice, we are happy to talk. Contact us at support@peeringdb.com . Tools Popular tools, including arouteserver have been updated to include support for API Keys and to make more efficient queries. We publish a list of tools that we know use PeeringDB. Check the list for tools that you use and upgrade old versions to take advantage of new features and improve everyone\u2019s PeeringDB experience.","title":"HOWTO: Work Within PeeringDB\u2019s Query Limits"},{"location":"howto/work_within_peeringdbs_query_limits/#howto-work-within-peeringdbs-query-limits","text":"PeeringDB implements query throttling to encourage efficiently formatted queries and/or local caching. Many popular tools have been upgraded to use PeeringDB more efficiently.","title":"HOWTO: Work Within PeeringDB\u2019s Query Limits"},{"location":"howto/work_within_peeringdbs_query_limits/#query-limits","text":"Duplicate queries: Repeated anonymous identical requests with a response size above 100kb are being limited to 1/hour Repeated anonymous identical requests of any size are being limited to 2/minute Query rate limit: Anonymous queries limited to 20/minute per IP address Authenticated queries limited to 40/minute per user or organization (when an organizational API key is used)","title":"Query limits"},{"location":"howto/work_within_peeringdbs_query_limits/#efficient-queries","text":"We encourage users to make fewer, larger queries instead of making many small queries. Instead of sending each ASN you want to learn about as a separate query, create a list of ASNs and send them in a single query. The query element would look like this: asn__in=$list_of_ASN_separated_by_comma We encourage sending lists of up to 150 ASNs in a single query. We have a HOWTO article describing the basics of using our API using popular command line tools such as curl, Python, and jq. Please use API Keys when automating queries to PeeringDB and set a User-Agent header that identifies the unique software you are using, rather than just a generic query library name. We also encourage you to leave at least two seconds between queries.","title":"Efficient queries"},{"location":"howto/work_within_peeringdbs_query_limits/#local-cache","text":"We encourage you to use a local cache and synchronize it every hour or less frequently in accordance with your organization's needs. When you use a local cache you will only be sent changes since the last sync. We publish peeringdb-py, which can be used directly or as a reference implementation. Code is here and documentation is here . Use of an API key with peeringdb-py is highly recommended. If you want to implement a local cache using different tools and would like advice, we are happy to talk. Contact us at support@peeringdb.com .","title":"Local cache"},{"location":"howto/work_within_peeringdbs_query_limits/#tools","text":"Popular tools, including arouteserver have been updated to include support for API Keys and to make more efficient queries. We publish a list of tools that we know use PeeringDB. Check the list for tools that you use and upgrade old versions to take advantage of new features and improve everyone\u2019s PeeringDB experience.","title":"Tools"},{"location":"release_notes/","text":"Release Notes and Schedule The release notes list the GitHub issues and a summary of what has changed in PeeringDB software releases. Each new release has a one week beta test period on the beta server before it goes live. The beta and new releases are announced on the PeeringDB Announce Mailing List and on Facebook , LinkedIn and X . Release schedule This schedule provides planned dates for PeeringDB\u2019s future releases. We are sharing these dates to help PeeringDB users plan ahead for testing new and improved features in beta. We also want to help volunteer developers know the date on which their code changes are needed for internal testing before beta release. We provide a rolling schedule. Dates can change, so if you have a question or request please contact us at: support@peeringdb.com . Our releases are generally deployed at around 04:00 UTC. Release number Internal testing Beta release Production release 2.63.0 2024-11-06 2024-11-13 2024-11-20 2.64.0 2024-01-08 2024-01-15 2024-01-22 2.65.0 2025-02-05 2025-02-12 2025-02-19 2.66.0 2025-03-14 2025-03-23 2025-03-30 2.67.0 2025-04-22 2025-04-29 2025-04-30 2.68.0 2025-05-07 2025-05-14 2025-05-21 2.69.0 2025-06-11 2025-06-18 2025-05-25 Release 2.63.0 Beta Announcement Date: 13 November 2024 Release Date: 20 November 2024 GitHub issue Summary #1671 Inconsistent netixlan ASN data can result in inability for deleted netixlan to be claimed by new user Nullify the local asn field of netixlan objects and make it a read only view of $network.asn.. #1666 Schedule reset of tutorial server database As title. #1635 ops: add read-only server side switch PeeringDB can now be placed into read-only mode when needed. #1593 Dev module docs auto generation broken Fixes a bug that broke autogeneration of documentation. #1690 New net_side and ix_side fields on netixlan breaks sync once django-peeringdb is released Fixes a bug that blocked the release of an updated django-peeringdb because of the new new net_side and ix_side fields added to netixlan in 2.62.0. peeringdb-py #65 Make spinning up peeringdb-py fully automated As title. Release 2.62.1 Release Date: 24 October 2024 GitHub issue Summary #1692 Fix otp email one time password Fixes compatibility issues after two-factor library upgrade, causing issues with emailing one time passwords. Release 2.62.0 Beta Announcement Date: 9 October 2024 Release Date: 16 October 2024 GitHub issue Summary #1584 Passkey support for login Adds a new 2FA method, Passkeys . #1612 Feature Parity for Carrier Object: Search and Export to JSON, CSV, KMZ As title. #1555 Remove \"Media Type\" field for Internet Exchange object As title. #1563 CSV and JSON exports truncate at 250 records Exports no longer truncate at 250 records. #607 Add location of Physical IX-Port & Router Port IXPs can now indicate the location of their switch using the pdb_facility_id attribute of the switch statement in their IX-F JSON export . peeringdb-py #95 Make client more robust when dealing with api errors. As title. peeringdb-py #86 DB sync fails due to validation error Bug fix as title. #1635 ops: add read-only server side switch Server can go into read-only mode, while allowing user login. This mode allows basic service to be sustained in adverse situations. #1654 Direct query access to Elasticsearch to aid search improvements Direct query access to ElasticSearch for internal PeeringDB users. #1653 Update dependencies and modernise As title. peeringdb-py #94 Update deps and modernize As title. django-peeringdb #103 Update dependencies and modernise As title. #340 switch to uv, update deps Dependency update for docs.peeringdb.com. Release 2.61.0 Beta Announcement Date: 14 August 2024 Release Date: 21 August 2024 GitHub issue Summary #1617 Snag list for preview.beta.peeringdb.com Updates preview.beta.peeringdb.com to improve the UI. #1142 Email one time password button should be less prominent As title. #766 For any forbidden actions set a 403 and give a \"Not Allowed\" header As title. #1302 Fix OpenAPI types where needed As title. peeringdb-py #76 Client should handle rate limiting errors gracefully As title. #1583 bfd_support undocumented parameter in API Documentation improved. django-peeringdb #98 ORM configuration Options is missing (postgreSQL) Config option updated. #1014 When removing a network, removing all netixlans have to happen before removing pocs Fixes blocking of network deletion due to to Prevent deletion of a last technical contact if there is an existing netixlan object #923. Release 2.60.0 Beta Announcement Date: 17 July 2024 Release Date: 24 July 2024 GitHub issue Summary #1452 Normalizing the presentation of place names Place names are now normalized, improving the consistency of search results. #1189 Data export buttons for Network, Exchange, and Facilities As title. #1561 Deploy www on ECS/Fargate www.peeringdb.com will be deployed using containers. peeringdb-py #67 Allow option for logging to co-exist with existing loggers Improves logging support in peeringdb-py local cache. peeringdb-py #72 --output-format in cli does not seem to be working Fixes bug as per title. #1322 Give API writes high priority and limits As title. #1610 possible for ixpfx object with empty prefix to exist in a soft-deleted state Fixes bug as per title. #1040 Verification queue ticket subject changes Fixes bug as per title. Release 2.59.0 Beta Announcement Date: 19 June 2024 Release Date: 26 June 2024 GitHub issue Summary #1585 Publish OAuth authorization server metadata endpoint As title. #1483 Address Change UI Fixes an error where it was not possible to reject the suggestion for an address. #1561 Deploy www on ECS/Fargate Switch www.peeringdb.com to ECS/Fargate. Initial deployment will be on beta.peeringdb.com with www.peeringdb.com following at a later date. peeringdb-py #49 Automatically update docs site on code release As title. peeringdb-py #88 docs need updating to reflect some api changes to the Client.update_all() call As title. #1603 Organization API key table formatting broken Improves the display of Organizational API Keys. #1604 API limit=x does not work when response type set in URL Limits to response sizes were ignored as per title. #971 Remove white space from strings As title. #1606 rir_status update handler: intermittent bug that may attempt to delete a network too early Fixes an over eager data cleanup process. #1608 pdb_delete_outdated_pending_affil_request failure Fixes an error is a data cleanup process. Release 2.58.0 Beta Announcement Date: 29 May 2024 Release Date: 5 June 2024 GitHub issue Summary #1343 Inconsistent return results when querying facilities by state (Datafill) Enforces state naming on validation and normalize data. #1502 Create preview.peeringdb.com with updated web UI Preview site for new PeeringDB web design. #1414 Tooltip with Full IX Name on Mouse-Over IX-Abbreviation As title. #1115 Enhancement to Ownership Information Field Lessee tooltip now says \"Leased or Rented\". #1487 URL Referrer Behavior Clicking on a link now opens it in a new tab or window. #840 Add help text to \"Traffic Levels\" Add tooltip \"Total, self-classified traffic in/out to this network.\". #1491 Add logo watermark and peeringdb.com URL to kmz As title. #975 \"Incomplete data\" complainer for Peering Policy even with General Policy \"None\" or \"Open\" No longer show missing data warning for empty Peering Policy field if General Policy is set to \"Open\" or \"No\". #1580 Validator: Add validator for X usernames, were requirements Validator for usernames on the X social media network. #1481 Network Registration fail results in AC action and retry failure Improved network registration process where email address does not match RDAP output. #1500 pdb_stats needs to be updated to include Campuses, Carriers, etc. & possible bug with user counts Improvements to internal stats package. #1503 Is it possible to create an affiliation request even when the ASN (~Net) has been deleted? (But the ORG still exist) As title. #1038 add default for config key MELISSA_KEY now defaults to a blank string. #1048 TOTP devices sort is by id. However, only username is shown Fixes a UI bug with internal support tools. #85 DB sync fails due to duplicate entries Fixes a peeringdb-py data sync bug. Release 2.57.0 Beta Announcement Date: 17 April 2024 Release Date: 24 April 2024 GitHub issue Summary #1545 Feature request: Allow permissions to be given per user on Carrier As title. #1123 Make a Technical POC mandatory when enabling \"Allow IXP Update\" As title. #1231 Change ix-f to IX-F As title. #1577 Remove more clutter from KMZ Metadata Makes data easier to read and slims download size. #1475 KML Placemark/Point Meta Data Not Displaying Correctly Fixes a bug that broke the way metadata displayed for .KMZ pins. #1546 v2 search: 500 error when last character is a colon As title. #1530 missing search results when doing a city location search for facilities Fixes a bug that did not show fac entries located in a city in simple search. #1533 Exchange Advanced search fails and returns bad search data Fixes and intermittent Advanced Search failure. #1451 Cosmetic issue with affiliation emails and double-slash in URL Fixes a cosmetic bug in autogenerated support messages. #1416 Add (PeeringDB Support) after superuser name in public notifications Support messages now more clearly identified as coming from PeeringDB Support. #1415 Auto-CleanUp old pending \"User to Organization Affiliation Request\" Pending affiliation requests are now cleaned up after 3 months. #1494 drop any facilities without location data (PDB Example) No fac without a geocode is now listed in the .KMZ export. #1528 pdb_rir_status task errors on deskpro ticket creation Fixes a bug in an internal support tool. #1453 DELETION PREVENTED: Link is not formatted as html element Fixes a bug in an internal support tool. #1484 Update ORG Social Media Option \"Twitter\" to \"X\" As title. Release 2.56.1 Release Date: 27 March 2024 GitHub issue Summary #1581 rdap to 1.5.2 Merge third-party library needed for complete fix of #1455 . Release 2.56.0 Beta Announcement Date: 13 March 2024 Release Date: 20 March 2024 GitHub issue Summary #1447 v2 search - support for ISO 3166 alpha-2 country codes v2 search now has support for ISO 3166 alpha-2 codes. #1495 Enable .KMZ export for Advanced Search results As title. #1489 Remove unneeded fields from the KMZ Removes field clutter to optimize file size. #1490 Spelling fix for KMZ Fixes spelling of 'Latitude'. #1099 Expose authentication methods on outbound federation Adds Authentication Method Reference field to OAuth profile, with choices from Section 2 of RFC8176 , documentation, and scope. #1133 Return auth error when multiple auth methods are used Now returns a 401 code with a helpful message when Authorization: Basic fails with corrupt base64 input. #1456 Duplicate AS-SET name Adds a tooltip suggesting hierarchical AS-SET names and a warning if a duplicate name is entered. #1331 BFD support field in Global and IX specific views Adds a boolean value for BFD support per IP address and a mouseover icon on the website when it's true. #1478 Social link controls showing up when not logged in Fixes a cosmetic bug that showed non-operational social media controls when not logged in. #1425 Update social media icons in footer Updates social media icons in the footer. #1152 Tab URLs don't work anymore Fixes tab URLs in the admin interface. Release 2.55.0 Beta Announcement Date: 21 February 2024 Release Date: 28 February 2024 GitHub issue Summary #1410 Adjust IPv4/6 prefix limits automatically Max prefix limit is now automatically adjusted based on the DFZ. #1455 Org name RIPE-NCC-END-MNT for new networks Fixes a bug that named orgs RIPE-NCC-END-MNT. #1468 translation refresh and dependency update translate.peeringdb.com updated to weblate 5.0 and other dependency updates. #1480 pdb_load_data no longer creates necessary org usergroups Fixes a bug with data sync tool. Release 2.54.2 Release Date: 31 January 2024 GitHub issue Summary #1536 Support 202311 rollback ux changes Reverted web UI changes that caused issues. Release 2.54.1 Release Date: 30 January 2024 GitHub issue Summary #1511 Non-obvious search box on the front page Search bar in header is now auto deployed. #1513 Mobile interface front page has lots of misaligned sections Fixes layout issues for some mobile devices. #1514 Two different search boxes on a network page information page in the same area As title. #1515 Bottom search box on some pages does not work correctly As title. Release 2.54.0 Beta Announcement Date: 18 January 2024 Release Date: 24 January 2024 GitHub issue Summary #1463 Update website to take advantage of wider screen and improve mobile device support As title. #1357 Clarifying the Network Type field Add multi-select for Network Type field. #1341 Only indicate availability of DC voltage for facilities Limits power options to non-standard voltages. #1476 v2 search not able to find organization and network - Marconi Solutions Srls Fixes a bug where bad search results are returned. #170 Add a \"flag bad data\" button on various places Adds a box web users can click to report bad data. #1430 Changing ASN field on \"Add Network\" to be numbers only The text box is now restricted to numbers, reducing scope for data entry issues. #1455 Org name RIPE-NCC-END-MNT for new networks Fixes a bug tat set some networks' names to RIPE-NCC-END-MNT. #1280 Improve RIR Update Procedure Improves the process for removing stale networks from PeeringDB. #1065 api-cache improvements As title. #1303 Add headers to API requests Adds a mechanism to indicate that behavior/schema has changed to API consumers. #1410 Adjust IPv4/6 prefix limits automatically Now automatically sets the maximum to 25% of the DFZ. #410 Add a \"last synced at $date\" to beta.peeringdb.com As title. #1468 translation refresh and dependency update As title. #1466 Analysis: Investigate use of ECS/Fargate As title. #1412 Improve performance by updating Python client code As title. Older releases 2023 Release Notes 2022 Release Notes 2021 Release Notes 2020 Release Notes","title":"Release Notes"},{"location":"release_notes/#release-notes-and-schedule","text":"The release notes list the GitHub issues and a summary of what has changed in PeeringDB software releases. Each new release has a one week beta test period on the beta server before it goes live. The beta and new releases are announced on the PeeringDB Announce Mailing List and on Facebook , LinkedIn and X .","title":"Release Notes and Schedule"},{"location":"release_notes/#release-schedule","text":"This schedule provides planned dates for PeeringDB\u2019s future releases. We are sharing these dates to help PeeringDB users plan ahead for testing new and improved features in beta. We also want to help volunteer developers know the date on which their code changes are needed for internal testing before beta release. We provide a rolling schedule. Dates can change, so if you have a question or request please contact us at: support@peeringdb.com . Our releases are generally deployed at around 04:00 UTC. Release number Internal testing Beta release Production release 2.63.0 2024-11-06 2024-11-13 2024-11-20 2.64.0 2024-01-08 2024-01-15 2024-01-22 2.65.0 2025-02-05 2025-02-12 2025-02-19 2.66.0 2025-03-14 2025-03-23 2025-03-30 2.67.0 2025-04-22 2025-04-29 2025-04-30 2.68.0 2025-05-07 2025-05-14 2025-05-21 2.69.0 2025-06-11 2025-06-18 2025-05-25","title":"Release schedule"},{"location":"release_notes/#release-2630","text":"Beta Announcement Date: 13 November 2024 Release Date: 20 November 2024 GitHub issue Summary #1671 Inconsistent netixlan ASN data can result in inability for deleted netixlan to be claimed by new user Nullify the local asn field of netixlan objects and make it a read only view of $network.asn.. #1666 Schedule reset of tutorial server database As title. #1635 ops: add read-only server side switch PeeringDB can now be placed into read-only mode when needed. #1593 Dev module docs auto generation broken Fixes a bug that broke autogeneration of documentation. #1690 New net_side and ix_side fields on netixlan breaks sync once django-peeringdb is released Fixes a bug that blocked the release of an updated django-peeringdb because of the new new net_side and ix_side fields added to netixlan in 2.62.0. peeringdb-py #65 Make spinning up peeringdb-py fully automated As title.","title":"Release 2.63.0"},{"location":"release_notes/#release-2621","text":"Release Date: 24 October 2024 GitHub issue Summary #1692 Fix otp email one time password Fixes compatibility issues after two-factor library upgrade, causing issues with emailing one time passwords.","title":"Release 2.62.1"},{"location":"release_notes/#release-2620","text":"Beta Announcement Date: 9 October 2024 Release Date: 16 October 2024 GitHub issue Summary #1584 Passkey support for login Adds a new 2FA method, Passkeys . #1612 Feature Parity for Carrier Object: Search and Export to JSON, CSV, KMZ As title. #1555 Remove \"Media Type\" field for Internet Exchange object As title. #1563 CSV and JSON exports truncate at 250 records Exports no longer truncate at 250 records. #607 Add location of Physical IX-Port & Router Port IXPs can now indicate the location of their switch using the pdb_facility_id attribute of the switch statement in their IX-F JSON export . peeringdb-py #95 Make client more robust when dealing with api errors. As title. peeringdb-py #86 DB sync fails due to validation error Bug fix as title. #1635 ops: add read-only server side switch Server can go into read-only mode, while allowing user login. This mode allows basic service to be sustained in adverse situations. #1654 Direct query access to Elasticsearch to aid search improvements Direct query access to ElasticSearch for internal PeeringDB users. #1653 Update dependencies and modernise As title. peeringdb-py #94 Update deps and modernize As title. django-peeringdb #103 Update dependencies and modernise As title. #340 switch to uv, update deps Dependency update for docs.peeringdb.com.","title":"Release 2.62.0"},{"location":"release_notes/#release-2610","text":"Beta Announcement Date: 14 August 2024 Release Date: 21 August 2024 GitHub issue Summary #1617 Snag list for preview.beta.peeringdb.com Updates preview.beta.peeringdb.com to improve the UI. #1142 Email one time password button should be less prominent As title. #766 For any forbidden actions set a 403 and give a \"Not Allowed\" header As title. #1302 Fix OpenAPI types where needed As title. peeringdb-py #76 Client should handle rate limiting errors gracefully As title. #1583 bfd_support undocumented parameter in API Documentation improved. django-peeringdb #98 ORM configuration Options is missing (postgreSQL) Config option updated. #1014 When removing a network, removing all netixlans have to happen before removing pocs Fixes blocking of network deletion due to to Prevent deletion of a last technical contact if there is an existing netixlan object #923.","title":"Release 2.61.0"},{"location":"release_notes/#release-2600","text":"Beta Announcement Date: 17 July 2024 Release Date: 24 July 2024 GitHub issue Summary #1452 Normalizing the presentation of place names Place names are now normalized, improving the consistency of search results. #1189 Data export buttons for Network, Exchange, and Facilities As title. #1561 Deploy www on ECS/Fargate www.peeringdb.com will be deployed using containers. peeringdb-py #67 Allow option for logging to co-exist with existing loggers Improves logging support in peeringdb-py local cache. peeringdb-py #72 --output-format in cli does not seem to be working Fixes bug as per title. #1322 Give API writes high priority and limits As title. #1610 possible for ixpfx object with empty prefix to exist in a soft-deleted state Fixes bug as per title. #1040 Verification queue ticket subject changes Fixes bug as per title.","title":"Release 2.60.0"},{"location":"release_notes/#release-2590","text":"Beta Announcement Date: 19 June 2024 Release Date: 26 June 2024 GitHub issue Summary #1585 Publish OAuth authorization server metadata endpoint As title. #1483 Address Change UI Fixes an error where it was not possible to reject the suggestion for an address. #1561 Deploy www on ECS/Fargate Switch www.peeringdb.com to ECS/Fargate. Initial deployment will be on beta.peeringdb.com with www.peeringdb.com following at a later date. peeringdb-py #49 Automatically update docs site on code release As title. peeringdb-py #88 docs need updating to reflect some api changes to the Client.update_all() call As title. #1603 Organization API key table formatting broken Improves the display of Organizational API Keys. #1604 API limit=x does not work when response type set in URL Limits to response sizes were ignored as per title. #971 Remove white space from strings As title. #1606 rir_status update handler: intermittent bug that may attempt to delete a network too early Fixes an over eager data cleanup process. #1608 pdb_delete_outdated_pending_affil_request failure Fixes an error is a data cleanup process.","title":"Release 2.59.0"},{"location":"release_notes/#release-2580","text":"Beta Announcement Date: 29 May 2024 Release Date: 5 June 2024 GitHub issue Summary #1343 Inconsistent return results when querying facilities by state (Datafill) Enforces state naming on validation and normalize data. #1502 Create preview.peeringdb.com with updated web UI Preview site for new PeeringDB web design. #1414 Tooltip with Full IX Name on Mouse-Over IX-Abbreviation As title. #1115 Enhancement to Ownership Information Field Lessee tooltip now says \"Leased or Rented\". #1487 URL Referrer Behavior Clicking on a link now opens it in a new tab or window. #840 Add help text to \"Traffic Levels\" Add tooltip \"Total, self-classified traffic in/out to this network.\". #1491 Add logo watermark and peeringdb.com URL to kmz As title. #975 \"Incomplete data\" complainer for Peering Policy even with General Policy \"None\" or \"Open\" No longer show missing data warning for empty Peering Policy field if General Policy is set to \"Open\" or \"No\". #1580 Validator: Add validator for X usernames, were requirements Validator for usernames on the X social media network. #1481 Network Registration fail results in AC action and retry failure Improved network registration process where email address does not match RDAP output. #1500 pdb_stats needs to be updated to include Campuses, Carriers, etc. & possible bug with user counts Improvements to internal stats package. #1503 Is it possible to create an affiliation request even when the ASN (~Net) has been deleted? (But the ORG still exist) As title. #1038 add default for config key MELISSA_KEY now defaults to a blank string. #1048 TOTP devices sort is by id. However, only username is shown Fixes a UI bug with internal support tools. #85 DB sync fails due to duplicate entries Fixes a peeringdb-py data sync bug.","title":"Release 2.58.0"},{"location":"release_notes/#release-2570","text":"Beta Announcement Date: 17 April 2024 Release Date: 24 April 2024 GitHub issue Summary #1545 Feature request: Allow permissions to be given per user on Carrier As title. #1123 Make a Technical POC mandatory when enabling \"Allow IXP Update\" As title. #1231 Change ix-f to IX-F As title. #1577 Remove more clutter from KMZ Metadata Makes data easier to read and slims download size. #1475 KML Placemark/Point Meta Data Not Displaying Correctly Fixes a bug that broke the way metadata displayed for .KMZ pins. #1546 v2 search: 500 error when last character is a colon As title. #1530 missing search results when doing a city location search for facilities Fixes a bug that did not show fac entries located in a city in simple search. #1533 Exchange Advanced search fails and returns bad search data Fixes and intermittent Advanced Search failure. #1451 Cosmetic issue with affiliation emails and double-slash in URL Fixes a cosmetic bug in autogenerated support messages. #1416 Add (PeeringDB Support) after superuser name in public notifications Support messages now more clearly identified as coming from PeeringDB Support. #1415 Auto-CleanUp old pending \"User to Organization Affiliation Request\" Pending affiliation requests are now cleaned up after 3 months. #1494 drop any facilities without location data (PDB Example) No fac without a geocode is now listed in the .KMZ export. #1528 pdb_rir_status task errors on deskpro ticket creation Fixes a bug in an internal support tool. #1453 DELETION PREVENTED: Link is not formatted as html element Fixes a bug in an internal support tool. #1484 Update ORG Social Media Option \"Twitter\" to \"X\" As title.","title":"Release 2.57.0"},{"location":"release_notes/#release-2561","text":"Release Date: 27 March 2024 GitHub issue Summary #1581 rdap to 1.5.2 Merge third-party library needed for complete fix of #1455 .","title":"Release 2.56.1"},{"location":"release_notes/#release-2560","text":"Beta Announcement Date: 13 March 2024 Release Date: 20 March 2024 GitHub issue Summary #1447 v2 search - support for ISO 3166 alpha-2 country codes v2 search now has support for ISO 3166 alpha-2 codes. #1495 Enable .KMZ export for Advanced Search results As title. #1489 Remove unneeded fields from the KMZ Removes field clutter to optimize file size. #1490 Spelling fix for KMZ Fixes spelling of 'Latitude'. #1099 Expose authentication methods on outbound federation Adds Authentication Method Reference field to OAuth profile, with choices from Section 2 of RFC8176 , documentation, and scope. #1133 Return auth error when multiple auth methods are used Now returns a 401 code with a helpful message when Authorization: Basic fails with corrupt base64 input. #1456 Duplicate AS-SET name Adds a tooltip suggesting hierarchical AS-SET names and a warning if a duplicate name is entered. #1331 BFD support field in Global and IX specific views Adds a boolean value for BFD support per IP address and a mouseover icon on the website when it's true. #1478 Social link controls showing up when not logged in Fixes a cosmetic bug that showed non-operational social media controls when not logged in. #1425 Update social media icons in footer Updates social media icons in the footer. #1152 Tab URLs don't work anymore Fixes tab URLs in the admin interface.","title":"Release 2.56.0"},{"location":"release_notes/#release-2550","text":"Beta Announcement Date: 21 February 2024 Release Date: 28 February 2024 GitHub issue Summary #1410 Adjust IPv4/6 prefix limits automatically Max prefix limit is now automatically adjusted based on the DFZ. #1455 Org name RIPE-NCC-END-MNT for new networks Fixes a bug that named orgs RIPE-NCC-END-MNT. #1468 translation refresh and dependency update translate.peeringdb.com updated to weblate 5.0 and other dependency updates. #1480 pdb_load_data no longer creates necessary org usergroups Fixes a bug with data sync tool.","title":"Release 2.55.0"},{"location":"release_notes/#release-2542","text":"Release Date: 31 January 2024 GitHub issue Summary #1536 Support 202311 rollback ux changes Reverted web UI changes that caused issues.","title":"Release 2.54.2"},{"location":"release_notes/#release-2541","text":"Release Date: 30 January 2024 GitHub issue Summary #1511 Non-obvious search box on the front page Search bar in header is now auto deployed. #1513 Mobile interface front page has lots of misaligned sections Fixes layout issues for some mobile devices. #1514 Two different search boxes on a network page information page in the same area As title. #1515 Bottom search box on some pages does not work correctly As title.","title":"Release 2.54.1"},{"location":"release_notes/#release-2540","text":"Beta Announcement Date: 18 January 2024 Release Date: 24 January 2024 GitHub issue Summary #1463 Update website to take advantage of wider screen and improve mobile device support As title. #1357 Clarifying the Network Type field Add multi-select for Network Type field. #1341 Only indicate availability of DC voltage for facilities Limits power options to non-standard voltages. #1476 v2 search not able to find organization and network - Marconi Solutions Srls Fixes a bug where bad search results are returned. #170 Add a \"flag bad data\" button on various places Adds a box web users can click to report bad data. #1430 Changing ASN field on \"Add Network\" to be numbers only The text box is now restricted to numbers, reducing scope for data entry issues. #1455 Org name RIPE-NCC-END-MNT for new networks Fixes a bug tat set some networks' names to RIPE-NCC-END-MNT. #1280 Improve RIR Update Procedure Improves the process for removing stale networks from PeeringDB. #1065 api-cache improvements As title. #1303 Add headers to API requests Adds a mechanism to indicate that behavior/schema has changed to API consumers. #1410 Adjust IPv4/6 prefix limits automatically Now automatically sets the maximum to 25% of the DFZ. #410 Add a \"last synced at $date\" to beta.peeringdb.com As title. #1468 translation refresh and dependency update As title. #1466 Analysis: Investigate use of ECS/Fargate As title. #1412 Improve performance by updating Python client code As title.","title":"Release 2.54.0"},{"location":"release_notes/#older-releases","text":"2023 Release Notes 2022 Release Notes 2021 Release Notes 2020 Release Notes","title":"Older releases"},{"location":"release_notes/release_notes_2020/","text":"2020 Release Notes The release notes list the GitHub issues and a summary of what has changed in PeeringDB software releases in 2020. Release notes for the current year are available on the Release Notes page. Each new release has a one week beta test period on the beta server before it goes live. The beta and new releases are announced on the PeeringDB Announce Mailing List and on Twitter , LinkedIn and Facebook . Release 2.24.0 Beta Announcement Date: 4 November, 2020 Release Date: 11 November, 2020 GitHub issue Summary #381 Network type: Add \"Government\" \u201cGovernment\u201d added as a network type. #463 Add new network type for networks that provide network services \u201cNetwork Services\" for networks whose function is to provide specialized services, like DNS, RDAP, Whois or DDoS protection added as a network type. #745 Add \u201cRoute Collector\u201d network type \u201cRoute Collector\u201d added as a network type. #747 Clean up info_type if name contains \"Route Servers\" or \"Route Collector\" Data cleanup related to #745. All networks with route collectors have now been properly classified. #665 Drop ixlan name from displaying at \"Peers at this Exchange Point\" Simplified the user interface by removing the name of the ixlan as there is now just one ixlan per exchange point. #775 Misleading tooltip of prefix limit fields NO Improved the user interface with better language in the tooltip. The distinction between maximum prefix length and maximum number of prefixes should now be clearer. #814 Suppress RDAP call for contact data/handles for NIC.br // AUTOTOOL Internal tool change. This change suppresses calls for contact data over RDAP because NIC.br is no longer allowed to provide direct calls for personal data. #803 Searching for a user in /cp/peeringdb_server/userorgaffiliationrequest results in 500 Internal tool change. Fixed an error that could return a 500 error on some searches. #688 Automate creation of Release Notes Internal tool change. A new script that extracts data from Github milestones to build the markdown for the release notes page. #851 sponsorship_notify RuntimeWarning (was: End of Sponsorship notification email is no longer working) Internal tool change to improve the tracking of sponsorship renewals. #861 add explicit order for fields in admin control panel Internal tool change. Display fields in an explicit order. #850 IX-F Importer: Repeated emails are being generated for things already emailed Internal procedure optimisation. A series of improvements to the IX-F importer tool. These changes are all related to improving notifications about data quality that were developed by the Data Ownership Task Force. #856 IX-F Importer: Make hyperlinks clickable when creating DeskPRO tickets See #850. #857 IX-F Importer: intermittent issue with speed validation See #850. #858 IX-F Importer: Make pdb_deskpro_publish command ignore importer tickets See #850. #859 IX-F Importer: ERROR: 'IXFMemberData' object has no attribute 'ixf_log_entry' See #850. #860 IX-F Importer Blocker: \"Days until DeskPRO ticket is created\" should now be ignored/removed, such that no ticket or emails happen after a delay See #850. Release 2.23.0 Beta Announcement Date: 30 September, 2020 Release Date: 7 October, 2020 GitHub issue Summary #833 - IX-F Importer: Add failed email resending Implement re-send mechanic for emails that could not be sent (indicated by a sent value of null). When re-sending an email add a note to the email stating \"This email could not be delivered initially and may contain stale information\". Add a field to the admin-com import emails table to show this note as well. Update sent if send is successful #832 - IX-F Importer: suggested update when it should be add + remove In some edge cases a deletion will end up as a requirement incorrectly to a legitimate new entry still. See #770 #816 #831 - [prod] IX-F importer: NameError: name 'EmailMultiAlternatives' is not defined Fixes broken email function of ix-f importer #826 - Make technical poc mandatory when adding a netixlan Upon creating a netixlan object check that net has at least one ( Technical , NOC , Policy ) poc and that the poc has an e-mail address. If not ask them to create one first. Visibility of at least one ( Technical , NOC , Policy ) poc has to be \"Users\" resp. \"Public\" #825 - [beta] IX-F importer: Make Importer return non-zero when there is an error that Ops should see Improvements to ix-f importer that allow for easier notification and tracking of errors for the Ops team #824 - IX-F Preview - shows the consolidated delete operation when it shouldn't Simplified the UI for consolidated modifications to improve user understanding #759 - Describe the 'never-via-routeservers' flag Add tooltip for never-via-routeservers option: \"Indicates if this network will announce its routes via route servers or not\" #571 - Facility registration tool adds identifier Fixes small UI bug in facility registration tool used by the Admin Committee #481 - Add min_speed and max_speed to ixlan Based on the discussion in #475 adds a new global setting that limits netixlan speed values now. It's not a property on the ixlan anymore. #371 - Clean up users in verification queue A tool to delete user entries older than 90 days from the so-called verification queue and run it on a regular schedule #370 - Make Website mandatory for suggesting a facility Website is now mandatory when suggesting a facility but zipcode only mandatory for countries that have zipcodes #321 - Typos in locale Fixes a number of typographical errors Release 2.22.0 Beta Announcement Date: 15 July, 2020 Release Date: 26 August, 2020 GitHub issue Summary #249 - Add the IX-F Member Export URL to the ixlan API endpoint There are two new fields in the ixlan section resp. the ixlan object, called ixf_ixp_member_list_url and ixf_ixp_member_list_url_visible. The first one contains the URL to the IX-F import file while the second governs the visibility of the URL. Values are the same as for the poc object, namely \"Public\", \"Users\" and \"Private\", defaulting to \"Private\" (i.e. or users who are members of the org). #268 - Database: unique constraints This issue fixes internal DB behaviour. #358 - Lock ASN once the record is created Once a network has been created, the field asn is made read-only. As the ASN is unique there is no reason to change it. Making the field read-only is to prevent unwanted side effects. #431 - Null 'rencode' from facility Null out all values for legacy unused rencode field, and make it read only to prepare for removal in PDB v3 [#625] (https://github.com/peeringdb/peeringdb/issues/625). #600 - Visibility for \"Allow IXP update\" switch A new field is added to the API net object, called allow_ixp_update. Furthermore, a line is added in global stats in the footer with a count (called \"Automated Networks\") of the networks which have \"Allow IXP Update\" enabled. #649 - Possible for 'ok' ixpfx to exist in 'pending' ixlan This issue fixes an internal bug. #683 - Add net_count_ixf field to ix object A field is added to the API object ix, called net_count_ixf, which indicates the number of net objects the exchange has in their IX-F JSON if they provide one. Otherwise, the value is null. #696 - Lock some objects from being deleted by the owner To protect operational data objects fac, ix, ixlan and org are prevented from being deleted as long as there are other objects related to it. First, these objects must be deleted before the object itself can be deleted. The attempt to delete such a protected object gives an error message and also opens a ticket with the PeeringDB support. #697 - Creating, changing, and deleting a netixlan object We completely re-implemented the way a connection to an exchange is handled. This new procedure allows both for a safe heads up a network can give to their peers as well as a safe way for exchanges to get rid of stale entries. Moreover, it allows networks to easily acknowledge new entries at exchanges which use the IX-F importer feature. See also the webinar for detailed information on this new procedure. Release 2.21.0 Beta Announcement Date: 24 June, 2020 Release Date: 1 July, 2020 GitHub issue Summary #72 - Enable sort and reverse sort of IP column in IX display Sort and reverse sort of IP column in IX display are added. Sort of the IP addresses in the expected natural order. The IPv4 address is the primary sort key. The IPv6 address is the secondary key. #121 - missing delete button for organizations New feature. An admin user is able to delete an org if it has no live objects under it. #290 - Offer 2FA 2FA is offered now. The implementation includes optional 2FA using TOTP is offered there is a knob in the user profile to enable and set it up email recovery is added using the verified user email address an icon is added in the org admin section to denote to org admins if users have 2FA enabled #352 - Mark IXP peering LAN as bogon Allow IXP to tag their LAN prefixes as bogons. In general, LAN prefixes should not be visible in the DFZ. If it should be visible, IXPs are able to debogonise them #356 - Sorting by clicking table headers should use local-compare Bugfix. Sorting now honours locale-sorting #519 - Make spelling of traffic levels consistent This is a bug fix and a minor improvement. Spelling is made consistent and traffic levels up to 100+Tbps are added. #526 - Show \"Last Updated\" fields on fac, ix, org records A \"Last Updated\" field is visible now for fac, ix, and org objects #537 - Posting https://www.peeringdb.com onto social media doesn't select a good preview image Add opengraph image for page preview. #566 - Should deleted personal data be accessable through the API? If a poc object is deleted it is made immediately non-gettable via the API, too. In case the corresponding net object was deleted unintentionally the object is still kept in the DB. After 30 days it will be hard-deleted. #569 - Don't return any POC data with status=deleted POC objects do have a visibility scope. If a POC record is deleted it should not be able to retrieve it at all, even if visibility had been set to \"public\" before. The data will still be kept internally for 30 days for rollback if the deletion happened unintentionally. After 30 days the record will be hard-deleted. #580 - Add a clear error message, when user tries to re-add a previously deleted facility Bug fix for an unclear behaviour. If a connection from a network to a facility was deleted the user was unable to re-add this connection by themselves and an unclear error message was given. Now, the user is able to re-add the connection. #618 - Support alternative direction of writing, e.g. Arabic For right-to-left written languages, the entire layout of the PeeringDB website has to be flipped around. #644 - Undeleting an ixlan with an emtpy IPv4 XOR IPv6 field throws a silly error Bugfix for the Admin Committee UI. An empty field was considered to be a legit non-null value and the system hence enforced uniqueness #650 - Add pointer from API docs to tutorial A URL is added from the API documentation website to the PeeringDB tutorials #654 - Add pointer from API docs to tutorial Bugfix for the Admin Committee UI. #663 - change default encoding of API calls to 'utf-8' The output of API calls will change from content-type: application/json; charset=iso-8859-1 to content-type: application/json; charset=utf-8 #664 - Selection should only present undeleted objects Admin Committee only related. Only non-deleted should be presented for selection #666 - Selection should only present undeleted objects When changing owner of an ix admin GUI borks because of \"Ixlan for exchange already exists\" #669 - Add help text to \"Add {Facility, Network, Exchange} tab Added a better help text to make crystal clear that adding a Facility, Network, or Exchange means that you are owning this object. #679 - Add read-only Superuser Provide PC members with a read-only access to the Admin UI. #712 - User is unable to update their net record Bug fix. Missing pointer to where the non-compliant value is Release 2.20.2 Release Date: 23 April, 2020 GitHub issue Summary #707 - Make source not required for IRR records Making source not required for IRR records. This requirement was an oversight during implementation of [#151 - Validation of IRR Records] (https://github.com/peeringdb/peeringdb/issues/151) that was released with 2.20.0 - see below. Product Committee revisited the issue after 2.20.0 and reports of concern from community and decided to retract the requirement in an emergency release Release 2.20.1 Release Date: 21 April, 2020 GitHub issue Summary #702 - Requests from peeringdb-py error 500 Emergency release for a config change Release 2.20.0 Beta Announcement Date: 15 April, 2020 Release Date: 21 April, 2020 GitHub issue Summary #151 - Validation of IRR Records To make the IRR as-set/route-set field of more operational value, strict rules apply the as-set/rs-set name has to conform to RFC 2622 (5.1 and 5.2) the source may be specified by AS-SET@SOURCE or SOURCE::AS-SET (preferred) valid sources are taken from the list of known IRRs multiple values must be separated by either ,, , or , (i.e. comma, space or comma followed by space) #189 - Improve explanatory and help text A clear help text is added for requesting affiliation to an organization. #251 - Limit number of concurrent affiliation requests per user In order to reduce organization affiliation request spamming, the number of pending organization requests has been limited to 5. #295 Desk pro tickets -> DeskPRO tickets This is a bug fix and only affects the Admin UI. #378 - Add contact information for Facilities (fac) the same way as for ix and net Contact information is added to Facilities and IXP. #452 - Org/Network name of a sponsor should not link to /sponsors, only the sponsor badge should This is a bug fix. From now on only when clicking on the sponsor badge will direct to the sponsor page. #462 - Route-server URL starting with ssh:// Add SSH as supported protocol. #539 - Add attribute 'operational' to 'netixlan' This is a new feature and allows networks to give early notice to their peers that they soon will show up at an IXP. There is a new check box when adding an IXP connection. By default, a connection is considered operational and the box is ticked. When the connection is still in provisioning status, please untick the box. When viewing, the warning glyphicon is shown right to the network name. The correspondent API object netixlan is enhanced by a boolean field operational defaulting to true. This feature is in line with the Data Ownership Policy . #548 - containerize server Internal software deployment system has been changed to use containers which reduces time spent by the ops team for deployments, allows for better scaling, and reduces the cost of entry for new developers to write and test their code. #555 - Notes field translate button disappears This is a bug fix. The \"Translate\" button is there for a moment and then disappeared. #557 - Show all languages on beta, even if translation is not ready for prod As soon as a new translation is starting it is available on the beta to help the translators and to encourage the community for input. #598 - bug caused by the org affiliationship request without an asn This is a bug fix and is only relevant for the PeeringDB Admin Committee. #609 - When creating an ix via the API also return ixlan_id and ixpfx_id When creating an IX record via API, the call will also return the implicitly created ixlan_id and ixpfx_id. This makes it simpler and reduces the number of calls that need to be made to the API. #615 - Insert links into ID fields in DESKPRO AUTOASN tickets This only affects tickets generated for PeeringDB Admin Committee. A link to the object in the UI is added. #626 - Update API docs Internal mechanisms for generating the API docs have been updated to current standards. This also allows for easier user contributions to the docs themselves. #634 - Remove support for python2 Python 2.7 and 3.4 support is being removed from PeeringDB packages. #636 - Don't create a new net object, when there only is an ASN block This is a bug fix and is only relevant for the PeeringDB Admin Committee. #667 - Fix use autocomplete fields in the admincom controlpanel to speed up loading times This is a bug fix and is only relevant for the PeeringDB Admin Committee.","title":"2020 Release Notes"},{"location":"release_notes/release_notes_2020/#2020-release-notes","text":"The release notes list the GitHub issues and a summary of what has changed in PeeringDB software releases in 2020. Release notes for the current year are available on the Release Notes page. Each new release has a one week beta test period on the beta server before it goes live. The beta and new releases are announced on the PeeringDB Announce Mailing List and on Twitter , LinkedIn and Facebook .","title":"2020 Release Notes"},{"location":"release_notes/release_notes_2020/#release-2240","text":"Beta Announcement Date: 4 November, 2020 Release Date: 11 November, 2020 GitHub issue Summary #381 Network type: Add \"Government\" \u201cGovernment\u201d added as a network type. #463 Add new network type for networks that provide network services \u201cNetwork Services\" for networks whose function is to provide specialized services, like DNS, RDAP, Whois or DDoS protection added as a network type. #745 Add \u201cRoute Collector\u201d network type \u201cRoute Collector\u201d added as a network type. #747 Clean up info_type if name contains \"Route Servers\" or \"Route Collector\" Data cleanup related to #745. All networks with route collectors have now been properly classified. #665 Drop ixlan name from displaying at \"Peers at this Exchange Point\" Simplified the user interface by removing the name of the ixlan as there is now just one ixlan per exchange point. #775 Misleading tooltip of prefix limit fields NO Improved the user interface with better language in the tooltip. The distinction between maximum prefix length and maximum number of prefixes should now be clearer. #814 Suppress RDAP call for contact data/handles for NIC.br // AUTOTOOL Internal tool change. This change suppresses calls for contact data over RDAP because NIC.br is no longer allowed to provide direct calls for personal data. #803 Searching for a user in /cp/peeringdb_server/userorgaffiliationrequest results in 500 Internal tool change. Fixed an error that could return a 500 error on some searches. #688 Automate creation of Release Notes Internal tool change. A new script that extracts data from Github milestones to build the markdown for the release notes page. #851 sponsorship_notify RuntimeWarning (was: End of Sponsorship notification email is no longer working) Internal tool change to improve the tracking of sponsorship renewals. #861 add explicit order for fields in admin control panel Internal tool change. Display fields in an explicit order. #850 IX-F Importer: Repeated emails are being generated for things already emailed Internal procedure optimisation. A series of improvements to the IX-F importer tool. These changes are all related to improving notifications about data quality that were developed by the Data Ownership Task Force. #856 IX-F Importer: Make hyperlinks clickable when creating DeskPRO tickets See #850. #857 IX-F Importer: intermittent issue with speed validation See #850. #858 IX-F Importer: Make pdb_deskpro_publish command ignore importer tickets See #850. #859 IX-F Importer: ERROR: 'IXFMemberData' object has no attribute 'ixf_log_entry' See #850. #860 IX-F Importer Blocker: \"Days until DeskPRO ticket is created\" should now be ignored/removed, such that no ticket or emails happen after a delay See #850.","title":"Release 2.24.0"},{"location":"release_notes/release_notes_2020/#release-2230","text":"Beta Announcement Date: 30 September, 2020 Release Date: 7 October, 2020 GitHub issue Summary #833 - IX-F Importer: Add failed email resending Implement re-send mechanic for emails that could not be sent (indicated by a sent value of null). When re-sending an email add a note to the email stating \"This email could not be delivered initially and may contain stale information\". Add a field to the admin-com import emails table to show this note as well. Update sent if send is successful #832 - IX-F Importer: suggested update when it should be add + remove In some edge cases a deletion will end up as a requirement incorrectly to a legitimate new entry still. See #770 #816 #831 - [prod] IX-F importer: NameError: name 'EmailMultiAlternatives' is not defined Fixes broken email function of ix-f importer #826 - Make technical poc mandatory when adding a netixlan Upon creating a netixlan object check that net has at least one ( Technical , NOC , Policy ) poc and that the poc has an e-mail address. If not ask them to create one first. Visibility of at least one ( Technical , NOC , Policy ) poc has to be \"Users\" resp. \"Public\" #825 - [beta] IX-F importer: Make Importer return non-zero when there is an error that Ops should see Improvements to ix-f importer that allow for easier notification and tracking of errors for the Ops team #824 - IX-F Preview - shows the consolidated delete operation when it shouldn't Simplified the UI for consolidated modifications to improve user understanding #759 - Describe the 'never-via-routeservers' flag Add tooltip for never-via-routeservers option: \"Indicates if this network will announce its routes via route servers or not\" #571 - Facility registration tool adds identifier Fixes small UI bug in facility registration tool used by the Admin Committee #481 - Add min_speed and max_speed to ixlan Based on the discussion in #475 adds a new global setting that limits netixlan speed values now. It's not a property on the ixlan anymore. #371 - Clean up users in verification queue A tool to delete user entries older than 90 days from the so-called verification queue and run it on a regular schedule #370 - Make Website mandatory for suggesting a facility Website is now mandatory when suggesting a facility but zipcode only mandatory for countries that have zipcodes #321 - Typos in locale Fixes a number of typographical errors","title":"Release 2.23.0"},{"location":"release_notes/release_notes_2020/#release-2220","text":"Beta Announcement Date: 15 July, 2020 Release Date: 26 August, 2020 GitHub issue Summary #249 - Add the IX-F Member Export URL to the ixlan API endpoint There are two new fields in the ixlan section resp. the ixlan object, called ixf_ixp_member_list_url and ixf_ixp_member_list_url_visible. The first one contains the URL to the IX-F import file while the second governs the visibility of the URL. Values are the same as for the poc object, namely \"Public\", \"Users\" and \"Private\", defaulting to \"Private\" (i.e. or users who are members of the org). #268 - Database: unique constraints This issue fixes internal DB behaviour. #358 - Lock ASN once the record is created Once a network has been created, the field asn is made read-only. As the ASN is unique there is no reason to change it. Making the field read-only is to prevent unwanted side effects. #431 - Null 'rencode' from facility Null out all values for legacy unused rencode field, and make it read only to prepare for removal in PDB v3 [#625] (https://github.com/peeringdb/peeringdb/issues/625). #600 - Visibility for \"Allow IXP update\" switch A new field is added to the API net object, called allow_ixp_update. Furthermore, a line is added in global stats in the footer with a count (called \"Automated Networks\") of the networks which have \"Allow IXP Update\" enabled. #649 - Possible for 'ok' ixpfx to exist in 'pending' ixlan This issue fixes an internal bug. #683 - Add net_count_ixf field to ix object A field is added to the API object ix, called net_count_ixf, which indicates the number of net objects the exchange has in their IX-F JSON if they provide one. Otherwise, the value is null. #696 - Lock some objects from being deleted by the owner To protect operational data objects fac, ix, ixlan and org are prevented from being deleted as long as there are other objects related to it. First, these objects must be deleted before the object itself can be deleted. The attempt to delete such a protected object gives an error message and also opens a ticket with the PeeringDB support. #697 - Creating, changing, and deleting a netixlan object We completely re-implemented the way a connection to an exchange is handled. This new procedure allows both for a safe heads up a network can give to their peers as well as a safe way for exchanges to get rid of stale entries. Moreover, it allows networks to easily acknowledge new entries at exchanges which use the IX-F importer feature. See also the webinar for detailed information on this new procedure.","title":"Release 2.22.0"},{"location":"release_notes/release_notes_2020/#release-2210","text":"Beta Announcement Date: 24 June, 2020 Release Date: 1 July, 2020 GitHub issue Summary #72 - Enable sort and reverse sort of IP column in IX display Sort and reverse sort of IP column in IX display are added. Sort of the IP addresses in the expected natural order. The IPv4 address is the primary sort key. The IPv6 address is the secondary key. #121 - missing delete button for organizations New feature. An admin user is able to delete an org if it has no live objects under it. #290 - Offer 2FA 2FA is offered now. The implementation includes optional 2FA using TOTP is offered there is a knob in the user profile to enable and set it up email recovery is added using the verified user email address an icon is added in the org admin section to denote to org admins if users have 2FA enabled #352 - Mark IXP peering LAN as bogon Allow IXP to tag their LAN prefixes as bogons. In general, LAN prefixes should not be visible in the DFZ. If it should be visible, IXPs are able to debogonise them #356 - Sorting by clicking table headers should use local-compare Bugfix. Sorting now honours locale-sorting #519 - Make spelling of traffic levels consistent This is a bug fix and a minor improvement. Spelling is made consistent and traffic levels up to 100+Tbps are added. #526 - Show \"Last Updated\" fields on fac, ix, org records A \"Last Updated\" field is visible now for fac, ix, and org objects #537 - Posting https://www.peeringdb.com onto social media doesn't select a good preview image Add opengraph image for page preview. #566 - Should deleted personal data be accessable through the API? If a poc object is deleted it is made immediately non-gettable via the API, too. In case the corresponding net object was deleted unintentionally the object is still kept in the DB. After 30 days it will be hard-deleted. #569 - Don't return any POC data with status=deleted POC objects do have a visibility scope. If a POC record is deleted it should not be able to retrieve it at all, even if visibility had been set to \"public\" before. The data will still be kept internally for 30 days for rollback if the deletion happened unintentionally. After 30 days the record will be hard-deleted. #580 - Add a clear error message, when user tries to re-add a previously deleted facility Bug fix for an unclear behaviour. If a connection from a network to a facility was deleted the user was unable to re-add this connection by themselves and an unclear error message was given. Now, the user is able to re-add the connection. #618 - Support alternative direction of writing, e.g. Arabic For right-to-left written languages, the entire layout of the PeeringDB website has to be flipped around. #644 - Undeleting an ixlan with an emtpy IPv4 XOR IPv6 field throws a silly error Bugfix for the Admin Committee UI. An empty field was considered to be a legit non-null value and the system hence enforced uniqueness #650 - Add pointer from API docs to tutorial A URL is added from the API documentation website to the PeeringDB tutorials #654 - Add pointer from API docs to tutorial Bugfix for the Admin Committee UI. #663 - change default encoding of API calls to 'utf-8' The output of API calls will change from content-type: application/json; charset=iso-8859-1 to content-type: application/json; charset=utf-8 #664 - Selection should only present undeleted objects Admin Committee only related. Only non-deleted should be presented for selection #666 - Selection should only present undeleted objects When changing owner of an ix admin GUI borks because of \"Ixlan for exchange already exists\" #669 - Add help text to \"Add {Facility, Network, Exchange} tab Added a better help text to make crystal clear that adding a Facility, Network, or Exchange means that you are owning this object. #679 - Add read-only Superuser Provide PC members with a read-only access to the Admin UI. #712 - User is unable to update their net record Bug fix. Missing pointer to where the non-compliant value is","title":"Release 2.21.0"},{"location":"release_notes/release_notes_2020/#release-2202","text":"Release Date: 23 April, 2020 GitHub issue Summary #707 - Make source not required for IRR records Making source not required for IRR records. This requirement was an oversight during implementation of [#151 - Validation of IRR Records] (https://github.com/peeringdb/peeringdb/issues/151) that was released with 2.20.0 - see below. Product Committee revisited the issue after 2.20.0 and reports of concern from community and decided to retract the requirement in an emergency release","title":"Release 2.20.2"},{"location":"release_notes/release_notes_2020/#release-2201","text":"Release Date: 21 April, 2020 GitHub issue Summary #702 - Requests from peeringdb-py error 500 Emergency release for a config change","title":"Release 2.20.1"},{"location":"release_notes/release_notes_2020/#release-2200","text":"Beta Announcement Date: 15 April, 2020 Release Date: 21 April, 2020 GitHub issue Summary #151 - Validation of IRR Records To make the IRR as-set/route-set field of more operational value, strict rules apply the as-set/rs-set name has to conform to RFC 2622 (5.1 and 5.2) the source may be specified by AS-SET@SOURCE or SOURCE::AS-SET (preferred) valid sources are taken from the list of known IRRs multiple values must be separated by either ,, , or , (i.e. comma, space or comma followed by space) #189 - Improve explanatory and help text A clear help text is added for requesting affiliation to an organization. #251 - Limit number of concurrent affiliation requests per user In order to reduce organization affiliation request spamming, the number of pending organization requests has been limited to 5. #295 Desk pro tickets -> DeskPRO tickets This is a bug fix and only affects the Admin UI. #378 - Add contact information for Facilities (fac) the same way as for ix and net Contact information is added to Facilities and IXP. #452 - Org/Network name of a sponsor should not link to /sponsors, only the sponsor badge should This is a bug fix. From now on only when clicking on the sponsor badge will direct to the sponsor page. #462 - Route-server URL starting with ssh:// Add SSH as supported protocol. #539 - Add attribute 'operational' to 'netixlan' This is a new feature and allows networks to give early notice to their peers that they soon will show up at an IXP. There is a new check box when adding an IXP connection. By default, a connection is considered operational and the box is ticked. When the connection is still in provisioning status, please untick the box. When viewing, the warning glyphicon is shown right to the network name. The correspondent API object netixlan is enhanced by a boolean field operational defaulting to true. This feature is in line with the Data Ownership Policy . #548 - containerize server Internal software deployment system has been changed to use containers which reduces time spent by the ops team for deployments, allows for better scaling, and reduces the cost of entry for new developers to write and test their code. #555 - Notes field translate button disappears This is a bug fix. The \"Translate\" button is there for a moment and then disappeared. #557 - Show all languages on beta, even if translation is not ready for prod As soon as a new translation is starting it is available on the beta to help the translators and to encourage the community for input. #598 - bug caused by the org affiliationship request without an asn This is a bug fix and is only relevant for the PeeringDB Admin Committee. #609 - When creating an ix via the API also return ixlan_id and ixpfx_id When creating an IX record via API, the call will also return the implicitly created ixlan_id and ixpfx_id. This makes it simpler and reduces the number of calls that need to be made to the API. #615 - Insert links into ID fields in DESKPRO AUTOASN tickets This only affects tickets generated for PeeringDB Admin Committee. A link to the object in the UI is added. #626 - Update API docs Internal mechanisms for generating the API docs have been updated to current standards. This also allows for easier user contributions to the docs themselves. #634 - Remove support for python2 Python 2.7 and 3.4 support is being removed from PeeringDB packages. #636 - Don't create a new net object, when there only is an ASN block This is a bug fix and is only relevant for the PeeringDB Admin Committee. #667 - Fix use autocomplete fields in the admincom controlpanel to speed up loading times This is a bug fix and is only relevant for the PeeringDB Admin Committee.","title":"Release 2.20.0"},{"location":"release_notes/release_notes_2021/","text":"2021 Release Notes The release notes list the GitHub issues and a summary of what has changed in PeeringDB software releases. Release notes for the current year are available on the Release Notes page. Each new release has a one week beta test period on the beta server before it goes live. The beta and new releases are announced on the PeeringDB Announce Mailing List and on Twitter , LinkedIn and Facebook . Release 2.32.0 Beta Announcement Date: 10 November 2021 Release Date: 17 November 2021 GitHub issue Summary #695 Auto focus cursor on search field on main website Places cursor in search box on first opening https://www.peeringdb.com #954 Rework ordering of dependencies Improved load speed for pages with large lists #748 PeeringDB website has a poor choice of line-breaks for IPv6 addresses IP addresses now have a no wrap style option so their numeric values aren't broken across lines #949 Add sales email and phone contact to ix object ix objects can now have a sales_email and sales_phone #838 Delete childless org objects Notifies admins of childless org s that they have no objects and deletes the org after 30 days if none are added #956 api documentation generate broken Fixes a bug that stopped the https://www.peeringdb.com/apidocs/ beingh updated automatically #962 Increase timeout timer for IX-F JSON importer to 30s Adds setting to control IX-F importer request timeout and default to 30 seconds #1054 IX-F manually triggered import bugs Fixes bugs triggered by manually importing IX-F data #807 [beta] IX-F importer: manual add followed by IX-F prompted add can result in \"The server rejected your data\" Resolves a bug triggered by manually adding netixlan in rare situations Release 2.31.0 Beta Announcement Date: 12 October 2021 Release Date: 20 October 2021 GitHub issue Summary #995 Block registering private ASN ranges Improves error message to user when attempting to register private ASNs and no longer automatically creates a support ticket #1007 Add a continental region field for facilities Continental region is now recorded for fac and is searchable from the advanced search page #18 IXP and Facility summary Presents a short statistical summary for ix 's and fac s #232 Incorrect order of search results ASNs will be moved to the top of the search results when a numeric search is an exact match for that ASN #346 Allow users to upload a small logo to their record orgs can now include a small logo in their record #453 Missing sponsor status in translations Fixed a bug so sponsor badges now show up properly in translations Release 2.30.0 Beta Announcement Date: 14 September 2021 Release Date: 22 September 2021 GitHub issue Summary #1944 Remove visibility \"Private\" from POC Make the \"Private\" visibility status invalid and requires an admin to review and update contacts when next making an update to their poc information #800 Additional self-selection fields for Facilities Adds additional fields to Facilities: Offered Space, Offered Power, Offered Resilience with appropriate details #1016 Add additional advanced search filters for new facility fields from #800 Adds the ability to search based on the new elements defined in #800 using Advanced Search #1032 Issue with api relationship filtering via __id Fixes a bug that impacted filtered searches made via the API #500 When network sets netixlan speed to 1200000 only 1T is shown instead of 1.2T ... sometimes Fixes a bug for speeds above 1Tb #1021 504 Gateway Time-out Fixes a timeout problem with the adminsitrative interface #1019 IX-F Importer: needless saves to deleted netixlans Fixes a bug that unnecessarily saved data to deleted objects Release 2.29.1 Release Date: 26 August 2021 GitHub issue Summary #1034 CORS Access-Control-Allow-Origin header missing in API responses Fixes an issue that stopped cross site API requests in the browser #1036 Issue with verification queue and deskpro ticket creation Fixes an issue that stopped newly created objects creating verification queue entries and a deskpro ticket Release 2.29.0 Beta Announcement Date: 18 August 2021 Release Date: 25 August 2021 GitHub issue Summary #779 Allow IXP to trigger ix-f importer for their exchange Exchanges can now trigger theIX-F importer and the UI communicates the status of the request #920 IX-F Importer: ticket status change when posting re-occuring conflict to existing resolved ticket Improve internal handling of IX-F importer conflicts #967 IX-F Importer: fix command output buffering Improve handling of output from IX-F importer command #903 Describe the 'DOT1Q' flag Set the field to false and made it read only (with a tooltip for the web interface) until v3 of the API #715 Support for Django 3 Upgrade to Django 3.2.1 and upgrade dependencies where possible #166 Add name, city, country to ixfac (GET operation) Add read-only fields name , city and country to object ixfac . The values for these fields are fac.name , fac.city and fac.country from the facility fac with id == fac_id #1023 Bug with email reports for internal errors Fixes an error with e-mail notifications for internal errors #1026 Fallback captcha solution is broken Fixes the fallback CAPTCHA on the account signup page #1013 The process to permanently remove old soft-deleted network contacts pdb_delete_pocs raises a false ProtectedAction Fixes a problem with adminsitrators permanently deleting contacts. #1015 Fallback captcha solution is broken Fixes a CAPTCHA bug affecting the AC through work on #715 Release 2.28.0 Beta Announcement Date: 14 July 2021 Release Date: 21 July 2021 GitHub issue Summary #23 make websearch smarter Provide a better search experience for quick search, advanced search and API filtering. The key features are properly indexed search, which supports search based on partial name matches, and geocoded search, which supports search based on coordinates. #965 IX-F importer: intermittent bug during consolidation of notifications Fixes a bug with the IX-F Member Export importer that resulted in intermittent import failures. #863 Improve error handling when a user tries to add an object which is already there Increases visibility of field validation error notes by increasing size and font weight. #375 On changing email address rescan open affiliation requests When a user changes their e-mail address we now automatically re-evaluate any open affiliation request that the user has that are tied to an ASN. #923 Prevent deletion of a last technical contact if there is an existing netixlan object Prevents deletion of the last technical contact of existing netixlan , i.e. enforce that netixlan should always have at least one technical contact Release 2.27.1 Beta Announcement Date: 19 May, 2021 Release Date: 26 May, 2021 GitHub issue Summary #946 Evaluate non-google map/geo sources Evaluated alternative geo data APIs and selected Melissa. #802 Extend Advanced Search for IXes and Facilities Adds search filters to advanced search (ix capacity search, organization presence search, and network presence search.) #799 Additional self-selection fields for IX objects Added service_level and terms fields to InternetExchange objects to allow exchanges to share additional ifnormation about their offering. These are supported as filters in the advanced search. #834 Add ix_count to object fac In the API, added a read-only field to fac called ix_count that counts the number of exchanges the linked to the facility). #835 Add {ix,fac}_count to object net In the API, added read-only fields to net called ix_count and fac_count that count the number of exchanges and facilities linked to the network). #836 Add fac_count to object ix In the API, added a read-only field to ix called fac_count that counts the number of facilities in which the exchange has a presence. #922 Circumvent approval of a facility by deleting and re-adding Fixed bug where if a user deletes a status \"pending\" fac, they can re-add it and it will be status \"ok\" (should be \"pending\"). #810 Get rid of the 'Protocols supported' fields / UI for IXes Removed proto_unicast , proto_multicast , and proto_ipv6 fields from ix UI. The fields remain in the v2 api but proto_ipv6 and proto_unicast will be populated from the existance of protocols in the exchange's ixpfx records. #985 500 Error on advanced search Resolved an issue where unauthenticated users got a 500 error in advanced search. Release 2.26.1 Beta Announcement Date: 14 April, 2021 Release Date: 21 April, 2021 GitHub issue Summary #883 IXF-Importer: minimise emails to Support/DeskPRO/AC This change collates all importer suggestions into a single e-mail notification. #931 Limit the number of requests for affiliation to an ASN/org to 1 Limits the number of affiliation request to an ASN to just one. Provides visual feedback on subsequent request attempts. #913 API should do an IP6 address instead of a string match Normalizes how IPv6 addresses are stored in the database and updates existing IPv6 addresses in the databases and elsewhere. Release 2.26.0 Beta Announcement Date: 10 March, 2021 Release Date: 24 March, 2021 GitHub issue Summary #266 Add API Keys This release introduces organization level API Keys . #827 Make GUI and API feature equivalent PeeringDB has a GUI and an API. This issue is a reminder to keep both feature equivalent. #865 Allow arbitrary decimal places as input for longitude and latitude. Systems rounds to six Allow arbitrary length of inputs to latitude and longitude. Round to 6 digits (including Google Maps output). #902 Add \"long name\" or \"aka\" field to 'fac' records add fields aka and name_long to object fac , ix , net , and org . #937 Geocode for org is broken This was fixed through work on #940. #939 Replace Validation Error with Validation \"Warning\" for geolocation validation If our address validation service cannot find an address corresponding to the user-inputed address it will allow the object to be saved and raise a \"validation warning\" in the meta object of the API response. The web UI will display a pop-up based on this warning. #940 Return geo-normalized fields as \"suggested address\" In an effort to normalize addresses, the system may overwrite the user input. In case of a mismatch, the user now is prompted with a \"suggested address\" and either confirms or rejects. In case of rejection, the address is taken as provided by the user. Please keep an eye on what you provided and what is suggested. The suggestion may flip street name and house name as well as cut off postal codes. #918 drop travis ci and move to github actions Changed CI environment to improve deployment speed. Release 2.25.0 Release Date: 3 February, 2021 GitHub issue Summary #246 IXF should be IX-F This release introduces various spelling corrections. #828 IX-F importer: Handle ipv4/ipv6 on same vlan but separate connections This issue deals with how the IX-F importer handles information from the IX-F JSON import. PeeringDB handles both the IPv4 as well as the IPv6 address in the same object ( netixlan ). And from a peering partner pov this is ok as it doesn't matter whether these addresses are on the same interface or even same router. However, IX-F JSON differentiates. For the time being, the importer combines IPv4 and IPv6 if both are set to an operational status in the IX-F JSON. #846 IX-F importer: if ixf_ixp_member_list_url is null then ixf_ixp_import_enabled can't be true Apply logic to the meaning of ixf_ixp_member_list_url . i.e. only allow ixf_ixp_import_enabled to be set to true if a URL is specified. #875 \"IXF-Importer: improved handling of how contacts are joined into direct conflict resolution deskpro tickets\" Resolved an issue where responses to automatically generated Deskpro tickets were routed to the wrong ticket. #878 IXF-Importer: reorder of email content This is mainly an internal improvement. And fixes also not disclosing private IXP information to the public. #882 IXF-Importer: don't abort when there is nothing to import If there is nothing to import from an IX-F JSON don't abort with an error message. #893 IX-F Importer: history of changes per ixlan & netixlan Fixed bug related to the logging of importer changes. #896 IX-F Importer: Bogus output of \"Preview\" tool Fixed a bug in the preview tool, where invalid member type ignored messages weren't filtered for the network viewing the preview. #888 Type issue when overriding settings through environment variables for numeric types Fixed a bug and now ensure that overrides are coerced to the correct expected type. #872 Update dependencies Updated container to python 3.9 and addressed all dependencies. #694 add syntactic sugar for entering port speeds Simplifies the UI for editing port speeds to make it more human friendly. #717 Loading time issue /cp facility view Fixed slow load or timeouts for loading data for some facilities #837 Provide a friendlier explanation when entering / changing a phone number Provides a tooltip to help people enter E.164 formatted telephone numbers. #541 When looking at a network record, show last updated ix<->net or fac<->net date Improved information about when records were last updated.","title":"2021 Release Notes"},{"location":"release_notes/release_notes_2021/#2021-release-notes","text":"The release notes list the GitHub issues and a summary of what has changed in PeeringDB software releases. Release notes for the current year are available on the Release Notes page. Each new release has a one week beta test period on the beta server before it goes live. The beta and new releases are announced on the PeeringDB Announce Mailing List and on Twitter , LinkedIn and Facebook .","title":"2021 Release Notes"},{"location":"release_notes/release_notes_2021/#release-2320","text":"Beta Announcement Date: 10 November 2021 Release Date: 17 November 2021 GitHub issue Summary #695 Auto focus cursor on search field on main website Places cursor in search box on first opening https://www.peeringdb.com #954 Rework ordering of dependencies Improved load speed for pages with large lists #748 PeeringDB website has a poor choice of line-breaks for IPv6 addresses IP addresses now have a no wrap style option so their numeric values aren't broken across lines #949 Add sales email and phone contact to ix object ix objects can now have a sales_email and sales_phone #838 Delete childless org objects Notifies admins of childless org s that they have no objects and deletes the org after 30 days if none are added #956 api documentation generate broken Fixes a bug that stopped the https://www.peeringdb.com/apidocs/ beingh updated automatically #962 Increase timeout timer for IX-F JSON importer to 30s Adds setting to control IX-F importer request timeout and default to 30 seconds #1054 IX-F manually triggered import bugs Fixes bugs triggered by manually importing IX-F data #807 [beta] IX-F importer: manual add followed by IX-F prompted add can result in \"The server rejected your data\" Resolves a bug triggered by manually adding netixlan in rare situations","title":"Release 2.32.0"},{"location":"release_notes/release_notes_2021/#release-2310","text":"Beta Announcement Date: 12 October 2021 Release Date: 20 October 2021 GitHub issue Summary #995 Block registering private ASN ranges Improves error message to user when attempting to register private ASNs and no longer automatically creates a support ticket #1007 Add a continental region field for facilities Continental region is now recorded for fac and is searchable from the advanced search page #18 IXP and Facility summary Presents a short statistical summary for ix 's and fac s #232 Incorrect order of search results ASNs will be moved to the top of the search results when a numeric search is an exact match for that ASN #346 Allow users to upload a small logo to their record orgs can now include a small logo in their record #453 Missing sponsor status in translations Fixed a bug so sponsor badges now show up properly in translations","title":"Release 2.31.0"},{"location":"release_notes/release_notes_2021/#release-2300","text":"Beta Announcement Date: 14 September 2021 Release Date: 22 September 2021 GitHub issue Summary #1944 Remove visibility \"Private\" from POC Make the \"Private\" visibility status invalid and requires an admin to review and update contacts when next making an update to their poc information #800 Additional self-selection fields for Facilities Adds additional fields to Facilities: Offered Space, Offered Power, Offered Resilience with appropriate details #1016 Add additional advanced search filters for new facility fields from #800 Adds the ability to search based on the new elements defined in #800 using Advanced Search #1032 Issue with api relationship filtering via __id Fixes a bug that impacted filtered searches made via the API #500 When network sets netixlan speed to 1200000 only 1T is shown instead of 1.2T ... sometimes Fixes a bug for speeds above 1Tb #1021 504 Gateway Time-out Fixes a timeout problem with the adminsitrative interface #1019 IX-F Importer: needless saves to deleted netixlans Fixes a bug that unnecessarily saved data to deleted objects","title":"Release 2.30.0"},{"location":"release_notes/release_notes_2021/#release-2291","text":"Release Date: 26 August 2021 GitHub issue Summary #1034 CORS Access-Control-Allow-Origin header missing in API responses Fixes an issue that stopped cross site API requests in the browser #1036 Issue with verification queue and deskpro ticket creation Fixes an issue that stopped newly created objects creating verification queue entries and a deskpro ticket","title":"Release 2.29.1"},{"location":"release_notes/release_notes_2021/#release-2290","text":"Beta Announcement Date: 18 August 2021 Release Date: 25 August 2021 GitHub issue Summary #779 Allow IXP to trigger ix-f importer for their exchange Exchanges can now trigger theIX-F importer and the UI communicates the status of the request #920 IX-F Importer: ticket status change when posting re-occuring conflict to existing resolved ticket Improve internal handling of IX-F importer conflicts #967 IX-F Importer: fix command output buffering Improve handling of output from IX-F importer command #903 Describe the 'DOT1Q' flag Set the field to false and made it read only (with a tooltip for the web interface) until v3 of the API #715 Support for Django 3 Upgrade to Django 3.2.1 and upgrade dependencies where possible #166 Add name, city, country to ixfac (GET operation) Add read-only fields name , city and country to object ixfac . The values for these fields are fac.name , fac.city and fac.country from the facility fac with id == fac_id #1023 Bug with email reports for internal errors Fixes an error with e-mail notifications for internal errors #1026 Fallback captcha solution is broken Fixes the fallback CAPTCHA on the account signup page #1013 The process to permanently remove old soft-deleted network contacts pdb_delete_pocs raises a false ProtectedAction Fixes a problem with adminsitrators permanently deleting contacts. #1015 Fallback captcha solution is broken Fixes a CAPTCHA bug affecting the AC through work on #715","title":"Release 2.29.0"},{"location":"release_notes/release_notes_2021/#release-2280","text":"Beta Announcement Date: 14 July 2021 Release Date: 21 July 2021 GitHub issue Summary #23 make websearch smarter Provide a better search experience for quick search, advanced search and API filtering. The key features are properly indexed search, which supports search based on partial name matches, and geocoded search, which supports search based on coordinates. #965 IX-F importer: intermittent bug during consolidation of notifications Fixes a bug with the IX-F Member Export importer that resulted in intermittent import failures. #863 Improve error handling when a user tries to add an object which is already there Increases visibility of field validation error notes by increasing size and font weight. #375 On changing email address rescan open affiliation requests When a user changes their e-mail address we now automatically re-evaluate any open affiliation request that the user has that are tied to an ASN. #923 Prevent deletion of a last technical contact if there is an existing netixlan object Prevents deletion of the last technical contact of existing netixlan , i.e. enforce that netixlan should always have at least one technical contact","title":"Release 2.28.0"},{"location":"release_notes/release_notes_2021/#release-2271","text":"Beta Announcement Date: 19 May, 2021 Release Date: 26 May, 2021 GitHub issue Summary #946 Evaluate non-google map/geo sources Evaluated alternative geo data APIs and selected Melissa. #802 Extend Advanced Search for IXes and Facilities Adds search filters to advanced search (ix capacity search, organization presence search, and network presence search.) #799 Additional self-selection fields for IX objects Added service_level and terms fields to InternetExchange objects to allow exchanges to share additional ifnormation about their offering. These are supported as filters in the advanced search. #834 Add ix_count to object fac In the API, added a read-only field to fac called ix_count that counts the number of exchanges the linked to the facility). #835 Add {ix,fac}_count to object net In the API, added read-only fields to net called ix_count and fac_count that count the number of exchanges and facilities linked to the network). #836 Add fac_count to object ix In the API, added a read-only field to ix called fac_count that counts the number of facilities in which the exchange has a presence. #922 Circumvent approval of a facility by deleting and re-adding Fixed bug where if a user deletes a status \"pending\" fac, they can re-add it and it will be status \"ok\" (should be \"pending\"). #810 Get rid of the 'Protocols supported' fields / UI for IXes Removed proto_unicast , proto_multicast , and proto_ipv6 fields from ix UI. The fields remain in the v2 api but proto_ipv6 and proto_unicast will be populated from the existance of protocols in the exchange's ixpfx records. #985 500 Error on advanced search Resolved an issue where unauthenticated users got a 500 error in advanced search.","title":"Release 2.27.1"},{"location":"release_notes/release_notes_2021/#release-2261","text":"Beta Announcement Date: 14 April, 2021 Release Date: 21 April, 2021 GitHub issue Summary #883 IXF-Importer: minimise emails to Support/DeskPRO/AC This change collates all importer suggestions into a single e-mail notification. #931 Limit the number of requests for affiliation to an ASN/org to 1 Limits the number of affiliation request to an ASN to just one. Provides visual feedback on subsequent request attempts. #913 API should do an IP6 address instead of a string match Normalizes how IPv6 addresses are stored in the database and updates existing IPv6 addresses in the databases and elsewhere.","title":"Release 2.26.1"},{"location":"release_notes/release_notes_2021/#release-2260","text":"Beta Announcement Date: 10 March, 2021 Release Date: 24 March, 2021 GitHub issue Summary #266 Add API Keys This release introduces organization level API Keys . #827 Make GUI and API feature equivalent PeeringDB has a GUI and an API. This issue is a reminder to keep both feature equivalent. #865 Allow arbitrary decimal places as input for longitude and latitude. Systems rounds to six Allow arbitrary length of inputs to latitude and longitude. Round to 6 digits (including Google Maps output). #902 Add \"long name\" or \"aka\" field to 'fac' records add fields aka and name_long to object fac , ix , net , and org . #937 Geocode for org is broken This was fixed through work on #940. #939 Replace Validation Error with Validation \"Warning\" for geolocation validation If our address validation service cannot find an address corresponding to the user-inputed address it will allow the object to be saved and raise a \"validation warning\" in the meta object of the API response. The web UI will display a pop-up based on this warning. #940 Return geo-normalized fields as \"suggested address\" In an effort to normalize addresses, the system may overwrite the user input. In case of a mismatch, the user now is prompted with a \"suggested address\" and either confirms or rejects. In case of rejection, the address is taken as provided by the user. Please keep an eye on what you provided and what is suggested. The suggestion may flip street name and house name as well as cut off postal codes. #918 drop travis ci and move to github actions Changed CI environment to improve deployment speed.","title":"Release 2.26.0"},{"location":"release_notes/release_notes_2021/#release-2250","text":"Release Date: 3 February, 2021 GitHub issue Summary #246 IXF should be IX-F This release introduces various spelling corrections. #828 IX-F importer: Handle ipv4/ipv6 on same vlan but separate connections This issue deals with how the IX-F importer handles information from the IX-F JSON import. PeeringDB handles both the IPv4 as well as the IPv6 address in the same object ( netixlan ). And from a peering partner pov this is ok as it doesn't matter whether these addresses are on the same interface or even same router. However, IX-F JSON differentiates. For the time being, the importer combines IPv4 and IPv6 if both are set to an operational status in the IX-F JSON. #846 IX-F importer: if ixf_ixp_member_list_url is null then ixf_ixp_import_enabled can't be true Apply logic to the meaning of ixf_ixp_member_list_url . i.e. only allow ixf_ixp_import_enabled to be set to true if a URL is specified. #875 \"IXF-Importer: improved handling of how contacts are joined into direct conflict resolution deskpro tickets\" Resolved an issue where responses to automatically generated Deskpro tickets were routed to the wrong ticket. #878 IXF-Importer: reorder of email content This is mainly an internal improvement. And fixes also not disclosing private IXP information to the public. #882 IXF-Importer: don't abort when there is nothing to import If there is nothing to import from an IX-F JSON don't abort with an error message. #893 IX-F Importer: history of changes per ixlan & netixlan Fixed bug related to the logging of importer changes. #896 IX-F Importer: Bogus output of \"Preview\" tool Fixed a bug in the preview tool, where invalid member type ignored messages weren't filtered for the network viewing the preview. #888 Type issue when overriding settings through environment variables for numeric types Fixed a bug and now ensure that overrides are coerced to the correct expected type. #872 Update dependencies Updated container to python 3.9 and addressed all dependencies. #694 add syntactic sugar for entering port speeds Simplifies the UI for editing port speeds to make it more human friendly. #717 Loading time issue /cp facility view Fixed slow load or timeouts for loading data for some facilities #837 Provide a friendlier explanation when entering / changing a phone number Provides a tooltip to help people enter E.164 formatted telephone numbers. #541 When looking at a network record, show last updated ix<->net or fac<->net date Improved information about when records were last updated.","title":"Release 2.25.0"},{"location":"release_notes/release_notes_2022/","text":"2022 Release Notes The release notes list the GitHub issues and a summary of what has changed in PeeringDB software releases. Release notes for the current year are available on the Release Notes page. Each new release has a one week beta test period on the beta server before it goes live. The beta and new releases are announced on the PeeringDB Announce Mailing List and on Twitter , LinkedIn and Facebook . Release 2.42.0 Beta Announcement Date: 9 November 2022 Release Date: 16 November 2022 GitHub issue Summary #983 Allow REALPEER to overwrite GHOSTPEER netixlan entry, if asn and IPv6/v4 addresses matches the IX-F Members Export information Improve the quality of IXP data delivered through IX-F Imports for cases when a network disconnects from an IXP but does not update their PeeringDB record. #1153 Exporting Advanced Search broken Fixes a bug that stopped users exporting some searches as structured data. #1091 Adjust \"Add Facility\" menu to include newly defined fields Newly defined fac fields, such as available voltage services, can now be entered when creating the Facility. #1253 Reset IX-F suggestions link non-functional Fixes a link that presents users with suggestions. #758 Lightweight user notification mechanism Introduce a mechanism to alert logged in web users to upcoming changes. #1250 UI shows own email when viewing affiliation requests for an organization Fixes a bug that showed organization admins their own email address instead of the user requesting affiliation. #1234 Transition from lgtm.com before the service ends Migrate to a new CI service. #1168 Ops: Throttle strings with \"Response size\" should be renamed \"Repeated request\" Improve the quality of error messages related to usage throttling. #953 User may request affiliation with a deleted organisation Fixes a bug that allowed users to request affiliation with a deleted organization. #659 Improve readability when users have special permissions Makes a support screen easier to read. #924 Allow change of ixpfx Improves automation for updating records associated with IXP peering LANs. #1270 Enable Google Analytics for beta.peeringdb.com Introduces Google Analytics for beta.peeringdb.com. More details . #1224 Internal admins only: console 504 time-out bug for ix history Fixes a timeout error affecting PeeringDB Admins. #1283 Footer \"Global System Statistics\" should be cached within django instance, not updated with every page load Introduces cacheing for the Global System Statistics data on each page. Release 2.41.1 Release Date: 26 October 2022 GitHub issue Summary #1275 Missing allowed sources for scripts Adds in some missing sources that were stopping /apidocs and CAPTCHA from working. Release 2.41.0 Beta Announcement Date: 12 October 2022 Release Date: 26 October 2022 GitHub issue Summary #586 Add export tool to https://peeringdb.com/cp/peeringdb_server/$type Adds new data exports on CSV format. #1044 Adding a POC must require an email address or phone number Points of Contact must now have either an email address or a phone number. #1244 IX-F importer fails on nulled ipv4 / ipv6 properties in vlan_list entries Fixes a bug where the IX-F importer would raise an error when encountering null values for ipv6 or ipv4 properties in the vlan_list property . #1216 RIR Status update misses ASNs Fixes a bug in the way RIR status is recorded for networks. #1223 Invalid data (in choice fields) found via API Fixes a bug where some records had invalid values. #1198 Add automated testing at the browser level Introduces automated testing for web functionality. #1149 HTTP 404 for dom-purify/purify.min.js.map and showdown/showdown.min.js.map Fixes a JS problem affecting several popular browsers. #1234 Transition from lgtm.com before the service ends Ensures continuity of continuous security analysis now after lgtm.com closes. Release 2.40.0 Beta Announcement Date: 14 September 2022 Release Date: 21 September 2022 GitHub issue Summary #736 Periodic validation of user's contact information Organizations can now require affiliated users to revalidate their accounts after a number of days chosen by the organization. #737 Restrict email domains for organizations Organizations can now require users to have an email address using a specific domain to affiliate with the organization. #484 Show username and email address when user is logged in User will now see their username and email address when logged in to the website. #738 Allow multiple email addresses per user User can have multiple email addresses associated with an account. #907 User email address change should notify previous email Users will now be notified at the old address when replacing their email address. #947 Make it possible to display the TOTP secret in text form instead of QR code only When setting up TOTP MFA, users can now see the secret as well as a QR code. #267 remove users with duplicate emails The user database has been cleaned so that only one user account can have an email address. #380 DB clean-up of elderly ophaned user accounts Users are notified when their account is not associated with an organization for 60 days. The account is removed a month later if not associated with an organization. #1157 An account with admin status can not have permissions When users gain admin status for an organization they now lose all granular permissions as they have all permissions. #468 Have the \"Select language\" drop down sorted Translation language names are now sorted alphabetically in English with the translated version of the language name presented alongside. #1202 Add Support for Enums against Locale Field Validates that languages are supported by translations. #1203 Validate Local Field against set of Enums Improves error handling when users set invalid languages. #499 Trigger IX-F import when network sets allow_ixp_update to \"yes\" An IX-F import is now triggered when a network sets allow_ixp_update to yes. #1213 robots.txt needed, at a minimum to limit bots from creating Django sessions Added robots.txt files to stop search engines indexing pages that shouldn't be indexed. #1210 UX Bugs Fixes several bugs introduced with the big UX dependency updates rolled out with 2.38. #959 ASNAUTO tool broken Fixes an issue with the ASNAuto tool sending out incorrect manual approval requests. #981 Error-handling of failed creation of DeskPRO tickets Fixes a problem with the creation of support tickets. #1150 Ops: Log Melissa payload in django.log Fixes a logging issue for the Ops team. #1228 Change \"Resul length\" to \"Result length\" Fixes a typo. This release also introduced a change for updates made with the API. These operations must now be authenticated with an API Key. Our HOWTO document explains how to get started using API Keys. Release 2.39.0 Beta Announcement Date: 20 July 2022 Release Date: 27 July 2022 GitHub issue Summary #473 add rir_* fields to keep track of ASN status Improve data quality by adding fields that will allow us to perform statical analysis and remove ASNs when no longer assigned. #1203 Validate Local Field against set of Enums Improvements to error handling should a user mischievously send junk data. #1205 Ops: Limit Django sessions to pages that need it Django sessions are now limited to pages that need it. #941 Organization Merging Tool only offers the first 10 matches Improve the organization merge tool for admins. #1043 AC Change User Permission broken Fixes a bug that did not remove users from an organization when it was deleted. #1157 An account with admin status can not have permissions Fixes a bug that did not remove granular permissions for an organization when a users was upgraded to an admin. #1135 #727 RS Peer Checkbox followup changes Cosmetic changes to the RS Peer Checkbox. Release 2.38.2 Release Date: 24 June 2022 GitHub issue Summary #1194 Advanced search issues Fixes a bug that stopped advanced search from delivering results. #1195 UI: active tabs no longer highlighted after switching Fixes a bug that stopped the current tab being highlighted in active search after changing tab. Release 2.38.0 Beta Announcement Date: 15 June 2022 Release Date: 22 June 2022 GitHub issue Summary #930 Admin user is missing the \"Edit\" button Fixes a bug that prevented users from editing their entries. #963 Add the IX name and id to IX-F Import Emails Addresses messages to exchange operators more clearly. #879 Add \"Last login\" to https://peeringdb.com/cp/peeringdb_server/user/ Let's the Admin Committee know who from an organization most recently logged in. #1057 Force users to provide input for first / last names when registering with PeeringDB Use the username instead of formal name in tickets when it's not registered. #660 Bug in renumbering tool Fixes a bug with the renubering tool. #1172 Ops: Exempt superusers (PeeringDB Admin Committee & Operations Committee admins) from throttling API and Melissa request throttling is no longer applied to authenticated admin users. #1177 Locale field update has uncaught exception Fixes a bug where a logged in user could send data that generated DataError and Internal Server Error. Exceptions are now caught appropriately and return relevant errors to users. #1174 Insecure Dependencies Upgrades three dependencies to newer versions that address known vulnerabilities. #1186 Browser caches OAuth2 application client secrets Fixes a bug that allowed browsers to cache the OAuth2 application details page. #1184 Tie CSRF token to session Fixes a bug by binding the session ID and the CSRF token together to reduce the risk that an old token is misused. Release 2.37.0 Beta Announcement Date: 11 May 2022 Release Date: 17 May 2022 GitHub issue Summary #403 Notify a record holder when there is an automated change to the profile Notifications are now sent when PeeringDB administrators make changes to records. #1155 Feature Request: Promote OAuth application to admin-level access? Adds organization level OAuth app management and allows organizations to transfer existing OAuth apps tied to their users to the organization. #942 Failure on Admin Organization Merge Fixes a big that prevented PeeringDB Admins from merging organizations. #960 Change any \"Primary ASN\" to \"ASN\" Replaces the phrase \"Primary ASN\" with \"ASN\" everywhere as the Primary ASN concept does not exist in PeeringDB 2.0. #986 Add link to release notes to the footer of www.peeringdb.com Release notes are now linked from the footer, making them easier for all users to find. Release 2.36.0 Beta Announcement Date: 13 April 2022 Release Date: 11 May 2022 GitHub issue Summary peeringdb-py #62 Support User & Org API keys Adds API keys support for the peeringdb-py cacheing client. #1079 Normalize the names of states & provinces for various objects Normalizes names for states and provinces, improving search experience. #784 Do not show objects in status \"pending\" on the UI Objects that do not have an OK status are no longer returned in search results. #996 500 Error during login for 2FA enabled accounts with unverified email address Fixes a bug that generated a 500 error when logging in with an account whose e-mail address had not been verified. #845 Need consolidated app logs Improvements to logging. #1119 Some command-line-tool executions are not logged Improves logging so AC tools can undo actions. #1120 Ops: response header X-Auth-ID to augment logging Logs the user for requested authenticated by API keys allowing them to be contacted. #1121 Ops: API throttling needs customizable messages API requests can now be throttled with custom return code (HTTP 429). #1122 Logging for melissa (geo-address normalization) queries Adds support for logging geosearch queries to the external API. #1124 Allow rate-limiting of melissa enabled api functionality. Adds support for rate-limiting the geosearch features that rely on an external API. #1126 Ops: API throttling of repeated requests Adds support for throttling repeated requests. #1096 Clicking on Facility history in AC GUI throws 500 Fixes a bug that hid fac history. #1035 Django-Admin: adding a network with existing asn fails with internal error Fixes a bug that returned a 500 error when a user attempted to add a net with the same ASN as an existing object. It now returns a more helpful validation error. Release 2.35.0 Beta Announcement Date: 8 March 2022 Release Date: 22 March 2022 GitHub issue Summary #506 Add \"Management\" search field to Advanced Search of Exchanges Allows users to search for IXPs based on the organization that operates the IXP. #727 RS Peer Checkbox also visible on IX Site Information about networks claiming to peer with the Route Server is now shown on the IXP's page. #512 New Field \"Health Check\" Networks, IXPs, and Facilities can now link to a status dashboard page. #653 missing delete button for user There is now a button to delete a user account directly through the web interface. #656 Sort user IDs in https://www.peeringdb.com/cp/peeringdb_server/userpermission/xxxxx numerically Fixes the sorting order of user IDs, so they are now sorted in numerical order. #881 wrap correctly on mobile The ASN column on mobile view will show seven digits before wrapping the number. #908 2FA Backup Tokens language doesn't seem correct Fixes the backup tokens language for 2FA. #916 To force or not to force www, that is a question Forces https://www.peeringdb.com as the URL for PeeringDB, enabling other improvements. Some clients will need to adjust their endpoints to use www.peeringdb.com. curl users will want to use the -L flag. #1042 Long caching of deleted entries Fixes a problem where deleted objects continued to be returned because of cacheing. #1117 Bad API keys need to return 401 just like a bad user/pass. Presently they return 200 Fixes a problem where corrupt or expired or bogus API key simply resulted in an anonymous user session. Release 2.34.0 Beta Announcement Date: 9 February 2022 Release Date: 16 February 2022 GitHub issue Summary #722 Create a validation tool for syntactically well defined fields Introduces a tool to improve data quality by validating syntactically well defined fields. #853 substantially rate limit unauthenticated /api/ queries to encourage authenticated queries Introduces rate limiting for unauthenticated API queries to reduce the possibility of service impacting queries. #620 Add organisations and registered users to \"Global System Statistics\" in footer Adds the number of registered users to the footer, giving users a better idea of the size of the interconnection community. Release 2.33.0 Beta Announcement Date: 12 January 2022 Release Date: 19 January 2022 GitHub issue Summary #1083 Nanog 83 Hackathon improvements to the PeeringDB Website When using simple search on the front page of www.peeringdb.com (or via the API) searches for numbers return the most relevant results. Key changes include: searching for a short ASN returns just that network, and searches for two segments of an IP address are required to return related ix and net objects. #1070 OpenID Connect integration Allows organizations using PeeringDB to enable an identity federation with a managed service. #692 Add FIDO U2F 2FA support Adds support for FIDO U2F hardware tokens, allowing users to enable 2FA without relying on a TOTP app. #1033 Clicking \"Add\" to add a user api-key without providing a name for the key raises Internal Error Fixes a bug where unnamed user api-keys could not be added and there was just an internal error. #374 make URL required for new objects A URL to a website is now required when adding new objects. #469 Add IXP to AS record / dropdown limited Fixes a bug that limited the number of entries in the dropdown menu when adding an ix to a net . #284 global stats don't show up at login screen Global stats are now shown at the login web page. #874 Better error message when entering the wrong password for email change Improved the error message when entering the wrong password for an e-mail change. #365 Username retrieval non-existant email bug Fixes a bug where we attempted to send mail to non-existant addresses. #735 Cascade delete when performed by superuser Admin users can now cascade delete through the admin interface. #901 Creating a facility that matches the name of a soft-deleted facility will cause the entry to bypass the verification queue Fixes a bug where fac creation could bypass the validation process. #921 irr source validator doesn't allow for hyphens in source IRRs with a hyphen in the name, like ARIN-NONAUTH, are now supported. #1060 \"HARAKIRI ON WORKER\" issues need to be resolved Fixes an operational issue. #1062 Registering a new facility or exchange organization is broken Fixes a bug that prevented new fac and ix objects to be registered. #1077 Possible for \"pending\" exchange to have \"deleted\" ixlan Fixes a bug that allowed linked ix objects to jhave a different status, affecting API sync. #1088 Tweaks for empty organization clean up Fixes a bug that allowed sponsor organizations to be deleted by an automatic process when they should not be.","title":"2022 Release Notes"},{"location":"release_notes/release_notes_2022/#2022-release-notes","text":"The release notes list the GitHub issues and a summary of what has changed in PeeringDB software releases. Release notes for the current year are available on the Release Notes page. Each new release has a one week beta test period on the beta server before it goes live. The beta and new releases are announced on the PeeringDB Announce Mailing List and on Twitter , LinkedIn and Facebook .","title":"2022 Release Notes"},{"location":"release_notes/release_notes_2022/#release-2420","text":"Beta Announcement Date: 9 November 2022 Release Date: 16 November 2022 GitHub issue Summary #983 Allow REALPEER to overwrite GHOSTPEER netixlan entry, if asn and IPv6/v4 addresses matches the IX-F Members Export information Improve the quality of IXP data delivered through IX-F Imports for cases when a network disconnects from an IXP but does not update their PeeringDB record. #1153 Exporting Advanced Search broken Fixes a bug that stopped users exporting some searches as structured data. #1091 Adjust \"Add Facility\" menu to include newly defined fields Newly defined fac fields, such as available voltage services, can now be entered when creating the Facility. #1253 Reset IX-F suggestions link non-functional Fixes a link that presents users with suggestions. #758 Lightweight user notification mechanism Introduce a mechanism to alert logged in web users to upcoming changes. #1250 UI shows own email when viewing affiliation requests for an organization Fixes a bug that showed organization admins their own email address instead of the user requesting affiliation. #1234 Transition from lgtm.com before the service ends Migrate to a new CI service. #1168 Ops: Throttle strings with \"Response size\" should be renamed \"Repeated request\" Improve the quality of error messages related to usage throttling. #953 User may request affiliation with a deleted organisation Fixes a bug that allowed users to request affiliation with a deleted organization. #659 Improve readability when users have special permissions Makes a support screen easier to read. #924 Allow change of ixpfx Improves automation for updating records associated with IXP peering LANs. #1270 Enable Google Analytics for beta.peeringdb.com Introduces Google Analytics for beta.peeringdb.com. More details . #1224 Internal admins only: console 504 time-out bug for ix history Fixes a timeout error affecting PeeringDB Admins. #1283 Footer \"Global System Statistics\" should be cached within django instance, not updated with every page load Introduces cacheing for the Global System Statistics data on each page.","title":"Release 2.42.0"},{"location":"release_notes/release_notes_2022/#release-2411","text":"Release Date: 26 October 2022 GitHub issue Summary #1275 Missing allowed sources for scripts Adds in some missing sources that were stopping /apidocs and CAPTCHA from working.","title":"Release 2.41.1"},{"location":"release_notes/release_notes_2022/#release-2410","text":"Beta Announcement Date: 12 October 2022 Release Date: 26 October 2022 GitHub issue Summary #586 Add export tool to https://peeringdb.com/cp/peeringdb_server/$type Adds new data exports on CSV format. #1044 Adding a POC must require an email address or phone number Points of Contact must now have either an email address or a phone number. #1244 IX-F importer fails on nulled ipv4 / ipv6 properties in vlan_list entries Fixes a bug where the IX-F importer would raise an error when encountering null values for ipv6 or ipv4 properties in the vlan_list property . #1216 RIR Status update misses ASNs Fixes a bug in the way RIR status is recorded for networks. #1223 Invalid data (in choice fields) found via API Fixes a bug where some records had invalid values. #1198 Add automated testing at the browser level Introduces automated testing for web functionality. #1149 HTTP 404 for dom-purify/purify.min.js.map and showdown/showdown.min.js.map Fixes a JS problem affecting several popular browsers. #1234 Transition from lgtm.com before the service ends Ensures continuity of continuous security analysis now after lgtm.com closes.","title":"Release 2.41.0"},{"location":"release_notes/release_notes_2022/#release-2400","text":"Beta Announcement Date: 14 September 2022 Release Date: 21 September 2022 GitHub issue Summary #736 Periodic validation of user's contact information Organizations can now require affiliated users to revalidate their accounts after a number of days chosen by the organization. #737 Restrict email domains for organizations Organizations can now require users to have an email address using a specific domain to affiliate with the organization. #484 Show username and email address when user is logged in User will now see their username and email address when logged in to the website. #738 Allow multiple email addresses per user User can have multiple email addresses associated with an account. #907 User email address change should notify previous email Users will now be notified at the old address when replacing their email address. #947 Make it possible to display the TOTP secret in text form instead of QR code only When setting up TOTP MFA, users can now see the secret as well as a QR code. #267 remove users with duplicate emails The user database has been cleaned so that only one user account can have an email address. #380 DB clean-up of elderly ophaned user accounts Users are notified when their account is not associated with an organization for 60 days. The account is removed a month later if not associated with an organization. #1157 An account with admin status can not have permissions When users gain admin status for an organization they now lose all granular permissions as they have all permissions. #468 Have the \"Select language\" drop down sorted Translation language names are now sorted alphabetically in English with the translated version of the language name presented alongside. #1202 Add Support for Enums against Locale Field Validates that languages are supported by translations. #1203 Validate Local Field against set of Enums Improves error handling when users set invalid languages. #499 Trigger IX-F import when network sets allow_ixp_update to \"yes\" An IX-F import is now triggered when a network sets allow_ixp_update to yes. #1213 robots.txt needed, at a minimum to limit bots from creating Django sessions Added robots.txt files to stop search engines indexing pages that shouldn't be indexed. #1210 UX Bugs Fixes several bugs introduced with the big UX dependency updates rolled out with 2.38. #959 ASNAUTO tool broken Fixes an issue with the ASNAuto tool sending out incorrect manual approval requests. #981 Error-handling of failed creation of DeskPRO tickets Fixes a problem with the creation of support tickets. #1150 Ops: Log Melissa payload in django.log Fixes a logging issue for the Ops team. #1228 Change \"Resul length\" to \"Result length\" Fixes a typo. This release also introduced a change for updates made with the API. These operations must now be authenticated with an API Key. Our HOWTO document explains how to get started using API Keys.","title":"Release 2.40.0"},{"location":"release_notes/release_notes_2022/#release-2390","text":"Beta Announcement Date: 20 July 2022 Release Date: 27 July 2022 GitHub issue Summary #473 add rir_* fields to keep track of ASN status Improve data quality by adding fields that will allow us to perform statical analysis and remove ASNs when no longer assigned. #1203 Validate Local Field against set of Enums Improvements to error handling should a user mischievously send junk data. #1205 Ops: Limit Django sessions to pages that need it Django sessions are now limited to pages that need it. #941 Organization Merging Tool only offers the first 10 matches Improve the organization merge tool for admins. #1043 AC Change User Permission broken Fixes a bug that did not remove users from an organization when it was deleted. #1157 An account with admin status can not have permissions Fixes a bug that did not remove granular permissions for an organization when a users was upgraded to an admin. #1135 #727 RS Peer Checkbox followup changes Cosmetic changes to the RS Peer Checkbox.","title":"Release 2.39.0"},{"location":"release_notes/release_notes_2022/#release-2382","text":"Release Date: 24 June 2022 GitHub issue Summary #1194 Advanced search issues Fixes a bug that stopped advanced search from delivering results. #1195 UI: active tabs no longer highlighted after switching Fixes a bug that stopped the current tab being highlighted in active search after changing tab.","title":"Release 2.38.2"},{"location":"release_notes/release_notes_2022/#release-2380","text":"Beta Announcement Date: 15 June 2022 Release Date: 22 June 2022 GitHub issue Summary #930 Admin user is missing the \"Edit\" button Fixes a bug that prevented users from editing their entries. #963 Add the IX name and id to IX-F Import Emails Addresses messages to exchange operators more clearly. #879 Add \"Last login\" to https://peeringdb.com/cp/peeringdb_server/user/ Let's the Admin Committee know who from an organization most recently logged in. #1057 Force users to provide input for first / last names when registering with PeeringDB Use the username instead of formal name in tickets when it's not registered. #660 Bug in renumbering tool Fixes a bug with the renubering tool. #1172 Ops: Exempt superusers (PeeringDB Admin Committee & Operations Committee admins) from throttling API and Melissa request throttling is no longer applied to authenticated admin users. #1177 Locale field update has uncaught exception Fixes a bug where a logged in user could send data that generated DataError and Internal Server Error. Exceptions are now caught appropriately and return relevant errors to users. #1174 Insecure Dependencies Upgrades three dependencies to newer versions that address known vulnerabilities. #1186 Browser caches OAuth2 application client secrets Fixes a bug that allowed browsers to cache the OAuth2 application details page. #1184 Tie CSRF token to session Fixes a bug by binding the session ID and the CSRF token together to reduce the risk that an old token is misused.","title":"Release 2.38.0"},{"location":"release_notes/release_notes_2022/#release-2370","text":"Beta Announcement Date: 11 May 2022 Release Date: 17 May 2022 GitHub issue Summary #403 Notify a record holder when there is an automated change to the profile Notifications are now sent when PeeringDB administrators make changes to records. #1155 Feature Request: Promote OAuth application to admin-level access? Adds organization level OAuth app management and allows organizations to transfer existing OAuth apps tied to their users to the organization. #942 Failure on Admin Organization Merge Fixes a big that prevented PeeringDB Admins from merging organizations. #960 Change any \"Primary ASN\" to \"ASN\" Replaces the phrase \"Primary ASN\" with \"ASN\" everywhere as the Primary ASN concept does not exist in PeeringDB 2.0. #986 Add link to release notes to the footer of www.peeringdb.com Release notes are now linked from the footer, making them easier for all users to find.","title":"Release 2.37.0"},{"location":"release_notes/release_notes_2022/#release-2360","text":"Beta Announcement Date: 13 April 2022 Release Date: 11 May 2022 GitHub issue Summary peeringdb-py #62 Support User & Org API keys Adds API keys support for the peeringdb-py cacheing client. #1079 Normalize the names of states & provinces for various objects Normalizes names for states and provinces, improving search experience. #784 Do not show objects in status \"pending\" on the UI Objects that do not have an OK status are no longer returned in search results. #996 500 Error during login for 2FA enabled accounts with unverified email address Fixes a bug that generated a 500 error when logging in with an account whose e-mail address had not been verified. #845 Need consolidated app logs Improvements to logging. #1119 Some command-line-tool executions are not logged Improves logging so AC tools can undo actions. #1120 Ops: response header X-Auth-ID to augment logging Logs the user for requested authenticated by API keys allowing them to be contacted. #1121 Ops: API throttling needs customizable messages API requests can now be throttled with custom return code (HTTP 429). #1122 Logging for melissa (geo-address normalization) queries Adds support for logging geosearch queries to the external API. #1124 Allow rate-limiting of melissa enabled api functionality. Adds support for rate-limiting the geosearch features that rely on an external API. #1126 Ops: API throttling of repeated requests Adds support for throttling repeated requests. #1096 Clicking on Facility history in AC GUI throws 500 Fixes a bug that hid fac history. #1035 Django-Admin: adding a network with existing asn fails with internal error Fixes a bug that returned a 500 error when a user attempted to add a net with the same ASN as an existing object. It now returns a more helpful validation error.","title":"Release 2.36.0"},{"location":"release_notes/release_notes_2022/#release-2350","text":"Beta Announcement Date: 8 March 2022 Release Date: 22 March 2022 GitHub issue Summary #506 Add \"Management\" search field to Advanced Search of Exchanges Allows users to search for IXPs based on the organization that operates the IXP. #727 RS Peer Checkbox also visible on IX Site Information about networks claiming to peer with the Route Server is now shown on the IXP's page. #512 New Field \"Health Check\" Networks, IXPs, and Facilities can now link to a status dashboard page. #653 missing delete button for user There is now a button to delete a user account directly through the web interface. #656 Sort user IDs in https://www.peeringdb.com/cp/peeringdb_server/userpermission/xxxxx numerically Fixes the sorting order of user IDs, so they are now sorted in numerical order. #881 wrap correctly on mobile The ASN column on mobile view will show seven digits before wrapping the number. #908 2FA Backup Tokens language doesn't seem correct Fixes the backup tokens language for 2FA. #916 To force or not to force www, that is a question Forces https://www.peeringdb.com as the URL for PeeringDB, enabling other improvements. Some clients will need to adjust their endpoints to use www.peeringdb.com. curl users will want to use the -L flag. #1042 Long caching of deleted entries Fixes a problem where deleted objects continued to be returned because of cacheing. #1117 Bad API keys need to return 401 just like a bad user/pass. Presently they return 200 Fixes a problem where corrupt or expired or bogus API key simply resulted in an anonymous user session.","title":"Release 2.35.0"},{"location":"release_notes/release_notes_2022/#release-2340","text":"Beta Announcement Date: 9 February 2022 Release Date: 16 February 2022 GitHub issue Summary #722 Create a validation tool for syntactically well defined fields Introduces a tool to improve data quality by validating syntactically well defined fields. #853 substantially rate limit unauthenticated /api/ queries to encourage authenticated queries Introduces rate limiting for unauthenticated API queries to reduce the possibility of service impacting queries. #620 Add organisations and registered users to \"Global System Statistics\" in footer Adds the number of registered users to the footer, giving users a better idea of the size of the interconnection community.","title":"Release 2.34.0"},{"location":"release_notes/release_notes_2022/#release-2330","text":"Beta Announcement Date: 12 January 2022 Release Date: 19 January 2022 GitHub issue Summary #1083 Nanog 83 Hackathon improvements to the PeeringDB Website When using simple search on the front page of www.peeringdb.com (or via the API) searches for numbers return the most relevant results. Key changes include: searching for a short ASN returns just that network, and searches for two segments of an IP address are required to return related ix and net objects. #1070 OpenID Connect integration Allows organizations using PeeringDB to enable an identity federation with a managed service. #692 Add FIDO U2F 2FA support Adds support for FIDO U2F hardware tokens, allowing users to enable 2FA without relying on a TOTP app. #1033 Clicking \"Add\" to add a user api-key without providing a name for the key raises Internal Error Fixes a bug where unnamed user api-keys could not be added and there was just an internal error. #374 make URL required for new objects A URL to a website is now required when adding new objects. #469 Add IXP to AS record / dropdown limited Fixes a bug that limited the number of entries in the dropdown menu when adding an ix to a net . #284 global stats don't show up at login screen Global stats are now shown at the login web page. #874 Better error message when entering the wrong password for email change Improved the error message when entering the wrong password for an e-mail change. #365 Username retrieval non-existant email bug Fixes a bug where we attempted to send mail to non-existant addresses. #735 Cascade delete when performed by superuser Admin users can now cascade delete through the admin interface. #901 Creating a facility that matches the name of a soft-deleted facility will cause the entry to bypass the verification queue Fixes a bug where fac creation could bypass the validation process. #921 irr source validator doesn't allow for hyphens in source IRRs with a hyphen in the name, like ARIN-NONAUTH, are now supported. #1060 \"HARAKIRI ON WORKER\" issues need to be resolved Fixes an operational issue. #1062 Registering a new facility or exchange organization is broken Fixes a bug that prevented new fac and ix objects to be registered. #1077 Possible for \"pending\" exchange to have \"deleted\" ixlan Fixes a bug that allowed linked ix objects to jhave a different status, affecting API sync. #1088 Tweaks for empty organization clean up Fixes a bug that allowed sponsor organizations to be deleted by an automatic process when they should not be.","title":"Release 2.33.0"},{"location":"release_notes/release_notes_2023/","text":"2023 Release Notes The release notes list the GitHub issues and a summary of what has changed in PeeringDB software releases. Each new release has a one week beta test period on the beta server before it goes live. The beta and new releases are announced on the PeeringDB Announce Mailing List and on Facebook , LinkedIn and X . Release 2.53.0 Beta Announcement Date: 29 November 2023 Release Date: 6 December 2023 GitHub issue Summary #1362 Show connected networks, exchanges, and carriers on campus results pages Adds an aggregated view of interconnection resources at a campus on the campus page. #1247 Store language preference in the user's profile instead of cookies Improved handling of website language preferences. #1327 Improve visibility of contact data settings Admins now see the visibility settings for their contacts alongside the set values. This makes it easier to identify and correct mistakes. #1385 Keep the list of IRR up to date As title. #1432 Make dates ISO 8601 compliant everywhere in PeeringDB As title. #1252 Display dates consistently As title. #1433 Timestamps should be consistent As title. Release 2.52.0 Beta Announcement Date: 25 October 2023 Release Date: 6 November 2023 GitHub issue Summary #1328 Support web updates from a source of truth Internal sources of truth, like configuration management systems, can now propose PeeringDB updates that a web user can review and either accept or deny. #1374 Search to include new objects: Campus & Carrier Support for new carrier and campus objects in v2 search, which is now the default with v1 search linked for the time being. #1368 Facility data export into Google Earth KMZ PeeringDB facility data is now exported into a Google Earth KMZ file that includes the details of the facility fields and their contents ( ix , net , carrier ). It is linked from the web footer and generated every day. #1394 v2 search failing to find some names Fixes a bug where names with hyphens in them were not handled properly by v2 search. #1313 Improve email confirmation control - add 3 month option & maybe set new default value Improve the design of the periodic reconfirmation control for user email addresses and add a new 3 month value. #1257 Help text covers non-compliant email addresses Non-compliant email addresses of affiliated users are now shown, making it easier to know who to contact. #1164 better rdap error reporting Improved error handling and friendlier error reporting to users. #1260 Add Selenium Grid to CI testing Improve automated browser testing for website. #1380 Reset 'Social Media' to '{}' if field is null Fixes a bug with broken page rendering for backend admin users when a social media field was set to null . Release 2.51.0 Beta Announcement Date: 13 September 2023 Release Date: 20 September 2023 GitHub issue Summary #1364 IX Object Creation Per Policy Automates approval of new ix objects per policy . #1226 Add a \"Delete Affiliation\" button/option to the profile Users can now remove an affiliation from their account. #1431 add redis for caching Improves cacheing performance. #1382 Syntax checker for social media user names broken Fixes a bug that rejected social media names that incorporated a hyphen. #1401 Creating a new network not possible Fixes a bug that stopped net creation when social media fields were sent with request. #1419 replace missing Glyphicons Use Google's \"Sort by Alpha\" icon in table headers. #1182 Manual IX-F import request queue can get stuck Fixes a bug that allowed users to enable IX-F imports without setting a URL. The importers also discards imports without a URL. #1334 IX-F Importer: Cosmetic issue with \"resolved\" emails and double-slashes in URLs after the FQDN Fixes a cosmetic issue with IX-F notification messages. Release 2.50.0 Beta Announcement Date: 16 August 2023 Release Date: 23 August 2023 GitHub issue Summary #1352 Include carrier and campus objects in the API carrier and campus objects were not included in the main API at first as we did not know if users would use them. They are now part of the API, making them usable by tools that rely on the API. #1300 display website URL on all non-org objects The website from org objects is now inherited by all child objects. #1381 Add hover tip to describe meaning of routeserver icon As title. #1361 Add Campus and Carrier Tooltips As title. #1360 IX-F Importer: IX-F Member Data not being nullified after IX stops/changes import Fixes a bug where the IX and participants were being mailed about import issues after the import was turned of by the IX operator. #1239 Add a search field to all AC views Better search for support tools. #1027 Make the search field on cp/peeringdb_server/network/ aware of leading AS/ASN Improved handling of variant syntax in support tools. #1412 Improve performance by updating Python client code Replace old python2 sync code with python3 code. Release 2.49.0 Beta Announcement Date: 12 July 2023 Release Date: 19 July 2023 GitHub issue Summary #1344 Auto approval of new carrierfac objects carrierfac objects are now approved automatically, like netfac objects . #1299 Alphabetize simple search results Exact match search now go at the top, with other results displayed alphabetically. #997 Allow organizations to require affiliated users to enable 2FA Organizations can now require their users to turn on MFA. #1370 Facility Geocode not working Fixed a bug that meant some fac s did not have a geocode. #1225 Evaluate ways to reduce operational costs Operational work to support deployment directly on cloud provider infrastructure, instead of in a VM. #1219 Optimize Cacheing It is now easier to obtain and cache PeeringDB data. #1404 Upgrade the django-oauth-toolkit library Django update deferred from last month. Oauth application owners were given notice of this breaking change. Release 2.48.0 Beta Announcement Date: 21 June 2023 Release Date: 28 June 2023 GitHub issue Summary #1311 Update Dependencies Update all dependencies to new major releases. This year includes Django 4.2 LTS. Release 2.47.0 Beta Announcement Date: 17 May 2023 Release Date: 24 May 2023 GitHub issue Summary #1204 Improve Search Functionality Significant improvements to search via a new backend. #1290 Add permission 'manage peering sessions' Adds a permission for managing peering sessions, that is useful for portal enabling PeeringDB OAuth. #1241 Don't allow the first and last addresses being assigned Added a validation check to fail on network and broadcast addresses. #1238 Put an Icon next to user name on https://www.peeringdb.com/org/nnnn#users if the user is using U2F Added a U2F badge next to user name in organization user listing if the user has set up U2F 2FA #1339 Tie TOTP devices and Webauthn Security Keys to the user account Tie TOTP devices and Webauthn Security Keys to the user account so the AC can see this information. #1291 Show all e-mail addresses associated with a username All e-mail addresses associated with a user are now shown in the users tab. #1372 Facility history still broken Fixes an issue with fac history for AC use. Release 2.46.0 Beta Announcement Date: 12 April 2023 Release Date: 19 April 2023 GitHub issue Summary #1336 Clearly show when a facility is part of a campus Adds a small icon to show that a fac is a part of a campus . #387 Replace \"website\" element in API/UI with social media tags Introduces the ability to include links to social media accounts from PeeringDB pages. #1333 Calling /api/carrier with parameters is broken Fixes a bug in the API support for the new carrier object. #1094 IX-F Importer: duplicate address(es) should result in rejection of JSON export and notification of IXP Fixes a bug in handling duplicate IP addresses in IX-F imports. #1249 Update MkDocs for docs.peeringdb.com Updates the software used by https://docs.peeringdb.com Release 2.45.0 Beta Announcement Date: 15 March 2023 Release Date: 22 March 2023 GitHub issue Summary #1295 Allow anonymous users to change languages It is now possible to select a PeeringDB translation without logging in to the website. #1281 better <title> tags The HTML <title> tag of pages on www.peeringdb.com now shows key information from the page, like a network name or search term. #749 Rename Private Peering Facilities to Interconnection Facilities in the UI Private Peering Facilities have been renamed to Interconnection Facilities in the UI. #1308 Deploy Google Analytics on www and docs We have deployed Google Analytics to measure website traffic. #1271 Implement auto-removal of stale networks according to DOTF recommendations Stay networks are now automatically removed as per the DOTF recommendations . #389 It should be impossible to save an active entity under an entity that is marked as deleted. It is no longer possible to save an object under one that's marked as deleted. Release 2.44.0 Beta Announcement Date: 15 February 2023 Release Date: 22 February 2023 GitHub issue Summary #1110 Add campus object Initial deployment of a Campus object \u2013 a record to describe facilities where inter-facility cross connects are available as easily as intra-facility cross connects. #1191 OAuth logins with 2FA don't complete first time Fixes a bug that broke the OAuth flow when MFA was enabled. #668 Add \"self\" as an object identifier, for documentation purposes Adds a \"self\" object identifier to API and views for GET requests. Authenticated users going to https://www.peeringdb.com/{net Release 2.43.1 Release Date: 10 February 2023 GitHub issue Summary #1315 issues when accepting / denying carrier presence requests Fix permission issues when accepting or rejecting carrier facility presence requests and automatically approve them when they are from the same organization. Release 2.43.0 Beta Announcement Date: 18 January 2023 Release Date: 25 January 2023 GitHub issue Summary #909 Add Carrier Record Type Initial deployment of a Carrier record \u2013 a record to describe providers of high capacity links between facilities, running at layers 1 or 2 . #1140 API keys: disabling of user account by a PeeringDB admin does not disable access via a User API key. Also no disable mech, only revoke. Fixes a bug where user API Keys were not disabled when their account was disabled. #1220 API requests with invalid Authentication headers should notify users in some way Requests with an invalid API key now return appropriate error codes. #1130 Allow user to change account username Users can now change their account name. #970 Cache hints are needed for optimal CDN use Adds cache hints to make CDN deployment more effective. #1278 Commandline tool \"Run command\" button gone Fixes a problem affecting Admins \u2013 a tool was hidden. #1279 RIR status gets deleted when changes are made to the network Improves the new process for validating networks against RIR data (see: #1280 ). #658 Improve MTU field MTUs now default to 1500 and there's a new dropdown list of options to select from. #1282 Ops: Emails to OPERATIONS_EMAIL need to be rate-limited Introduces a rate limit for automatic mail sent to Operations. #1283 Footer \"Global System Statistics\" should be cached within django instance, not updated with every page load Global System Statistics are now generated periodically instead of on each page load. #1284 Ops: django needs lightweight healthcheck route that confirms database connectivity Introduces a lightweight health check for database availability. #1285 Ops: various indexes are needed Introduces new database indexes. #1288 Ops: Expose CSP_CONNECT_SRC to .env Add configuration options for ease of operations. #1296 CSRF cookie not set error from email confirmation view Fix a bug with CSRF cookies not being set. Older releases 2022 Release Notes 2021 Release Notes 2020 Release Notes","title":"2023 Release Notes"},{"location":"release_notes/release_notes_2023/#2023-release-notes","text":"The release notes list the GitHub issues and a summary of what has changed in PeeringDB software releases. Each new release has a one week beta test period on the beta server before it goes live. The beta and new releases are announced on the PeeringDB Announce Mailing List and on Facebook , LinkedIn and X .","title":"2023 Release Notes"},{"location":"release_notes/release_notes_2023/#release-2530","text":"Beta Announcement Date: 29 November 2023 Release Date: 6 December 2023 GitHub issue Summary #1362 Show connected networks, exchanges, and carriers on campus results pages Adds an aggregated view of interconnection resources at a campus on the campus page. #1247 Store language preference in the user's profile instead of cookies Improved handling of website language preferences. #1327 Improve visibility of contact data settings Admins now see the visibility settings for their contacts alongside the set values. This makes it easier to identify and correct mistakes. #1385 Keep the list of IRR up to date As title. #1432 Make dates ISO 8601 compliant everywhere in PeeringDB As title. #1252 Display dates consistently As title. #1433 Timestamps should be consistent As title.","title":"Release 2.53.0"},{"location":"release_notes/release_notes_2023/#release-2520","text":"Beta Announcement Date: 25 October 2023 Release Date: 6 November 2023 GitHub issue Summary #1328 Support web updates from a source of truth Internal sources of truth, like configuration management systems, can now propose PeeringDB updates that a web user can review and either accept or deny. #1374 Search to include new objects: Campus & Carrier Support for new carrier and campus objects in v2 search, which is now the default with v1 search linked for the time being. #1368 Facility data export into Google Earth KMZ PeeringDB facility data is now exported into a Google Earth KMZ file that includes the details of the facility fields and their contents ( ix , net , carrier ). It is linked from the web footer and generated every day. #1394 v2 search failing to find some names Fixes a bug where names with hyphens in them were not handled properly by v2 search. #1313 Improve email confirmation control - add 3 month option & maybe set new default value Improve the design of the periodic reconfirmation control for user email addresses and add a new 3 month value. #1257 Help text covers non-compliant email addresses Non-compliant email addresses of affiliated users are now shown, making it easier to know who to contact. #1164 better rdap error reporting Improved error handling and friendlier error reporting to users. #1260 Add Selenium Grid to CI testing Improve automated browser testing for website. #1380 Reset 'Social Media' to '{}' if field is null Fixes a bug with broken page rendering for backend admin users when a social media field was set to null .","title":"Release 2.52.0"},{"location":"release_notes/release_notes_2023/#release-2510","text":"Beta Announcement Date: 13 September 2023 Release Date: 20 September 2023 GitHub issue Summary #1364 IX Object Creation Per Policy Automates approval of new ix objects per policy . #1226 Add a \"Delete Affiliation\" button/option to the profile Users can now remove an affiliation from their account. #1431 add redis for caching Improves cacheing performance. #1382 Syntax checker for social media user names broken Fixes a bug that rejected social media names that incorporated a hyphen. #1401 Creating a new network not possible Fixes a bug that stopped net creation when social media fields were sent with request. #1419 replace missing Glyphicons Use Google's \"Sort by Alpha\" icon in table headers. #1182 Manual IX-F import request queue can get stuck Fixes a bug that allowed users to enable IX-F imports without setting a URL. The importers also discards imports without a URL. #1334 IX-F Importer: Cosmetic issue with \"resolved\" emails and double-slashes in URLs after the FQDN Fixes a cosmetic issue with IX-F notification messages.","title":"Release 2.51.0"},{"location":"release_notes/release_notes_2023/#release-2500","text":"Beta Announcement Date: 16 August 2023 Release Date: 23 August 2023 GitHub issue Summary #1352 Include carrier and campus objects in the API carrier and campus objects were not included in the main API at first as we did not know if users would use them. They are now part of the API, making them usable by tools that rely on the API. #1300 display website URL on all non-org objects The website from org objects is now inherited by all child objects. #1381 Add hover tip to describe meaning of routeserver icon As title. #1361 Add Campus and Carrier Tooltips As title. #1360 IX-F Importer: IX-F Member Data not being nullified after IX stops/changes import Fixes a bug where the IX and participants were being mailed about import issues after the import was turned of by the IX operator. #1239 Add a search field to all AC views Better search for support tools. #1027 Make the search field on cp/peeringdb_server/network/ aware of leading AS/ASN Improved handling of variant syntax in support tools. #1412 Improve performance by updating Python client code Replace old python2 sync code with python3 code.","title":"Release 2.50.0"},{"location":"release_notes/release_notes_2023/#release-2490","text":"Beta Announcement Date: 12 July 2023 Release Date: 19 July 2023 GitHub issue Summary #1344 Auto approval of new carrierfac objects carrierfac objects are now approved automatically, like netfac objects . #1299 Alphabetize simple search results Exact match search now go at the top, with other results displayed alphabetically. #997 Allow organizations to require affiliated users to enable 2FA Organizations can now require their users to turn on MFA. #1370 Facility Geocode not working Fixed a bug that meant some fac s did not have a geocode. #1225 Evaluate ways to reduce operational costs Operational work to support deployment directly on cloud provider infrastructure, instead of in a VM. #1219 Optimize Cacheing It is now easier to obtain and cache PeeringDB data. #1404 Upgrade the django-oauth-toolkit library Django update deferred from last month. Oauth application owners were given notice of this breaking change.","title":"Release 2.49.0"},{"location":"release_notes/release_notes_2023/#release-2480","text":"Beta Announcement Date: 21 June 2023 Release Date: 28 June 2023 GitHub issue Summary #1311 Update Dependencies Update all dependencies to new major releases. This year includes Django 4.2 LTS.","title":"Release 2.48.0"},{"location":"release_notes/release_notes_2023/#release-2470","text":"Beta Announcement Date: 17 May 2023 Release Date: 24 May 2023 GitHub issue Summary #1204 Improve Search Functionality Significant improvements to search via a new backend. #1290 Add permission 'manage peering sessions' Adds a permission for managing peering sessions, that is useful for portal enabling PeeringDB OAuth. #1241 Don't allow the first and last addresses being assigned Added a validation check to fail on network and broadcast addresses. #1238 Put an Icon next to user name on https://www.peeringdb.com/org/nnnn#users if the user is using U2F Added a U2F badge next to user name in organization user listing if the user has set up U2F 2FA #1339 Tie TOTP devices and Webauthn Security Keys to the user account Tie TOTP devices and Webauthn Security Keys to the user account so the AC can see this information. #1291 Show all e-mail addresses associated with a username All e-mail addresses associated with a user are now shown in the users tab. #1372 Facility history still broken Fixes an issue with fac history for AC use.","title":"Release 2.47.0"},{"location":"release_notes/release_notes_2023/#release-2460","text":"Beta Announcement Date: 12 April 2023 Release Date: 19 April 2023 GitHub issue Summary #1336 Clearly show when a facility is part of a campus Adds a small icon to show that a fac is a part of a campus . #387 Replace \"website\" element in API/UI with social media tags Introduces the ability to include links to social media accounts from PeeringDB pages. #1333 Calling /api/carrier with parameters is broken Fixes a bug in the API support for the new carrier object. #1094 IX-F Importer: duplicate address(es) should result in rejection of JSON export and notification of IXP Fixes a bug in handling duplicate IP addresses in IX-F imports. #1249 Update MkDocs for docs.peeringdb.com Updates the software used by https://docs.peeringdb.com","title":"Release 2.46.0"},{"location":"release_notes/release_notes_2023/#release-2450","text":"Beta Announcement Date: 15 March 2023 Release Date: 22 March 2023 GitHub issue Summary #1295 Allow anonymous users to change languages It is now possible to select a PeeringDB translation without logging in to the website. #1281 better <title> tags The HTML <title> tag of pages on www.peeringdb.com now shows key information from the page, like a network name or search term. #749 Rename Private Peering Facilities to Interconnection Facilities in the UI Private Peering Facilities have been renamed to Interconnection Facilities in the UI. #1308 Deploy Google Analytics on www and docs We have deployed Google Analytics to measure website traffic. #1271 Implement auto-removal of stale networks according to DOTF recommendations Stay networks are now automatically removed as per the DOTF recommendations . #389 It should be impossible to save an active entity under an entity that is marked as deleted. It is no longer possible to save an object under one that's marked as deleted.","title":"Release 2.45.0"},{"location":"release_notes/release_notes_2023/#release-2440","text":"Beta Announcement Date: 15 February 2023 Release Date: 22 February 2023 GitHub issue Summary #1110 Add campus object Initial deployment of a Campus object \u2013 a record to describe facilities where inter-facility cross connects are available as easily as intra-facility cross connects. #1191 OAuth logins with 2FA don't complete first time Fixes a bug that broke the OAuth flow when MFA was enabled. #668 Add \"self\" as an object identifier, for documentation purposes Adds a \"self\" object identifier to API and views for GET requests. Authenticated users going to https://www.peeringdb.com/{net","title":"Release 2.44.0"},{"location":"release_notes/release_notes_2023/#release-2431","text":"Release Date: 10 February 2023 GitHub issue Summary #1315 issues when accepting / denying carrier presence requests Fix permission issues when accepting or rejecting carrier facility presence requests and automatically approve them when they are from the same organization.","title":"Release 2.43.1"},{"location":"release_notes/release_notes_2023/#release-2430","text":"Beta Announcement Date: 18 January 2023 Release Date: 25 January 2023 GitHub issue Summary #909 Add Carrier Record Type Initial deployment of a Carrier record \u2013 a record to describe providers of high capacity links between facilities, running at layers 1 or 2 . #1140 API keys: disabling of user account by a PeeringDB admin does not disable access via a User API key. Also no disable mech, only revoke. Fixes a bug where user API Keys were not disabled when their account was disabled. #1220 API requests with invalid Authentication headers should notify users in some way Requests with an invalid API key now return appropriate error codes. #1130 Allow user to change account username Users can now change their account name. #970 Cache hints are needed for optimal CDN use Adds cache hints to make CDN deployment more effective. #1278 Commandline tool \"Run command\" button gone Fixes a problem affecting Admins \u2013 a tool was hidden. #1279 RIR status gets deleted when changes are made to the network Improves the new process for validating networks against RIR data (see: #1280 ). #658 Improve MTU field MTUs now default to 1500 and there's a new dropdown list of options to select from. #1282 Ops: Emails to OPERATIONS_EMAIL need to be rate-limited Introduces a rate limit for automatic mail sent to Operations. #1283 Footer \"Global System Statistics\" should be cached within django instance, not updated with every page load Global System Statistics are now generated periodically instead of on each page load. #1284 Ops: django needs lightweight healthcheck route that confirms database connectivity Introduces a lightweight health check for database availability. #1285 Ops: various indexes are needed Introduces new database indexes. #1288 Ops: Expose CSP_CONNECT_SRC to .env Add configuration options for ease of operations. #1296 CSRF cookie not set error from email confirmation view Fix a bug with CSRF cookies not being set.","title":"Release 2.43.0"},{"location":"release_notes/release_notes_2023/#older-releases","text":"2022 Release Notes 2021 Release Notes 2020 Release Notes","title":"Older releases"},{"location":"taskforce/dataownership/","text":"PeeringDB Data Ownership Task Force 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 (as in netixlan, ixfac, netfac, etc objects). A call for participation to the task Force was made on September 10th, 2019. Data Ownership Task Force discussions are archived and can be found at: https://lists.peeringdb.com/pipermail/dataownership-tf/ This webpage is where the work of Data Ownership Task Force will be documented, including meeting minutes, draft documents etc. as their work progresses. In April 2020, the Task Force completed its work and published the resulting PeeringDB Data Ownership Policy Document after few cycles of a Review Phase and a final Last Call over a draft document circulated on their mailing list. (Please see the mailing list archives linked above.) The resulting document can be found at: https://docs.peeringdb.com/gov/misc/2020-04-06_PeeringDB_Data_Ownership_Policy_Document_v1.0.pdf 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 publishing the Policy Document, the Task Force ended. Data ownership policy implementation presentation This video and presentation explains how PeeringDB handles IX-F import data, creating, changing or deleting netixlan objects and other changes from the implementation of the PeeringDB Data Ownership Policy. Members Darrell Budic Chris Caputo Patrick Gilmore Shane Kerr Fredrik Korsb\u00e4ck Jhonny Lima Ben Maddison Christopher Malayter William Marantz Jeri McNeill Arnold Nipper Barry O\u2019Donovan Mustafa Timur Sever Bijal Shangani Job Snijders Terry Sweetser Lukas Tribus Stefan Wahl Filiz Yilmaz (Chair)","title":"Data Ownership Task Force"},{"location":"taskforce/dataownership/#peeringdb-data-ownership-task-force","text":"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 (as in netixlan, ixfac, netfac, etc objects). A call for participation to the task Force was made on September 10th, 2019. Data Ownership Task Force discussions are archived and can be found at: https://lists.peeringdb.com/pipermail/dataownership-tf/ This webpage is where the work of Data Ownership Task Force will be documented, including meeting minutes, draft documents etc. as their work progresses. In April 2020, the Task Force completed its work and published the resulting PeeringDB Data Ownership Policy Document after few cycles of a Review Phase and a final Last Call over a draft document circulated on their mailing list. (Please see the mailing list archives linked above.) The resulting document can be found at: https://docs.peeringdb.com/gov/misc/2020-04-06_PeeringDB_Data_Ownership_Policy_Document_v1.0.pdf","title":"PeeringDB Data Ownership Task Force"},{"location":"taskforce/dataownership/#scope","text":"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 publishing the Policy Document, the Task Force ended.","title":"Scope"},{"location":"taskforce/dataownership/#data-ownership-policy-implementation-presentation","text":"This video and presentation explains how PeeringDB handles IX-F import data, creating, changing or deleting netixlan objects and other changes from the implementation of the PeeringDB Data Ownership Policy.","title":"Data ownership policy implementation presentation"},{"location":"taskforce/dataownership/#members","text":"Darrell Budic Chris Caputo Patrick Gilmore Shane Kerr Fredrik Korsb\u00e4ck Jhonny Lima Ben Maddison Christopher Malayter William Marantz Jeri McNeill Arnold Nipper Barry O\u2019Donovan Mustafa Timur Sever Bijal Shangani Job Snijders Terry Sweetser Lukas Tribus Stefan Wahl Filiz Yilmaz (Chair)","title":"Members"}]}
\ No newline at end of file
+{"config":{"indexing":"full","lang":["en"],"min_search_length":3,"prebuild_index":false,"separator":"[\\s\\-]+"},"docs":[{"location":"","text":"About PeeringDB How can PeeringDB help me to interconnect? Policies By using this service, you agree to adhere to PeeringDB's Acceptable Use Policy . The Admin Committee Guidelines and Criteria for Approving Networks, IXPs, and Facilities documents PeeringDB\u2019s registration approval process. Getting started Several short HOWTOs provide a beginner detailed instructions on how to get started using PeeringDB. Create an account and register in PeeringDB. We also have a glossary of PeeringDB terms. Getting help Please log bugs and feature requests at GitHub . Questions, comments and everything else should go to support@peeringdb.com . Mailing lists We have changed the way in which PeeringDB will be announcing future enhancements, changes, maintenance windows, and other information. If you would like to be notified of certain events, or participate in certain discussions, please subscribe to one of the following email lists: PeeringDB Announce All PeeringDB administrative announcement information, such as upgrades, maintenances, outages, etc. PeeringDB Governance Discussion list for PeeringDB governance issues. This is a community-based effort, the community\u2019s input will help guide the future of the PeeringDB as it has always done. PeeringDB Technical Discussion about PeeringDB technical topics. PeeringDB Translate Discussions about PeeringDB translations. PeeringDB User-Discuss All other topics. Our goal is to give you all the information you want, and no more. Please subscribe to any of these lists you feel are appropriate, or none. You will still be able to use the database even if you are not subscribed to any lists. Quick API start PeeringDB is available at https://www.peeringdb.com/ with self-describing API docs at https://www.peeringdb.com/apidocs/ . More thorough docs are at API Specs , but in a nutshell, just prepend the URL with api/ to get that object in JSON. For example: https://www.peeringdb.com/net/1 becomes: https://www.peeringdb.com/api/net/1 List all via API by taking the id off: https://www.peeringdb.com/api/net Local database replication is accomplished with this command line tool , please see the documentation for more information. Release notes and schedule The release notes and schedule page lists upcoming releases, and the GitHub issues and a summary of what has changed in PeeringDB software releases. Guides [es] Gu\u00eda corta para uso de peeringdb.com - Fabi\u00e1n Mej\u00eda [pt-BR] Guia de cadastro de informa\u00e7\u00f5es de ASNs no PeeringDB - Julimar Lunguinho Mendes / Equipe de Engenharia [pt-BR] Guia de cadastro de informa\u00e7\u00f5es de Facilities no PeeringDB - Julimar Lunguinho Mendes / Equipe de Engenharia Tools The tools page features tools developed by PeeringDB users. Tutorials and workshops High-level HOWTOs provide a beginner detailed instructions on how to get started using PeeringDB. PDB 101 in 20 Minutes at Peering Asia 6.0 - November 5, 2024 - Arnold Nipper PeeringDB Tutorial, learning the GUI and the API at APRICOT 2022 - February 25, 2022 - Arnold Nipper The How-to Guide at Teraco Virtual Tech Day with PeeringDB - May 6, 2021 - Ben Ryall PeeringDB Tutorial, learning the GUI and the API at APRICOT 2020 , Melbourne, AU - February 20, 2020 - Arnold Nipper How is PeeringDB organised? and The PeeringDB API at DENOG11 , Hamburg, DE - November 10, 2019 - Arnold Nipper PeeringDB Workshop at AfPIF-10 , Balaclava, MV - August 20, 2019 - Arnold Nipper ( video starts at 14:00) Part 1: Intro , Part 2: Main , Part 3: API at APRICOT 2019 , Daejeon, KR - February 27, 2018 - Arnold Nipper ( video ) Presentations The presentations page has a complete list of PeeringDB presentations that were given at events around the world. Open source Source code audit PeeringDB commissioned a full audit of PeeringDB's source code in 2018. Computest (the auditor) prepared a Third Party Memo , this memo provides a high level overview of the outcome of the source code audit. The report is available here . Beta development The PeeringDB beta server runs the latest beta software version, with full access over HTTP and the API. Note that changes made to the beta database are local to the beta server only, and are not reflected on the production servers. The latest changes to PeeringDB automagically redirects to the list of issues on PeeringDB's GitHub repository that document all of the changes in the current beta version. Historical data MySQL dumps from July, 29 2010 to March 14, 2016 are archived by CAIDA at http://data.caida.org/datasets/peeringdb-v1/ . How you can help Check your entries and make sure everything looks correct Port any scripts to the new API Send us feedback Improve these docs Add or improve a translation Thanks for your feedback, we look forward to hearing from you!","title":"About"},{"location":"#about-peeringdb","text":"","title":"About PeeringDB"},{"location":"#how-can-peeringdb-help-me-to-interconnect","text":"","title":"How can PeeringDB help me to interconnect?"},{"location":"#policies","text":"By using this service, you agree to adhere to PeeringDB's Acceptable Use Policy . The Admin Committee Guidelines and Criteria for Approving Networks, IXPs, and Facilities documents PeeringDB\u2019s registration approval process.","title":"Policies"},{"location":"#getting-started","text":"Several short HOWTOs provide a beginner detailed instructions on how to get started using PeeringDB. Create an account and register in PeeringDB. We also have a glossary of PeeringDB terms.","title":"Getting started"},{"location":"#getting-help","text":"Please log bugs and feature requests at GitHub . Questions, comments and everything else should go to support@peeringdb.com .","title":"Getting help"},{"location":"#mailing-lists","text":"We have changed the way in which PeeringDB will be announcing future enhancements, changes, maintenance windows, and other information. If you would like to be notified of certain events, or participate in certain discussions, please subscribe to one of the following email lists: PeeringDB Announce All PeeringDB administrative announcement information, such as upgrades, maintenances, outages, etc. PeeringDB Governance Discussion list for PeeringDB governance issues. This is a community-based effort, the community\u2019s input will help guide the future of the PeeringDB as it has always done. PeeringDB Technical Discussion about PeeringDB technical topics. PeeringDB Translate Discussions about PeeringDB translations. PeeringDB User-Discuss All other topics. Our goal is to give you all the information you want, and no more. Please subscribe to any of these lists you feel are appropriate, or none. You will still be able to use the database even if you are not subscribed to any lists.","title":"Mailing lists"},{"location":"#quick-api-start","text":"PeeringDB is available at https://www.peeringdb.com/ with self-describing API docs at https://www.peeringdb.com/apidocs/ . More thorough docs are at API Specs , but in a nutshell, just prepend the URL with api/ to get that object in JSON. For example: https://www.peeringdb.com/net/1 becomes: https://www.peeringdb.com/api/net/1 List all via API by taking the id off: https://www.peeringdb.com/api/net Local database replication is accomplished with this command line tool , please see the documentation for more information.","title":"Quick API start"},{"location":"#release-notes-and-schedule","text":"The release notes and schedule page lists upcoming releases, and the GitHub issues and a summary of what has changed in PeeringDB software releases.","title":"Release notes and schedule"},{"location":"#guides","text":"[es] Gu\u00eda corta para uso de peeringdb.com - Fabi\u00e1n Mej\u00eda [pt-BR] Guia de cadastro de informa\u00e7\u00f5es de ASNs no PeeringDB - Julimar Lunguinho Mendes / Equipe de Engenharia [pt-BR] Guia de cadastro de informa\u00e7\u00f5es de Facilities no PeeringDB - Julimar Lunguinho Mendes / Equipe de Engenharia","title":"Guides"},{"location":"#tools","text":"The tools page features tools developed by PeeringDB users.","title":"Tools"},{"location":"#tutorials-and-workshops","text":"High-level HOWTOs provide a beginner detailed instructions on how to get started using PeeringDB. PDB 101 in 20 Minutes at Peering Asia 6.0 - November 5, 2024 - Arnold Nipper PeeringDB Tutorial, learning the GUI and the API at APRICOT 2022 - February 25, 2022 - Arnold Nipper The How-to Guide at Teraco Virtual Tech Day with PeeringDB - May 6, 2021 - Ben Ryall PeeringDB Tutorial, learning the GUI and the API at APRICOT 2020 , Melbourne, AU - February 20, 2020 - Arnold Nipper How is PeeringDB organised? and The PeeringDB API at DENOG11 , Hamburg, DE - November 10, 2019 - Arnold Nipper PeeringDB Workshop at AfPIF-10 , Balaclava, MV - August 20, 2019 - Arnold Nipper ( video starts at 14:00) Part 1: Intro , Part 2: Main , Part 3: API at APRICOT 2019 , Daejeon, KR - February 27, 2018 - Arnold Nipper ( video )","title":"Tutorials and workshops"},{"location":"#presentations","text":"The presentations page has a complete list of PeeringDB presentations that were given at events around the world.","title":"Presentations"},{"location":"#open-source","text":"","title":"Open source"},{"location":"#source-code-audit","text":"PeeringDB commissioned a full audit of PeeringDB's source code in 2018. Computest (the auditor) prepared a Third Party Memo , this memo provides a high level overview of the outcome of the source code audit. The report is available here .","title":"Source code audit"},{"location":"#beta-development","text":"The PeeringDB beta server runs the latest beta software version, with full access over HTTP and the API. Note that changes made to the beta database are local to the beta server only, and are not reflected on the production servers. The latest changes to PeeringDB automagically redirects to the list of issues on PeeringDB's GitHub repository that document all of the changes in the current beta version.","title":"Beta development"},{"location":"#historical-data","text":"MySQL dumps from July, 29 2010 to March 14, 2016 are archived by CAIDA at http://data.caida.org/datasets/peeringdb-v1/ .","title":"Historical data"},{"location":"#how-you-can-help","text":"Check your entries and make sure everything looks correct Port any scripts to the new API Send us feedback Improve these docs Add or improve a translation Thanks for your feedback, we look forward to hearing from you!","title":"How you can help"},{"location":"api_specs/","text":"RESTful API endpoints and specifications Object types and tags Each object has an associated short hand tag you can use, current available tags are listed at https://www.peeringdb.com/apidocs/ . Requests URL The URL base appended with /api/ , append with object type and optionally object primary key Object type is not case sensitive. For example: https://www.peeringdb.com/api/ OBJ / id Encoding To specify the output format, either use the Accept: HTTP header Accept: application/json Or use extension type https://www.peeringdb.com/api/network/42.json JSON all returns fit into object: { meta: { status: message: } data: [ {}, {} ] } meta are optional data always array Note Please let us know what serializers you'd like to see. Authentication Basic HTTP authorization In order to access the API as a guest simply omit any authentication Operations GET: multiple objects endpoint: GET /api/ OBJ optional URL parameters limit int limits rows in the result set skip int skips n rows in the result set depth int nested sets will be loaded (slow) fields str comma separated list of field names - only matching fields will be returned in the data since int retrieve all objects updated since specified time (unix timestamp, seconds) [field_name] int|string queries for fields with matching value returns array of objects HTTP: GET /api/OBJ curl: curl -X GET https://<username>:<password>@peeringdb.com/api/OBJ Nested data Any field ending in the suffix _set (with the exception of 'irr_as_set') is a list of objects in a relationship with the parent object, you can expand those lists with the 'depth' parameter as explained below. The naming schema of the field will always tell you which type of object the set is holding and will correspond with the object's endpoint on the API <object_type>_set So a set called 'net_set' will hold Network objects (API endpoint /net) Note: unlike GET single, 'depth' here will ONLY expand sets, no single relationships will be expanded - this is by design Depth 0: don't expand anything (default) 1: expand all first level sets to ids 2: expand all first level sets to objects curl: curl -X GET https://<username>:<password>@peeringdb.com/api/OBJ?depth=2 Querying examples exact: curl -X GET https://<username>:<password>@peeringdb.com/api/OBJ?name=something modifier: curl -X GET https://<username>:<password>@peeringdb.com/api/OBJ?name__contains=something Querying modifiers numeric fields: __lt, less than __lte, less than equal __gt, greater than __gte, greater than equal __in, value inside set of values (comma separated) string fields: __contains, field value contains this value __startswith, field value starts with this value __in, value inside set of values (comma separated) Since You can use the since argument with a unix timestamp (seconds) to retrieve all objects updated since then. ?since=1443414678 GET: single object endpoint: GET /api/ OBJ / id required URL parameters id int optional URL parameters depth int defaults to 2 aka. nested sets and objects will be expanded fields str comma separated list of field names - only matching fields will be returned in the data returns single object in an array HTTP: GET /api/OBJ/42 curl: curl -H \"Accept: application/json\" -X GET https://<username>:<password>@peeringdb.com/api/OBJ/42 Nested data Any field ending in the suffix _set (with the exception of 'irr_as_set') is a list of objects in a relationship with the parent object, you can expand those lists with the 'depth' parameter as explained below. The naming schema of the field will always tell you which type of object the set is holding and will correspond with the object's endpoint on the API <object_type>_set So a set called 'net_set' will hold Network objects (API endpoint /net) Note: unlike GET multiple, 'depth' here will also expand single relationship in addition to sets. So 'net_id' would get expanded into a network object. unexpanded: { ... \"net_id\" : 1 } expanded: { ... \"net_id\" : 1 \"net\" : { ... network object ... } } Depth 0: don't expand anything 1 to 4: expand all sets and related objects according to level of depth specified 2 is default POST: create new object endpoint: POST /api/ OBJ required URL parameters id int fields to post in either JSON obj \"{}\" or urlencoded field=value curl: curl -H \"Content-Type: application/json\" -X POST --data \"{\\\"state\\\":\\\"active\\\"}\" https://<username>:<password>@peeringdb.com/api/OBJ PUT: edit object endpoint: PUT /api/ OBJ / id required URL parameters id int fields to post in either JSON obj \"{}\" or urlencoded field=value you have to provide the complete object with modified data. Retrieve data with depth=0, modify and then put up again. HTTP: PUT /api/OBJ/42 curl: curl -H \"Content-Type: application/json\" -X PUT --data \"{\\\"state\\\":\\\"active\\\"}\" https://<username>:<password>@peeringdb.com/api/OBJ/42 DELETE: delete object endpoint: DELETE /api/ OBJ / id required URL parameters id int HTTP: DELETE /api/OBJ/42 curl: curl -H \"Accept: application/json\" -X DELETE https://<username>:<password>@peeringdb.com/api/OBJ/42 Deleted objects can be retrieved by filtering on status=deleted with since > 0. Real world example Q: I'd like to search for Microsoft's, Salesforce.com's and Amazon.com's peering points in Europe. How can I do this? A: You can use the API to perform complex queries, like in this example. curl -sG https://www.peeringdb.com/api/netixlan --data-urlencode net_id__in=694,1100,1418 --data-urlencode ix_id__in=`curl -sG https://www.peeringdb.com/api/ix --data-urlencode region_continent=Europe | jq -c '[.data[].id]' | sed 's/\\[//;s/\\]//'` | jq -c '.data[] | [.ix_id, .net_id, .ipaddr4, .ipaddr6, .speed]' | sort -V The query looks for netixlan records belonging to Microsoft, Salesforce.com and Amazone.com (net_id__in=694,1100,1418) which are constrained to IXes in Europe based on the output from the embedded query. The embedded query in single quotes looks for all IXes with \"Continental Region = Europe\". We do a little massaging on the IX ids to get a comma-separated list, which we then use as input in the query. curl -sG https://www.peeringdb.com/api/ix --data-urlencode region_continent=Europe | jq -c '[.data[].id]' | sed 's/\\[//;s/\\]//'","title":"API Specs"},{"location":"api_specs/#restful-api-endpoints-and-specifications","text":"","title":"RESTful API endpoints and specifications"},{"location":"api_specs/#object-types-and-tags","text":"Each object has an associated short hand tag you can use, current available tags are listed at https://www.peeringdb.com/apidocs/ .","title":"Object types and tags"},{"location":"api_specs/#requests","text":"","title":"Requests"},{"location":"api_specs/#url","text":"The URL base appended with /api/ , append with object type and optionally object primary key Object type is not case sensitive. For example: https://www.peeringdb.com/api/ OBJ / id","title":"URL"},{"location":"api_specs/#encoding","text":"To specify the output format, either use the Accept: HTTP header Accept: application/json Or use extension type https://www.peeringdb.com/api/network/42.json JSON all returns fit into object: { meta: { status: message: } data: [ {}, {} ] } meta are optional data always array Note Please let us know what serializers you'd like to see.","title":"Encoding"},{"location":"api_specs/#authentication","text":"Basic HTTP authorization In order to access the API as a guest simply omit any authentication","title":"Authentication"},{"location":"api_specs/#operations","text":"","title":"Operations"},{"location":"api_specs/#get-multiple-objects","text":"endpoint: GET /api/ OBJ optional URL parameters limit int limits rows in the result set skip int skips n rows in the result set depth int nested sets will be loaded (slow) fields str comma separated list of field names - only matching fields will be returned in the data since int retrieve all objects updated since specified time (unix timestamp, seconds) [field_name] int|string queries for fields with matching value returns array of objects HTTP: GET /api/OBJ curl: curl -X GET https://<username>:<password>@peeringdb.com/api/OBJ","title":"GET: multiple objects"},{"location":"api_specs/#nested-data","text":"Any field ending in the suffix _set (with the exception of 'irr_as_set') is a list of objects in a relationship with the parent object, you can expand those lists with the 'depth' parameter as explained below. The naming schema of the field will always tell you which type of object the set is holding and will correspond with the object's endpoint on the API <object_type>_set So a set called 'net_set' will hold Network objects (API endpoint /net) Note: unlike GET single, 'depth' here will ONLY expand sets, no single relationships will be expanded - this is by design","title":"Nested data"},{"location":"api_specs/#depth","text":"0: don't expand anything (default) 1: expand all first level sets to ids 2: expand all first level sets to objects curl: curl -X GET https://<username>:<password>@peeringdb.com/api/OBJ?depth=2","title":"Depth"},{"location":"api_specs/#querying-examples","text":"exact: curl -X GET https://<username>:<password>@peeringdb.com/api/OBJ?name=something modifier: curl -X GET https://<username>:<password>@peeringdb.com/api/OBJ?name__contains=something","title":"Querying examples"},{"location":"api_specs/#querying-modifiers","text":"numeric fields: __lt, less than __lte, less than equal __gt, greater than __gte, greater than equal __in, value inside set of values (comma separated) string fields: __contains, field value contains this value __startswith, field value starts with this value __in, value inside set of values (comma separated)","title":"Querying modifiers"},{"location":"api_specs/#since","text":"You can use the since argument with a unix timestamp (seconds) to retrieve all objects updated since then. ?since=1443414678","title":"Since"},{"location":"api_specs/#get-single-object","text":"endpoint: GET /api/ OBJ / id required URL parameters id int optional URL parameters depth int defaults to 2 aka. nested sets and objects will be expanded fields str comma separated list of field names - only matching fields will be returned in the data returns single object in an array HTTP: GET /api/OBJ/42 curl: curl -H \"Accept: application/json\" -X GET https://<username>:<password>@peeringdb.com/api/OBJ/42","title":"GET: single object"},{"location":"api_specs/#nested-data_1","text":"Any field ending in the suffix _set (with the exception of 'irr_as_set') is a list of objects in a relationship with the parent object, you can expand those lists with the 'depth' parameter as explained below. The naming schema of the field will always tell you which type of object the set is holding and will correspond with the object's endpoint on the API <object_type>_set So a set called 'net_set' will hold Network objects (API endpoint /net) Note: unlike GET multiple, 'depth' here will also expand single relationship in addition to sets. So 'net_id' would get expanded into a network object. unexpanded: { ... \"net_id\" : 1 } expanded: { ... \"net_id\" : 1 \"net\" : { ... network object ... } }","title":"Nested data"},{"location":"api_specs/#depth_1","text":"0: don't expand anything 1 to 4: expand all sets and related objects according to level of depth specified 2 is default","title":"Depth"},{"location":"api_specs/#post-create-new-object","text":"endpoint: POST /api/ OBJ required URL parameters id int fields to post in either JSON obj \"{}\" or urlencoded field=value curl: curl -H \"Content-Type: application/json\" -X POST --data \"{\\\"state\\\":\\\"active\\\"}\" https://<username>:<password>@peeringdb.com/api/OBJ","title":"POST: create new object"},{"location":"api_specs/#put-edit-object","text":"endpoint: PUT /api/ OBJ / id required URL parameters id int fields to post in either JSON obj \"{}\" or urlencoded field=value you have to provide the complete object with modified data. Retrieve data with depth=0, modify and then put up again. HTTP: PUT /api/OBJ/42 curl: curl -H \"Content-Type: application/json\" -X PUT --data \"{\\\"state\\\":\\\"active\\\"}\" https://<username>:<password>@peeringdb.com/api/OBJ/42","title":"PUT: edit object"},{"location":"api_specs/#delete-delete-object","text":"endpoint: DELETE /api/ OBJ / id required URL parameters id int HTTP: DELETE /api/OBJ/42 curl: curl -H \"Accept: application/json\" -X DELETE https://<username>:<password>@peeringdb.com/api/OBJ/42 Deleted objects can be retrieved by filtering on status=deleted with since > 0.","title":"DELETE: delete object"},{"location":"api_specs/#real-world-example","text":"Q: I'd like to search for Microsoft's, Salesforce.com's and Amazon.com's peering points in Europe. How can I do this? A: You can use the API to perform complex queries, like in this example. curl -sG https://www.peeringdb.com/api/netixlan --data-urlencode net_id__in=694,1100,1418 --data-urlencode ix_id__in=`curl -sG https://www.peeringdb.com/api/ix --data-urlencode region_continent=Europe | jq -c '[.data[].id]' | sed 's/\\[//;s/\\]//'` | jq -c '.data[] | [.ix_id, .net_id, .ipaddr4, .ipaddr6, .speed]' | sort -V The query looks for netixlan records belonging to Microsoft, Salesforce.com and Amazone.com (net_id__in=694,1100,1418) which are constrained to IXes in Europe based on the output from the embedded query. The embedded query in single quotes looks for all IXes with \"Continental Region = Europe\". We do a little massaging on the IX ids to get a comma-separated list, which we then use as input in the query. curl -sG https://www.peeringdb.com/api/ix --data-urlencode region_continent=Europe | jq -c '[.data[].id]' | sed 's/\\[//;s/\\]//'","title":"Real world example"},{"location":"blogs/","text":"PeeringDB Blogs 2024 PeeringDB blogs provide deeper insight into the releases and product roadmap. October 2024 PeeringDB Product Update - October 4, 2024 Data Quality \u2014 Removing Closed Networks - September 7, 2024 Structured Data and More With PeeringDB - July 31, 2024 Containerized Deployment - July 12, 2024 Making beta.peeringdb.com, Search, and KMZ More Attractive - April 15, 2024 Better Search and Export - March 14, 2024 2023 Product Report - February 19, 2024 What happened to our web UI? - February 5, 2024 Better Data - January 19, 2024 2023 PeeringDB Whois Service to Close - November 3, 2023 Your Internal Source of Truth Can Now Push Updates to PeeringDB - November 2, 2023 See Locations in PeeringDB on a Map - October 25, 2023 Alphabetical Search Results - July 21, 2023 Network Type \u2013 What did you tell us? - July 12, 2023 We're Updating our Web UI - July 6, 2023 Network Type \u2013 Your Input Sought - June 3, 2023 New Permission: Manage Peering Sessions - May 23, 2023 Search Gets Better - May 17, 2023 PeeringDB in Your Preferred Language - March 24, 2023 User Suggestions Improve PeeringDB Usability - March 24, 2023 Do You Want Your Configuration Management System to Update PeeringDB - February 23, 2023 PeeringDB's Product Roadmap for 2023 - February 6, 2023 Carrier Objects - January 24, 2023 PeeringDB 2022 Product Report - January 9, 2023 2022 Installing peeringdb-py at NANOG 86 - November 8, 2022 Introducing Analytics - November 3, 2022 Data Quality Improvements Rolled Out - October 26, 2022 API Writes now Need an API Key - September 25, 2022 Organizational Policy Features and More - September 25, 2022 PeeringDB 2022 User Survey - September 14, 2022 Faster PeeringDB Queries - No Limits - July 26, 2022 NANOG 85 Hackathon Project - April 25, 2022 Improve Your Account Security - And Check Our URL - March 28, 2022 2021 Survey Results and 2022 Product Roadmap - February 10, 2022 PeeringDB is Developed by its Community - January 17, 2022 2021 Guidelines for Registering in PeeringDB - October 21, 2021 Your Logo Goes Here! - October 12, 2021 More Details on Facilities - September 21, 2021 Changes to Contacts Marked as Private - September 14, 2021 PeeringDB 2021 User Survey - September 7, 2021 Automating Configuration - Why We Support the IX-F Member Export Schema - August 18, 2021 Advanced Search (Part 2) - July 23, 2021 Should PeeringDB Create a New \u201cCarrier\u201d Object? - July 5, 2021 Advanced Search (Part 1) - June 23, 2021 PeeringDB Can Bring Users to Your Application - May 24, 2021 Getting the Most from PeeringDB with User Developed Tools - May 4, 2021 Geographic Search - March 24, 2021 API Keys - March 10, 2021 2020 Survey Results and 2021 Product Roadmap - March 9, 2021 2020 Contributing Code to PeeringDB Just Got Easier - December 7, 2020 PeeringDB Release v2.24.0 - November 12, 2020 PeeringDB 2020 Satisfaction Survey - November 2, 2020 PeeringDB Release v2.23.0 - October 7, 2020","title":"Blogs"},{"location":"blogs/#peeringdb-blogs","text":"","title":"PeeringDB Blogs"},{"location":"blogs/#2024","text":"PeeringDB blogs provide deeper insight into the releases and product roadmap. October 2024 PeeringDB Product Update - October 4, 2024 Data Quality \u2014 Removing Closed Networks - September 7, 2024 Structured Data and More With PeeringDB - July 31, 2024 Containerized Deployment - July 12, 2024 Making beta.peeringdb.com, Search, and KMZ More Attractive - April 15, 2024 Better Search and Export - March 14, 2024 2023 Product Report - February 19, 2024 What happened to our web UI? - February 5, 2024 Better Data - January 19, 2024","title":"2024"},{"location":"blogs/#2023","text":"PeeringDB Whois Service to Close - November 3, 2023 Your Internal Source of Truth Can Now Push Updates to PeeringDB - November 2, 2023 See Locations in PeeringDB on a Map - October 25, 2023 Alphabetical Search Results - July 21, 2023 Network Type \u2013 What did you tell us? - July 12, 2023 We're Updating our Web UI - July 6, 2023 Network Type \u2013 Your Input Sought - June 3, 2023 New Permission: Manage Peering Sessions - May 23, 2023 Search Gets Better - May 17, 2023 PeeringDB in Your Preferred Language - March 24, 2023 User Suggestions Improve PeeringDB Usability - March 24, 2023 Do You Want Your Configuration Management System to Update PeeringDB - February 23, 2023 PeeringDB's Product Roadmap for 2023 - February 6, 2023 Carrier Objects - January 24, 2023 PeeringDB 2022 Product Report - January 9, 2023","title":"2023"},{"location":"blogs/#2022","text":"Installing peeringdb-py at NANOG 86 - November 8, 2022 Introducing Analytics - November 3, 2022 Data Quality Improvements Rolled Out - October 26, 2022 API Writes now Need an API Key - September 25, 2022 Organizational Policy Features and More - September 25, 2022 PeeringDB 2022 User Survey - September 14, 2022 Faster PeeringDB Queries - No Limits - July 26, 2022 NANOG 85 Hackathon Project - April 25, 2022 Improve Your Account Security - And Check Our URL - March 28, 2022 2021 Survey Results and 2022 Product Roadmap - February 10, 2022 PeeringDB is Developed by its Community - January 17, 2022","title":"2022"},{"location":"blogs/#2021","text":"Guidelines for Registering in PeeringDB - October 21, 2021 Your Logo Goes Here! - October 12, 2021 More Details on Facilities - September 21, 2021 Changes to Contacts Marked as Private - September 14, 2021 PeeringDB 2021 User Survey - September 7, 2021 Automating Configuration - Why We Support the IX-F Member Export Schema - August 18, 2021 Advanced Search (Part 2) - July 23, 2021 Should PeeringDB Create a New \u201cCarrier\u201d Object? - July 5, 2021 Advanced Search (Part 1) - June 23, 2021 PeeringDB Can Bring Users to Your Application - May 24, 2021 Getting the Most from PeeringDB with User Developed Tools - May 4, 2021 Geographic Search - March 24, 2021 API Keys - March 10, 2021 2020 Survey Results and 2021 Product Roadmap - March 9, 2021","title":"2021"},{"location":"blogs/#2020","text":"Contributing Code to PeeringDB Just Got Easier - December 7, 2020 PeeringDB Release v2.24.0 - November 12, 2020 PeeringDB 2020 Satisfaction Survey - November 2, 2020 PeeringDB Release v2.23.0 - October 7, 2020","title":"2020"},{"location":"faq/","text":"Frequently Asked Questions General What is PeeringDB? PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions. The database is a non-profit, community-driven initiative run and promoted by volunteers. It is a public tool for the growth and good of the Internet. Join the community and support the continued development of the Internet. How do I get started? See our Quick Start guide: http://docs.peeringdb.com/#quick-start Affiliation requests Q: How does affiliation to an organization work? A: After you have registered, go to your profile . If your organization owns a network (also called AS or ASN), type in the AS number into the field ASN . Then click on the button Affiliate . If your ASN already is in PeeringDB and your org record does not yet have an admin account this request will be sent to PeeringDB Support If your organisation already has one or more admins your request is forwarded to them. They will have to approve / deny your request If your ASN is not in PeeringDB this procedure will first try to retrieve information about this ASN via RDAP to prepopulate the net record and the org record in case it also does not exist. We also use information from this query to auto approve your request if the email address in the RDAP record matches your email address. If this fails your request will be sent to PeeringDB Support You may also use the field organisation to request affiliation to an existing or new organisation. Start typing the name of your company and select from the popup or create a new organisation. Your request is sent to your admins if there is one or to PeeringDB Support otherwise In any case you should get an answer either from your admin or PeeringDB Support . If you don't get an answer within two working days, please mail PeeringDB Support providing necessary information (ASN, Organization). Technical How do I query by ASN? You may type in the ASN in the search box, or for web: http://as42.peeringdb.com https://www.peeringdb.com/net?asn=42 For API: https://www.peeringdb.com/api/net?asn=42 Using /asn used to work, what happened? Please see http://lists.peeringdb.com/pipermail/pdb-announce/2016-March/000036.html for details. How do the new permissions work? Now there is an org entity which owns the records. A record can be a facility, an exchange point, or a network. Users are added to the org entity and can then be given access to any facility, any network, any exchange point, or anything the org itself owns. Authenticating via embedded user/pass in the URL Support for this depends on the client and some browsers have stopped supporting embedded authentication in the URL So for example https://<username>:<password>@peeringdb.com/api/net/1 may work or it may not depending on the browser you are using. Why are dates represented as strings in the API? Date strings are ISO 8601 to keep a standard format. Comparison operations such as __gt , __lt , etc all still work as expected. For fetching records against updated timestamp, you may also use ?since=<seconds since epoch> How do I sync the whole database to my local machine? You may make a full local copy with https://github.com/peeringdb/peeringdb-py , see docs at http://peeringdb.github.io/peeringdb-py/cli/ The initial run will perform a full sync, while subsequent runs will incrementally update changed records. Alternatively peeringdb-simplesync can be used to maintain a mirror in PostgreSQL. When syncing to MySQL I get 'Illegal mix of collations' Such as: django.db.utils.OperationalError: (1267, \"Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation '='\") We will fix that when time allows, for the time being, just run: alter database peeringdb default character set utf8 default collate utf8_unicode_ci; What does the Never via route servers flag mean and how does it work? With release 2.18.0 a new feature Never via route servers (API field info_never_via_route_servers ) has been introduced. There is a tick box in section \"Protocols Supported\" to set it. If set it is a hint for an IXP to use that information to block any BGP updates where the AS_PATH matches the regular expression ASN . Please make sure that the IXPs you are connected to are supporting this feature. I.e. they have to check PeeringDB regularly, evaluate this field and honour the setting. Governance and membership How does one become a PeeringDB member? Your organization does not need to be a Member to have an active account at PeeringDB.com, but Membership is available to those that do. Per the Bylaws, Membership is determined by having an active PeeringDB.com account, and a subscription to the pdb-gov mailing list. What are the Terms and Conditions for PeeringDB membership? Please see http://docs.peeringdb.com/gov/#organizational-documents for the legal aspects of PeeringDB. The Acceptable Use Policy is at https://www.peeringdb.com/aup . Are there any membership fees required for members? No, there are no membership fees required. The organization welcomes sponsorships as its method of financial support. Please see https://www.peeringdb.com/sponsors for more information on supporting the PeeringDB. Are there any liabilities imposed on members? No, there are not. To register network information in the PeeringDB, is an organization required to join as a member? No, that isn't necessary.","title":"FAQs"},{"location":"faq/#frequently-asked-questions","text":"","title":"Frequently Asked Questions"},{"location":"faq/#general","text":"","title":"General"},{"location":"faq/#what-is-peeringdb","text":"PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions. The database is a non-profit, community-driven initiative run and promoted by volunteers. It is a public tool for the growth and good of the Internet. Join the community and support the continued development of the Internet.","title":"What is PeeringDB?"},{"location":"faq/#how-do-i-get-started","text":"See our Quick Start guide: http://docs.peeringdb.com/#quick-start","title":"How do I get started?"},{"location":"faq/#affiliation-requests","text":"Q: How does affiliation to an organization work? A: After you have registered, go to your profile . If your organization owns a network (also called AS or ASN), type in the AS number into the field ASN . Then click on the button Affiliate . If your ASN already is in PeeringDB and your org record does not yet have an admin account this request will be sent to PeeringDB Support If your organisation already has one or more admins your request is forwarded to them. They will have to approve / deny your request If your ASN is not in PeeringDB this procedure will first try to retrieve information about this ASN via RDAP to prepopulate the net record and the org record in case it also does not exist. We also use information from this query to auto approve your request if the email address in the RDAP record matches your email address. If this fails your request will be sent to PeeringDB Support You may also use the field organisation to request affiliation to an existing or new organisation. Start typing the name of your company and select from the popup or create a new organisation. Your request is sent to your admins if there is one or to PeeringDB Support otherwise In any case you should get an answer either from your admin or PeeringDB Support . If you don't get an answer within two working days, please mail PeeringDB Support providing necessary information (ASN, Organization).","title":"Affiliation requests"},{"location":"faq/#technical","text":"","title":"Technical"},{"location":"faq/#how-do-i-query-by-asn","text":"You may type in the ASN in the search box, or for web: http://as42.peeringdb.com https://www.peeringdb.com/net?asn=42 For API: https://www.peeringdb.com/api/net?asn=42","title":"How do I query by ASN?"},{"location":"faq/#using-asn-used-to-work-what-happened","text":"Please see http://lists.peeringdb.com/pipermail/pdb-announce/2016-March/000036.html for details.","title":"Using /asn used to work, what happened?"},{"location":"faq/#how-do-the-new-permissions-work","text":"Now there is an org entity which owns the records. A record can be a facility, an exchange point, or a network. Users are added to the org entity and can then be given access to any facility, any network, any exchange point, or anything the org itself owns.","title":"How do the new permissions work?"},{"location":"faq/#authenticating-via-embedded-userpass-in-the-url","text":"Support for this depends on the client and some browsers have stopped supporting embedded authentication in the URL So for example https://<username>:<password>@peeringdb.com/api/net/1 may work or it may not depending on the browser you are using.","title":"Authenticating via embedded user/pass in the URL"},{"location":"faq/#why-are-dates-represented-as-strings-in-the-api","text":"Date strings are ISO 8601 to keep a standard format. Comparison operations such as __gt , __lt , etc all still work as expected. For fetching records against updated timestamp, you may also use ?since=<seconds since epoch>","title":"Why are dates represented as strings in the API?"},{"location":"faq/#how-do-i-sync-the-whole-database-to-my-local-machine","text":"You may make a full local copy with https://github.com/peeringdb/peeringdb-py , see docs at http://peeringdb.github.io/peeringdb-py/cli/ The initial run will perform a full sync, while subsequent runs will incrementally update changed records. Alternatively peeringdb-simplesync can be used to maintain a mirror in PostgreSQL.","title":"How do I sync the whole database to my local machine?"},{"location":"faq/#when-syncing-to-mysql-i-get-illegal-mix-of-collations","text":"Such as: django.db.utils.OperationalError: (1267, \"Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation '='\") We will fix that when time allows, for the time being, just run: alter database peeringdb default character set utf8 default collate utf8_unicode_ci;","title":"When syncing to MySQL I get 'Illegal mix of collations'"},{"location":"faq/#what-does-the-never-via-route-servers-flag-mean-and-how-does-it-work","text":"With release 2.18.0 a new feature Never via route servers (API field info_never_via_route_servers ) has been introduced. There is a tick box in section \"Protocols Supported\" to set it. If set it is a hint for an IXP to use that information to block any BGP updates where the AS_PATH matches the regular expression ASN . Please make sure that the IXPs you are connected to are supporting this feature. I.e. they have to check PeeringDB regularly, evaluate this field and honour the setting.","title":"What does the Never via route servers flag mean and how does it work?"},{"location":"faq/#governance-and-membership","text":"","title":"Governance and membership"},{"location":"faq/#how-does-one-become-a-peeringdb-member","text":"Your organization does not need to be a Member to have an active account at PeeringDB.com, but Membership is available to those that do. Per the Bylaws, Membership is determined by having an active PeeringDB.com account, and a subscription to the pdb-gov mailing list.","title":"How does one become a PeeringDB member?"},{"location":"faq/#what-are-the-terms-and-conditions-for-peeringdb-membership","text":"Please see http://docs.peeringdb.com/gov/#organizational-documents for the legal aspects of PeeringDB. The Acceptable Use Policy is at https://www.peeringdb.com/aup .","title":"What are the Terms and Conditions for PeeringDB membership?"},{"location":"faq/#are-there-any-membership-fees-required-for-members","text":"No, there are no membership fees required. The organization welcomes sponsorships as its method of financial support. Please see https://www.peeringdb.com/sponsors for more information on supporting the PeeringDB.","title":"Are there any membership fees required for members?"},{"location":"faq/#are-there-any-liabilities-imposed-on-members","text":"No, there are not.","title":"Are there any liabilities imposed on members?"},{"location":"faq/#to-register-network-information-in-the-peeringdb-is-an-organization-required-to-join-as-a-member","text":"No, that isn't necessary.","title":"To register network information in the PeeringDB, is an organization required to join as a member?"},{"location":"glossary/","text":"Glossary This glossary focuses on terms that are specific to PeeringDB. Other organizations provide glossaries of a wide range of Internet infrastructure terminology. These include: APNIC Euro-IX ICANN RIPE NCC The first set of definitions describes object types and the second set defines the different kinds of contacts. PeeringDB specific terms Object Name Definition fac The name of the database object representing interconnection facilities. Facility A place where networks can connect with other networks. Some interconnection facilities are data centers or suites within data centers. Others are significantly smaller. facix The name of an object derived from the intersection of a fac and an ix object. This happens when an IXP has a presence at an interconnection facility. ix The name of the database object representing IXPs. ix-f The Internet Exchange Federation is a group of four regional IXP Associations. In the context of PeeringDB, their name is applied to the import of JSON structured data that complies with the IX-F Member Export Schema . IXP An infrastructure for interconnecting three or more Autonomous Systems. net The name of the database object representing networks. netix The name of an object derived from the intersection of a net and an ix object. This happens when a network is connected to an IXP. Network An Autonomous System, as defined in RFC 1930 . PeeringDB PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions. poc A Point of Contact for a specific functional role at an organization (see below). Contact role types Not all organizations will have all contact types. For example, an academic institution might not need a sales contact. Role Description Abuse A contact address where reports of abuse can be submitted. Maintenance A contact address for the receipt of maintenance notifications, such as the scheduling of maintenance windows from peers. NOC A contact address for a Network Operations Center. This is the address to use when discussing network anomalies. Policy A contact address for peering and interconnection requests and questions. Public Relations A contact address for an organization\u2019s PR or marketing team. Sales A contact address for an organization\u2019s sales team. Technical A contact address for non-routine technical questions that aren't handled by the NOC.","title":"Glossary"},{"location":"glossary/#glossary","text":"This glossary focuses on terms that are specific to PeeringDB. Other organizations provide glossaries of a wide range of Internet infrastructure terminology. These include: APNIC Euro-IX ICANN RIPE NCC The first set of definitions describes object types and the second set defines the different kinds of contacts.","title":"Glossary"},{"location":"glossary/#peeringdb-specific-terms","text":"Object Name Definition fac The name of the database object representing interconnection facilities. Facility A place where networks can connect with other networks. Some interconnection facilities are data centers or suites within data centers. Others are significantly smaller. facix The name of an object derived from the intersection of a fac and an ix object. This happens when an IXP has a presence at an interconnection facility. ix The name of the database object representing IXPs. ix-f The Internet Exchange Federation is a group of four regional IXP Associations. In the context of PeeringDB, their name is applied to the import of JSON structured data that complies with the IX-F Member Export Schema . IXP An infrastructure for interconnecting three or more Autonomous Systems. net The name of the database object representing networks. netix The name of an object derived from the intersection of a net and an ix object. This happens when a network is connected to an IXP. Network An Autonomous System, as defined in RFC 1930 . PeeringDB PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions. poc A Point of Contact for a specific functional role at an organization (see below).","title":"PeeringDB specific terms"},{"location":"glossary/#contact-role-types","text":"Not all organizations will have all contact types. For example, an academic institution might not need a sales contact. Role Description Abuse A contact address where reports of abuse can be submitted. Maintenance A contact address for the receipt of maintenance notifications, such as the scheduling of maintenance windows from peers. NOC A contact address for a Network Operations Center. This is the address to use when discussing network anomalies. Policy A contact address for peering and interconnection requests and questions. Public Relations A contact address for an organization\u2019s PR or marketing team. Sales A contact address for an organization\u2019s sales team. Technical A contact address for non-routine technical questions that aren't handled by the NOC.","title":"Contact role types"},{"location":"gov/","text":"PeeringDB Governance Mission Statement PeeringDB, a nonprofit member-based organization, facilitates the interconnection of Internet networks globally, with user-maintained information. Organizational Documents Organizational Consent (2015-12-08) Certificate and Articles of Incorporation (2015-12-16) Bylaws (2024-05-18) Policies Acceptable Use Policy Conflict of Interest Policy Data Ownership Policy Financial Controls Policy Press Release Policy Privacy Policy Member Meetings April 18th, 2024: Agenda - Minutes - Audio - Video April 13th, 2023: Agenda - Minutes April 12th, 2022: Agenda - Minutes - Audio April 8th, 2021: Agenda - Minutes - Audio April 17th, 2020: Agenda - Minutes - Audio April 25th, 2019: Agenda - Minutes - Audio April 19th, 2018: Agenda - Minutes - Audio April 20th, 2017: Agenda - Minutes - Audio April 21st, 2016: Agenda - Minutes - Audio Board Meetings & Consents 2024: 2024-05-18 , 2024-02-27 2023: 2023-08-11 , 2023-05-18 , 2023-05-08 2022: 2022-07-29 2021: 2021-09-01 , 2021-01-13 2020: 2020-07-09 , 2020-05-08 , 2020-01-13 2019: 2019-09-27 , 2019-07-16 , 2019-05-16 , 2019-03-27 , 2019-01-29 2018: 2018-11-15 , 2018-10-09 , 2018-07-19 , 2018-05-18 , 2018-04-09 , 2018-02-08 2017: 2017-10-18 , 2017-09-20 , 2017-07-07 , 2017-05-18 , 2017-02-09 , 2017-01-13 2016: 2016-12-02 , 2016-09-22 , 2016-08-10 , 2016-07-01 , 2016-05-18 , 2016-04-06 , 2016-03-04 , 2016-02-04 , 2016-01-07 2015: 2015-12-08 Strategic Plan & Organizational Objectives 2020-2021 2019-2020 2017-2018 DRAFT Finances Finance Reports: 2023 , 2022 , 2021 , 2020 , 2019 , 2018 , 2017 , 2016 , 2015 , 2014 IRS Form 990 Tax Exempt Return: 2023 , 2022 , 2021 , 2020 , 2019 , 2018 , 2017 , 2016 , 2015 , 2014 IRS Form W-9: Request for Taxpayer Identification Number and Certification (2019-09-17) IRS Exemption Letter for 501(c)(6) (2016-02-24) IRS Form 1024: Application for Recognition of Exemption Under Section 501(c)(6) (2016-01-07) Washington State Nonprofit Corporation Annual Reports 2024-11-14 , 2023-11-03 , 2022-11-01 , 2021-11-01 , 2020-11-02 , 2019-11-01 , 2018-11-01 , 2017-12-01 , 2016-12-01 , 2016-05-18 Elections & Surveys Election Results: 2024 , 2023 , 2022 , 2021 , 2020 , 2019 , 2018 , 2017 , 2016 , 2015 Voter's Guides: 2024 , 2023 , 2022 , 2021 , 2020 , 2019 , 2018 , 2017 , 2016 , 2015 Announcement of survey results and Board election plan (2015-10-20) Survey for future of PeeringDB (2015-08) Board of Directors Seat 1 (term expires 2025): Christopher Malayter , 2021- Seat 2 (term expires 2026): Job Snijders , 2015- Seat 3 (term expires 2025): Rahul Makhija , 2023- Seat 4 (term expires 2026): Aaron Hughes , 2015- Seat 5 (term expires 2025): Livio Morina , 2023- Officers Christopher Malayter , President, 2023- Aaron Hughes , Vice President, 2023- Shawna Bong , Secretary & Treasurer, 2024- Admin Committee Please see the Admin Committee page. Operations Committee Board members Snijders (Chair) and Hughes. Outreach Committee Please see the Outreach Committee page. Product Committee Please see the Product Committee page. Alumni Chris Caputo, Secretary & Treasurer 2015-2024 Patrick W. Gilmore, Board of Directors 2015-2023, Vice President 2015-2016 Matt Griswold, Board of Directors 2015-2017 Aaron Hughes, President 2015-2023 Fredrik Korsb\u00e4ck, Board of Directors 2019-2021 Arnold Nipper, Board of Directors 2015-2019 Bijal Sanghani, Board of Directors 2017-2023 Job Snijders, Vice President 2016-2023","title":"Governance"},{"location":"gov/#peeringdb-governance","text":"","title":"PeeringDB Governance"},{"location":"gov/#mission-statement","text":"PeeringDB, a nonprofit member-based organization, facilitates the interconnection of Internet networks globally, with user-maintained information.","title":"Mission Statement"},{"location":"gov/#organizational-documents","text":"Organizational Consent (2015-12-08) Certificate and Articles of Incorporation (2015-12-16) Bylaws (2024-05-18)","title":"Organizational Documents"},{"location":"gov/#policies","text":"Acceptable Use Policy Conflict of Interest Policy Data Ownership Policy Financial Controls Policy Press Release Policy Privacy Policy","title":"Policies"},{"location":"gov/#member-meetings","text":"April 18th, 2024: Agenda - Minutes - Audio - Video April 13th, 2023: Agenda - Minutes April 12th, 2022: Agenda - Minutes - Audio April 8th, 2021: Agenda - Minutes - Audio April 17th, 2020: Agenda - Minutes - Audio April 25th, 2019: Agenda - Minutes - Audio April 19th, 2018: Agenda - Minutes - Audio April 20th, 2017: Agenda - Minutes - Audio April 21st, 2016: Agenda - Minutes - Audio","title":"Member Meetings"},{"location":"gov/#board-meetings-consents","text":"2024: 2024-05-18 , 2024-02-27 2023: 2023-08-11 , 2023-05-18 , 2023-05-08 2022: 2022-07-29 2021: 2021-09-01 , 2021-01-13 2020: 2020-07-09 , 2020-05-08 , 2020-01-13 2019: 2019-09-27 , 2019-07-16 , 2019-05-16 , 2019-03-27 , 2019-01-29 2018: 2018-11-15 , 2018-10-09 , 2018-07-19 , 2018-05-18 , 2018-04-09 , 2018-02-08 2017: 2017-10-18 , 2017-09-20 , 2017-07-07 , 2017-05-18 , 2017-02-09 , 2017-01-13 2016: 2016-12-02 , 2016-09-22 , 2016-08-10 , 2016-07-01 , 2016-05-18 , 2016-04-06 , 2016-03-04 , 2016-02-04 , 2016-01-07 2015: 2015-12-08","title":"Board Meetings & Consents"},{"location":"gov/#strategic-plan-organizational-objectives","text":"2020-2021 2019-2020 2017-2018 DRAFT","title":"Strategic Plan & Organizational Objectives"},{"location":"gov/#finances","text":"Finance Reports: 2023 , 2022 , 2021 , 2020 , 2019 , 2018 , 2017 , 2016 , 2015 , 2014 IRS Form 990 Tax Exempt Return: 2023 , 2022 , 2021 , 2020 , 2019 , 2018 , 2017 , 2016 , 2015 , 2014 IRS Form W-9: Request for Taxpayer Identification Number and Certification (2019-09-17) IRS Exemption Letter for 501(c)(6) (2016-02-24) IRS Form 1024: Application for Recognition of Exemption Under Section 501(c)(6) (2016-01-07)","title":"Finances"},{"location":"gov/#washington-state-nonprofit-corporation-annual-reports","text":"2024-11-14 , 2023-11-03 , 2022-11-01 , 2021-11-01 , 2020-11-02 , 2019-11-01 , 2018-11-01 , 2017-12-01 , 2016-12-01 , 2016-05-18","title":"Washington State Nonprofit Corporation Annual Reports"},{"location":"gov/#elections-surveys","text":"Election Results: 2024 , 2023 , 2022 , 2021 , 2020 , 2019 , 2018 , 2017 , 2016 , 2015 Voter's Guides: 2024 , 2023 , 2022 , 2021 , 2020 , 2019 , 2018 , 2017 , 2016 , 2015 Announcement of survey results and Board election plan (2015-10-20) Survey for future of PeeringDB (2015-08)","title":"Elections & Surveys"},{"location":"gov/#board-of-directors","text":"Seat 1 (term expires 2025): Christopher Malayter , 2021- Seat 2 (term expires 2026): Job Snijders , 2015- Seat 3 (term expires 2025): Rahul Makhija , 2023- Seat 4 (term expires 2026): Aaron Hughes , 2015- Seat 5 (term expires 2025): Livio Morina , 2023-","title":"Board of Directors"},{"location":"gov/#officers","text":"Christopher Malayter , President, 2023- Aaron Hughes , Vice President, 2023- Shawna Bong , Secretary & Treasurer, 2024-","title":"Officers"},{"location":"gov/#admin-committee","text":"Please see the Admin Committee page.","title":"Admin Committee"},{"location":"gov/#operations-committee","text":"Board members Snijders (Chair) and Hughes.","title":"Operations Committee"},{"location":"gov/#outreach-committee","text":"Please see the Outreach Committee page.","title":"Outreach Committee"},{"location":"gov/#product-committee","text":"Please see the Product Committee page.","title":"Product Committee"},{"location":"gov/#alumni","text":"Chris Caputo, Secretary & Treasurer 2015-2024 Patrick W. Gilmore, Board of Directors 2015-2023, Vice President 2015-2016 Matt Griswold, Board of Directors 2015-2017 Aaron Hughes, President 2015-2023 Fredrik Korsb\u00e4ck, Board of Directors 2019-2021 Arnold Nipper, Board of Directors 2015-2019 Bijal Sanghani, Board of Directors 2017-2023 Job Snijders, Vice President 2016-2023","title":"Alumni"},{"location":"howtos/","text":"PeeringDB HOWTOs HOWTOs provide a beginner detailed instructions on how to get started using PeeringDB. Create entries Get Started with PeeringDB as a Carrier Operator Get Started with PeeringDB as a Exchange Operator Get Started with PeeringDB as a Facility or Campus Operator Get Started with PeeringDB as a Network Operator Manage entries Manage Organizational Policy Manage User Permissions Search Get Started with Search in PeeringDB Work Within PeeringDB\u2019s Query Limits v2 Search Authentication and security Authenticate to PeeringDB Get Started with API Keys Report a Security Issue Turn on 2FA and Require Users to Enable It Other Become a PeeringDB Member and Vote Install peeringdb-py Get Started with Developing for PeeringDB Setup a PeeringDB Development Environment What is AS112?","title":"HOWTOs"},{"location":"howtos/#peeringdb-howtos","text":"HOWTOs provide a beginner detailed instructions on how to get started using PeeringDB.","title":"PeeringDB HOWTOs"},{"location":"howtos/#create-entries","text":"Get Started with PeeringDB as a Carrier Operator Get Started with PeeringDB as a Exchange Operator Get Started with PeeringDB as a Facility or Campus Operator Get Started with PeeringDB as a Network Operator","title":"Create entries"},{"location":"howtos/#manage-entries","text":"Manage Organizational Policy Manage User Permissions","title":"Manage entries"},{"location":"howtos/#search","text":"Get Started with Search in PeeringDB Work Within PeeringDB\u2019s Query Limits v2 Search","title":"Search"},{"location":"howtos/#authentication-and-security","text":"Authenticate to PeeringDB Get Started with API Keys Report a Security Issue Turn on 2FA and Require Users to Enable It","title":"Authentication and security"},{"location":"howtos/#other","text":"Become a PeeringDB Member and Vote Install peeringdb-py Get Started with Developing for PeeringDB Setup a PeeringDB Development Environment What is AS112?","title":"Other"},{"location":"ix-f-json-import-rules/","text":"IX-F JSON Importer PeeringDB allows networks and IXPs to update entries via the IX-F JSON import feature. General remarks The Importer abides by the recommendations of the Data Ownership Task Force and its resulting Policy Document . Most significantly, this means that unless the tick box Allow IXP Update is enabled by a network, published data will not automatically become unpublished nor will unpublished data automatically become published. For Networks There is a tick box Allow IXP Update which governs the behavior of the Importer. By default this is set to disabled. If Allow IXP Update is enabled, a network entry at an IX may automatically be created, changed, or removed. The network's IX entry is completely governed by the settings in the IX-F JSON data provided by the IX. If Allow IXP Update is disabled, differences in data provided by the IX and the network will result in the following: An email to the network with details about the differences. An email to the IX with details about the differences. Admins for the network will see hints for their network within the PeeringDB web interface. These hints may be accepted or dismissed. The network and the IX are encouraged to reach out to each other to resolve any differences. IXP Update Tools: The Preview button shows the changes that will be performed or suggested during the next IX-F import, depending on the Allow IXP Update setting. The Postmortem button shows a log of recent changes performed as a result of IX-F imports. For IXPs To enable IX-F JSON import: Make sure that your JSON file is valid . Provide a URL to your IX-F JSON data. To do so, click Edit on your IX web page and set the IX-F Member Export URL to the URL and set Enable IX-F Import to enabled. You may also set the visibility of your IX-F JSON URL. Daily at 0000 UTC, the IX-F JSON data will be retrieved and processed by the Importer. The steps above for networks will then be followed. If the IX-F JSON state field is present, settings of active , connected , or operational may be used to indicate a network is operational, while a setting of inactive will be interpreted as the network not being operational. This may be used to denote a network in the process of connecting but not yet active, or a network on hiatus. IX-F Import Preview: The Preview button shows the changes that will be performed or suggested, depending on participant Allow IXP Update settings. A JSON form of this preview is available at: https://www.peeringdb.com/import/ixlan/###/ixf/preview (replace ### with the ID that appears in the URL after /ix/ when viewing your IX page) Note : The Importer expects that you also provide IP addresses. If your IX-F JSON has an empty member_list or only contains ASNs, there will be no useful information. You might want to disable the import. Further Information August 17th, 2020 Data Ownership Policy Implementation Presentation: slides and video","title":"IX-F JSON"},{"location":"ix-f-json-import-rules/#ix-f-json-importer","text":"PeeringDB allows networks and IXPs to update entries via the IX-F JSON import feature.","title":"IX-F JSON Importer"},{"location":"ix-f-json-import-rules/#general-remarks","text":"The Importer abides by the recommendations of the Data Ownership Task Force and its resulting Policy Document . Most significantly, this means that unless the tick box Allow IXP Update is enabled by a network, published data will not automatically become unpublished nor will unpublished data automatically become published.","title":"General remarks"},{"location":"ix-f-json-import-rules/#for-networks","text":"There is a tick box Allow IXP Update which governs the behavior of the Importer. By default this is set to disabled. If Allow IXP Update is enabled, a network entry at an IX may automatically be created, changed, or removed. The network's IX entry is completely governed by the settings in the IX-F JSON data provided by the IX. If Allow IXP Update is disabled, differences in data provided by the IX and the network will result in the following: An email to the network with details about the differences. An email to the IX with details about the differences. Admins for the network will see hints for their network within the PeeringDB web interface. These hints may be accepted or dismissed. The network and the IX are encouraged to reach out to each other to resolve any differences. IXP Update Tools: The Preview button shows the changes that will be performed or suggested during the next IX-F import, depending on the Allow IXP Update setting. The Postmortem button shows a log of recent changes performed as a result of IX-F imports.","title":"For Networks"},{"location":"ix-f-json-import-rules/#for-ixps","text":"To enable IX-F JSON import: Make sure that your JSON file is valid . Provide a URL to your IX-F JSON data. To do so, click Edit on your IX web page and set the IX-F Member Export URL to the URL and set Enable IX-F Import to enabled. You may also set the visibility of your IX-F JSON URL. Daily at 0000 UTC, the IX-F JSON data will be retrieved and processed by the Importer. The steps above for networks will then be followed. If the IX-F JSON state field is present, settings of active , connected , or operational may be used to indicate a network is operational, while a setting of inactive will be interpreted as the network not being operational. This may be used to denote a network in the process of connecting but not yet active, or a network on hiatus. IX-F Import Preview: The Preview button shows the changes that will be performed or suggested, depending on participant Allow IXP Update settings. A JSON form of this preview is available at: https://www.peeringdb.com/import/ixlan/###/ixf/preview (replace ### with the ID that appears in the URL after /ix/ when viewing your IX page) Note : The Importer expects that you also provide IP addresses. If your IX-F JSON has an empty member_list or only contains ASNs, there will be no useful information. You might want to disable the import.","title":"For IXPs"},{"location":"ix-f-json-import-rules/#further-information","text":"August 17th, 2020 Data Ownership Policy Implementation Presentation: slides and video","title":"Further Information"},{"location":"oauth/","text":"OAuth PeeringDB now offers OAuth2 authentication for third-party applications to allow users to authenticate against PeeringDB. Implementation details are at Github #131 . For an example, see IXP-Manager issue #322 . What is OAuth? There is a good write up at https://aaronparecki.com/oauth-2-simplified/ . Register an application First you need to register your application at PeeringDB. : For most applications, you'll want to use the following: Client type: Confidential Authorization grant type: Authorization code Redirect uris: add your redirect URLs here An OIDC algorithm must be selected. URLs PDB_ENDPOINT = \"https://auth.peeringdb.com/\" PDB_OAUTH_ACCESS_TOKEN_URL = '{}oauth2/token/'.format(PDB_ENDPOINT) PDB_OAUTH_AUTHORIZE_URL = '{}oauth2/authorize/'.format(PDB_ENDPOINT) PDB_OAUTH_PROFILE_URL = '{}profile/v1'.format(PDB_ENDPOINT) Fields The fields are based largely on OpenID Connect. Scopes currently are defined as profile : user profile email : adds fields email and verified_email networks : add field networks The perms field is a bitmask for CRUD as the 4 least significant bits. See following: 0b0000 1 1 1 1 | | | +-- Delete | | +---- Update | +------ Read + ------- Create Example for my user: { \"id\": 3, \"name\": \"Matt Griswold\", \"given_name\": \"Matt\", \"family_name\": \"Griswold\", \"email\": \"grizz@20c.com\", \"verified_user\": true, \"verified_email\": true, \"networks\": [ { \"perms\": 15, \"asn\": 63311, \"name\": \"20C\", \"id\": 20 }, { \"perms\": 15, \"asn\": 33713, \"name\": \"United IX\", \"id\": 7889 } ] }","title":"OAuth"},{"location":"oauth/#oauth","text":"PeeringDB now offers OAuth2 authentication for third-party applications to allow users to authenticate against PeeringDB. Implementation details are at Github #131 . For an example, see IXP-Manager issue #322 .","title":"OAuth"},{"location":"oauth/#what-is-oauth","text":"There is a good write up at https://aaronparecki.com/oauth-2-simplified/ .","title":"What is OAuth?"},{"location":"oauth/#register-an-application","text":"First you need to register your application at PeeringDB. : For most applications, you'll want to use the following: Client type: Confidential Authorization grant type: Authorization code Redirect uris: add your redirect URLs here An OIDC algorithm must be selected.","title":"Register an application"},{"location":"oauth/#urls","text":"PDB_ENDPOINT = \"https://auth.peeringdb.com/\" PDB_OAUTH_ACCESS_TOKEN_URL = '{}oauth2/token/'.format(PDB_ENDPOINT) PDB_OAUTH_AUTHORIZE_URL = '{}oauth2/authorize/'.format(PDB_ENDPOINT) PDB_OAUTH_PROFILE_URL = '{}profile/v1'.format(PDB_ENDPOINT)","title":"URLs"},{"location":"oauth/#fields","text":"The fields are based largely on OpenID Connect. Scopes currently are defined as profile : user profile email : adds fields email and verified_email networks : add field networks The perms field is a bitmask for CRUD as the 4 least significant bits. See following: 0b0000 1 1 1 1 | | | +-- Delete | | +---- Update | +------ Read + ------- Create Example for my user: { \"id\": 3, \"name\": \"Matt Griswold\", \"given_name\": \"Matt\", \"family_name\": \"Griswold\", \"email\": \"grizz@20c.com\", \"verified_user\": true, \"verified_email\": true, \"networks\": [ { \"perms\": 15, \"asn\": 63311, \"name\": \"20C\", \"id\": 20 }, { \"perms\": 15, \"asn\": 33713, \"name\": \"United IX\", \"id\": 7889 } ] }","title":"Fields"},{"location":"presentations/","text":"Presentations 2024 What's new on PeeringDB? at RSNOG 10 , Belgrade, RS - November 19, 2024 - Livio Morina What's new on PeeringDB? at 8th South African Peering Forum , Cape Town, ZA - November 14, 2024 - Obinna Adumike What's new on PeeringDB? at nog.fi meeting 2024.11 , Helsinki, FI - November 6, 2024 - Livio Morina PeeringDB Update at RIPE 89 , Prague, CZ - October 31, 2024 - Leo Vegoda What's new on PeeringDB? at NgNOG 2024 , Lagos, NG - October 23, 2024 - Obinna Adumike What's new on PeeringDB? at Netnod Tech Meeting 2024 , Stockhold, SE - October 15, 2024 - Livio Morina What's new on PeeringDB? at RONOG 9 , Bucharest, RO - October 2, 2024 - Livio Morina PeeringDB in Five Minutes at AusNOG 2024 , Sydney, AU - September 5, 2024 - Arnold Nipper What's new on PeeringDB? at AfPIF 2024 , Kinsahsa, CD - August 20, 2024 - Ben Ryall PeeringDB Introduction & Update at PhNOG 2024 Week , Makati City, PH - July 10, 2024 - Arnold Nipper PeeringDB Update at NetUK 1 , London, UK - July 8, 2024 - Paul Hoogsteder What's new on PeeringDB? at WAPF 2024 , Abidjan, CI - June 26, 2024 - Ben Ryall PeeringDB Update at MWPS 2024 , Kansas City, MO, US - June 14, 2024 - Martin Hannigan PeeringDB Update at LINX122 , London, UK - May 28, 2024 - Ben Ryall PeeringDB Update at RIPE 88 , Krak\u00f3w, PL - May 23, 2024 - Paul Hoogsteder What's new on PeeringDB? at ITNOG8 , Bologna, IT - May 7, 2024 - Livio Morina PeeringDB Introduction & Update at SANOG 41 , Mumbai, IN - April 29, 2024 - Arnold Nipper What's new on PeeringDB? at SEE 12 , Athens, GR - April 22, 2024 - Livio Morina PeeringDB Update at GPF 2024 , San Juan, PR, US - April 15, 2024 - Chris Malayter PeeringDB Update at DKNOG14 , Copenhagen, DK - March 8, 2024 - Chriztoffer Hansen PeeringDB Update at Peering Days 2024 , Krakow, PL - March 7, 2024 - Ben Ryall PeeringDB Update at NANOG 90 , Charlotte, NC, US - February 12, 2024 - Martin Hannigan 2023 PeeringDB Update at RIPE 87 , Rome, IT - November 30, 2023 - Leo Vegoda What's new on PeeringDB? at MIX Salotto 2023 , Milan, IT - November 15, 2023 - Livio Morina What is PeeringDB? Why is it important for network operators? at RSNOG9 , Belgrade, RS - November 9, 2023 - Livio Morina What\u2019s new on PeeringDB? at GRNOG 15 , Athens, GR - October 25, 2023 - Livio Morina What\u2019s new on PeeringDB? at FRnOG 38 , Paris, FR - October 6, 2023 - Livio Morina PeeringDB Operations & Product Update at SwiNOG#38 , Berne, CH - June 21, 2023 - Arnold Nipper PeeringDB Update at RIPE 86 , Rotterdam, NL - May 25, 2023 - Leo Vegoda PeeringDB Operations & Product Update at ITNOG7 , Bologna, IT - May 9, 2023 - Arnold Nipper What\u2019s new on PeeringDB? at the 38th Euro-IX Forum , Cluj-Napoca, RO - April 24, 2023 - Arnold Nipper PeeringDB Operations & Product Update at SEE 11 , Split, HR - April 5, 2023 - Arnold Nipper PeeringDB Operations & Product Update at GPF 2023 , Coronado, CA, US - April 4, 2023 - Matt Griswold PeeringDB Operations & Product Update at Peering Days 2023 , Sofia, BG - March 30, 2023 - Arnold Nipper PeeringDB Operations & Product Update at DKNOG13 , Copenhagen, DK - March 10, 2023 - Arnold Nipper 2022 PeeringDB at AOPF/AONOG 2022 - December 8, 2022 - Darwin Da Costa PeeringDB Operations & Product Update at DENOG14 , Hamburg, DE - November 15, 2022 - Arnold Nipper PeeringDB Operations & Product Update at RIPE 85 , Belgrade, RS - October 26, 2022 - Arnold Nipper PeeringDB Operations & Product Update at ngPIF 2022 , Lagos, NG - October 25, 2022 - Ben Ryall PeeringDB at WTR POP-PI 2022 - October 20, 2022 - Julimar Lunguinho Mendes ( video ) PeeringDB Call for Committee Members at NANOG 86 , Hollywood, CA, US - October 19, 2022 - Patrick Gilmore PeeringDB Operations & Product Update at the 37th Euro-IX Forum , Edinburgh, UK - October 11, 2022 - Greg Hankins PeeringDB Update at EPF 2022 , Rome, IT - September 12, 2022 - Arnold Nipper PeeringDB Update at AfPIF 2022 , Kigali, RW - August 23, 2022 - Ben Ryall PeeringDB Update at GPF 2022 , Washington, DC, US - May 12, 2022 - Chris Malayter 2021 Status Update at Virtual Tech Day with Euro-IX PeeringToolbox - February 3, 2022 - Leo Vegoda 2021 Introduction to PeeringDB at GNA-G Routing WG - December 14, 2021 - Arnold Nipper PeeringDB Update at Semana de Capacita\u00e7\u00e3o On-line 3 - October 1, 2021 - Julimar Lunguinho Mendes PeeringDB Update at WTR PoP-MA - September 30, 2021 - Julimar Lunguinho Mendes 2020 PeeringDB at IX F\u00f3rum 14 - December 4, 2020 - Julimar Lunguinho Mendes ( video ) Introducci\u00f3n a PeeringDB at Seguridad en el Ruteo: MANRS para Operadores de Red de Universidades - October 2, 2020 - Diego Dominguez Data Ownership Policy Implementation Presentation - August 17, 2020 - Filiz Yilmaz, Steve McManus, Arnold Nipper ( video ) PeeringDB Data Ownership Task Force at PeeringDB Annual Meeting 2020 - April 17, 2020 - Filiz Yilmaz PeeringDB at ABRINT na Estrada Campo Grande , Campo Grande, BR - March 10, 2020 - Julimar Lunguinho Mendes PeeringDB Update at PhNOG 2020 , Manila, PH - February 26, 2020 - Arnold Nipper PeeringDB Update at APRICOT 2020 , Melbourne, AU - February 19, 2020 - Arnold Nipper 2019 PeeringDB Update (English)/ \u041d\u043e\u0432\u043e\u0441\u0442\u0438 \u043e\u0442 PeeringDB (P\u0443\u0441\u0441\u043a\u0438\u0439) at MSK-IX Peering Forum 2019 , Moscow, RU - December 5, 2019 - Filiz Yilmaz PeeringDB - Como Est\u00e1 a Ado\u00e7\u00e3o no Brasil at MUM in Brazil , Foz do Igua\u00e7u, BR - November 29, 2019 - Julimar Lunguinho Mendes PeeringDB Para Que Sirve? at XII Encuentro Nacional de T\u00e9cnicos , Salta, AR - November 28, 2019 - Hernan Moguilevsky PeeringDB Update: A Look Into PeeringDB's Data for AT/CH/DE/LU and the Latest Changes at DENOG11 , Hamburg, DE - November 12, 2019 - Stefan Funke PeeringDB Update at Peering Asia 3.0 , Kuala Lumpur, MY - November 7, 2019 - Arnold Nipper PeeringDB Update at ATNOG 2019/2 , Vienna, AT - November 5, 2019 - Stefan Funke Introduction to PeeringDB at JBIX Peering Forum 2019 , Kuala Lumpur, MY - November 5, 2019 - Arnold Nipper Introduction to PeeringDB at ngNOG 2019 , Lagos, NG - October 30, 2019 - Ben Ryall Cadastro para participantes do IX.br at IX F\u00f3rum Regional , Florian\u00f3polis, BR - October 25, 2019 - Julimar Lunguinho Mendes OAuth for IXP Operators at the 35th Euro-IX Forum , Zaandam, NL - October 21, 2019 - Barry O'Donovan The PeeringDB API at the 35th Euro-IX Forum , Zaandam, NL - October 21, 2019 - Arnold Nipper Introduction to PeeringDB at RONOG 6 , Bucharest, RO - October 1, 2019 - Arnold Nipper PeeringDB Update at EPF14 , Tallinn, EE - September 18, 2019 - Filiz Yilmaz Cadastro para participantes do IX.br at IX F\u00f3rum Regional , Natal, BR - September 6, 2019 - Julimar Lunguinho Mendes Introduction to PeeringDB at SAFNOG-5 , Johannesburg, ZA - August 28, 2019 - Arnold Nipper Introduction to PeeringDB at AfPIF-10 , Balaclava, MV - August 22, 2019 - Arnold Nipper Introducci\u00f3n a PeeringDB at MexNOG 2019 , Mexico City, MX - August 14, 2019 - Diego Dominguez Introduction to PeeringDB at ATNOG 2019/1 , Salzburg, AT - July 16, 2019 - Arnold Nipper Introduction to PeeringDB at INNOG 2 , New Delhi, IN - July 1, 2019 - Arnold Nipper ( video ) Cadastro para participantes do IX.br at IX F\u00f3rum Regional , S\u00e3o Paulo, BR - June 10, 2019 - Julimar Lunguinho Mendes News from PeeringDB at ENOG 16 , Tbilisi, GE - June 3, 2019 - Arnold Nipper PeeringDB Update at NONOG-3 , Oslo, NO - May 27, 2019 - Arnold Nipper PeeringDB Update at SINOG 6.0 , Ljubljana, SI - May 14, 2019 - Arnold Nipper Introduction to PeeringDB at BKNIX Peering Forum and ThaiNOG Day 2019 , Bangkok, TH - May 7, 2019 - Arnold Nipper Use in Latin America at Peering Forum LAC , Punta Cana, DR - May 6, 2019 - Julimar Lunguinho Mendes and Carlos Martinez Cagnazzo Cadastro para participantes do IX.br at IX F\u00f3rum Regional , Campo Grande, BR - April 26, 2019 - Julimar Lunguinho Mendes Introduction to PeeringDB at Telecom Day , St. Petersburg, RU - April 19, 2019 - Arnold Nipper PeeringDB Update at SEE 8 , Sarajevo, BH - April 17, 2019 - Arnold Nipper PeeringDB Update at Curso Avan\u00e7ado de IPv6 , S\u00e3o Paulo, BR - April 5, 2019 - Julimar Lunguinho Mendes PeeringDB Update at BCIX Round Table April 2019 , Berlin, DE - April 4, 2019 - Stefan Funke PeeringDB Update at MENOG 19 , Beirut, LB - April 3, 2019 - Arnold Nipper PeeringDB Update at DKNOG9 , Copenhagen, DK - March 15, 2019 - Arnold Nipper PeeringDB Update at Peering Days 2019 , Zagreb, CR - March 12, 2019 - Arnold Nipper PeeringDB Update at PhNOG 2019 , Cebu, PH - March 8, 2019 - Arnold Nipper PeeringDB Update at HKNOG 7.0 , Hong Kong, HK - March 1, 2019 - Arnold Nipper 2018 PeeringDB Update at MSK-IX Peering Forum 2018 , Moscow, RU - November 23, 2018 - Rebecca Stani\u0107 PeeringDB Update at DENOG10 , Darmstadt, DE - November 21, 2018 - Arnold Nipper PeeringDB Update at ITNOG4 , Bologna, IT - November 9, 2018 - Arnold Nipper Introduction to PeeringDB API at the 33rd Euro-IX Forum , Venice, IT - November 6, 2018 - Arnold Nipper PeeringDB Introduction at ngNOG 2018 , Lagos, NG - October 31, 2018 - Ben Ryall PeeringDB Update at SwiNOG #34 , Berne, CH - October 30, 2018 - Arnold Nipper PeeringDB Update and Japanese Localization Experience at Peering Asia 2.0 , Hong Kong, HK - October 25, 2018 - Arnold Nipper and Masataka Mawatari PeeringDB Update at SAFNOG-4/EANOG/tzNOG , Dar es Salaam, TZ - September 25, 2018 - Arnold Nipper PeeringDB Update at EPF 13 , Athens, GR - September 18, 2018 - Rebecca Stani\u0107 Cadastro para participantes do IX.br at IX (PTT) F\u00f3rum Regional , Natal, BR - September 14, 2018 - Julimar Lunguinho Mendes PeeringDB Frontend Translation Project at APNIC 46 , Noumea, NC - September 12, 2018 - Masataka Mawatari PeeringDB Update at AfPIF2018 , Cape Town, ZA - August 23, 2018 - Arnold Nipper PeeringDB for IXes at AFIX , Cape Town, ZA - August 20, 2018 - Arnold Nipper Introduction to PeeringDB API at SANOG 32 , Dhaka, BD - August 10, 2018 - Arnold Nipper PeeringDB Update at SANOG 32 , Dhaka, BD - August 9, 2018 - Arnold Nipper PeeringDB: What is it, how to and benefits at New England Peering Forum 2018 , Cambridge, MA, US - June 22, 2018 - Patrick W. Gilmore PeeringDB Update at SEE 7 , Timi\u0219oara, R0 - June 18, 2018 - Arnold Nipper PeeringDB Update at ENOG 15 , Moscow, RU - June 5, 2018 - Arnold Nipper PeeringDB Update at SwiNOG 33 , Berne, CH - May 24, 2018 - Arnold Nipper PeeringDB Update e cadastro de Facilities at GTER 45 , Florian\u00f3polis, BR - May 22, 2018 - Julimar Lunguinho Mendes ( video ) PeeringDB Update at RIPE 76 Connect Working Group , Marseille, FR - May 16, 2018 - Arnold Nipper ( video ) PeeringDB Update at African Internet Summit 2018 , Dakar, SN - May 8, 2018 - Arnold Nipper PeeringDB Update at DKNOG8 , Copenhagen, DK - March 9, 2018 - Arnold Nipper PeeringDB Update at CEE Peering Days 2018 , Berlin, DE - March 7, 2018 - Arnold Nipper Introduction to PeeringDB at APRICOT 2018 , Kathmandu, NP - February 26, 2018 - Arnold Nipper PeeringDB Update at APIX Meeting #17 , Kathmandu, NP - February 24, 2018 - Arnold Nipper PeeringDB Introduction at Capacity India & SAARC 2018 , New Delhi, IN - February 8, 2018 - Arnold Nipper 2017 PeeringDB Update at NIX.cz Member Meering , Prague, CZ - November 23, 2017 - Bijal Sanghani PeeringDB Update at DENOG9 , Darmstadt, DE - November 23, 2017 - Arnold Nipper PeeringDB Update at ALNOF , Tirana, AL - November 14, 2017 - Bijal Sanghani PeeringDB Update at Peering Asia 1.0 , Kyoto, JP - November 1, 2017 - Arnold Nipper PeeringDB Update at TOP-IX Meeting , Torino, IT - September 26, 2017 - Bijal Sanghani PeeringDB Update at NPD 17 , The Hague, NL - September 15, 2017 - Arnold Nipper PeeringDB Update at SAFNOG-3 , Durban, ZA - September 6, 2017 - Arnold Nipper PeeringDB Update at AfPIF 2017 , Abidjan, CI - August 24, 2017 - Arnold Nipper PeeringDB Update at SANOG 30 Peering Forum, Gurgaon, IN - July 10, 2017 - Arnold Nipper More benefits from PeeringDB at DE-CIX Technical Meeting , Frankfurt, DE - June 22, 2017 - Arnold Nipper PeeringDB Update at NANOG 70 , Bellevue, WA, US - June 5, 2017 - Aaron Hughes PeeringDB Update at BOSNOG Meeting & IX Peering Forum , Cambridge, MA, US - June 2, 2017 - Stephen McManus Orienta\u00e7\u00f5es no preenchimento de participantes do IX.br at GTER 43 , Foz do Igua\u00e7u, BR - May 25, 2017 - Julimar Lunguinho Mendes PeeringDB Update at ENOG 13.0 , Saint Petersburg, RU - May 23, 2017 - Arnold Nipper PeeringDB Update at Global Peering Forum 12.0 , New York, NY, US - April 26, 2017 - Aaron Huges PeeringDB at GORE/ESNOG Reunion 19 , Barcelona, ES - April 6, 2017 - Arnold Nipper PeeringDB at CEE Peering Days 2017 , Ljubljana, SL - March 23, 2017 - Arnold Nipper PeeringDB 2.0 at APRICOT 2017 , Ho Chi Minh City, VN - February 28, 2017 - Arnold Nipper 2016 PeeringDB at 19 KIKE Conference , Serock, PL - November 23, 2016 - Robert Jakub PeeringDB 2.0 at ITNOG2 , Bologna, IT - November 3, 2016 - Arnold Nipper PeeringDB Product Committee Charter Survey at EPF 11 , Sofia, BG - September 20, 2016 - Eric Loos PeeringDB 2.0 at NPD 16 , The Hague, NL - September 16, 2016 - Walt Wollny PeeringDB 2.0 at AfPIF 2016 , Dar es Salaam, TZ - August 30, 2016 - Arnold Nipper PeeringDB 2.0 for IXPs at AFIX 2016 , Dar es Salaam, TZ - August 29, 2016 - Arnold Nipper PeeringDB 2.0 at ENOG 11 , Moscow, RU - June 7, 2016 - Arnold Nipper PeeringDB 2.0 at RIPE 72 , Copenhagen, DK - May 25, 2016 - Greg Hankins PeeringDB 2.0 at CHI-NOG 06 , Chicago, IL, US - May 12, 2016 - Matt Griswold PeeringDB 2.0 e o Cen\u00e1rio Brasileiro and IX.br Guia de cadastro de informa\u00e7\u00f5es de ASNs no PeeringDB at GTER 41 , Uberl\u00e2ndia, BR - May 12, 2016 - Eduardo Ascen\u00e7o Reis PeeringDB 2.0 for IXPs at 28th Euro-IX Forum , Luxembourg, LU - April 26, 2016 - Greg Hankins / Arnold Nipper RIPE SEE 5 , Tirana, AL - April 19, 2016 - Arnold Nipper PeeringDB 2.0 at UKNOF34 , Manchester, UK - April 21, 2016 - Greg Hankins PeeringDB Update at GPF 11 , Los Angeles, CA, US - April 13, 2016 - Aaron Hughes NetNod , Stockholm, SE - March 17, 2016 - Job Snijders DKNOG6 , Copenhagen, DK - March 10, 2016 - Job Snijders PeeringDB Update - Aaron Hughes APRICOT 2016 , Auckland, NZ - February 23, 2016 - Aaron Hughes NANOG 66 , San Diego, CA, US - February 10, 2016 - Aaron Hughes PeeringDB Version 2 Coding Introduction at NANOG 66 , San Diego, CA, US - February 8, 2016 - Matt Griswold 2015 PeeringDB Version 2 Brazil - Matt Griswold / Greg Hankins IX (PTT) F\u00f3rum 9 , S\u00e3o Paulo, BR - December 8, 2015 - Greg Hankins PeeringDB Version 2 Introduction - Matt Griswold 27th Euro-IX Forum , Berlin, DE - October 26, 2015 - Greg Hankins DENOG7 , Darmstadt, DE - October 30, 2015 - Arnold Nipper","title":"Presentations"},{"location":"presentations/#presentations","text":"","title":"Presentations"},{"location":"presentations/#2024","text":"What's new on PeeringDB? at RSNOG 10 , Belgrade, RS - November 19, 2024 - Livio Morina What's new on PeeringDB? at 8th South African Peering Forum , Cape Town, ZA - November 14, 2024 - Obinna Adumike What's new on PeeringDB? at nog.fi meeting 2024.11 , Helsinki, FI - November 6, 2024 - Livio Morina PeeringDB Update at RIPE 89 , Prague, CZ - October 31, 2024 - Leo Vegoda What's new on PeeringDB? at NgNOG 2024 , Lagos, NG - October 23, 2024 - Obinna Adumike What's new on PeeringDB? at Netnod Tech Meeting 2024 , Stockhold, SE - October 15, 2024 - Livio Morina What's new on PeeringDB? at RONOG 9 , Bucharest, RO - October 2, 2024 - Livio Morina PeeringDB in Five Minutes at AusNOG 2024 , Sydney, AU - September 5, 2024 - Arnold Nipper What's new on PeeringDB? at AfPIF 2024 , Kinsahsa, CD - August 20, 2024 - Ben Ryall PeeringDB Introduction & Update at PhNOG 2024 Week , Makati City, PH - July 10, 2024 - Arnold Nipper PeeringDB Update at NetUK 1 , London, UK - July 8, 2024 - Paul Hoogsteder What's new on PeeringDB? at WAPF 2024 , Abidjan, CI - June 26, 2024 - Ben Ryall PeeringDB Update at MWPS 2024 , Kansas City, MO, US - June 14, 2024 - Martin Hannigan PeeringDB Update at LINX122 , London, UK - May 28, 2024 - Ben Ryall PeeringDB Update at RIPE 88 , Krak\u00f3w, PL - May 23, 2024 - Paul Hoogsteder What's new on PeeringDB? at ITNOG8 , Bologna, IT - May 7, 2024 - Livio Morina PeeringDB Introduction & Update at SANOG 41 , Mumbai, IN - April 29, 2024 - Arnold Nipper What's new on PeeringDB? at SEE 12 , Athens, GR - April 22, 2024 - Livio Morina PeeringDB Update at GPF 2024 , San Juan, PR, US - April 15, 2024 - Chris Malayter PeeringDB Update at DKNOG14 , Copenhagen, DK - March 8, 2024 - Chriztoffer Hansen PeeringDB Update at Peering Days 2024 , Krakow, PL - March 7, 2024 - Ben Ryall PeeringDB Update at NANOG 90 , Charlotte, NC, US - February 12, 2024 - Martin Hannigan","title":"2024"},{"location":"presentations/#2023","text":"PeeringDB Update at RIPE 87 , Rome, IT - November 30, 2023 - Leo Vegoda What's new on PeeringDB? at MIX Salotto 2023 , Milan, IT - November 15, 2023 - Livio Morina What is PeeringDB? Why is it important for network operators? at RSNOG9 , Belgrade, RS - November 9, 2023 - Livio Morina What\u2019s new on PeeringDB? at GRNOG 15 , Athens, GR - October 25, 2023 - Livio Morina What\u2019s new on PeeringDB? at FRnOG 38 , Paris, FR - October 6, 2023 - Livio Morina PeeringDB Operations & Product Update at SwiNOG#38 , Berne, CH - June 21, 2023 - Arnold Nipper PeeringDB Update at RIPE 86 , Rotterdam, NL - May 25, 2023 - Leo Vegoda PeeringDB Operations & Product Update at ITNOG7 , Bologna, IT - May 9, 2023 - Arnold Nipper What\u2019s new on PeeringDB? at the 38th Euro-IX Forum , Cluj-Napoca, RO - April 24, 2023 - Arnold Nipper PeeringDB Operations & Product Update at SEE 11 , Split, HR - April 5, 2023 - Arnold Nipper PeeringDB Operations & Product Update at GPF 2023 , Coronado, CA, US - April 4, 2023 - Matt Griswold PeeringDB Operations & Product Update at Peering Days 2023 , Sofia, BG - March 30, 2023 - Arnold Nipper PeeringDB Operations & Product Update at DKNOG13 , Copenhagen, DK - March 10, 2023 - Arnold Nipper","title":"2023"},{"location":"presentations/#2022","text":"PeeringDB at AOPF/AONOG 2022 - December 8, 2022 - Darwin Da Costa PeeringDB Operations & Product Update at DENOG14 , Hamburg, DE - November 15, 2022 - Arnold Nipper PeeringDB Operations & Product Update at RIPE 85 , Belgrade, RS - October 26, 2022 - Arnold Nipper PeeringDB Operations & Product Update at ngPIF 2022 , Lagos, NG - October 25, 2022 - Ben Ryall PeeringDB at WTR POP-PI 2022 - October 20, 2022 - Julimar Lunguinho Mendes ( video ) PeeringDB Call for Committee Members at NANOG 86 , Hollywood, CA, US - October 19, 2022 - Patrick Gilmore PeeringDB Operations & Product Update at the 37th Euro-IX Forum , Edinburgh, UK - October 11, 2022 - Greg Hankins PeeringDB Update at EPF 2022 , Rome, IT - September 12, 2022 - Arnold Nipper PeeringDB Update at AfPIF 2022 , Kigali, RW - August 23, 2022 - Ben Ryall PeeringDB Update at GPF 2022 , Washington, DC, US - May 12, 2022 - Chris Malayter 2021 Status Update at Virtual Tech Day with Euro-IX PeeringToolbox - February 3, 2022 - Leo Vegoda","title":"2022"},{"location":"presentations/#2021","text":"Introduction to PeeringDB at GNA-G Routing WG - December 14, 2021 - Arnold Nipper PeeringDB Update at Semana de Capacita\u00e7\u00e3o On-line 3 - October 1, 2021 - Julimar Lunguinho Mendes PeeringDB Update at WTR PoP-MA - September 30, 2021 - Julimar Lunguinho Mendes","title":"2021"},{"location":"presentations/#2020","text":"PeeringDB at IX F\u00f3rum 14 - December 4, 2020 - Julimar Lunguinho Mendes ( video ) Introducci\u00f3n a PeeringDB at Seguridad en el Ruteo: MANRS para Operadores de Red de Universidades - October 2, 2020 - Diego Dominguez Data Ownership Policy Implementation Presentation - August 17, 2020 - Filiz Yilmaz, Steve McManus, Arnold Nipper ( video ) PeeringDB Data Ownership Task Force at PeeringDB Annual Meeting 2020 - April 17, 2020 - Filiz Yilmaz PeeringDB at ABRINT na Estrada Campo Grande , Campo Grande, BR - March 10, 2020 - Julimar Lunguinho Mendes PeeringDB Update at PhNOG 2020 , Manila, PH - February 26, 2020 - Arnold Nipper PeeringDB Update at APRICOT 2020 , Melbourne, AU - February 19, 2020 - Arnold Nipper","title":"2020"},{"location":"presentations/#2019","text":"PeeringDB Update (English)/ \u041d\u043e\u0432\u043e\u0441\u0442\u0438 \u043e\u0442 PeeringDB (P\u0443\u0441\u0441\u043a\u0438\u0439) at MSK-IX Peering Forum 2019 , Moscow, RU - December 5, 2019 - Filiz Yilmaz PeeringDB - Como Est\u00e1 a Ado\u00e7\u00e3o no Brasil at MUM in Brazil , Foz do Igua\u00e7u, BR - November 29, 2019 - Julimar Lunguinho Mendes PeeringDB Para Que Sirve? at XII Encuentro Nacional de T\u00e9cnicos , Salta, AR - November 28, 2019 - Hernan Moguilevsky PeeringDB Update: A Look Into PeeringDB's Data for AT/CH/DE/LU and the Latest Changes at DENOG11 , Hamburg, DE - November 12, 2019 - Stefan Funke PeeringDB Update at Peering Asia 3.0 , Kuala Lumpur, MY - November 7, 2019 - Arnold Nipper PeeringDB Update at ATNOG 2019/2 , Vienna, AT - November 5, 2019 - Stefan Funke Introduction to PeeringDB at JBIX Peering Forum 2019 , Kuala Lumpur, MY - November 5, 2019 - Arnold Nipper Introduction to PeeringDB at ngNOG 2019 , Lagos, NG - October 30, 2019 - Ben Ryall Cadastro para participantes do IX.br at IX F\u00f3rum Regional , Florian\u00f3polis, BR - October 25, 2019 - Julimar Lunguinho Mendes OAuth for IXP Operators at the 35th Euro-IX Forum , Zaandam, NL - October 21, 2019 - Barry O'Donovan The PeeringDB API at the 35th Euro-IX Forum , Zaandam, NL - October 21, 2019 - Arnold Nipper Introduction to PeeringDB at RONOG 6 , Bucharest, RO - October 1, 2019 - Arnold Nipper PeeringDB Update at EPF14 , Tallinn, EE - September 18, 2019 - Filiz Yilmaz Cadastro para participantes do IX.br at IX F\u00f3rum Regional , Natal, BR - September 6, 2019 - Julimar Lunguinho Mendes Introduction to PeeringDB at SAFNOG-5 , Johannesburg, ZA - August 28, 2019 - Arnold Nipper Introduction to PeeringDB at AfPIF-10 , Balaclava, MV - August 22, 2019 - Arnold Nipper Introducci\u00f3n a PeeringDB at MexNOG 2019 , Mexico City, MX - August 14, 2019 - Diego Dominguez Introduction to PeeringDB at ATNOG 2019/1 , Salzburg, AT - July 16, 2019 - Arnold Nipper Introduction to PeeringDB at INNOG 2 , New Delhi, IN - July 1, 2019 - Arnold Nipper ( video ) Cadastro para participantes do IX.br at IX F\u00f3rum Regional , S\u00e3o Paulo, BR - June 10, 2019 - Julimar Lunguinho Mendes News from PeeringDB at ENOG 16 , Tbilisi, GE - June 3, 2019 - Arnold Nipper PeeringDB Update at NONOG-3 , Oslo, NO - May 27, 2019 - Arnold Nipper PeeringDB Update at SINOG 6.0 , Ljubljana, SI - May 14, 2019 - Arnold Nipper Introduction to PeeringDB at BKNIX Peering Forum and ThaiNOG Day 2019 , Bangkok, TH - May 7, 2019 - Arnold Nipper Use in Latin America at Peering Forum LAC , Punta Cana, DR - May 6, 2019 - Julimar Lunguinho Mendes and Carlos Martinez Cagnazzo Cadastro para participantes do IX.br at IX F\u00f3rum Regional , Campo Grande, BR - April 26, 2019 - Julimar Lunguinho Mendes Introduction to PeeringDB at Telecom Day , St. Petersburg, RU - April 19, 2019 - Arnold Nipper PeeringDB Update at SEE 8 , Sarajevo, BH - April 17, 2019 - Arnold Nipper PeeringDB Update at Curso Avan\u00e7ado de IPv6 , S\u00e3o Paulo, BR - April 5, 2019 - Julimar Lunguinho Mendes PeeringDB Update at BCIX Round Table April 2019 , Berlin, DE - April 4, 2019 - Stefan Funke PeeringDB Update at MENOG 19 , Beirut, LB - April 3, 2019 - Arnold Nipper PeeringDB Update at DKNOG9 , Copenhagen, DK - March 15, 2019 - Arnold Nipper PeeringDB Update at Peering Days 2019 , Zagreb, CR - March 12, 2019 - Arnold Nipper PeeringDB Update at PhNOG 2019 , Cebu, PH - March 8, 2019 - Arnold Nipper PeeringDB Update at HKNOG 7.0 , Hong Kong, HK - March 1, 2019 - Arnold Nipper","title":"2019"},{"location":"presentations/#2018","text":"PeeringDB Update at MSK-IX Peering Forum 2018 , Moscow, RU - November 23, 2018 - Rebecca Stani\u0107 PeeringDB Update at DENOG10 , Darmstadt, DE - November 21, 2018 - Arnold Nipper PeeringDB Update at ITNOG4 , Bologna, IT - November 9, 2018 - Arnold Nipper Introduction to PeeringDB API at the 33rd Euro-IX Forum , Venice, IT - November 6, 2018 - Arnold Nipper PeeringDB Introduction at ngNOG 2018 , Lagos, NG - October 31, 2018 - Ben Ryall PeeringDB Update at SwiNOG #34 , Berne, CH - October 30, 2018 - Arnold Nipper PeeringDB Update and Japanese Localization Experience at Peering Asia 2.0 , Hong Kong, HK - October 25, 2018 - Arnold Nipper and Masataka Mawatari PeeringDB Update at SAFNOG-4/EANOG/tzNOG , Dar es Salaam, TZ - September 25, 2018 - Arnold Nipper PeeringDB Update at EPF 13 , Athens, GR - September 18, 2018 - Rebecca Stani\u0107 Cadastro para participantes do IX.br at IX (PTT) F\u00f3rum Regional , Natal, BR - September 14, 2018 - Julimar Lunguinho Mendes PeeringDB Frontend Translation Project at APNIC 46 , Noumea, NC - September 12, 2018 - Masataka Mawatari PeeringDB Update at AfPIF2018 , Cape Town, ZA - August 23, 2018 - Arnold Nipper PeeringDB for IXes at AFIX , Cape Town, ZA - August 20, 2018 - Arnold Nipper Introduction to PeeringDB API at SANOG 32 , Dhaka, BD - August 10, 2018 - Arnold Nipper PeeringDB Update at SANOG 32 , Dhaka, BD - August 9, 2018 - Arnold Nipper PeeringDB: What is it, how to and benefits at New England Peering Forum 2018 , Cambridge, MA, US - June 22, 2018 - Patrick W. Gilmore PeeringDB Update at SEE 7 , Timi\u0219oara, R0 - June 18, 2018 - Arnold Nipper PeeringDB Update at ENOG 15 , Moscow, RU - June 5, 2018 - Arnold Nipper PeeringDB Update at SwiNOG 33 , Berne, CH - May 24, 2018 - Arnold Nipper PeeringDB Update e cadastro de Facilities at GTER 45 , Florian\u00f3polis, BR - May 22, 2018 - Julimar Lunguinho Mendes ( video ) PeeringDB Update at RIPE 76 Connect Working Group , Marseille, FR - May 16, 2018 - Arnold Nipper ( video ) PeeringDB Update at African Internet Summit 2018 , Dakar, SN - May 8, 2018 - Arnold Nipper PeeringDB Update at DKNOG8 , Copenhagen, DK - March 9, 2018 - Arnold Nipper PeeringDB Update at CEE Peering Days 2018 , Berlin, DE - March 7, 2018 - Arnold Nipper Introduction to PeeringDB at APRICOT 2018 , Kathmandu, NP - February 26, 2018 - Arnold Nipper PeeringDB Update at APIX Meeting #17 , Kathmandu, NP - February 24, 2018 - Arnold Nipper PeeringDB Introduction at Capacity India & SAARC 2018 , New Delhi, IN - February 8, 2018 - Arnold Nipper","title":"2018"},{"location":"presentations/#2017","text":"PeeringDB Update at NIX.cz Member Meering , Prague, CZ - November 23, 2017 - Bijal Sanghani PeeringDB Update at DENOG9 , Darmstadt, DE - November 23, 2017 - Arnold Nipper PeeringDB Update at ALNOF , Tirana, AL - November 14, 2017 - Bijal Sanghani PeeringDB Update at Peering Asia 1.0 , Kyoto, JP - November 1, 2017 - Arnold Nipper PeeringDB Update at TOP-IX Meeting , Torino, IT - September 26, 2017 - Bijal Sanghani PeeringDB Update at NPD 17 , The Hague, NL - September 15, 2017 - Arnold Nipper PeeringDB Update at SAFNOG-3 , Durban, ZA - September 6, 2017 - Arnold Nipper PeeringDB Update at AfPIF 2017 , Abidjan, CI - August 24, 2017 - Arnold Nipper PeeringDB Update at SANOG 30 Peering Forum, Gurgaon, IN - July 10, 2017 - Arnold Nipper More benefits from PeeringDB at DE-CIX Technical Meeting , Frankfurt, DE - June 22, 2017 - Arnold Nipper PeeringDB Update at NANOG 70 , Bellevue, WA, US - June 5, 2017 - Aaron Hughes PeeringDB Update at BOSNOG Meeting & IX Peering Forum , Cambridge, MA, US - June 2, 2017 - Stephen McManus Orienta\u00e7\u00f5es no preenchimento de participantes do IX.br at GTER 43 , Foz do Igua\u00e7u, BR - May 25, 2017 - Julimar Lunguinho Mendes PeeringDB Update at ENOG 13.0 , Saint Petersburg, RU - May 23, 2017 - Arnold Nipper PeeringDB Update at Global Peering Forum 12.0 , New York, NY, US - April 26, 2017 - Aaron Huges PeeringDB at GORE/ESNOG Reunion 19 , Barcelona, ES - April 6, 2017 - Arnold Nipper PeeringDB at CEE Peering Days 2017 , Ljubljana, SL - March 23, 2017 - Arnold Nipper PeeringDB 2.0 at APRICOT 2017 , Ho Chi Minh City, VN - February 28, 2017 - Arnold Nipper","title":"2017"},{"location":"presentations/#2016","text":"PeeringDB at 19 KIKE Conference , Serock, PL - November 23, 2016 - Robert Jakub PeeringDB 2.0 at ITNOG2 , Bologna, IT - November 3, 2016 - Arnold Nipper PeeringDB Product Committee Charter Survey at EPF 11 , Sofia, BG - September 20, 2016 - Eric Loos PeeringDB 2.0 at NPD 16 , The Hague, NL - September 16, 2016 - Walt Wollny PeeringDB 2.0 at AfPIF 2016 , Dar es Salaam, TZ - August 30, 2016 - Arnold Nipper PeeringDB 2.0 for IXPs at AFIX 2016 , Dar es Salaam, TZ - August 29, 2016 - Arnold Nipper PeeringDB 2.0 at ENOG 11 , Moscow, RU - June 7, 2016 - Arnold Nipper PeeringDB 2.0 at RIPE 72 , Copenhagen, DK - May 25, 2016 - Greg Hankins PeeringDB 2.0 at CHI-NOG 06 , Chicago, IL, US - May 12, 2016 - Matt Griswold PeeringDB 2.0 e o Cen\u00e1rio Brasileiro and IX.br Guia de cadastro de informa\u00e7\u00f5es de ASNs no PeeringDB at GTER 41 , Uberl\u00e2ndia, BR - May 12, 2016 - Eduardo Ascen\u00e7o Reis PeeringDB 2.0 for IXPs at 28th Euro-IX Forum , Luxembourg, LU - April 26, 2016 - Greg Hankins / Arnold Nipper RIPE SEE 5 , Tirana, AL - April 19, 2016 - Arnold Nipper PeeringDB 2.0 at UKNOF34 , Manchester, UK - April 21, 2016 - Greg Hankins PeeringDB Update at GPF 11 , Los Angeles, CA, US - April 13, 2016 - Aaron Hughes NetNod , Stockholm, SE - March 17, 2016 - Job Snijders DKNOG6 , Copenhagen, DK - March 10, 2016 - Job Snijders PeeringDB Update - Aaron Hughes APRICOT 2016 , Auckland, NZ - February 23, 2016 - Aaron Hughes NANOG 66 , San Diego, CA, US - February 10, 2016 - Aaron Hughes PeeringDB Version 2 Coding Introduction at NANOG 66 , San Diego, CA, US - February 8, 2016 - Matt Griswold","title":"2016"},{"location":"presentations/#2015","text":"PeeringDB Version 2 Brazil - Matt Griswold / Greg Hankins IX (PTT) F\u00f3rum 9 , S\u00e3o Paulo, BR - December 8, 2015 - Greg Hankins PeeringDB Version 2 Introduction - Matt Griswold 27th Euro-IX Forum , Berlin, DE - October 26, 2015 - Greg Hankins DENOG7 , Darmstadt, DE - October 30, 2015 - Arnold Nipper","title":"2015"},{"location":"tools/","text":"Tools to Help You Get the Best from PeeringDB Many PeeringDB users develop tools that make use of our API to help you analyze our data and make informed decisions. This page features tools that have been made freely available for anyone to use under permissive licenses. If you have developed a tool and would like to be added to this page, please contact support@peeringdb.com with details and we will follow up with you. Name Function ARouteServer ARouteServer builds and tests feature-rich configurations for BGP route servers. Routing policy information is sourced from PeeringDB. It delivers a templated configuration file for BIRD or OpenBGPD route servers. django-peeringdb Django library with a local PeeringDB database sync. It defines the database schema to create a local database copy. The library is easy to integrate into a common framework for local tools and custom interfaces, and also supports multiple database engines (MySQL, Postgres, SQLite). ixgen Ixgen is yet-another open-source, multi-platform generator for peering configurations on IXs incorporating the global peeringdb api, but also is able to spin up its own \"compatible\" server for faster results. Ixgen is configured by an INI- or JSON-style format, producing custom template-driven or fixed json-style configurations, that can be printed on the terminal, to a file or served by HTTP. IXP Manager IXP Manager is a full stack management platform for Internet eXchange Points (IXPs) which includes an administration and customer portal; provides end to end provisioning; and both teaches and implements best practice. pdb-intersect Find common peering points in peeringdb. This is a brother to PeerFinder . It will find common possible peering points, even if either of the peering parties is NOT using the same ASN in all locations (like, incidentally, 3557 does). PeerFinder PeerFinder is a python3.7 and beyond script which finds common points of presence between ASNs as reported by PeeringDB. Peering Manager Peering Manager is an open-source BGP management solution built with Python and Django. Designed with features and simplicity in mind, it allows engineers to track and configure BGP sessions on networks without having to copy and paste existing configurations. peeringdb-py peeringdb-py is a Python client for PeeringDB. It features functions to get objects and display them in JSON or YAML format, and provides a whois-like display of records. The client also has an integrated local database sync, and provides a Python library for integration with custom tools. Some examples are available too. rich-traceroute rich-traceroute enhances traceroute output with additional information, like the origin ASNs of the IPs and the name of any Internet Exchange peering LAN that shows up in the path. Search in PeeringDB Search in PeeringDB a Chrome extension to search for ASNs, networks, and IXs in PeeringDB using the context menu. TraceMON TraceMON is a tool for visualizing a network topology generated by traceroutes that provides one-click access to IXP and network information. It also displays PeeringDB information and allows the user to update their record. RIPE Atlas users can access it by selecting a traceroute measurement and clicking on the TraceMON tab","title":"Tools to Help You Get the Best from PeeringDB"},{"location":"tools/#tools-to-help-you-get-the-best-from-peeringdb","text":"Many PeeringDB users develop tools that make use of our API to help you analyze our data and make informed decisions. This page features tools that have been made freely available for anyone to use under permissive licenses. If you have developed a tool and would like to be added to this page, please contact support@peeringdb.com with details and we will follow up with you. Name Function ARouteServer ARouteServer builds and tests feature-rich configurations for BGP route servers. Routing policy information is sourced from PeeringDB. It delivers a templated configuration file for BIRD or OpenBGPD route servers. django-peeringdb Django library with a local PeeringDB database sync. It defines the database schema to create a local database copy. The library is easy to integrate into a common framework for local tools and custom interfaces, and also supports multiple database engines (MySQL, Postgres, SQLite). ixgen Ixgen is yet-another open-source, multi-platform generator for peering configurations on IXs incorporating the global peeringdb api, but also is able to spin up its own \"compatible\" server for faster results. Ixgen is configured by an INI- or JSON-style format, producing custom template-driven or fixed json-style configurations, that can be printed on the terminal, to a file or served by HTTP. IXP Manager IXP Manager is a full stack management platform for Internet eXchange Points (IXPs) which includes an administration and customer portal; provides end to end provisioning; and both teaches and implements best practice. pdb-intersect Find common peering points in peeringdb. This is a brother to PeerFinder . It will find common possible peering points, even if either of the peering parties is NOT using the same ASN in all locations (like, incidentally, 3557 does). PeerFinder PeerFinder is a python3.7 and beyond script which finds common points of presence between ASNs as reported by PeeringDB. Peering Manager Peering Manager is an open-source BGP management solution built with Python and Django. Designed with features and simplicity in mind, it allows engineers to track and configure BGP sessions on networks without having to copy and paste existing configurations. peeringdb-py peeringdb-py is a Python client for PeeringDB. It features functions to get objects and display them in JSON or YAML format, and provides a whois-like display of records. The client also has an integrated local database sync, and provides a Python library for integration with custom tools. Some examples are available too. rich-traceroute rich-traceroute enhances traceroute output with additional information, like the origin ASNs of the IPs and the name of any Internet Exchange peering LAN that shows up in the path. Search in PeeringDB Search in PeeringDB a Chrome extension to search for ASNs, networks, and IXs in PeeringDB using the context menu. TraceMON TraceMON is a tool for visualizing a network topology generated by traceroutes that provides one-click access to IXP and network information. It also displays PeeringDB information and allows the user to update their record. RIPE Atlas users can access it by selecting a traceroute measurement and clicking on the TraceMON tab","title":"Tools to Help You Get the Best from PeeringDB"},{"location":"translation/","text":"Contributing to translations Adding a new locale If you wish to add a new locale, create a new ticket at https://github.com/peeringdb/peeringdb/issues stating your intent and one of the operators / developers will generate the necessary files for your locale and add them to the repository. Translation is done using PeeringDB's Weblate instance at https://translate.peeringdb.com/ . Signing in to Weblate Authentication is done via your PeeringDB credentials. So the only thing you have to do is to register with PeeringDB. Selecting languages Go to https://translate.peeringdb.com/accounts/profile/ to edit your profile and also to select the languages you want to help with. Viewing updates Translations are updated hourly on the beta website https://beta.peeringdb.com/ and daily at 0000 UTC on the production website https://www.peeringdb.com/ . Mailing list The http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-translate mailing list is open to anyone working on, or interested in translations. Thanks to the translators! ar Sara Alamin Mohamed Hassan de Sara Fink Stefan Funke Arnold Nipper jp Yutaro Fujii Norisuke Hirai Yuki Ikuno Chise Kawamura Kaoru Kitauchi Shintaro Kojima Yutaka Kumamoto Ryohey Matsumoto Masataka Mawatari Akira Nakagawa Satoshi Okawa Hideyuki Sasaki Tomocha Katsuyasu Toyama Taiji Tsuchiya Yudai Yamagishi Katsushi Yamaguchi Junpei Yoshino pt Ligio Gomes (NTT Communications) Robert Philips (NTT Communications)","title":"Translations"},{"location":"translation/#contributing-to-translations","text":"","title":"Contributing to translations"},{"location":"translation/#adding-a-new-locale","text":"If you wish to add a new locale, create a new ticket at https://github.com/peeringdb/peeringdb/issues stating your intent and one of the operators / developers will generate the necessary files for your locale and add them to the repository. Translation is done using PeeringDB's Weblate instance at https://translate.peeringdb.com/ .","title":"Adding a new locale"},{"location":"translation/#signing-in-to-weblate","text":"Authentication is done via your PeeringDB credentials. So the only thing you have to do is to register with PeeringDB.","title":"Signing in to Weblate"},{"location":"translation/#selecting-languages","text":"Go to https://translate.peeringdb.com/accounts/profile/ to edit your profile and also to select the languages you want to help with.","title":"Selecting languages"},{"location":"translation/#viewing-updates","text":"Translations are updated hourly on the beta website https://beta.peeringdb.com/ and daily at 0000 UTC on the production website https://www.peeringdb.com/ .","title":"Viewing updates"},{"location":"translation/#mailing-list","text":"The http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-translate mailing list is open to anyone working on, or interested in translations.","title":"Mailing list"},{"location":"translation/#thanks-to-the-translators","text":"","title":"Thanks to the translators!"},{"location":"translation/#ar","text":"Sara Alamin Mohamed Hassan","title":"ar"},{"location":"translation/#de","text":"Sara Fink Stefan Funke Arnold Nipper","title":"de"},{"location":"translation/#jp","text":"Yutaro Fujii Norisuke Hirai Yuki Ikuno Chise Kawamura Kaoru Kitauchi Shintaro Kojima Yutaka Kumamoto Ryohey Matsumoto Masataka Mawatari Akira Nakagawa Satoshi Okawa Hideyuki Sasaki Tomocha Katsuyasu Toyama Taiji Tsuchiya Yudai Yamagishi Katsushi Yamaguchi Junpei Yoshino","title":"jp"},{"location":"translation/#pt","text":"Ligio Gomes (NTT Communications) Robert Philips (NTT Communications)","title":"pt"},{"location":"blog/2022_product_report/","text":"PeeringDB 2022 Product Report Data quality and search were ranked most important by respondents to our last three user surveys. This update looks at improvements we have made to keep data quality high by improving automation, giving users better tools, and making it easier to find and export data in PeeringDB. How to sum up what PeeringDB delivered for its users in 2022? Let's start with some numbers that help describe the scale of the work we\u2019ve done. This year, we put out 10 major releases resolving over 100 issues. These included: Search and export improvements Continued improvements to support for IX-F Member Export Better tools to support organizational admins 10 more HOWTO documents We got contributions from a number of community members, including engineers at Amazon and Google. Search We normalised the names of states and provinces to improve search results. This builds on the improvements to advanced search deployed in 2021, which allow users to drill down to get very specific information and export in structured formats. Managing your organization We improved the way organizational admins can manage their users. Features include the ability to require affiliated users to enable Multi Factor Authentication using authenticator apps or a hardware token, or use a particular email domain. Automation We implemented a process to ensure that old networks are removed from PeeringDB when the RIRs or NIRs deregister their AS Numbers. In combination with regular improvements to our support for the IX-F Member Export Schema, we are ensuring that PeeringDB\u2019s data remains fresh. Operations We built on last year\u2019s improvements to API Key support. We introduced query throttling with authenticated users getting more queries. We also worked with developers of third-party tools that query PeeringDB so that they make efficient queries. We want users to have the best experience they can. So we teamed up with members of the community at the NANOG 86 Hackathon to install our local cache, peeringdb-py , on a wide range of systems. Having tested that we have documented the installation process to make it easier for users to sync PeeringDB to their own infrastructure. Documentation Last year we introduced our HOWTO series . This year we expanded it and have had to organise it into five sections. We probably have an explanation of how to do what you want. If there\u2019s something missing, then please let us know. User support Sometimes users need support. We\u2019ve improved lots of support tools, so we can help users more quickly and effectively. On average, tickets are resolved in under eight hours, with automation managing 40% of this workload. What\u2019s Coming Next? Two major improvements scheduled for early 2023 include further improvements to search, and translation for anonymous web users. We\u2019ll publish a more detailed product roadmap towards the end of January. The improvements we make are only as good as the requests we get from you. We want to make sure that we understand what you need and why. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB 2022 Product Report"},{"location":"blog/2022_product_report/#peeringdb-2022-product-report","text":"Data quality and search were ranked most important by respondents to our last three user surveys. This update looks at improvements we have made to keep data quality high by improving automation, giving users better tools, and making it easier to find and export data in PeeringDB. How to sum up what PeeringDB delivered for its users in 2022? Let's start with some numbers that help describe the scale of the work we\u2019ve done. This year, we put out 10 major releases resolving over 100 issues. These included: Search and export improvements Continued improvements to support for IX-F Member Export Better tools to support organizational admins 10 more HOWTO documents We got contributions from a number of community members, including engineers at Amazon and Google.","title":"PeeringDB 2022 Product Report"},{"location":"blog/2022_product_report/#search","text":"We normalised the names of states and provinces to improve search results. This builds on the improvements to advanced search deployed in 2021, which allow users to drill down to get very specific information and export in structured formats.","title":"Search"},{"location":"blog/2022_product_report/#managing-your-organization","text":"We improved the way organizational admins can manage their users. Features include the ability to require affiliated users to enable Multi Factor Authentication using authenticator apps or a hardware token, or use a particular email domain.","title":"Managing your organization"},{"location":"blog/2022_product_report/#automation","text":"We implemented a process to ensure that old networks are removed from PeeringDB when the RIRs or NIRs deregister their AS Numbers. In combination with regular improvements to our support for the IX-F Member Export Schema, we are ensuring that PeeringDB\u2019s data remains fresh.","title":"Automation"},{"location":"blog/2022_product_report/#operations","text":"We built on last year\u2019s improvements to API Key support. We introduced query throttling with authenticated users getting more queries. We also worked with developers of third-party tools that query PeeringDB so that they make efficient queries. We want users to have the best experience they can. So we teamed up with members of the community at the NANOG 86 Hackathon to install our local cache, peeringdb-py , on a wide range of systems. Having tested that we have documented the installation process to make it easier for users to sync PeeringDB to their own infrastructure.","title":"Operations"},{"location":"blog/2022_product_report/#documentation","text":"Last year we introduced our HOWTO series . This year we expanded it and have had to organise it into five sections. We probably have an explanation of how to do what you want. If there\u2019s something missing, then please let us know.","title":"Documentation"},{"location":"blog/2022_product_report/#user-support","text":"Sometimes users need support. We\u2019ve improved lots of support tools, so we can help users more quickly and effectively. On average, tickets are resolved in under eight hours, with automation managing 40% of this workload.","title":"User support"},{"location":"blog/2022_product_report/#whats-coming-next","text":"Two major improvements scheduled for early 2023 include further improvements to search, and translation for anonymous web users. We\u2019ll publish a more detailed product roadmap towards the end of January. The improvements we make are only as good as the requests we get from you. We want to make sure that we understand what you need and why. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"What\u2019s Coming Next?"},{"location":"blog/2023_product_report/","text":"2023 Product Report PeeringDB users have consistently ranked data quality and search as most important. We worked on improvements to these core aspects of our service alongside others in 2023. We didn\u2019t run a survey at the end of 2023 as we heard the same message consistently. We are in the process of delivering improvements and will survey users again when we have completed their delivery. We deployed 12 releases in 2023, addressing 76 issues, 11 of which were bugs. We also introduced four new features and made some significant improvements that all users will care about. New data We introduced two new objects in 2023. The Carrier object describes networks providing high capacity links between facilities. Now, when you look at a facility you can scroll down and see which carriers have a presence there. We also introduced the Campus object. This is a set object. It describes a group of facilities where inter-buildings cross-connects are available. When you look at a campus's page on our website you'll see which facilities: Are served by each Carrier Where each Ix is present Where each Network is present Data access We also started publishing all our facility data in a .KMZ file, which we update once a day. You can either download it regularly or set it as a network location in Google Earth Pro. You can view facilities in a map view and overlay them with other datasets. We also introduced a new search backend. You can now search for a type of data in a location. It knows the coordinates of facilities and has a radius for each locality. This means you don't need to worry about city names in conurbations \u2013 or rural areas. Data quality We introduced a way for your internal source of truth to propose updates to PeeringDB . You don't need to give your internal source of truth any PeeringDB credentials. You can then log into our website and approve or deny the changes. This helps organizations that are too big for fully manual updates but not big enough to want to automate everything. Improvements We introduced some policy options for organization admins in 2023. PeeringDB Oauth is increasingly relied on for peering and more. Now, organization admins can require their users to: Enable 2FA Use an email address tied to a specific domain Reconfirm their address periodically We also introduced a peering permission . Now admins can control who is able to use PeeringDB Oauth for peering portals. Volunteer developers We're glad that volunteers can contribute to PeeringDB. We improved the development environment a couple of years ago and volunteers use it. We'd like to acknowledge 2023 contributions from: Carlos Aguado Daniel Van Allen Todd Crane kiraum What's coming in 2024? PeeringDB users have told us that they love the simplicity of our web UI. They've also told us that it's outdated and slow. We have developed new designs for our front end and admin interfaces. We'll start rolling these out in parallel soon. You'll be able to test and provide feedback through preview.peeringdb.com. We started that process early in 2024. It didn\u2019t go quite right, so we rolled back the changes and will improve our testing and deployment processes. We'll also be making significant improvements to our .KMZ support. We'll streamline the daily export and make .KMZ available as an export format for Advanced Searches, where that makes sense. We'll also continue to improve support for the carrier and campus objects. People The Admin Committee , the people behind support@peeringdb.com, changed in 2023. Chriztoffer Hansen took the chair, Peter Helmenstine the vice-chair, and new members joined: Budiwijaya Ron Grant Adam Korab Cris\u00f3stomo Mbundu Ryan Williams Ben Ryall recruited new members for the Outreach Committee in 2023: Lynsey Buckingham Tarryn Kidd Jonathan Martone Ester Paal The Product Committee changed for the start of 2024. We have three new members: Jeff Bartig Jack Carrozzo Paul Hoogsteder And Stephen McManus will step down as chair of the committee at the start of March. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"2023 Product Report"},{"location":"blog/2023_product_report/#2023-product-report","text":"PeeringDB users have consistently ranked data quality and search as most important. We worked on improvements to these core aspects of our service alongside others in 2023. We didn\u2019t run a survey at the end of 2023 as we heard the same message consistently. We are in the process of delivering improvements and will survey users again when we have completed their delivery. We deployed 12 releases in 2023, addressing 76 issues, 11 of which were bugs. We also introduced four new features and made some significant improvements that all users will care about.","title":"2023 Product Report"},{"location":"blog/2023_product_report/#new-data","text":"We introduced two new objects in 2023. The Carrier object describes networks providing high capacity links between facilities. Now, when you look at a facility you can scroll down and see which carriers have a presence there. We also introduced the Campus object. This is a set object. It describes a group of facilities where inter-buildings cross-connects are available. When you look at a campus's page on our website you'll see which facilities: Are served by each Carrier Where each Ix is present Where each Network is present","title":"New data"},{"location":"blog/2023_product_report/#data-access","text":"We also started publishing all our facility data in a .KMZ file, which we update once a day. You can either download it regularly or set it as a network location in Google Earth Pro. You can view facilities in a map view and overlay them with other datasets. We also introduced a new search backend. You can now search for a type of data in a location. It knows the coordinates of facilities and has a radius for each locality. This means you don't need to worry about city names in conurbations \u2013 or rural areas.","title":"Data access"},{"location":"blog/2023_product_report/#data-quality","text":"We introduced a way for your internal source of truth to propose updates to PeeringDB . You don't need to give your internal source of truth any PeeringDB credentials. You can then log into our website and approve or deny the changes. This helps organizations that are too big for fully manual updates but not big enough to want to automate everything.","title":"Data quality"},{"location":"blog/2023_product_report/#improvements","text":"We introduced some policy options for organization admins in 2023. PeeringDB Oauth is increasingly relied on for peering and more. Now, organization admins can require their users to: Enable 2FA Use an email address tied to a specific domain Reconfirm their address periodically We also introduced a peering permission . Now admins can control who is able to use PeeringDB Oauth for peering portals.","title":"Improvements"},{"location":"blog/2023_product_report/#volunteer-developers","text":"We're glad that volunteers can contribute to PeeringDB. We improved the development environment a couple of years ago and volunteers use it. We'd like to acknowledge 2023 contributions from: Carlos Aguado Daniel Van Allen Todd Crane kiraum","title":"Volunteer developers"},{"location":"blog/2023_product_report/#whats-coming-in-2024","text":"PeeringDB users have told us that they love the simplicity of our web UI. They've also told us that it's outdated and slow. We have developed new designs for our front end and admin interfaces. We'll start rolling these out in parallel soon. You'll be able to test and provide feedback through preview.peeringdb.com. We started that process early in 2024. It didn\u2019t go quite right, so we rolled back the changes and will improve our testing and deployment processes. We'll also be making significant improvements to our .KMZ support. We'll streamline the daily export and make .KMZ available as an export format for Advanced Searches, where that makes sense. We'll also continue to improve support for the carrier and campus objects.","title":"What's coming in 2024?"},{"location":"blog/2023_product_report/#people","text":"The Admin Committee , the people behind support@peeringdb.com, changed in 2023. Chriztoffer Hansen took the chair, Peter Helmenstine the vice-chair, and new members joined: Budiwijaya Ron Grant Adam Korab Cris\u00f3stomo Mbundu Ryan Williams Ben Ryall recruited new members for the Outreach Committee in 2023: Lynsey Buckingham Tarryn Kidd Jonathan Martone Ester Paal The Product Committee changed for the start of 2024. We have three new members: Jeff Bartig Jack Carrozzo Paul Hoogsteder And Stephen McManus will step down as chair of the committee at the start of March. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"People"},{"location":"blog/advanced_search_1/","text":"Advanced Search (Part 1) You told us in our 2020 survey that improving search was your top priority. That\u2019s why we have been making some database changes to support better search. In a recent release we rolled out changes that significantly improve the performance of our advanced search feature. Advanced search now lets you explicitly filter searches location, network presence, service level and a wide range of other features. You get the results you\u2019re looking for and can export them in structured data formats, so you can import the data into tools that will help you make decisions. We are continuing to work on improvements to the advanced search options. We will then turn our focus to the default search. This set of improvements to search will build on the work we delivered earlier in the year and allow more geographically targeted searches. Take a look at the advanced search feature and try it for yourself! If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Advanced Search (Part 1)"},{"location":"blog/advanced_search_1/#advanced-search-part-1","text":"You told us in our 2020 survey that improving search was your top priority. That\u2019s why we have been making some database changes to support better search. In a recent release we rolled out changes that significantly improve the performance of our advanced search feature. Advanced search now lets you explicitly filter searches location, network presence, service level and a wide range of other features. You get the results you\u2019re looking for and can export them in structured data formats, so you can import the data into tools that will help you make decisions. We are continuing to work on improvements to the advanced search options. We will then turn our focus to the default search. This set of improvements to search will build on the work we delivered earlier in the year and allow more geographically targeted searches. Take a look at the advanced search feature and try it for yourself! If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Advanced Search (Part 1)"},{"location":"blog/advanced_search_2/","text":"Advanced Search (Part 2) We\u2019ve published a couple of recent blogs about how we are improving search, following feedback on its importance in the 2020 user survey . Here\u2019s another one! We introduced two significant improvements in the production release 2.28.0. Our first improvement makes it easier to search based on a partial name. When an organization\u2019s name has two parts, you can now search for just the first part and then select from all the organizations that share that name. Previously, search worked on exact matches. This change makes it easier for users to find the organizations they want. Our second improvement allows users to search for facilities within a given radius, using the Advanced Search interface. Users can search from a country and city, and select a radius in kilometres or miles. Of course, you can achieve the same results using the API or the web interface, which means you can integrate this feature into your own tools. We hope you find these changes make PeeringDB even more useful to you. We prioritized these improvements because of the feedback we hear in 2020. We run out 2021 user survey in September but we\u2019re open to feedback on how to improve PeeringDB at any time. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Advanced Search (Part 2)"},{"location":"blog/advanced_search_2/#advanced-search-part-2","text":"We\u2019ve published a couple of recent blogs about how we are improving search, following feedback on its importance in the 2020 user survey . Here\u2019s another one! We introduced two significant improvements in the production release 2.28.0. Our first improvement makes it easier to search based on a partial name. When an organization\u2019s name has two parts, you can now search for just the first part and then select from all the organizations that share that name. Previously, search worked on exact matches. This change makes it easier for users to find the organizations they want. Our second improvement allows users to search for facilities within a given radius, using the Advanced Search interface. Users can search from a country and city, and select a radius in kilometres or miles. Of course, you can achieve the same results using the API or the web interface, which means you can integrate this feature into your own tools. We hope you find these changes make PeeringDB even more useful to you. We prioritized these improvements because of the feedback we hear in 2020. We run out 2021 user survey in September but we\u2019re open to feedback on how to improve PeeringDB at any time. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Advanced Search (Part 2)"},{"location":"blog/alphabetical_search/","text":"Alphabetical Search Results PeeringDB users have told us that data quality and search are what they value most. We have made changes to improve the search experience: You can search a radius from any address in Advanced Search . You can filter searches using the criteria important to you. You can test our new, faster, v2 Search . We have just improved v2 search to give back results in alphabetical order. It's a small change but has a big impact. If there's an exact match for a search term, it will be shown at the very top of the results. Partial matches are shown in alphabetical order. Try it out! And try out other searches using v2 Search and then let us know what you think. We need your feedback to improve search. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Alphabetical Search Results"},{"location":"blog/alphabetical_search/#alphabetical-search-results","text":"PeeringDB users have told us that data quality and search are what they value most. We have made changes to improve the search experience: You can search a radius from any address in Advanced Search . You can filter searches using the criteria important to you. You can test our new, faster, v2 Search . We have just improved v2 search to give back results in alphabetical order. It's a small change but has a big impact. If there's an exact match for a search term, it will be shown at the very top of the results. Partial matches are shown in alphabetical order. Try it out! And try out other searches using v2 Search and then let us know what you think. We need your feedback to improve search. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Alphabetical Search Results"},{"location":"blog/api_keys/","text":"API Keys How often does one new feature deliver three important improvements? Adding support for API Keys in this week\u2019s beta release does this. API Keys will help organizations improve the security of the data they publish while linking the tools to the org itself and not its people. API Keys allow organizations to have authenticated access directly associated with the org itself and not with individual users. Organizations will now have better control of their data and won\u2019t need to tie automation to their users\u2019 credentials, which will improve robust continuity of operations should individuals leave the organization. Organizations previously faced a problem that if a user left, and their PeeringDB account was closed, any update processes that used the user\u2019s account would end. Organizations can now tie automated processes to role accounts, ensuring continuity of operations even when people change. And if you automate searches to find new peers, your scripts can now be updated to collect contact information as well as other details. As more organizations use API Keys to automate more of their interactions with PeeringDB, we will get a better idea of who is using the API and who is not. This will allow us to engage with them so we can understand what they value. Of course, this does not mean that we\u2019ll be abandoning users who want to focus on using the web interface. Aris Lambrianidis, a senior security engineer with White & Case LLP, says: \u201c The ability to leverage API keys means that programmatic workflows can work reliably using an authentication and authorization model independently of any credentials assigned to humans. Decoupling these access methods should significantly benefit the security and scalability of such operations. \u201d We have published some documentation showing how to generate an API Key, and use that API Key to achieve tasks that will be common to many organizations using PeeringDB. We have also published sample code to help you develop your own automation. Additional examples that others can use are also welcome. Everyone benefits from sharing this kind of code as it means more accurate data quality. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"API Keys"},{"location":"blog/api_keys/#api-keys","text":"How often does one new feature deliver three important improvements? Adding support for API Keys in this week\u2019s beta release does this. API Keys will help organizations improve the security of the data they publish while linking the tools to the org itself and not its people. API Keys allow organizations to have authenticated access directly associated with the org itself and not with individual users. Organizations will now have better control of their data and won\u2019t need to tie automation to their users\u2019 credentials, which will improve robust continuity of operations should individuals leave the organization. Organizations previously faced a problem that if a user left, and their PeeringDB account was closed, any update processes that used the user\u2019s account would end. Organizations can now tie automated processes to role accounts, ensuring continuity of operations even when people change. And if you automate searches to find new peers, your scripts can now be updated to collect contact information as well as other details. As more organizations use API Keys to automate more of their interactions with PeeringDB, we will get a better idea of who is using the API and who is not. This will allow us to engage with them so we can understand what they value. Of course, this does not mean that we\u2019ll be abandoning users who want to focus on using the web interface. Aris Lambrianidis, a senior security engineer with White & Case LLP, says: \u201c The ability to leverage API keys means that programmatic workflows can work reliably using an authentication and authorization model independently of any credentials assigned to humans. Decoupling these access methods should significantly benefit the security and scalability of such operations. \u201d We have published some documentation showing how to generate an API Key, and use that API Key to achieve tasks that will be common to many organizations using PeeringDB. We have also published sample code to help you develop your own automation. Additional examples that others can use are also welcome. Everyone benefits from sharing this kind of code as it means more accurate data quality. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"API Keys"},{"location":"blog/api_writes_need_api_key/","text":"API Writes now Need an API Key You now need to use an API key if you want to update PeeringDB using the API. PeeringDB will continue to support HTTP Basic Authentication (HBA) for queries with the existing API, but transitioning to an API key is strongly recommended for users and organizations who have not already done so, since it is a more secure operational practice. We encourage all users to enable Multi-Factor Authentication (MFA) and to use that when accessing our website from a browser. We encourage anyone that wants to use our API to do so using API keys. We made this change because there is no way to perform MFA with HBA. Removing the ability to update PeeringDB via the API without API keys conforms to security best practices. We support both user and organizational API keys. We have a HOWTO about creating API keys and using them. We have also introduced some organizational policy features this month. Organizations can now require users: To enable MFA To have an email address from a specific domain To revalidate their account on a schedule set by the organization We made this change because of an internal security analysis. We accept security reports to security@peeringdb.com . We have published a HOWTO for making security reports. If you have questions about PeeringDB security, please write to security@peeringdb.com . If you need help configuring API keys, please write to support@peeringdb.com .","title":"API Writes now Need an API Key"},{"location":"blog/api_writes_need_api_key/#api-writes-now-need-an-api-key","text":"You now need to use an API key if you want to update PeeringDB using the API. PeeringDB will continue to support HTTP Basic Authentication (HBA) for queries with the existing API, but transitioning to an API key is strongly recommended for users and organizations who have not already done so, since it is a more secure operational practice. We encourage all users to enable Multi-Factor Authentication (MFA) and to use that when accessing our website from a browser. We encourage anyone that wants to use our API to do so using API keys. We made this change because there is no way to perform MFA with HBA. Removing the ability to update PeeringDB via the API without API keys conforms to security best practices. We support both user and organizational API keys. We have a HOWTO about creating API keys and using them. We have also introduced some organizational policy features this month. Organizations can now require users: To enable MFA To have an email address from a specific domain To revalidate their account on a schedule set by the organization We made this change because of an internal security analysis. We accept security reports to security@peeringdb.com . We have published a HOWTO for making security reports. If you have questions about PeeringDB security, please write to security@peeringdb.com . If you need help configuring API keys, please write to support@peeringdb.com .","title":"API Writes now Need an API Key"},{"location":"blog/automating_configuration/","text":"Automating Configuration - Why We Support the IX-F Member Export Schema We just released 2.29.0-beta and three of the improvements relate to our support for the IX-F Member Export Schema . The last year has seen half a dozen releases with changes to better support it. But why should PeeringDB support this API? Why should exchanges use it? And how can networks benefit from it? It is an agreed standard for which allows IXPs to make their member lists available for automatic consumption by tools like PeeringDB. Exchanges can publish important technical information about their participating networks, including their AS Number and IP address information. There are freely available tools that use this data to build configurations and automate work that would otherwise require tickets, and some copy and paste. So, how can a network take advantage of this if they participate at an exchange using the schema? It\u2019s simple, just select the \u201cAllow IXP Update\u201d radio button in your network configuration page. And if you\u2019re an exchange that sees the advantage of automatically sharing information about your participating networks? If you are using software that can automatically generate the JSON, you just need to configure the URL for us to poll in the LAN configuration panel for your exchange. Our continuing efforts in this area are designed to help exchanges share more accurate information about their participants, and networks to automate configuration. So, take a look at what the schema can do for your organization. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Automating Configuration - Why We Support the IX-F Member Export Schema"},{"location":"blog/automating_configuration/#automating-configuration-why-we-support-the-ix-f-member-export-schema","text":"We just released 2.29.0-beta and three of the improvements relate to our support for the IX-F Member Export Schema . The last year has seen half a dozen releases with changes to better support it. But why should PeeringDB support this API? Why should exchanges use it? And how can networks benefit from it? It is an agreed standard for which allows IXPs to make their member lists available for automatic consumption by tools like PeeringDB. Exchanges can publish important technical information about their participating networks, including their AS Number and IP address information. There are freely available tools that use this data to build configurations and automate work that would otherwise require tickets, and some copy and paste. So, how can a network take advantage of this if they participate at an exchange using the schema? It\u2019s simple, just select the \u201cAllow IXP Update\u201d radio button in your network configuration page. And if you\u2019re an exchange that sees the advantage of automatically sharing information about your participating networks? If you are using software that can automatically generate the JSON, you just need to configure the URL for us to poll in the LAN configuration panel for your exchange. Our continuing efforts in this area are designed to help exchanges share more accurate information about their participants, and networks to automate configuration. So, take a look at what the schema can do for your organization. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Automating Configuration - Why We Support the IX-F Member Export Schema"},{"location":"blog/better_data/","text":"Better Data PeeringDB users told us in surveys that data quality and search results are their two top priorities. Release 2.54.0 has multiple changes to improve data quality and search results. Report inaccurate data One of them is a feature allowing logged in users to report data they believe to be inaccurate. Every page now has a button that lets users report data they believe is inaccurate. The report form lets the user identify the specific element believe to be wrong, along with a reason. If the user knows, they can suggest what the correct data should be. The Admin Committee will review reports. Network types Many networks provide more than one kind of function. You can now select more than one type for each network you run. The Product Committee considered adding more granularity for network types. They decided against it, as not everyone shares the same understanding of terms. Allowing networks to select multiple options is a compromise that doesn't require a breaking change in the API. The Network Type field will probably not be imported into v3 of the API. Power choices The Available Voltage Services field now only shows non-standard power offers. Everyone expects data centers to offer power at the standard voltages for the country or territory they serve. What users find interesting is the non-standard offers. For the time being we only offer three of these non-standard power options. If you offer a different non-standard power option, please let us know. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Better Data"},{"location":"blog/better_data/#better-data","text":"PeeringDB users told us in surveys that data quality and search results are their two top priorities. Release 2.54.0 has multiple changes to improve data quality and search results.","title":"Better Data"},{"location":"blog/better_data/#report-inaccurate-data","text":"One of them is a feature allowing logged in users to report data they believe to be inaccurate. Every page now has a button that lets users report data they believe is inaccurate. The report form lets the user identify the specific element believe to be wrong, along with a reason. If the user knows, they can suggest what the correct data should be. The Admin Committee will review reports.","title":"Report inaccurate data"},{"location":"blog/better_data/#network-types","text":"Many networks provide more than one kind of function. You can now select more than one type for each network you run. The Product Committee considered adding more granularity for network types. They decided against it, as not everyone shares the same understanding of terms. Allowing networks to select multiple options is a compromise that doesn't require a breaking change in the API. The Network Type field will probably not be imported into v3 of the API.","title":"Network types"},{"location":"blog/better_data/#power-choices","text":"The Available Voltage Services field now only shows non-standard power offers. Everyone expects data centers to offer power at the standard voltages for the country or territory they serve. What users find interesting is the non-standard offers. For the time being we only offer three of these non-standard power options. If you offer a different non-standard power option, please let us know. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Power choices"},{"location":"blog/better_search_and_export/","text":"Better Search and Export PeeringDB users tell us that they most value search and data quality. We've been working on improved search for the last year and have made another improvement to it. It now recognizes ISO 3166-1 alpha-2 codes \u2013 the codes used for ccTLDs. This means you can now search for things like all the facilities or IXPs in a country. But sometimes you want to visualize our data. For a while we've been offering a .KMZ file of all the facilities in PeeringDB with a geocode. We've now improved that file. The new format removes unneeded fields, making it small enough for Google Maps to use. And you can export any advanced search based on location in a KMZ format. So take a look at these features on beta.peeringdb.com ahead of their deployment to production. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Better Search and Export"},{"location":"blog/better_search_and_export/#better-search-and-export","text":"PeeringDB users tell us that they most value search and data quality. We've been working on improved search for the last year and have made another improvement to it. It now recognizes ISO 3166-1 alpha-2 codes \u2013 the codes used for ccTLDs. This means you can now search for things like all the facilities or IXPs in a country. But sometimes you want to visualize our data. For a while we've been offering a .KMZ file of all the facilities in PeeringDB with a geocode. We've now improved that file. The new format removes unneeded fields, making it small enough for Google Maps to use. And you can export any advanced search based on location in a KMZ format. So take a look at these features on beta.peeringdb.com ahead of their deployment to production. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Better Search and Export"},{"location":"blog/carrier_object/","text":"Should PeeringDB Create a New \u201cCarrier\u201d Object? That was the question we asked two focus groups on 29 June 2021. Initial discussion Our Product Committee and others have been discussing this issue for about six months now. The one thing we could agree on was that we needed to reach out to more of the people involved in buying and delivering these interconnection services to help make a decision. Focus groups To do that we held two focus groups on 29 June 2021. One was scheduled at a time that is good for people in APAC and the west coast of the Americas. The other was scheduled at a time that was good for people in EMEA and the east coast of the Americas. The discussion included 12 people with significant industry experience in running carriers, exchanges, facilities, and networks. To build a trusted environment we applied the Chatham House Rule, so this blog post describes what was discussed but does not quote anyone or attribute views to any participants. The focus groups began with a description of the problem and then looked at a simple approach to address it: an object to describe the carrier and associated objects listing the facilities and IXs where they have a presence. The focus groups then discussed several questions: Is there an unmet need? Should PeeringDB be the organization to address it? What do you feel about the proposed approach? Should the proposed approach be adapted in some way? Why? There was a strong sense across both sessions that it can be a challenge to find out about connectivity options between locations. While putting information about those options in PeeringDB would not eliminate the need for buyers to perform their own due diligence checks, it would simplify the process of finding out who to contact and what they might be able to offer. There was support for putting this information in PeeringDB because keeping related information in a single database makes things easier for users. Participants favored starting off with a less complex object and adding detail in future iterations. Including information about whether links between locations were L1, L2, or L3, and owned or leased seemed to be the agreed minimum set of information. That said, there were concerns that keeping this information accurate could be a challenge for multiple reasons, including inaccurate internal asset databases and a desire from marketing people to overclaim. Any implementation would need to be well supported by extensions to the API. Despite making it easy for people to rapidly deploy information about new and improved deployments to PeeringDB through the API there was support ensuring that a new object can be created and configured through the web interface. Next steps When the Product Committee has evaluated the feedback we got from these two focus groups it will make a decision on the principle of creating this new object. If the decision is to proceed there is work to be done in both designing and naming it. What is the minimum set of information that would be useful to PeeringDB users? What name would cause least confusion? We\u2019ll keep you updated. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Should PeeringDB Create a New \u201cCarrier\u201d Object?"},{"location":"blog/carrier_object/#should-peeringdb-create-a-new-carrier-object","text":"That was the question we asked two focus groups on 29 June 2021.","title":"Should PeeringDB Create a New \u201cCarrier\u201d Object?"},{"location":"blog/carrier_object/#initial-discussion","text":"Our Product Committee and others have been discussing this issue for about six months now. The one thing we could agree on was that we needed to reach out to more of the people involved in buying and delivering these interconnection services to help make a decision.","title":"Initial discussion"},{"location":"blog/carrier_object/#focus-groups","text":"To do that we held two focus groups on 29 June 2021. One was scheduled at a time that is good for people in APAC and the west coast of the Americas. The other was scheduled at a time that was good for people in EMEA and the east coast of the Americas. The discussion included 12 people with significant industry experience in running carriers, exchanges, facilities, and networks. To build a trusted environment we applied the Chatham House Rule, so this blog post describes what was discussed but does not quote anyone or attribute views to any participants. The focus groups began with a description of the problem and then looked at a simple approach to address it: an object to describe the carrier and associated objects listing the facilities and IXs where they have a presence. The focus groups then discussed several questions: Is there an unmet need? Should PeeringDB be the organization to address it? What do you feel about the proposed approach? Should the proposed approach be adapted in some way? Why? There was a strong sense across both sessions that it can be a challenge to find out about connectivity options between locations. While putting information about those options in PeeringDB would not eliminate the need for buyers to perform their own due diligence checks, it would simplify the process of finding out who to contact and what they might be able to offer. There was support for putting this information in PeeringDB because keeping related information in a single database makes things easier for users. Participants favored starting off with a less complex object and adding detail in future iterations. Including information about whether links between locations were L1, L2, or L3, and owned or leased seemed to be the agreed minimum set of information. That said, there were concerns that keeping this information accurate could be a challenge for multiple reasons, including inaccurate internal asset databases and a desire from marketing people to overclaim. Any implementation would need to be well supported by extensions to the API. Despite making it easy for people to rapidly deploy information about new and improved deployments to PeeringDB through the API there was support ensuring that a new object can be created and configured through the web interface.","title":"Focus groups"},{"location":"blog/carrier_object/#next-steps","text":"When the Product Committee has evaluated the feedback we got from these two focus groups it will make a decision on the principle of creating this new object. If the decision is to proceed there is work to be done in both designing and naming it. What is the minimum set of information that would be useful to PeeringDB users? What name would cause least confusion? We\u2019ll keep you updated. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Next steps"},{"location":"blog/carrier_object_deployed/","text":"Carrier Objects We introduced support for carrier objects in release 2.43.0. This is the first new pillar of data we\u2019ve introduced for several years. Take a look and tell us how we can improve our implementation. A \u201cCarrier\u201d provides high capacity links between facilities. Networks and IXPs use these to connect equipment spread across multiple interconnection facilities in a metro area. They are different from the regular network in PeeringDB because their services run at layers 1 or 2 . Our initial deployment lets carriers show that they have a presence in an interconnection facility. It does not show what services are provided, like wavelengths or fiber. This is a tighter set of features than was suggested by the focus group in 2021 . We want to get a minimal set of features out first and see how they are received before tackling more complicated features. We have started small and will expand based on user demand. If this is a feature that your organization could benefit from, please take a look and tell us what you think. You can contact us on social media, and you can reach the Product Committee on our mailing list . If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Carrier Objects"},{"location":"blog/carrier_object_deployed/#carrier-objects","text":"We introduced support for carrier objects in release 2.43.0. This is the first new pillar of data we\u2019ve introduced for several years. Take a look and tell us how we can improve our implementation. A \u201cCarrier\u201d provides high capacity links between facilities. Networks and IXPs use these to connect equipment spread across multiple interconnection facilities in a metro area. They are different from the regular network in PeeringDB because their services run at layers 1 or 2 . Our initial deployment lets carriers show that they have a presence in an interconnection facility. It does not show what services are provided, like wavelengths or fiber. This is a tighter set of features than was suggested by the focus group in 2021 . We want to get a minimal set of features out first and see how they are received before tackling more complicated features. We have started small and will expand based on user demand. If this is a feature that your organization could benefit from, please take a look and tell us what you think. You can contact us on social media, and you can reach the Product Committee on our mailing list . If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Carrier Objects"},{"location":"blog/contacts_marked_private/","text":"Changes to Contacts Marked as Private We are removing the \u201cPrivate\u201d status from Points of Contact in PeeringDB in Release 2.30.0 . This status was carried over from v1 of PeeringDB but is no longer useful, it just confuses users. It will no longer be available as a status for newly created contacts. And if your organization has one or more contacts marked as \u201cPrivate\u201d in PeeringDB, admin users will be prompted to make a decision between two statuses when they next log in. These are : Users: only other PeeringDB users can see the Point of Contact Public: the record is shown to anonymous users as well as authenticated users If you are an administrator for your organization\u2019s entry in PeeringDB, you need to decide which of the Points of Contact you publish should only be disclosed to authenticated PeeringDB users and which should be published to anonymous users. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Changes to Contacts Marked as Private"},{"location":"blog/contacts_marked_private/#changes-to-contacts-marked-as-private","text":"We are removing the \u201cPrivate\u201d status from Points of Contact in PeeringDB in Release 2.30.0 . This status was carried over from v1 of PeeringDB but is no longer useful, it just confuses users. It will no longer be available as a status for newly created contacts. And if your organization has one or more contacts marked as \u201cPrivate\u201d in PeeringDB, admin users will be prompted to make a decision between two statuses when they next log in. These are : Users: only other PeeringDB users can see the Point of Contact Public: the record is shown to anonymous users as well as authenticated users If you are an administrator for your organization\u2019s entry in PeeringDB, you need to decide which of the Points of Contact you publish should only be disclosed to authenticated PeeringDB users and which should be published to anonymous users. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Changes to Contacts Marked as Private"},{"location":"blog/containerize/","text":"Containerized Deployment We deployed beta.peeringdb.com on a container based platform in release 2.59.0 . We'll be starting integration on www.peeringdb.com in the 2.60 release. PeeringDB started on a bare metal LAMP stack, and was deployed to virtual machines with the release of PeeringDB 2.0 about ten years ago, but technology has advanced since then. By deploying PeeringDB in containers, we will reduce our computing costs and more easily adjust compute resources dynamically based on load. Managing spending is important as PeeringDB is fully funded by our sponsors . It should also help us narrow the scope of work for our volunteer Operations Committee. We have been looking for ways to improve the efficiency of our spending since 2022 and started looking at switching to serving directly from containers in November 2023 . This deployment will complete that process. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Containerized Deployment"},{"location":"blog/containerize/#containerized-deployment","text":"We deployed beta.peeringdb.com on a container based platform in release 2.59.0 . We'll be starting integration on www.peeringdb.com in the 2.60 release. PeeringDB started on a bare metal LAMP stack, and was deployed to virtual machines with the release of PeeringDB 2.0 about ten years ago, but technology has advanced since then. By deploying PeeringDB in containers, we will reduce our computing costs and more easily adjust compute resources dynamically based on load. Managing spending is important as PeeringDB is fully funded by our sponsors . It should also help us narrow the scope of work for our volunteer Operations Committee. We have been looking for ways to improve the efficiency of our spending since 2022 and started looking at switching to serving directly from containers in November 2023 . This deployment will complete that process. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Containerized Deployment"},{"location":"blog/contributing_code/","text":"Contributing Code to PeeringDB Just Got Easier Have you ever wanted to contribute code to improve PeeringDB but found it too challenging to set up a test environment? The good news is that spinning up a development environment is now radically simplified. We have made it much easier for volunteer developers to contribute code to PeeringDB. Until now, even if a code fix was relatively simple, the process for testing it before making the contribution was a challenge. Now, you can spin up a PeeringDB development instance in a couple of minutes. You\u2019ll be able to test changes locally and then submit pull requests when you\u2019re ready to publish your contribution. Andy Davidson, CTO of Asteroid says: \u201c I recently developed some code against the PeeringDB OAuth instance for https://trackbgp.com . But it was hard to get a development environment set up. Now I can spin up a development environment in less time than it takes to boil a kettle. \u201d We have documented the steps needed to get up and running on GitHub. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Contributing Code to PeeringDB Just Got Easier"},{"location":"blog/contributing_code/#contributing-code-to-peeringdb-just-got-easier","text":"Have you ever wanted to contribute code to improve PeeringDB but found it too challenging to set up a test environment? The good news is that spinning up a development environment is now radically simplified. We have made it much easier for volunteer developers to contribute code to PeeringDB. Until now, even if a code fix was relatively simple, the process for testing it before making the contribution was a challenge. Now, you can spin up a PeeringDB development instance in a couple of minutes. You\u2019ll be able to test changes locally and then submit pull requests when you\u2019re ready to publish your contribution. Andy Davidson, CTO of Asteroid says: \u201c I recently developed some code against the PeeringDB OAuth instance for https://trackbgp.com . But it was hard to get a development environment set up. Now I can spin up a development environment in less time than it takes to boil a kettle. \u201d We have documented the steps needed to get up and running on GitHub. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Contributing Code to PeeringDB Just Got Easier"},{"location":"blog/data_quality_improvements/","text":"Data Quality Improvements Rolled Out Each year we run a user survey. Users keep telling us that network configuration data in PeeringDB is a top priority. We have recently added some automation to improve our data quality for networks. We now track the status of each ASN registered in PeeringDB at the RIRs and NIRs. When a network is no longer in the RIR or NIR database we can remove it. Release 2.41.0 completes the deployment of this feature. It will remove about 150 networks, which is only about 0.5%. But over time, it should help us maintain the highest quality data possible. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Data Quality Improvements Rolled Out"},{"location":"blog/data_quality_improvements/#data-quality-improvements-rolled-out","text":"Each year we run a user survey. Users keep telling us that network configuration data in PeeringDB is a top priority. We have recently added some automation to improve our data quality for networks. We now track the status of each ASN registered in PeeringDB at the RIRs and NIRs. When a network is no longer in the RIR or NIR database we can remove it. Release 2.41.0 completes the deployment of this feature. It will remove about 150 networks, which is only about 0.5%. But over time, it should help us maintain the highest quality data possible. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Data Quality Improvements Rolled Out"},{"location":"blog/data_quality_removing_closed_networks/","text":"Data Quality \u2014 Removing Closed Networks We added an \"RIR Status\" field in the data returned for networks a few months ago. The \"ok\" status lets you know that the ASN was assigned by an RIR or NIR. The \"RIR Status Updated\" field lets you know when we last checked. We use these fields to enable automation. In September we\u2019ll remove about 400 networks that have been returned to the RIR. We check the status of the network every day and will only flag it for deletion if the status was \u201cnot assigned\u201d for three months. This automation runs every month. It will improve data quality. You won't see results for networks that aren't operating anymore. And organizations assigned those returned and reissued ASNs will be able to register on PeeringDB without needing support from our volunteer Admin Committee. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Data Quality \u2014 Removing Closed Networks"},{"location":"blog/data_quality_removing_closed_networks/#data-quality-removing-closed-networks","text":"We added an \"RIR Status\" field in the data returned for networks a few months ago. The \"ok\" status lets you know that the ASN was assigned by an RIR or NIR. The \"RIR Status Updated\" field lets you know when we last checked. We use these fields to enable automation. In September we\u2019ll remove about 400 networks that have been returned to the RIR. We check the status of the network every day and will only flag it for deletion if the status was \u201cnot assigned\u201d for three months. This automation runs every month. It will improve data quality. You won't see results for networks that aren't operating anymore. And organizations assigned those returned and reissued ASNs will be able to register on PeeringDB without needing support from our volunteer Admin Committee. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Data Quality \u2014 Removing Closed Networks"},{"location":"blog/faster_queries/","text":"Faster PeeringDB Queries - No Limits Did you know that you can have lightning fast access to PeeringDB's database without query limits? Our web and API services impose query limits. Network latency is sometimes a factor when querying from far away. That's why we have peeringdb-py . This is a cache you can run in your own network or even on a laptop. You synchronize the whole database to a machine you run. Once you've done that you are only limited by your own infrastructure. Re-synchronizing peeringdb-py is efficient - it only syncs changes since the last sync - and is unlikely to trigger any query limits if updated once per hour or less frequently as needed. Are there reasons you should run a local cache other than query limits and latency? Yes. If you populate internal databases or generate configurations with PeeringDB then a local cache adds reliability. You'll have local access instead of having to rely on intermediate networks. Of course, peeringdb-py isn't the only choice. Some organizations have developed their own local caches. If you want a local cache you are welcome to use the peeringdb-py codebase as a reference. And if all you need is to have PeeringDB in a local database, it can be really simple . If your organization is a heavy PeeringDB user then work out the right caching approach for you. We\u2019re happy to answer any questions. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Faster PeeringDB Queries - No Limits"},{"location":"blog/faster_queries/#faster-peeringdb-queries-no-limits","text":"Did you know that you can have lightning fast access to PeeringDB's database without query limits? Our web and API services impose query limits. Network latency is sometimes a factor when querying from far away. That's why we have peeringdb-py . This is a cache you can run in your own network or even on a laptop. You synchronize the whole database to a machine you run. Once you've done that you are only limited by your own infrastructure. Re-synchronizing peeringdb-py is efficient - it only syncs changes since the last sync - and is unlikely to trigger any query limits if updated once per hour or less frequently as needed. Are there reasons you should run a local cache other than query limits and latency? Yes. If you populate internal databases or generate configurations with PeeringDB then a local cache adds reliability. You'll have local access instead of having to rely on intermediate networks. Of course, peeringdb-py isn't the only choice. Some organizations have developed their own local caches. If you want a local cache you are welcome to use the peeringdb-py codebase as a reference. And if all you need is to have PeeringDB in a local database, it can be really simple . If your organization is a heavy PeeringDB user then work out the right caching approach for you. We\u2019re happy to answer any questions. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Faster PeeringDB Queries - No Limits"},{"location":"blog/geographic_search/","text":"Geographic Search Where is it? This isn\u2019t just the plaintive cry of someone wondering where the courier has left their package. Finding facilities in PeeringDB has been a big problem. The database did not associate partial and full names in searches, so if a facility owner had entered Montana but you were searching for MT, their facility might not be found. As new facilities are created in our database they will be linked to geographic coordinates. Changing the way we record authoritative data for locations in our database means that we will be able to introduce a number of helpful features over the next few months. Over time, we will improve the way existing address data is presented in the database. The number of facilities in PeeringDB grew by about a sixth in 2020. As we add entries with new addresses in 2021 we will normalize the primary presentation of addresses and use them as a search key. We\u2019ll add support for additional searches based on these addresses in the coming months and use this experience to help us clean up the data we already have. In the future, we will be able to expand the way we provide searches. For instance, we\u2019ll be able to provide a search for facilities with a distance radius of a chosen coordinate. Other innovative searches will be possible and we will prioritize their development based on user feedback. Tom Paseka, Network Strategy at Cloudflare, says: \u201c Getting location naming right is hugely important. Having D\u00fcsseldorf and Dusseldorf return the same results makes local use of PeeringDB possible, giving more precise data across languages and improving data integrity. This is great!. \u201d If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Geographic Search"},{"location":"blog/geographic_search/#geographic-search","text":"Where is it? This isn\u2019t just the plaintive cry of someone wondering where the courier has left their package. Finding facilities in PeeringDB has been a big problem. The database did not associate partial and full names in searches, so if a facility owner had entered Montana but you were searching for MT, their facility might not be found. As new facilities are created in our database they will be linked to geographic coordinates. Changing the way we record authoritative data for locations in our database means that we will be able to introduce a number of helpful features over the next few months. Over time, we will improve the way existing address data is presented in the database. The number of facilities in PeeringDB grew by about a sixth in 2020. As we add entries with new addresses in 2021 we will normalize the primary presentation of addresses and use them as a search key. We\u2019ll add support for additional searches based on these addresses in the coming months and use this experience to help us clean up the data we already have. In the future, we will be able to expand the way we provide searches. For instance, we\u2019ll be able to provide a search for facilities with a distance radius of a chosen coordinate. Other innovative searches will be possible and we will prioritize their development based on user feedback. Tom Paseka, Network Strategy at Cloudflare, says: \u201c Getting location naming right is hugely important. Having D\u00fcsseldorf and Dusseldorf return the same results makes local use of PeeringDB possible, giving more precise data across languages and improving data integrity. This is great!. \u201d If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Geographic Search"},{"location":"blog/guidelines_for_registering/","text":"Guidelines for Registering in PeeringDB About one third of ASNs are now registered in PeeringDB. While that\u2019s a success it comes with a responsibility to enhance transparency over what is required when registering a network, IXP, or facility in the database. We have just published a set of guidelines that document the criteria our automation uses, or will use when new software is developed. Where we cannot automate, volunteers on our Admin Committee evaluate requests. There are clear criteria for the automatic, or semi-automatic, approval of each type of object. These are illustrated with flowcharts that show the possible paths through the process. What Are They? Networks must have a unique and properly registered ASN. IXP LANs must use unique and properly registered address space. There are some automatic prefix limits but these can be manually overridden when needed. Facilities can automatically be added by organizations that already have a facility, be validated by a web page offering interconnection services there, or be attested to by users that confirm the facility exists. There is also a process to remove empty facilities without registered networks or IXPs present in them. Feedback Loop We know that these guidelines will need to be improved and updated as we learn, so we have built in an \u201cexception\u201d process to help with that. Whenever an easy path is not possible, the requester can ask for more eyes on their registration request. The first step in this process is to get input from all the volunteers on the Admin Committee. If more eyes are needed, the request can be shared with all of PeeringDB\u2019s Stewards, a group made from the committee chairs and board members. Where a formal decision is needed, the board can vote on a request and make a final decision. Each step of this process is an opportunity to learn from experience and feed that back into our published guidelines, our internal processes, and any software that automates them. So, while we\u2019ve published these today, we\u2019ll be updating them as the interconnection environment changes and we need to adapt to it. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Guidelines for Registering in PeeringDB"},{"location":"blog/guidelines_for_registering/#guidelines-for-registering-in-peeringdb","text":"About one third of ASNs are now registered in PeeringDB. While that\u2019s a success it comes with a responsibility to enhance transparency over what is required when registering a network, IXP, or facility in the database. We have just published a set of guidelines that document the criteria our automation uses, or will use when new software is developed. Where we cannot automate, volunteers on our Admin Committee evaluate requests. There are clear criteria for the automatic, or semi-automatic, approval of each type of object. These are illustrated with flowcharts that show the possible paths through the process.","title":"Guidelines for Registering in PeeringDB"},{"location":"blog/guidelines_for_registering/#what-are-they","text":"Networks must have a unique and properly registered ASN. IXP LANs must use unique and properly registered address space. There are some automatic prefix limits but these can be manually overridden when needed. Facilities can automatically be added by organizations that already have a facility, be validated by a web page offering interconnection services there, or be attested to by users that confirm the facility exists. There is also a process to remove empty facilities without registered networks or IXPs present in them.","title":"What Are They?"},{"location":"blog/guidelines_for_registering/#feedback-loop","text":"We know that these guidelines will need to be improved and updated as we learn, so we have built in an \u201cexception\u201d process to help with that. Whenever an easy path is not possible, the requester can ask for more eyes on their registration request. The first step in this process is to get input from all the volunteers on the Admin Committee. If more eyes are needed, the request can be shared with all of PeeringDB\u2019s Stewards, a group made from the committee chairs and board members. Where a formal decision is needed, the board can vote on a request and make a final decision. Each step of this process is an opportunity to learn from experience and feed that back into our published guidelines, our internal processes, and any software that automates them. So, while we\u2019ve published these today, we\u2019ll be updating them as the interconnection environment changes and we need to adapt to it. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Feedback Loop"},{"location":"blog/improving_beta_and_kmz_export/","text":"Making beta.peeringdb.com, Search, and KMZ More Attractive Just over half a percent of users visit beta.peeringdb.com each month. We recognize that there are good and bad reasons for this. On the good side, people are pretty happy with www.peeringdb.com . But on the bad side, we only used to refresh the data in beta.peeringdb.com once a month. We're getting ready to refresh data on our beta site every hour. That will come soon. It will make it an ideal place to test your searches each month \u2013 and get early access to new search features. Of course, you can also test making updates on our beta site. But any changes you make will be wiped at the next refresh. We're also refining our .KMZ export in 2.57.0. The export has tidier entries for each fac , improves the placemark, and drops facilities without location data. And two bugs have been fixed for v2 search, which is now the default search. A problem searching for a \" fac in city name\" has been resolved. And a bug that caused a server error when the last character was a colon has also been fixed. So, head on over to beta.peeringdb.com and test these improvements. Let us know if you see any problems with these improvements. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Making beta.peeringdb.com, Search, and KMZ More Attractive"},{"location":"blog/improving_beta_and_kmz_export/#making-betapeeringdbcom-search-and-kmz-more-attractive","text":"Just over half a percent of users visit beta.peeringdb.com each month. We recognize that there are good and bad reasons for this. On the good side, people are pretty happy with www.peeringdb.com . But on the bad side, we only used to refresh the data in beta.peeringdb.com once a month. We're getting ready to refresh data on our beta site every hour. That will come soon. It will make it an ideal place to test your searches each month \u2013 and get early access to new search features. Of course, you can also test making updates on our beta site. But any changes you make will be wiped at the next refresh. We're also refining our .KMZ export in 2.57.0. The export has tidier entries for each fac , improves the placemark, and drops facilities without location data. And two bugs have been fixed for v2 search, which is now the default search. A problem searching for a \" fac in city name\" has been resolved. And a bug that caused a server error when the last character was a colon has also been fixed. So, head on over to beta.peeringdb.com and test these improvements. Let us know if you see any problems with these improvements. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Making beta.peeringdb.com, Search, and KMZ More Attractive"},{"location":"blog/installing_peeringdb-py/","text":"Installing peeringdb-py at NANOG 86 NANOG 86 participants installed peeringdb-py on Linux, macOS, and Windows Subsystem for Linux. We have used what they learned to publish a new HOWTO document to help more users install it. peeringdb-py is our reference implementation of a local cache of our database. You can install it on your own infrastructure. That means you can avoid query limits and get the best response time. Our new HOWTO document explains when you'll need an API Key and what kind of API Key to create. It also lists the packages you'll need installed to get peeringdb-py up and running. Finally, it provides guidance on how you can automatically refresh the database. We improved the installation guide to help users keep their installation current. Better documentation makes it easier for everyone to install peeringdb-py . If you need to make a lot of PeeringDB queries then we encourage you to query a local cache. If you do this, you'll want to run API queries against it using our software library. The API will remain stable while the database structure could change. The API will remain stable and our library will ensure you don't need to rewrite your queries. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Installing peeringdb-py at NANOG 86"},{"location":"blog/installing_peeringdb-py/#installing-peeringdb-py-at-nanog-86","text":"NANOG 86 participants installed peeringdb-py on Linux, macOS, and Windows Subsystem for Linux. We have used what they learned to publish a new HOWTO document to help more users install it. peeringdb-py is our reference implementation of a local cache of our database. You can install it on your own infrastructure. That means you can avoid query limits and get the best response time. Our new HOWTO document explains when you'll need an API Key and what kind of API Key to create. It also lists the packages you'll need installed to get peeringdb-py up and running. Finally, it provides guidance on how you can automatically refresh the database. We improved the installation guide to help users keep their installation current. Better documentation makes it easier for everyone to install peeringdb-py . If you need to make a lot of PeeringDB queries then we encourage you to query a local cache. If you do this, you'll want to run API queries against it using our software library. The API will remain stable while the database structure could change. The API will remain stable and our library will ensure you don't need to rewrite your queries. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Installing peeringdb-py at NANOG 86"},{"location":"blog/introducing_analytics/","text":"Introducing Analytics Until now, we have not had any analytics about PeeringDB usage. This is a problem. It means we can't make informed decisions that will help us deliver a better service to users. Users have often told us that they want improvements to the website. We know what some of these are but not all. Introducing analytics will help us learn more about the problems some users face. We can then develop improvements to meet their needs. The Product Committee has decided to test Google Analytics. The first step is to deploy it on beta.peeringdb.com. We'll use this as a learning experience. When we are happy with the analytics, we want to deploy an analytics service on www.peeringdb.com. What's next? We know that analytics only provides some of the information we need. We are developing plans to help users give more timely and targeted feedback. We can use that feedback to design and implement the improvements that will be most valuable to users. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Introducing Analytics"},{"location":"blog/introducing_analytics/#introducing-analytics","text":"Until now, we have not had any analytics about PeeringDB usage. This is a problem. It means we can't make informed decisions that will help us deliver a better service to users. Users have often told us that they want improvements to the website. We know what some of these are but not all. Introducing analytics will help us learn more about the problems some users face. We can then develop improvements to meet their needs. The Product Committee has decided to test Google Analytics. The first step is to deploy it on beta.peeringdb.com. We'll use this as a learning experience. When we are happy with the analytics, we want to deploy an analytics service on www.peeringdb.com.","title":"Introducing Analytics"},{"location":"blog/introducing_analytics/#whats-next","text":"We know that analytics only provides some of the information we need. We are developing plans to help users give more timely and targeted feedback. We can use that feedback to design and implement the improvements that will be most valuable to users. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"What's next?"},{"location":"blog/more_details_facilities/","text":"More Details on Facilities We\u2019ve been working hard on improving search this year. In release 2.30.0 we have an improvement that will help data centers and their users. Organizations running facilities can now share information about ownership status, power availability, diversity and resilience. These can all be used as filters in the advanced search page . You will need to be logged in to take advantage of these features. These improvements build on improvements delivered in 2.27.1 and 2.28.0 . We have additional search improvements scheduled for development in upcoming releases. If you run a facility you\u2019ll want to login and update its entry, so it can be found when users take advantage of these new searches. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"More Details on Facilities"},{"location":"blog/more_details_facilities/#more-details-on-facilities","text":"We\u2019ve been working hard on improving search this year. In release 2.30.0 we have an improvement that will help data centers and their users. Organizations running facilities can now share information about ownership status, power availability, diversity and resilience. These can all be used as filters in the advanced search page . You will need to be logged in to take advantage of these features. These improvements build on improvements delivered in 2.27.1 and 2.28.0 . We have additional search improvements scheduled for development in upcoming releases. If you run a facility you\u2019ll want to login and update its entry, so it can be found when users take advantage of these new searches. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"More Details on Facilities"},{"location":"blog/nanog_85_hackathon/","text":"NANOG 85 Hackathon Project We\u2019re bringing a project to the NANOG 85 Hackathon on June 4 - 5, 2022. This time we\u2019re looking for your help in developing a proof of concept we can later develop into a full implementation. In exchange, we\u2019ll walk you through what PeeringDB does. We\u2019ll explain how we support different parts of the Internet community. And you can choose some PeeringDB swag as a thank you! We\u2019re looking for help both from people who want to help turn a flowchart into a designed tool and those who can code ( Python and Django ) and. If you can see yourself in one of those roles then let us know at productcom@lists.peeringdb.com and register for the Hackathon . What\u2019s the project? When we published our updated guidelines for registering in PeeringDB we noted that some of the processes would need to be automated. We want to automate the attestation process for confirming new interconnection facilities. This is a new process to let users confirm that an interconnection facility is real and offers relevant services. It\u2019s a simple workflow. What will you learn? We\u2019ll make sure that you have a good understanding of PeeringDB\u2019s structure. You\u2019ll learn what a network is - in PeeringDB. And we\u2019ll also explain about Internet Exchange Points and interconnection facilities. And you\u2019ll get a good understanding of how and why people use PeeringDB. What will we test together? We want to look at ways that facility operators could activate the process. How should they get the unique URL? Do we need to implement ways for them to share it? What should PeeringDB users see when they visit the URL? Should we implement #1156 ? What will success look like? Success is helping people understand PeeringDB and using that to work out how our tool needs to work. Getting some proof of concept code running would be nice. But identifying issues to take account of in a future feature design would be a win, too. Introducing new people to PeeringDB and getting them involved in extending it is a win for us! If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"NANOG 85 Hackathon Project"},{"location":"blog/nanog_85_hackathon/#nanog-85-hackathon-project","text":"We\u2019re bringing a project to the NANOG 85 Hackathon on June 4 - 5, 2022. This time we\u2019re looking for your help in developing a proof of concept we can later develop into a full implementation. In exchange, we\u2019ll walk you through what PeeringDB does. We\u2019ll explain how we support different parts of the Internet community. And you can choose some PeeringDB swag as a thank you! We\u2019re looking for help both from people who want to help turn a flowchart into a designed tool and those who can code ( Python and Django ) and. If you can see yourself in one of those roles then let us know at productcom@lists.peeringdb.com and register for the Hackathon .","title":"NANOG 85 Hackathon Project"},{"location":"blog/nanog_85_hackathon/#whats-the-project","text":"When we published our updated guidelines for registering in PeeringDB we noted that some of the processes would need to be automated. We want to automate the attestation process for confirming new interconnection facilities. This is a new process to let users confirm that an interconnection facility is real and offers relevant services. It\u2019s a simple workflow.","title":"What\u2019s the project?"},{"location":"blog/nanog_85_hackathon/#what-will-you-learn","text":"We\u2019ll make sure that you have a good understanding of PeeringDB\u2019s structure. You\u2019ll learn what a network is - in PeeringDB. And we\u2019ll also explain about Internet Exchange Points and interconnection facilities. And you\u2019ll get a good understanding of how and why people use PeeringDB.","title":"What will you learn?"},{"location":"blog/nanog_85_hackathon/#what-will-we-test-together","text":"We want to look at ways that facility operators could activate the process. How should they get the unique URL? Do we need to implement ways for them to share it? What should PeeringDB users see when they visit the URL? Should we implement #1156 ?","title":"What will we test together?"},{"location":"blog/nanog_85_hackathon/#what-will-success-look-like","text":"Success is helping people understand PeeringDB and using that to work out how our tool needs to work. Getting some proof of concept code running would be nice. But identifying issues to take account of in a future feature design would be a win, too. Introducing new people to PeeringDB and getting them involved in extending it is a win for us! If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"What will success look like?"},{"location":"blog/nanog_87_hackathon_proof_of_concept/","text":"Do You Want Your Configuration Management System to Update PeeringDB? The theme for NANOG 87's Hackathon was interacting with sources of truth. Our project focused on identifying the difference between what's in a configuration system and PeeringDB - then sending an update. Developers from FullCtl and Peering Manager worked together to develop a proof of concept feature. It lets users know when PeeringDB did not reflect the internal configuration. It then made it easy to send PeeringDB an update. Users tell us that network configuration data is what they value most. So developing ways to help users identify what to update could be valuable. And offering a way to tie that to an update mechanism could make updating PeeringDB much faster. We've created an issue describing this on GitHub . If you or your organization would benefit from a feature like this, please let us know. You can comment on the issue, write to the Product Committee's list , or chat with a PC member. If this is something our users want then we'll need to answer some questions. One example is how to manage multiple updates. How should web users be invited to review multiple updates, so they can approve or reject as needed? We also need to think about how to keep parity between the website and the API. The API supports write operations but is not interactive. So it might be important to add in a feature to show orgs the changes made to their objects. And we might want to add the ability to add a comment alongside updates, so admins can later review logs of what changed and why. We want to speak with people who develop tools that might implement this feature. If you develop a tool that could benefit from a feature like this then let us know. We'd like to speak. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Do You Want Your Configuration Management System to Update PeeringDB?"},{"location":"blog/nanog_87_hackathon_proof_of_concept/#do-you-want-your-configuration-management-system-to-update-peeringdb","text":"The theme for NANOG 87's Hackathon was interacting with sources of truth. Our project focused on identifying the difference between what's in a configuration system and PeeringDB - then sending an update. Developers from FullCtl and Peering Manager worked together to develop a proof of concept feature. It lets users know when PeeringDB did not reflect the internal configuration. It then made it easy to send PeeringDB an update. Users tell us that network configuration data is what they value most. So developing ways to help users identify what to update could be valuable. And offering a way to tie that to an update mechanism could make updating PeeringDB much faster. We've created an issue describing this on GitHub . If you or your organization would benefit from a feature like this, please let us know. You can comment on the issue, write to the Product Committee's list , or chat with a PC member. If this is something our users want then we'll need to answer some questions. One example is how to manage multiple updates. How should web users be invited to review multiple updates, so they can approve or reject as needed? We also need to think about how to keep parity between the website and the API. The API supports write operations but is not interactive. So it might be important to add in a feature to show orgs the changes made to their objects. And we might want to add the ability to add a comment alongside updates, so admins can later review logs of what changed and why. We want to speak with people who develop tools that might implement this feature. If you develop a tool that could benefit from a feature like this then let us know. We'd like to speak. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Do You Want Your Configuration Management System to Update PeeringDB?"},{"location":"blog/network_type_what_you_told_us/","text":"Network Type \u2013 What did you tell us? We invited PeeringDB users to tell us what they thought about the Network Type setting. This is the setting that describes your network to other PeeringDB users. It's OK 162 people participated and their core message was that the field is largely working for both those sharing and reading the data. Just over half of respondents use the field to make decisions. About two thirds think it is accurate or very accurate. About three quarters think the current range of options is useful or very useful. About half think the level of granularity is about right, while almost a third would like more nuance. Comments Lots of people told us how they use the Network Type field in the comments. Some reinforced their responses to the other questions with calls to remove the field, add additional options, or restrict the options to \u201ceyeball\u201d, \u201ccontent\u201d, and \u201chybrid\u201d. There was also a call to allow networks to select multiple categories. Next steps The Product Committee has decided to keep the Network Type field. We will not change the types of networks but will implement the ability to select multiple types. This will be implemented in the website and v2 API now deployed. We will plan a more radical update of the field for a future v3 API. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Network Type \u2013 What did you tell us?"},{"location":"blog/network_type_what_you_told_us/#network-type-what-did-you-tell-us","text":"We invited PeeringDB users to tell us what they thought about the Network Type setting. This is the setting that describes your network to other PeeringDB users.","title":"Network Type \u2013 What did you tell us?"},{"location":"blog/network_type_what_you_told_us/#its-ok","text":"162 people participated and their core message was that the field is largely working for both those sharing and reading the data. Just over half of respondents use the field to make decisions. About two thirds think it is accurate or very accurate. About three quarters think the current range of options is useful or very useful. About half think the level of granularity is about right, while almost a third would like more nuance.","title":"It's OK"},{"location":"blog/network_type_what_you_told_us/#comments","text":"Lots of people told us how they use the Network Type field in the comments. Some reinforced their responses to the other questions with calls to remove the field, add additional options, or restrict the options to \u201ceyeball\u201d, \u201ccontent\u201d, and \u201chybrid\u201d. There was also a call to allow networks to select multiple categories.","title":"Comments"},{"location":"blog/network_type_what_you_told_us/#next-steps","text":"The Product Committee has decided to keep the Network Type field. We will not change the types of networks but will implement the ability to select multiple types. This will be implemented in the website and v2 API now deployed. We will plan a more radical update of the field for a future v3 API. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Next steps"},{"location":"blog/network_type_your_input_sought/","text":"Network Type \u2013 Your Input Sought You can select from 10 options to describe your network in PeeringDB. We want to know if these options are useful. If we need to improve this part of PeeringDB, how should we improve it ? Please take our four question survey . We need your input to inform our decision. One option we're discussing is to clarify what each category means . Another is to deprecate the field . We know that not everyone understands the current categories in the same way. We don't know if anyone actually relies on this data to make decisions. Please take the survey and tell us if you use this data, how reliable you think it is, and how it should change if you think it needs improvement. The improvements we make are only as good as the requests we get from you. We want to make sure that we understand what you need and why. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Network Type \u2013 Your Input Sought"},{"location":"blog/network_type_your_input_sought/#network-type-your-input-sought","text":"You can select from 10 options to describe your network in PeeringDB. We want to know if these options are useful. If we need to improve this part of PeeringDB, how should we improve it ? Please take our four question survey . We need your input to inform our decision. One option we're discussing is to clarify what each category means . Another is to deprecate the field . We know that not everyone understands the current categories in the same way. We don't know if anyone actually relies on this data to make decisions. Please take the survey and tell us if you use this data, how reliable you think it is, and how it should change if you think it needs improvement. The improvements we make are only as good as the requests we get from you. We want to make sure that we understand what you need and why. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Network Type \u2013 Your Input Sought"},{"location":"blog/new_permission_manage_peering_sessions/","text":"New Permission: Manage Peering Sessions Last November, Maximilian Wilhelm suggested that we add a 'manage peering sessions' permission. Some networks let you request peering using our OAuth service . You don't have to rely on someone to read your email message. They get the ability to pull structured information about your network through our API. Automation. Everyone can win. Today, in 2.47.0 , we\u2019re introducing a new permission that lets organizations limit who can \"manage peering sessions\" via peering portals. It will default to \u2018on\u2019 for organizational admins. But other users won\u2019t get this permission by default. If you need this permission you\u2019ll need to speak with the admins for your organization\u2019s presence on PeeringDB. \" Today many peering portals leverage PeeringDB's OAuth to make managing peerings easier and remove the need to manage separate accounts with every network you peer with. The new \"manage peerings\" permission lets organisations control which of their teams can represent them to external organisations instead of relying on admin privileges in PeeringDB, providing safer and more secure access. \" Maximilian Wilhelm, Network Automation Engineer, Cloudflare Take a look at these new permissions if you use PeeringDB OAuth to manage peering sessions. If you operate a peering portal using our OAuth, you should make sure you check the new permission when authenticating users. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"New Permission: Manage Peering Sessions"},{"location":"blog/new_permission_manage_peering_sessions/#new-permission-manage-peering-sessions","text":"Last November, Maximilian Wilhelm suggested that we add a 'manage peering sessions' permission. Some networks let you request peering using our OAuth service . You don't have to rely on someone to read your email message. They get the ability to pull structured information about your network through our API. Automation. Everyone can win. Today, in 2.47.0 , we\u2019re introducing a new permission that lets organizations limit who can \"manage peering sessions\" via peering portals. It will default to \u2018on\u2019 for organizational admins. But other users won\u2019t get this permission by default. If you need this permission you\u2019ll need to speak with the admins for your organization\u2019s presence on PeeringDB. \" Today many peering portals leverage PeeringDB's OAuth to make managing peerings easier and remove the need to manage separate accounts with every network you peer with. The new \"manage peerings\" permission lets organisations control which of their teams can represent them to external organisations instead of relying on admin privileges in PeeringDB, providing safer and more secure access. \" Maximilian Wilhelm, Network Automation Engineer, Cloudflare Take a look at these new permissions if you use PeeringDB OAuth to manage peering sessions. If you operate a peering portal using our OAuth, you should make sure you check the new permission when authenticating users. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"New Permission: Manage Peering Sessions"},{"location":"blog/oauth_users/","text":"PeeringDB Can Bring Users to Your Application One of the most challenging parts of developing a new service or expanding an existing one is to get users to register for an account. That\u2019s one of the advantages of using PeeringDB\u2019s OAuth service. We\u2019ve already got plenty of users. But why would you want to enable PeeringDB\u2019s OAuth service with your application? Well, if it\u2019s focused on people at networks who engage in managing interconnections then you have a readymade audience. Take Facebook\u2019s example . They are now using PeeringDB OAuth as a part of the process they use to automate peering requests. \u201c We wanted to offer our partners an easy way to request and manage their peering with Facebook. Thanks to PeeringDB OAuth, our partner networks can submit peering requests and see their existing peering sessions with Facebook without having to login to their Facebook accounts! \u201d Jakub Heichman & Jenny Ramseyer @ Facebook Almost 150 applications have registered with PeeringDB and we\u2019re authenticating over 1,500 sessions each quarter. We expect that to grow. If you\u2019d like to learn how you can register your application with PeeringDB\u2019s OAuth service, take a look at our documentation . If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB Can Bring Users to Your Application"},{"location":"blog/oauth_users/#peeringdb-can-bring-users-to-your-application","text":"One of the most challenging parts of developing a new service or expanding an existing one is to get users to register for an account. That\u2019s one of the advantages of using PeeringDB\u2019s OAuth service. We\u2019ve already got plenty of users. But why would you want to enable PeeringDB\u2019s OAuth service with your application? Well, if it\u2019s focused on people at networks who engage in managing interconnections then you have a readymade audience. Take Facebook\u2019s example . They are now using PeeringDB OAuth as a part of the process they use to automate peering requests. \u201c We wanted to offer our partners an easy way to request and manage their peering with Facebook. Thanks to PeeringDB OAuth, our partner networks can submit peering requests and see their existing peering sessions with Facebook without having to login to their Facebook accounts! \u201d Jakub Heichman & Jenny Ramseyer @ Facebook Almost 150 applications have registered with PeeringDB and we\u2019re authenticating over 1,500 sessions each quarter. We expect that to grow. If you\u2019d like to learn how you can register your application with PeeringDB\u2019s OAuth service, take a look at our documentation . If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB Can Bring Users to Your Application"},{"location":"blog/october_2024_retrospective/","text":"October 2024 PeeringDB Product Update Strategy We reviewed and updated our strategy earlier in the year. We will be publishing overviews of product changes in April and October. We've had a blog for a few years but it\u2019s focused on details. These updates will give a bigger picture. People and process Terry Sweetser from APNIC has recently joined the Product Committee (PC). The PC now has members from Africa, Asia Pacific, Europe, and North America. Our committee\u2019s geographic diversity is matched by a diversity in expertise. We have updated our processes because our members live around the globe. We are using asynchronous work methods more. And we will focus on planning out sets of related issues to improve PeeringDB more quickly. We still encourage users to submit feature requests and bug reports in GitHub. We want to understand how feature developments can help our users. Please tell us whether you'd use a feature and how it would help. You can do this in GitHub, on our mailing list, or when you meet us at industry events. Last six months We've been rounding out support for Carrier objects. Organizations can now set user permissions for carriers. We\u2019ve also been working to improve data quality. We now enforce state naming. For instance, Queensland in Australia is now always QLD. We also normalize city names in responses but accept popular versions in the search request. So, a search for \"fac in M\u00fcnchen\" returns results for facilities within 34 km of Munich, Germany. The radius search is managed in the backend by the new search. It's different for each city. You can control the radius in Advanced Search, or just look on a map when you download our KMZ. The full KMZ download was popular. So, we tidied up the data in the export, added a watermark, so users know that they have PeeringDB data, and integrated KMZ support into other features. You can now download a .KMZ file of exchanges or facilities in a city, state, or country. This keeps the file size small, making it easier to integrate it with other data sources. Once you\u2019ve found the carrier, exchange, facility, or network you are interested in you can now export all their data in structured formats. Previously, this was only available for Advanced Search results. These data quality, search and extract features are one part of the work we've been doing. We've also put more effort into peeringdb-py, our local cache. We encourage anyone who wants to make heavy use of PeeringDB to run a local cache. There are no usage limits and no latency. If you often hit query limits then it could be worth installing. It is resource light, so it can run on a laptop as well as a server. If you sync it once an hour, the changes are normally under 100kb of data. We\u2019ve also made improvements behind the scenes. We\u2019ve switched to deploying PeeringDB in containers. This change will reduce the work needed by our volunteer Operations Committee. It will also help us manage costs better by adjusting compute resources dynamically based on load. Security A user made two security reports. Our Operations team also noticed one issue. Based on these reports, we will be making 2FA mandatory for all user accounts. We will also make some minor improvements to other elements of account security. We\u2019ll share more details after deploying changes. If you notice a security issue, please let us know! https://docs.peeringdb.com/howto/make-a-security-report/ Coming up and engagement Over the next six months we'd like to deploy improvements to our web design. These won't just make it look better. Once we have them in place we can implement lazy loading, to improve the user experience. We can also start to develop some key feature improvements, including saved searches, notifications, and comparison tools. Your input on how you'd use these and other feature improvements are welcome. You can create or comment on issues in GitHub. But we'd love to speak with you, too. We actively attend industry events around the world, so look for us there. Or send mail so we can schedule a conversation! If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"October 2024 PeeringDB Product Update"},{"location":"blog/october_2024_retrospective/#october-2024-peeringdb-product-update","text":"","title":"October 2024 PeeringDB Product Update"},{"location":"blog/october_2024_retrospective/#strategy","text":"We reviewed and updated our strategy earlier in the year. We will be publishing overviews of product changes in April and October. We've had a blog for a few years but it\u2019s focused on details. These updates will give a bigger picture.","title":"Strategy"},{"location":"blog/october_2024_retrospective/#people-and-process","text":"Terry Sweetser from APNIC has recently joined the Product Committee (PC). The PC now has members from Africa, Asia Pacific, Europe, and North America. Our committee\u2019s geographic diversity is matched by a diversity in expertise. We have updated our processes because our members live around the globe. We are using asynchronous work methods more. And we will focus on planning out sets of related issues to improve PeeringDB more quickly. We still encourage users to submit feature requests and bug reports in GitHub. We want to understand how feature developments can help our users. Please tell us whether you'd use a feature and how it would help. You can do this in GitHub, on our mailing list, or when you meet us at industry events.","title":"People and process"},{"location":"blog/october_2024_retrospective/#last-six-months","text":"We've been rounding out support for Carrier objects. Organizations can now set user permissions for carriers. We\u2019ve also been working to improve data quality. We now enforce state naming. For instance, Queensland in Australia is now always QLD. We also normalize city names in responses but accept popular versions in the search request. So, a search for \"fac in M\u00fcnchen\" returns results for facilities within 34 km of Munich, Germany. The radius search is managed in the backend by the new search. It's different for each city. You can control the radius in Advanced Search, or just look on a map when you download our KMZ. The full KMZ download was popular. So, we tidied up the data in the export, added a watermark, so users know that they have PeeringDB data, and integrated KMZ support into other features. You can now download a .KMZ file of exchanges or facilities in a city, state, or country. This keeps the file size small, making it easier to integrate it with other data sources. Once you\u2019ve found the carrier, exchange, facility, or network you are interested in you can now export all their data in structured formats. Previously, this was only available for Advanced Search results. These data quality, search and extract features are one part of the work we've been doing. We've also put more effort into peeringdb-py, our local cache. We encourage anyone who wants to make heavy use of PeeringDB to run a local cache. There are no usage limits and no latency. If you often hit query limits then it could be worth installing. It is resource light, so it can run on a laptop as well as a server. If you sync it once an hour, the changes are normally under 100kb of data. We\u2019ve also made improvements behind the scenes. We\u2019ve switched to deploying PeeringDB in containers. This change will reduce the work needed by our volunteer Operations Committee. It will also help us manage costs better by adjusting compute resources dynamically based on load.","title":"Last six months"},{"location":"blog/october_2024_retrospective/#security","text":"A user made two security reports. Our Operations team also noticed one issue. Based on these reports, we will be making 2FA mandatory for all user accounts. We will also make some minor improvements to other elements of account security. We\u2019ll share more details after deploying changes. If you notice a security issue, please let us know! https://docs.peeringdb.com/howto/make-a-security-report/","title":"Security"},{"location":"blog/october_2024_retrospective/#coming-up-and-engagement","text":"Over the next six months we'd like to deploy improvements to our web design. These won't just make it look better. Once we have them in place we can implement lazy loading, to improve the user experience. We can also start to develop some key feature improvements, including saved searches, notifications, and comparison tools. Your input on how you'd use these and other feature improvements are welcome. You can create or comment on issues in GitHub. But we'd love to speak with you, too. We actively attend industry events around the world, so look for us there. Or send mail so we can schedule a conversation! If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Coming up and engagement"},{"location":"blog/organizational_policy/","text":"Organizational Policy Features and More We want administrators for organizations in PeeringDB to log in and to look around. We have created some new settings to help you manage users affiliated with your organization in PeeringDB. There are three key changes you'll want to look at. You can now require your users to use a specific email domain. For example, if your company email uses example.com, you could require them to have an example.com email address for their PeeringDB account. You can now force users to revalidate their PeeringDB account periodically. You can set the period that fits with your organization's needs. Your users can now have multiple email addresses for their PeeringDB account. We have published a HOWTO that walks administrators through the details of how to configure these features. This release also includes improvements contributed by developers at Amazon and Google. We are grateful for their contributions. Take a look at our HOWTO about developing for PeeringDB if you'd like to contribute. This release also has several small feature improvements and changes that allow us to provide users with better support. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Organizational Policy Features and More"},{"location":"blog/organizational_policy/#organizational-policy-features-and-more","text":"We want administrators for organizations in PeeringDB to log in and to look around. We have created some new settings to help you manage users affiliated with your organization in PeeringDB. There are three key changes you'll want to look at. You can now require your users to use a specific email domain. For example, if your company email uses example.com, you could require them to have an example.com email address for their PeeringDB account. You can now force users to revalidate their PeeringDB account periodically. You can set the period that fits with your organization's needs. Your users can now have multiple email addresses for their PeeringDB account. We have published a HOWTO that walks administrators through the details of how to configure these features. This release also includes improvements contributed by developers at Amazon and Google. We are grateful for their contributions. Take a look at our HOWTO about developing for PeeringDB if you'd like to contribute. This release also has several small feature improvements and changes that allow us to provide users with better support. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Organizational Policy Features and More"},{"location":"blog/peeringdb_2020_satisfaction_survey/","text":"PeeringDB 2020 Satisfaction Survey PeeringDB wants input from network operators, exchange operators, facility providers, content distributors and anyone who uses our interconnection database. We are running an anonymous satisfaction survey until 23:59 UTC on 20 November 2020 and would like your feedback to help us make PeeringDB more useful to everyone involved in connecting networks. We haven\u2019t had the diversity of input we\u2019d like in previous surveys, so we are making an extra effort to reach parts of the community who weren\u2019t aware of our previous surveys. We're telling you here and we are teaming up with partners around the world to get the message out. Steve McManus, PeeringDB Product Committee Chair, says: \"Input from all PeeringDB users on what is important and what needs improving is essential. Telling us what you value and what you need us to improve will help us make PeeringDB better for you and make peering easier for all.\" The survey will help us understand what is important to you and how satisfied you are with what we are doing. We will use your responses to focus our product roadmap on the improvements that will make things better for you. If you have specific comments or suggestions we\u2019d love you to leave them along with your ratings. This is the first survey we are making available in multiple languages. In this survey we are using the six UN languages for the questions. That said, we\u2019re happy with people providing free text comments in whichever language they are happiest expressing themselves. We\u2019ll share the results and the new product roadmap early in 2021. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB 2020 Satisfaction Survey"},{"location":"blog/peeringdb_2020_satisfaction_survey/#peeringdb-2020-satisfaction-survey","text":"PeeringDB wants input from network operators, exchange operators, facility providers, content distributors and anyone who uses our interconnection database. We are running an anonymous satisfaction survey until 23:59 UTC on 20 November 2020 and would like your feedback to help us make PeeringDB more useful to everyone involved in connecting networks. We haven\u2019t had the diversity of input we\u2019d like in previous surveys, so we are making an extra effort to reach parts of the community who weren\u2019t aware of our previous surveys. We're telling you here and we are teaming up with partners around the world to get the message out. Steve McManus, PeeringDB Product Committee Chair, says: \"Input from all PeeringDB users on what is important and what needs improving is essential. Telling us what you value and what you need us to improve will help us make PeeringDB better for you and make peering easier for all.\" The survey will help us understand what is important to you and how satisfied you are with what we are doing. We will use your responses to focus our product roadmap on the improvements that will make things better for you. If you have specific comments or suggestions we\u2019d love you to leave them along with your ratings. This is the first survey we are making available in multiple languages. In this survey we are using the six UN languages for the questions. That said, we\u2019re happy with people providing free text comments in whichever language they are happiest expressing themselves. We\u2019ll share the results and the new product roadmap early in 2021. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB 2020 Satisfaction Survey"},{"location":"blog/peeringdb_2020_survey_2021_roadmap/","text":"2020 Survey Results and 2021 Product Roadmap Last November we asked you for input through our anonymous satisfaction survey, so we could use it to guide our product roadmap for 2021. Today, we are sharing what you told us through the survey and how we\u2019ll be improving PeeringDB and your experience of it in 2021. We had over 200 responses to the survey. Respondents identified themselves as connected with organizations operating on every continent and in every part of our industry. 99% of respondents described themselves as very or somewhat satisfied with PeeringDB overall. When we asked about specific service categories, we were told that Network Configuration Data and Search and Discovery capabilities were the most important. These service categories had lower, though still high, levels of satisfaction, with 95% and 96% of respondents describing themselves as very or somewhat satisfied with these aspects of PeeringDB. Although we saw higher satisfaction with the User Experience and Web Interface, at 97%, this service category both had the most responses and the most divided feedback. One user described the current web interface as \u201c clean and simple \u201d while others said it was \u201c showing its age .\u201d Documentation quality was also an area with lower specific satisfaction, at 93%. One comment homed in on a key problem, noting: \" Needs a top-level overview document/intro. Or if it exists, I need to find it. \" We have used your feedback to guide our product roadmap for 2021. The four key focus areas will be: Improving geographic search Developing a structured framework for user documentation Improving the web site\u2019s responsiveness Introducing a communications framework to alert users to developments and support future tooling Our first steps to accomplish this have been to add database support for coordinates of facilities. All new facilities will be located by their latitude and longitude, with street addresses as human friendly search terms instead of authoritative data. This is a major project and we will share more on this work in a future blog post. Another key change is the publication of our first HOWTO document . This document is designed to help new networks register with PeeringDB using our website. We will be publishing more documents in this series and developing a broader documentation framework to support API and web users equally. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"2020 Survey Results and 2021 Product Roadmap"},{"location":"blog/peeringdb_2020_survey_2021_roadmap/#2020-survey-results-and-2021-product-roadmap","text":"Last November we asked you for input through our anonymous satisfaction survey, so we could use it to guide our product roadmap for 2021. Today, we are sharing what you told us through the survey and how we\u2019ll be improving PeeringDB and your experience of it in 2021. We had over 200 responses to the survey. Respondents identified themselves as connected with organizations operating on every continent and in every part of our industry. 99% of respondents described themselves as very or somewhat satisfied with PeeringDB overall. When we asked about specific service categories, we were told that Network Configuration Data and Search and Discovery capabilities were the most important. These service categories had lower, though still high, levels of satisfaction, with 95% and 96% of respondents describing themselves as very or somewhat satisfied with these aspects of PeeringDB. Although we saw higher satisfaction with the User Experience and Web Interface, at 97%, this service category both had the most responses and the most divided feedback. One user described the current web interface as \u201c clean and simple \u201d while others said it was \u201c showing its age .\u201d Documentation quality was also an area with lower specific satisfaction, at 93%. One comment homed in on a key problem, noting: \" Needs a top-level overview document/intro. Or if it exists, I need to find it. \" We have used your feedback to guide our product roadmap for 2021. The four key focus areas will be: Improving geographic search Developing a structured framework for user documentation Improving the web site\u2019s responsiveness Introducing a communications framework to alert users to developments and support future tooling Our first steps to accomplish this have been to add database support for coordinates of facilities. All new facilities will be located by their latitude and longitude, with street addresses as human friendly search terms instead of authoritative data. This is a major project and we will share more on this work in a future blog post. Another key change is the publication of our first HOWTO document . This document is designed to help new networks register with PeeringDB using our website. We will be publishing more documents in this series and developing a broader documentation framework to support API and web users equally. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"2020 Survey Results and 2021 Product Roadmap"},{"location":"blog/peeringdb_2021_survey_2022_roadmap/","text":"2021 Survey Results and 2022 Product Roadmap Last September we asked you for input through our anonymous satisfaction survey, so we could use it to guide our product roadmap for 2022. Today, we are sharing what you told us through the survey and how we\u2019ll be improving PeeringDB and your experience of it in 2022. Highlights We had almost 250 responses to the survey, a 25% increase on last year. As with last year, respondents identified themselves as connected with organizations operating on every continent and in every part of our industry. Overall satisfaction remains unchanged from last year. We asked a few new questions in 2021 and learned: Almost 70% of respondents use PeeringDB every day or every week. Most of the rest use it every month. Under half of respondents use PeeringDB on a mobile device. About 70% of respondents want a way to be notified about changes that are relevant to them. From the questions that were repeated from 2021 we learned that Network Configuration Data and Search and Discovery capabilities remained the most important to our users. The User Experience and Web Interface remained the service categories with the lowest satisfaction, although 85% of respondents were still somewhat or very satisfied. The other lower performing area was Documentation Quality, which is an area that we started to address later in 2021 and some respondents won't have known about. Work on improving our documentation will continue in 2022. We hope that these improvements drive satisfaction in 2022. Roadmap We have used your feedback, in combination with a focus group consultation , to guide our product roadmap for 2022. The three key focus areas will be: Introduce a new \u201cCarrier\u201d object This object will describe providers of high capacity links between interconnection facilities. It was named \u201cCarrier\u201d during the discussion but that is a placeholder that could be changed if it is considered confusing or inappropriate. We are developing a design which will be circulated with the focus group before developing this new feature. As a new object, we\u2019ll make sure that it is well documented so users can get the most value from it. Improving the web site\u2019s responsiveness We recognize that the overall visual design needs some improvement. But perhaps more importantly we need to improve page load times. We plan to bring PeeringDB nearer to its users by completing deployment to a CDN. We have already tested this by deploying beta.peeringdb.com there and we will be moving www.peeringdb.com to it in 2022. We will also introduce modular page rendering, so each element loads via a separate connection, speeding the overall experience. We will use the CDN metrics to learn more about how www.peeringdb.com is used and that will inform improvements to the visual design. Continue improving search 2021 saw significant improvements to advanced search and simple search. We will continue to make improvements to search and help users keep the underlying data more accurate. One example of this is work that\u2019s going on, as I type, at the NANOG 84 Hackathon where volunteer developers are introducing intersection searches . That means you\u2019ll be able to make a single query to find out which IXPs or interconnection facilities have two networks present, such as your own and a desired peer\u2019s. This is an example of how PeeringDB is developed by its users as well as the core team. What else? Data accuracy We know that we need to do work to improve the quality of data in PeeringDB as it plays such an important role in configuration. We last looked at this in 2019\u2019s Data Ownership Task Force , whose report acknowledged the shared responsibility for data describing the interconnected nature of separately managed parts of our Internet. We plan to work with PeeringDB users to renew our work in this area so we can continue to improve the quality of data we publish. We are also setting course towards increased data accuracy by using the RPKI and Resource Signed Checklists (RSC). We want to use RSC validation to cryptographically validate our users\u2019 ability to control specific Internet Number Resources. Call to action We just deployed two user developed features: improvements to simple search and OpenID Connect integration. We are keen to include more user developed code. If you\u2019d like to contribute to PeeringDB then let me know and we can help you. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"2021 Survey Results and 2022 Product Roadmap"},{"location":"blog/peeringdb_2021_survey_2022_roadmap/#2021-survey-results-and-2022-product-roadmap","text":"Last September we asked you for input through our anonymous satisfaction survey, so we could use it to guide our product roadmap for 2022. Today, we are sharing what you told us through the survey and how we\u2019ll be improving PeeringDB and your experience of it in 2022.","title":"2021 Survey Results and 2022 Product Roadmap"},{"location":"blog/peeringdb_2021_survey_2022_roadmap/#highlights","text":"We had almost 250 responses to the survey, a 25% increase on last year. As with last year, respondents identified themselves as connected with organizations operating on every continent and in every part of our industry. Overall satisfaction remains unchanged from last year. We asked a few new questions in 2021 and learned: Almost 70% of respondents use PeeringDB every day or every week. Most of the rest use it every month. Under half of respondents use PeeringDB on a mobile device. About 70% of respondents want a way to be notified about changes that are relevant to them. From the questions that were repeated from 2021 we learned that Network Configuration Data and Search and Discovery capabilities remained the most important to our users. The User Experience and Web Interface remained the service categories with the lowest satisfaction, although 85% of respondents were still somewhat or very satisfied. The other lower performing area was Documentation Quality, which is an area that we started to address later in 2021 and some respondents won't have known about. Work on improving our documentation will continue in 2022. We hope that these improvements drive satisfaction in 2022.","title":"Highlights"},{"location":"blog/peeringdb_2021_survey_2022_roadmap/#roadmap","text":"We have used your feedback, in combination with a focus group consultation , to guide our product roadmap for 2022. The three key focus areas will be:","title":"Roadmap"},{"location":"blog/peeringdb_2021_survey_2022_roadmap/#introduce-a-new-carrier-object","text":"This object will describe providers of high capacity links between interconnection facilities. It was named \u201cCarrier\u201d during the discussion but that is a placeholder that could be changed if it is considered confusing or inappropriate. We are developing a design which will be circulated with the focus group before developing this new feature. As a new object, we\u2019ll make sure that it is well documented so users can get the most value from it.","title":"Introduce a new \u201cCarrier\u201d object"},{"location":"blog/peeringdb_2021_survey_2022_roadmap/#improving-the-web-sites-responsiveness","text":"We recognize that the overall visual design needs some improvement. But perhaps more importantly we need to improve page load times. We plan to bring PeeringDB nearer to its users by completing deployment to a CDN. We have already tested this by deploying beta.peeringdb.com there and we will be moving www.peeringdb.com to it in 2022. We will also introduce modular page rendering, so each element loads via a separate connection, speeding the overall experience. We will use the CDN metrics to learn more about how www.peeringdb.com is used and that will inform improvements to the visual design.","title":"Improving the web site\u2019s responsiveness"},{"location":"blog/peeringdb_2021_survey_2022_roadmap/#continue-improving-search","text":"2021 saw significant improvements to advanced search and simple search. We will continue to make improvements to search and help users keep the underlying data more accurate. One example of this is work that\u2019s going on, as I type, at the NANOG 84 Hackathon where volunteer developers are introducing intersection searches . That means you\u2019ll be able to make a single query to find out which IXPs or interconnection facilities have two networks present, such as your own and a desired peer\u2019s. This is an example of how PeeringDB is developed by its users as well as the core team.","title":"Continue improving search"},{"location":"blog/peeringdb_2021_survey_2022_roadmap/#what-else-data-accuracy","text":"We know that we need to do work to improve the quality of data in PeeringDB as it plays such an important role in configuration. We last looked at this in 2019\u2019s Data Ownership Task Force , whose report acknowledged the shared responsibility for data describing the interconnected nature of separately managed parts of our Internet. We plan to work with PeeringDB users to renew our work in this area so we can continue to improve the quality of data we publish. We are also setting course towards increased data accuracy by using the RPKI and Resource Signed Checklists (RSC). We want to use RSC validation to cryptographically validate our users\u2019 ability to control specific Internet Number Resources.","title":"What else? Data accuracy"},{"location":"blog/peeringdb_2021_survey_2022_roadmap/#call-to-action","text":"We just deployed two user developed features: improvements to simple search and OpenID Connect integration. We are keen to include more user developed code. If you\u2019d like to contribute to PeeringDB then let me know and we can help you. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Call to action"},{"location":"blog/peeringdb_2021_user_survey/","text":"PeeringDB 2021 User Survey PeeringDB wants input from network operators, exchange operators, facility providers, content distributors and anyone who uses our interconnection database. We are running an anonymous satisfaction survey until 23:59 UTC on Friday, 8 October 2021 and would like your feedback to help us make PeeringDB more useful to everyone involved in connecting networks. We had over 200 responses to last year\u2019s survey and those responses helped guide our product development. We\u2019ve made significant improvements to search based on user input, introduced a HOWTO documentation series , and are developing a documentation architecture directly as a result of your input. We\u2019d like more input, in 2021, so we can keep up with the industry\u2019s evolving needs. Steve McManus, PeeringDB Product Committee Chair, says: \" User comments in the 2020 survey helped us focus development where it was most needed. It directly influenced our roadmap and highlighted the need for specific expertise in documentation and user experience design to solve users\u2019 most pressing needs. Thanks to everyone who gives a few moments of their time to help us make PeeringDB a better service! \u201d In addition to the questions we asked last year, we have three extra questions about documentation priorities, notifications, and user experience on mobile devices. We are particularly keen to improve our understanding of people\u2019s needs for the website as this was the area with the most divided responses last year. The survey is available in the six UN languages and Portuguese. We\u2019re happy with people providing free text comments in whichever language they are happiest expressing themselves. We\u2019ll share the results and the new product roadmap early in 2022. So CLICK HERE to help guide PeeringDB\u2019s future development. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB 2021 User Survey"},{"location":"blog/peeringdb_2021_user_survey/#peeringdb-2021-user-survey","text":"PeeringDB wants input from network operators, exchange operators, facility providers, content distributors and anyone who uses our interconnection database. We are running an anonymous satisfaction survey until 23:59 UTC on Friday, 8 October 2021 and would like your feedback to help us make PeeringDB more useful to everyone involved in connecting networks. We had over 200 responses to last year\u2019s survey and those responses helped guide our product development. We\u2019ve made significant improvements to search based on user input, introduced a HOWTO documentation series , and are developing a documentation architecture directly as a result of your input. We\u2019d like more input, in 2021, so we can keep up with the industry\u2019s evolving needs. Steve McManus, PeeringDB Product Committee Chair, says: \" User comments in the 2020 survey helped us focus development where it was most needed. It directly influenced our roadmap and highlighted the need for specific expertise in documentation and user experience design to solve users\u2019 most pressing needs. Thanks to everyone who gives a few moments of their time to help us make PeeringDB a better service! \u201d In addition to the questions we asked last year, we have three extra questions about documentation priorities, notifications, and user experience on mobile devices. We are particularly keen to improve our understanding of people\u2019s needs for the website as this was the area with the most divided responses last year. The survey is available in the six UN languages and Portuguese. We\u2019re happy with people providing free text comments in whichever language they are happiest expressing themselves. We\u2019ll share the results and the new product roadmap early in 2022. So CLICK HERE to help guide PeeringDB\u2019s future development. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB 2021 User Survey"},{"location":"blog/peeringdb_2022_user_survey/","text":"PeeringDB 2022 User Survey PeeringDB wants input from everyone who uses our interconnection database. Our anonymous survey is now open until 23:59 UTC on 16 October 2022. We would like your feedback to help us make PeeringDB more useful to everyone involved in connecting networks. We had about 250 responses to last year\u2019s survey which helped guide our product development. Key changes delivered so far in 2022 include: Added API Key support to peeringdb-py Added FIDO U2F 2FA support to www.peeringdb.com Normalized place names We\u2019ve also published more documents in our HOWTO documentation series . Steve McManus, PeeringDB Product Committee Chair, says: \" The 2021 survey helped us focus development where it was most needed. We used it to develop our roadmap. We are still implementing things we have learned from previous surveys but want your input on how we should adapt. Please take a few moments of their time to help us make PeeringDB a better service! \u201d In 2022 we have added a couple of extra questions. We'd like to know how many people use PeeringDB at your organization. We'd also like to know how you use it: web, API, or via a local cache. We will use your answers to focus development work where it is most needed. The survey is available in the six UN languages, Portuguese and Ukrainian. Please provide comments in whatever language you want to express yourself. We\u2019ll share the results and the new product roadmap early in 2023. So CLICK HERE to help guide PeeringDB\u2019s future development. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB 2022 User Survey"},{"location":"blog/peeringdb_2022_user_survey/#peeringdb-2022-user-survey","text":"PeeringDB wants input from everyone who uses our interconnection database. Our anonymous survey is now open until 23:59 UTC on 16 October 2022. We would like your feedback to help us make PeeringDB more useful to everyone involved in connecting networks. We had about 250 responses to last year\u2019s survey which helped guide our product development. Key changes delivered so far in 2022 include: Added API Key support to peeringdb-py Added FIDO U2F 2FA support to www.peeringdb.com Normalized place names We\u2019ve also published more documents in our HOWTO documentation series . Steve McManus, PeeringDB Product Committee Chair, says: \" The 2021 survey helped us focus development where it was most needed. We used it to develop our roadmap. We are still implementing things we have learned from previous surveys but want your input on how we should adapt. Please take a few moments of their time to help us make PeeringDB a better service! \u201d In 2022 we have added a couple of extra questions. We'd like to know how many people use PeeringDB at your organization. We'd also like to know how you use it: web, API, or via a local cache. We will use your answers to focus development work where it is most needed. The survey is available in the six UN languages, Portuguese and Ukrainian. Please provide comments in whatever language you want to express yourself. We\u2019ll share the results and the new product roadmap early in 2023. So CLICK HERE to help guide PeeringDB\u2019s future development. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB 2022 User Survey"},{"location":"blog/peeringdb_2023_roadmap/","text":"PeeringDB's Product Roadmap for 2023 We want to build more agility into our Product Management process in 2023. This blog post describes what we have planned for the start of the year. It also describes how we want to work over the whole year, and how you can help us make good choices. We are starting the year with features that open new paths to us. Your input will help us choose how we move down them. Our roundup of 2022 noted that we have some big things planned for the start of 2023. The two biggest are two new objects. We deployed the first in our January release. The new carrier object is a way for providers of high capacity links to show which interconnection facilities they are in. We\u2019ve deployed the minimal possible structure for this new object. We want users to tell us what additional features they cannot do without. The next big new addition is a campus object. This will be a way for interconnection facilities to show that inter-building cross-connects are available with the same ease as those within a building. This will help buyers understand when they don't need to be in the same building as something they want to connect to. We can expand either or both of these objects. We need your feedback to help us decide what would make them more valuable. Respondents to our annual surveys have consistently told us that Network Configuration Data is what they value most. They are also quite divided about the website design. Some people love its simplicity and others want something more modern. We knew that we didn't have enough information to make good decisions on how to improve things for the people who want change without disappointing those who like it the way it is. We have deployed Google Analytics for beta.peeringdb.com and would like to deploy it to www.peeringdb.com and docs.peeringdb.com . This will give us important information about how people use our site. We\u2019ll use this information to understand the problems people experience and develop ways to solve them. We also have lots of users who rely on our API or a local cache of PeeringDB data. So, we want to make it easier for users to identify the deltas between what they have in PeeringDB and their local configuration management. This is the focus on the projects we're taking to the NANOG 87 Hackathon . We want to work with tool developers and anyone who relies on PeeringDB as a source of network configuration data. Ultimately, we'd like to offer a way for users to automatically identify deltas, the changes that could be made, and ways to make or approve those changes. Across the rest of the year, we'd like to focus on one theme at a time and deliver a set of significant improvements there. Then we can move on to the next relevant theme. So please let us know how we could make PeeringDB more valuable for your organization. As always, you can submit an issue, or comment on existing issues in GitHub . But you can also send us email or chat to us at various community events. PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB's Product Roadmap for 2023"},{"location":"blog/peeringdb_2023_roadmap/#peeringdbs-product-roadmap-for-2023","text":"We want to build more agility into our Product Management process in 2023. This blog post describes what we have planned for the start of the year. It also describes how we want to work over the whole year, and how you can help us make good choices. We are starting the year with features that open new paths to us. Your input will help us choose how we move down them. Our roundup of 2022 noted that we have some big things planned for the start of 2023. The two biggest are two new objects. We deployed the first in our January release. The new carrier object is a way for providers of high capacity links to show which interconnection facilities they are in. We\u2019ve deployed the minimal possible structure for this new object. We want users to tell us what additional features they cannot do without. The next big new addition is a campus object. This will be a way for interconnection facilities to show that inter-building cross-connects are available with the same ease as those within a building. This will help buyers understand when they don't need to be in the same building as something they want to connect to. We can expand either or both of these objects. We need your feedback to help us decide what would make them more valuable. Respondents to our annual surveys have consistently told us that Network Configuration Data is what they value most. They are also quite divided about the website design. Some people love its simplicity and others want something more modern. We knew that we didn't have enough information to make good decisions on how to improve things for the people who want change without disappointing those who like it the way it is. We have deployed Google Analytics for beta.peeringdb.com and would like to deploy it to www.peeringdb.com and docs.peeringdb.com . This will give us important information about how people use our site. We\u2019ll use this information to understand the problems people experience and develop ways to solve them. We also have lots of users who rely on our API or a local cache of PeeringDB data. So, we want to make it easier for users to identify the deltas between what they have in PeeringDB and their local configuration management. This is the focus on the projects we're taking to the NANOG 87 Hackathon . We want to work with tool developers and anyone who relies on PeeringDB as a source of network configuration data. Ultimately, we'd like to offer a way for users to automatically identify deltas, the changes that could be made, and ways to make or approve those changes. Across the rest of the year, we'd like to focus on one theme at a time and deliver a set of significant improvements there. Then we can move on to the next relevant theme. So please let us know how we could make PeeringDB more valuable for your organization. As always, you can submit an issue, or comment on existing issues in GitHub . But you can also send us email or chat to us at various community events. PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB's Product Roadmap for 2023"},{"location":"blog/peeringdb_in_your_preferred_language/","text":"PeeringDB in Your Preferred Language Volunteers translate PeeringDB into 17 different languages . Some of those translations, like Romanian, are complete. Others, like Indonesian, have only just started. Translation is important in making PeeringDB accessible to people around the world. But until now, you had to create an account \u2013 using the English language interface \u2013 to set your preferred language. We realized that this was not a perfect solution. We are grateful to Daniel Van Allen of Google. He developed the code to make translations available to anonymous web users. Now, you can land on the homepage and select the language you want to use from the dropdown menu. We hope that this will make PeeringDB accessible to more users. We also hope it will inspire people to volunteer to translate PeeringDB. If you want to volunteer, you can contact us . If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB in Your Preferred Language"},{"location":"blog/peeringdb_in_your_preferred_language/#peeringdb-in-your-preferred-language","text":"Volunteers translate PeeringDB into 17 different languages . Some of those translations, like Romanian, are complete. Others, like Indonesian, have only just started. Translation is important in making PeeringDB accessible to people around the world. But until now, you had to create an account \u2013 using the English language interface \u2013 to set your preferred language. We realized that this was not a perfect solution. We are grateful to Daniel Van Allen of Google. He developed the code to make translations available to anonymous web users. Now, you can land on the homepage and select the language you want to use from the dropdown menu. We hope that this will make PeeringDB accessible to more users. We also hope it will inspire people to volunteer to translate PeeringDB. If you want to volunteer, you can contact us . If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB in Your Preferred Language"},{"location":"blog/peeringdb_is_developed_by_its_community/","text":"PeeringDB is Developed by its Community PeeringDB community members have contributed two significant improvements that were deployed into production this month. Simple Search is Smarter Search As reported by NANOG last week, we have deployed code developed by Brad Schwyzer, James Lamanna, and Jeff Kala that significantly improves the accuracy of what we call Simple Search. This is the main search box on the front page or the basic API call. Until this month it provided an enthusiastic number of responses when searching for things like small AS Numbers. While the answers weren\u2019t wrong, our users needed to pay extra attention to find what they needed. Brad, James, and Jeff developed logic to work out what users are likely to be searching for and give them the most relevant results. Simple Search now knows about the difference between an AS Number, an IPv4 address, and an IPv6 address. It will only respond with IP address information if at least two segments of the address are included in the search. They turned this: Into this: We are grateful to them and to NANOG, who hosted the Hackathon where this code was developed. We are keen to participate in more Hackathons in the future. OpenID Connect We also deployed code developed by Carlos Aguado to implement OpenID Connect . This builds on our existing support for OAuth to enable identity federation with managed services. The code Carlos developed means that PeeringDB can be used as an OpenID Authorization Server so that any PeeringDB user can sign in to other websites. Your Code If you are a software developer who needs something from PeeringDB we might be able to deploy code you develop. We have a tested development environment and are keen to make PeeringDB service the interconnection community\u2019s needs. So please create an issue on GitHub or let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB is Developed by its Community"},{"location":"blog/peeringdb_is_developed_by_its_community/#peeringdb-is-developed-by-its-community","text":"PeeringDB community members have contributed two significant improvements that were deployed into production this month.","title":"PeeringDB is Developed by its Community"},{"location":"blog/peeringdb_is_developed_by_its_community/#simple-search-is-smarter-search","text":"As reported by NANOG last week, we have deployed code developed by Brad Schwyzer, James Lamanna, and Jeff Kala that significantly improves the accuracy of what we call Simple Search. This is the main search box on the front page or the basic API call. Until this month it provided an enthusiastic number of responses when searching for things like small AS Numbers. While the answers weren\u2019t wrong, our users needed to pay extra attention to find what they needed. Brad, James, and Jeff developed logic to work out what users are likely to be searching for and give them the most relevant results. Simple Search now knows about the difference between an AS Number, an IPv4 address, and an IPv6 address. It will only respond with IP address information if at least two segments of the address are included in the search. They turned this: Into this: We are grateful to them and to NANOG, who hosted the Hackathon where this code was developed. We are keen to participate in more Hackathons in the future.","title":"Simple Search is Smarter Search"},{"location":"blog/peeringdb_is_developed_by_its_community/#openid-connect","text":"We also deployed code developed by Carlos Aguado to implement OpenID Connect . This builds on our existing support for OAuth to enable identity federation with managed services. The code Carlos developed means that PeeringDB can be used as an OpenID Authorization Server so that any PeeringDB user can sign in to other websites.","title":"OpenID Connect"},{"location":"blog/peeringdb_is_developed_by_its_community/#your-code","text":"If you are a software developer who needs something from PeeringDB we might be able to deploy code you develop. We have a tested development environment and are keen to make PeeringDB service the interconnection community\u2019s needs. So please create an issue on GitHub or let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Your Code"},{"location":"blog/peeringdb_map_with_kmz/","text":"See Locations in PeeringDB on a Map We're making it easier for you to see where facilities are. It\u2019s good to know how close facilities are to each other and anything else that\u2019s important to you, like who and what is present there. We have coordinates for every facility in PeeringDB. For instance, One Wilshire in Los Angeles is at 34.047942, -118.255564. When you click on the coordinates on our site, you go to a map view. But that just shows you that one facility. Anyone who wants could use our API to extract the coordinates for all facilities. They could then populate any map they want. But that can be hard to do from raw data. We now produce a .KMZ file every day. It's ideal if you want to populate a map or GIS tool with PeeringDB facility data. We have linked to the file from the footer of every page on the site. If you want fresh data on interconnection facilities around the world, grab a copy every day. If you want to explore a new area, grab a copy and open it in your favorite .KMZ viewer. We have ideas for ways to improve the visualization of data in PeeringDB. But we want your input to guide us. Let us know what's most important to you, or the problems you need to solve. Contact the Product Committee , share it on our low traffic mailing lists , or have a chat when you meet us at an event. Or create an issue describing your need on GitHub. If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"See Locations in PeeringDB on a Map"},{"location":"blog/peeringdb_map_with_kmz/#see-locations-in-peeringdb-on-a-map","text":"We're making it easier for you to see where facilities are. It\u2019s good to know how close facilities are to each other and anything else that\u2019s important to you, like who and what is present there. We have coordinates for every facility in PeeringDB. For instance, One Wilshire in Los Angeles is at 34.047942, -118.255564. When you click on the coordinates on our site, you go to a map view. But that just shows you that one facility. Anyone who wants could use our API to extract the coordinates for all facilities. They could then populate any map they want. But that can be hard to do from raw data. We now produce a .KMZ file every day. It's ideal if you want to populate a map or GIS tool with PeeringDB facility data. We have linked to the file from the footer of every page on the site. If you want fresh data on interconnection facilities around the world, grab a copy every day. If you want to explore a new area, grab a copy and open it in your favorite .KMZ viewer. We have ideas for ways to improve the visualization of data in PeeringDB. But we want your input to guide us. Let us know what's most important to you, or the problems you need to solve. Contact the Product Committee , share it on our low traffic mailing lists , or have a chat when you meet us at an event. Or create an issue describing your need on GitHub. If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"See Locations in PeeringDB on a Map"},{"location":"blog/peeringdb_release_v2.23.0/","text":"PeeringDB Release v2.23.0 PeeringDB is pleased to announce the release of v2.23.0. Summary release notes are published on the release notes page . This release includes a key feature that comes out of the Data Ownership Task Force , which was established to clarify who is authoritative for data about networks where multiple members participate, like IXPs. This change means that all networks will need to have a technical POC when they publish a connection to an exchange network. This change will help all the parties on the exchange resolve technical issues efficiently. It was proposed and discussed in GitHub issues #826 . Stefan Wahl, Senior Ambassador ECIX, Megaport, says: \"This new feature is a great improvement allowing users to correctly identify the authoritative contact of a network. I enjoyed collaborating with the PeeringDB Task Force on this project.\" If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB Release v2.23.0"},{"location":"blog/peeringdb_release_v2.23.0/#peeringdb-release-v2230","text":"PeeringDB is pleased to announce the release of v2.23.0. Summary release notes are published on the release notes page . This release includes a key feature that comes out of the Data Ownership Task Force , which was established to clarify who is authoritative for data about networks where multiple members participate, like IXPs. This change means that all networks will need to have a technical POC when they publish a connection to an exchange network. This change will help all the parties on the exchange resolve technical issues efficiently. It was proposed and discussed in GitHub issues #826 . Stefan Wahl, Senior Ambassador ECIX, Megaport, says: \"This new feature is a great improvement allowing users to correctly identify the authoritative contact of a network. I enjoyed collaborating with the PeeringDB Task Force on this project.\" If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB Release v2.23.0"},{"location":"blog/peeringdb_release_v2.24.0/","text":"PeeringDB Release v2.24.0 PeeringDB is pleased to announce the release of v2.24.0. Summary release notes are published on the release notes page . This release focuses on improving data quality in the database by improving the way networks can identify themselves and making the user interface clearer where people misunderstood what was meant. Specialist networks can now identify themselves better. Governments, Route Collectors and organizations providing specialized Network Services, such as DNS, RDAP, or DDoS Protection can say so in their network type. We have cleaned up the data to reflect this for existing networks. Some users misunderstood the maximum prefix limit to mean the maximum prefix length. The tooltip now makes it clear that this refers to the maximum number of prefixes and not the prefix length. While our anonymous 2020 User Satisfaction Survey is still open, we can already see that we\u2019ll need to make more improvements along these lines. If you have not yet completed the survey, please do. It takes under three minutes and will help us build our product roadmap for the next year. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB Release v2.24.0"},{"location":"blog/peeringdb_release_v2.24.0/#peeringdb-release-v2240","text":"PeeringDB is pleased to announce the release of v2.24.0. Summary release notes are published on the release notes page . This release focuses on improving data quality in the database by improving the way networks can identify themselves and making the user interface clearer where people misunderstood what was meant. Specialist networks can now identify themselves better. Governments, Route Collectors and organizations providing specialized Network Services, such as DNS, RDAP, or DDoS Protection can say so in their network type. We have cleaned up the data to reflect this for existing networks. Some users misunderstood the maximum prefix limit to mean the maximum prefix length. The tooltip now makes it clear that this refers to the maximum number of prefixes and not the prefix length. While our anonymous 2020 User Satisfaction Survey is still open, we can already see that we\u2019ll need to make more improvements along these lines. If you have not yet completed the survey, please do. It takes under three minutes and will help us build our product roadmap for the next year. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB Release v2.24.0"},{"location":"blog/search_gets_better/","text":"Search Gets Better Users tell us that search and the quality of the data in PeeringDB are their two top priorities. We've previously written about using automation to improve data quality. We're now beta testing some improvements to search. You can test our new search interface now on beta.peeringdb.com . You can use natural language words, like \"near\" and \"in\", when you query PeeringDB. That means you're not forced to use the radius feature in Advanced Search. Martin Levy gave a use case when he opened issue #479 . The radius search improved things. This is a further improvement. In any of the countries where we\u2019ve normalized address data, you can search using a state name or its abbreviation. \" In my retirement, I finally had the time to visit and enjoy Montana. It's a wonderful state replete with interesting wildlife and absolutely-stunning landscapes. The fact that you can now find an IXP in Montana with an easy search on PeeringDB's website makes me very happy. I don't think I need to do that search anymore; however, I'm glad others active in the industry can now do that style of search. I wish PeeringDB and the whole industry all the best! I'm happy that my April 2019 issue on GitHub (You can\u2019t find an IXP in Montana; but you should be able to!) is now banished into the history books! \" Martin Levy When you search for facilities near New York, you\u2019ll get results for relevant locations in nearby New Jersey, just across the river. Similarly, searches for facilities near Los Angeles will extend south into Orange County. None of this takes away the Advanced Search tools . They are staying. But you can now find out about the scale of opportunities in a new area nice and quickly. As our first image shows, we\u2019re testing this new interface side-by-side with the old one. We\u2019d like you to try it and tell us what you think. There\u2019s a link to a feedback form at the top of the page. Please tell us what you like, what you'd like improved, or where our new search tool doesn't work properly. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Search Gets Better"},{"location":"blog/search_gets_better/#search-gets-better","text":"Users tell us that search and the quality of the data in PeeringDB are their two top priorities. We've previously written about using automation to improve data quality. We're now beta testing some improvements to search. You can test our new search interface now on beta.peeringdb.com . You can use natural language words, like \"near\" and \"in\", when you query PeeringDB. That means you're not forced to use the radius feature in Advanced Search. Martin Levy gave a use case when he opened issue #479 . The radius search improved things. This is a further improvement. In any of the countries where we\u2019ve normalized address data, you can search using a state name or its abbreviation. \" In my retirement, I finally had the time to visit and enjoy Montana. It's a wonderful state replete with interesting wildlife and absolutely-stunning landscapes. The fact that you can now find an IXP in Montana with an easy search on PeeringDB's website makes me very happy. I don't think I need to do that search anymore; however, I'm glad others active in the industry can now do that style of search. I wish PeeringDB and the whole industry all the best! I'm happy that my April 2019 issue on GitHub (You can\u2019t find an IXP in Montana; but you should be able to!) is now banished into the history books! \" Martin Levy When you search for facilities near New York, you\u2019ll get results for relevant locations in nearby New Jersey, just across the river. Similarly, searches for facilities near Los Angeles will extend south into Orange County. None of this takes away the Advanced Search tools . They are staying. But you can now find out about the scale of opportunities in a new area nice and quickly. As our first image shows, we\u2019re testing this new interface side-by-side with the old one. We\u2019d like you to try it and tell us what you think. There\u2019s a link to a feedback form at the top of the page. Please tell us what you like, what you'd like improved, or where our new search tool doesn't work properly. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Search Gets Better"},{"location":"blog/structured_data_and_more/","text":"Structured Data and More With PeeringDB This article describes our latest improvements and puts them in the context of recent feature developments. PeeringDB users have told us that their top priorities are data quality and search. These priorities have guided recent improvements. We want to make it easier to keep PeeringDB current. We want users to be able to analyze data. And we want to make the data available to users in the way that works best for them. Our API has enabled you to automate updates and get data in structured formats. And peeringdb-py , our local cache, lets you keep a local copy of our data. That makes it easy to keep queries local and integrate PeeringDB with other data sources. But we've been working to add key features for web users. Your internal source of truth can suggest updates to PeeringDB . Once you set that up, you can review and approve or deny suggestions. You can get PeeringDB data about facilities as a .KMZ file as well as CSV or JSON. So you can import it into Google Earth and other GIS tools. Simple search understands a wide range of geographic terms. For instance, you can just search for an ix in berlin or a fac in ke . Yes, PeeringDB understands ISO 3166-2 country codes. And now you can export data from any page. Of course, you could always copy and paste. But copying and pasting the list of peers at IX.br (PTT.br) S\u00e3o Paulo is a big job. Grabbing its data as a CSV or JSON removes copy/paste errors. You can import it straight into a business analytics engine.x Of course, it\u2019s not all feature changes. We know that we need to update the web design, too. We have a preview of the design available for you to look at and comment on: https://preview.beta.peeringdb.com Take a look and tell us what you like and what needs to be updated before we deploy this into production. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Structured Data and More With PeeringDB"},{"location":"blog/structured_data_and_more/#structured-data-and-more-with-peeringdb","text":"This article describes our latest improvements and puts them in the context of recent feature developments. PeeringDB users have told us that their top priorities are data quality and search. These priorities have guided recent improvements. We want to make it easier to keep PeeringDB current. We want users to be able to analyze data. And we want to make the data available to users in the way that works best for them. Our API has enabled you to automate updates and get data in structured formats. And peeringdb-py , our local cache, lets you keep a local copy of our data. That makes it easy to keep queries local and integrate PeeringDB with other data sources. But we've been working to add key features for web users. Your internal source of truth can suggest updates to PeeringDB . Once you set that up, you can review and approve or deny suggestions. You can get PeeringDB data about facilities as a .KMZ file as well as CSV or JSON. So you can import it into Google Earth and other GIS tools. Simple search understands a wide range of geographic terms. For instance, you can just search for an ix in berlin or a fac in ke . Yes, PeeringDB understands ISO 3166-2 country codes. And now you can export data from any page. Of course, you could always copy and paste. But copying and pasting the list of peers at IX.br (PTT.br) S\u00e3o Paulo is a big job. Grabbing its data as a CSV or JSON removes copy/paste errors. You can import it straight into a business analytics engine.x Of course, it\u2019s not all feature changes. We know that we need to update the web design, too. We have a preview of the design available for you to look at and comment on: https://preview.beta.peeringdb.com Take a look and tell us what you like and what needs to be updated before we deploy this into production. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Structured Data and More With PeeringDB"},{"location":"blog/u2f_and_url/","text":"Improve Your Account Security - And Check Our URL We completed our support for FIDO U2F hardware tokens this month and have made www.peeringdb.com the canonical URL for our service. We\u2019d like you to take advantage of two-factor security for your PeeringDB account. We also want to ensure you adjust any automation aimed at https://peeringdb.com so that it connects to https://www.peeringdb.com instead. This will ensure continuity of service for API users. Your listing in PeeringDB is how you present your network, IXP, or facility to the world. If a miscreant gains access to your account they can misrepresent you. Reclaiming control of the objects you look after and undoing any changes the miscreant has made could be a lot of work. You can protect yourself against this risk by enabling two-factor authentication on your account. We have supported industry standard Time-based One-Time Passwords, as defined in RFC 6238 for a while now. This is the protocol used by popular smartphone authenticator apps. We added support for FIDO U2F hardware tokens in Q1 2022. You enable 2FA in the Account Security section of your account settings. Click on the green button to Manage Two-Factor Authentication and you\u2019ll be guided through the process. Just be aware that you\u2019ll need a secure place to store your backup codes, so you can gain access to your account if you ever lose access to your authenticator app or U2F hardware token. What are you waiting for? Improve the protection for your organization\u2019s listing in PeeringDB today by enabling 2FA. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Improve Your Account Security - And Check Our URL"},{"location":"blog/u2f_and_url/#improve-your-account-security-and-check-our-url","text":"We completed our support for FIDO U2F hardware tokens this month and have made www.peeringdb.com the canonical URL for our service. We\u2019d like you to take advantage of two-factor security for your PeeringDB account. We also want to ensure you adjust any automation aimed at https://peeringdb.com so that it connects to https://www.peeringdb.com instead. This will ensure continuity of service for API users. Your listing in PeeringDB is how you present your network, IXP, or facility to the world. If a miscreant gains access to your account they can misrepresent you. Reclaiming control of the objects you look after and undoing any changes the miscreant has made could be a lot of work. You can protect yourself against this risk by enabling two-factor authentication on your account. We have supported industry standard Time-based One-Time Passwords, as defined in RFC 6238 for a while now. This is the protocol used by popular smartphone authenticator apps. We added support for FIDO U2F hardware tokens in Q1 2022. You enable 2FA in the Account Security section of your account settings. Click on the green button to Manage Two-Factor Authentication and you\u2019ll be guided through the process. Just be aware that you\u2019ll need a secure place to store your backup codes, so you can gain access to your account if you ever lose access to your authenticator app or U2F hardware token. What are you waiting for? Improve the protection for your organization\u2019s listing in PeeringDB today by enabling 2FA. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Improve Your Account Security - And Check Our URL"},{"location":"blog/updates_from_an_internal_source_of_truth/","text":"Your Internal Source of Truth Can Now Push Updates to PeeringDB We have an API . You can use our API to update PeeringDB as well as make queries. But most people don't want to hand craft API updates. Very few organizations have the scale that demands automating updates. Until now, that left a gap. If your network connects at many facilities and IXPs, there might be a gap between a change happening and appearing in PeeringDB. Our users value the quality of configuration data in PeeringDB, so we wanted to fill that gap. We used the NANOG 87 Hackathon as an opportunity to test a proof of concept. It went well, so we've put it into production. Your internal source of truth can now suggest updates to PeeringDB. You then log in to our web interface and approve or reject those changes. FullCtl, who participated in the Hackathon challenge , has already implemented support for this new feature. This new feature means you can have automation monitor the gap between your internal source of truth and PeeringDB. And you don't need to give that tool credentials to push updates to PeeringDB. Benefits include: Simplified user interface for changes Human oversight Third party tools do not need to be given credentials with write permission \" It's great when you see a project that's become as important and successful as PeeringDB continue to innovate and improve. We're super stoked to be the first of what I'm sure will be many apps to support this new feature - which is sure to increase the already amazing amount of high quality interconnection data available in PeeringDB, supporting global interconnection. \" Chris Grundemann, Co-Founder & CEO, FullCtl We\u2019d love to see more updates coming in from more sources of truth! If you have suggestions, contact the Product Committee , share them on our low traffic mailing lists , or have a chat when you meet us at an event. Or create an issue describing your need on GitHub. If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Your Internal Source of Truth Can Now Push Updates to PeeringDB"},{"location":"blog/updates_from_an_internal_source_of_truth/#your-internal-source-of-truth-can-now-push-updates-to-peeringdb","text":"We have an API . You can use our API to update PeeringDB as well as make queries. But most people don't want to hand craft API updates. Very few organizations have the scale that demands automating updates. Until now, that left a gap. If your network connects at many facilities and IXPs, there might be a gap between a change happening and appearing in PeeringDB. Our users value the quality of configuration data in PeeringDB, so we wanted to fill that gap. We used the NANOG 87 Hackathon as an opportunity to test a proof of concept. It went well, so we've put it into production. Your internal source of truth can now suggest updates to PeeringDB. You then log in to our web interface and approve or reject those changes. FullCtl, who participated in the Hackathon challenge , has already implemented support for this new feature. This new feature means you can have automation monitor the gap between your internal source of truth and PeeringDB. And you don't need to give that tool credentials to push updates to PeeringDB. Benefits include: Simplified user interface for changes Human oversight Third party tools do not need to be given credentials with write permission \" It's great when you see a project that's become as important and successful as PeeringDB continue to innovate and improve. We're super stoked to be the first of what I'm sure will be many apps to support this new feature - which is sure to increase the already amazing amount of high quality interconnection data available in PeeringDB, supporting global interconnection. \" Chris Grundemann, Co-Founder & CEO, FullCtl We\u2019d love to see more updates coming in from more sources of truth! If you have suggestions, contact the Product Committee , share them on our low traffic mailing lists , or have a chat when you meet us at an event. Or create an issue describing your need on GitHub. If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Your Internal Source of Truth Can Now Push Updates to PeeringDB"},{"location":"blog/updating_our_webUI/","text":"We're Updating our Web UI PeeringDB users have told us that they both love the simplicity of our web UI but want it improved. We have started on a project to update it. We must update it to fully integrate the new carrier and campus objects. Carrier objects describe providers of high capacity L1 and L2 links into facilities. A campus is a group of interconnected facilities under common ownership. Our priorities are: Improve tabular data available for Campus and Carrier pages Mobile UI optimization Personalization features for logged in users Visualization of metro areas in a dynamic map Wizard framework for supporting creation and editing of objects Lazy loading of object data We'll start with ways to make it easier for users to get the data they want and need. Then we'll look at making it easier for users to update their own data in PeeringDB. We'll share some of the design options to check they meet users\u2019 needs. Watch out for future announcements, so you can give us feedback. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"We're Updating our Web UI"},{"location":"blog/updating_our_webUI/#were-updating-our-web-ui","text":"PeeringDB users have told us that they both love the simplicity of our web UI but want it improved. We have started on a project to update it. We must update it to fully integrate the new carrier and campus objects. Carrier objects describe providers of high capacity L1 and L2 links into facilities. A campus is a group of interconnected facilities under common ownership. Our priorities are: Improve tabular data available for Campus and Carrier pages Mobile UI optimization Personalization features for logged in users Visualization of metro areas in a dynamic map Wizard framework for supporting creation and editing of objects Lazy loading of object data We'll start with ways to make it easier for users to get the data they want and need. Then we'll look at making it easier for users to update their own data in PeeringDB. We'll share some of the design options to check they meet users\u2019 needs. Watch out for future announcements, so you can give us feedback. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"We're Updating our Web UI"},{"location":"blog/user_developed_tools/","text":"Getting the Most from PeeringDB with User Developed Tools We develop PeeringDB based on user demand. Users tell us what they want through a survey and by opening issues describing the problems they face on GitHub. But sometimes, users\u2019 needs go beyond what we can do and that\u2019s when user developed tools come in. We have recently refreshed and updated our listing of user developed and maintained tools . It now has its own page and features eight tools that help you: Sync PeeringDB data to a local repository Find common peering points Find and manage peers, and Use PeeringDB from the search bar on your browser \u201c I'm glad to see Peering Manager listed on PeeringDB's new tools page. PeeringDB's API and data are a huge asset to Peering Manager, helping users to autofill and keep up-to-date a lot of details. Accessing the API is both simple and reliable, keeping development simple. \u201d Guillaume Mazoyer, developer of Peering Manager If you develop a tool that uses PeeringDB and would like to share it with others, please let us know and we\u2019ll link to it from our tools page, so other people can thank you for sharing. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Getting the Most from PeeringDB with User Developed Tools"},{"location":"blog/user_developed_tools/#getting-the-most-from-peeringdb-with-user-developed-tools","text":"We develop PeeringDB based on user demand. Users tell us what they want through a survey and by opening issues describing the problems they face on GitHub. But sometimes, users\u2019 needs go beyond what we can do and that\u2019s when user developed tools come in. We have recently refreshed and updated our listing of user developed and maintained tools . It now has its own page and features eight tools that help you: Sync PeeringDB data to a local repository Find common peering points Find and manage peers, and Use PeeringDB from the search bar on your browser \u201c I'm glad to see Peering Manager listed on PeeringDB's new tools page. PeeringDB's API and data are a huge asset to Peering Manager, helping users to autofill and keep up-to-date a lot of details. Accessing the API is both simple and reliable, keeping development simple. \u201d Guillaume Mazoyer, developer of Peering Manager If you develop a tool that uses PeeringDB and would like to share it with others, please let us know and we\u2019ll link to it from our tools page, so other people can thank you for sharing. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Getting the Most from PeeringDB with User Developed Tools"},{"location":"blog/user_suggestions_improve_PeeringDB_usability/","text":"User Suggestions Improve PeeringDB Usability Some people are heavy PeeringDB users. They research and compare options, with many PeeringDB tabs open at once. But finding the PeeringDB tab you want meant looking at each one. But no more. Marco d'Itri wrote to the Product Committee and suggested an improvement: I believe that it would be great to have the HTML <title> tag of the pages show more that just \"PeeringDB\", e.g. \"PeeringDB: AS65454\". This simple change would allow to find previously visited pages in the browser history and search box. We deployed this feature in our March release . Each page now has its key feature set as a search term. That's the AS Number for networks, or the name elsewhere. We set the whole search string as the page title for advanced searches. We hope this improves your PeeringDB web experience. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"User Suggestions Improve PeeringDB Usability"},{"location":"blog/user_suggestions_improve_PeeringDB_usability/#user-suggestions-improve-peeringdb-usability","text":"Some people are heavy PeeringDB users. They research and compare options, with many PeeringDB tabs open at once. But finding the PeeringDB tab you want meant looking at each one. But no more. Marco d'Itri wrote to the Product Committee and suggested an improvement: I believe that it would be great to have the HTML <title> tag of the pages show more that just \"PeeringDB\", e.g. \"PeeringDB: AS65454\". This simple change would allow to find previously visited pages in the browser history and search box. We deployed this feature in our March release . Each page now has its key feature set as a search term. That's the AS Number for networks, or the name elsewhere. We set the whole search string as the page title for advanced searches. We hope this improves your PeeringDB web experience. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"User Suggestions Improve PeeringDB Usability"},{"location":"blog/what_happened_to_our_web_ui/","text":"What happened to our web UI? We released 2.54.0 to production on 24 January 2024. PeeringDB users quickly made us aware of issues with the release. The problems centered on the impact of web UI changes on search: Users needed to click on the magnifying glass icon to open the search bar Some in page searches resulted in a CSRF error Other search attempts did not work We focused on four issues describing problems and developed fixes that addressed them in development and then beta environments. Ultimately, we decided that it was better to rollback the UI changes, so that\u2019s what we did. 2.54.2 is now in production. It has all the features from 2.54.0 except the web UI changes. Why did it happen? Our own internal testing missed the impact of these changes. We thought they were relatively small and planned to make an incremental improvement before introducing our updated design on preview.peeringdb.com . That was a mistake. Also, we\u2019ve had a remarkably good run of stable releases. We think this has contributed to a drop in testing on beta.peeringdb.com . Only about 0.25 percent of users visited beta.peeringdb.com in January 2024. How will we improve? We will be changing our process for introducing big changes. The first part is to improve our internal testing process. But we are also considering changes to the beta testing process. Instead of relying on users to speak up if they find a problem on beta.peeringdb.com we could do the reverse. We would only release major changes to production after we have had positive comments from users who have tested on beta.peeringdb.com . In some cases, we might need to delay a release \u2013 or part of it \u2013 until we had that positive input from users. What do you think? Would you prefer us to require more active involvement from users in beta testing? Let us know on our user-discuss mailing list , through our social media channels, or speak with our volunteers to share your thoughts. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"What happened to our web UI?"},{"location":"blog/what_happened_to_our_web_ui/#what-happened-to-our-web-ui","text":"We released 2.54.0 to production on 24 January 2024. PeeringDB users quickly made us aware of issues with the release. The problems centered on the impact of web UI changes on search: Users needed to click on the magnifying glass icon to open the search bar Some in page searches resulted in a CSRF error Other search attempts did not work We focused on four issues describing problems and developed fixes that addressed them in development and then beta environments. Ultimately, we decided that it was better to rollback the UI changes, so that\u2019s what we did. 2.54.2 is now in production. It has all the features from 2.54.0 except the web UI changes.","title":"What happened to our web UI?"},{"location":"blog/what_happened_to_our_web_ui/#why-did-it-happen","text":"Our own internal testing missed the impact of these changes. We thought they were relatively small and planned to make an incremental improvement before introducing our updated design on preview.peeringdb.com . That was a mistake. Also, we\u2019ve had a remarkably good run of stable releases. We think this has contributed to a drop in testing on beta.peeringdb.com . Only about 0.25 percent of users visited beta.peeringdb.com in January 2024.","title":"Why did it happen?"},{"location":"blog/what_happened_to_our_web_ui/#how-will-we-improve","text":"We will be changing our process for introducing big changes. The first part is to improve our internal testing process. But we are also considering changes to the beta testing process. Instead of relying on users to speak up if they find a problem on beta.peeringdb.com we could do the reverse. We would only release major changes to production after we have had positive comments from users who have tested on beta.peeringdb.com . In some cases, we might need to delay a release \u2013 or part of it \u2013 until we had that positive input from users. What do you think? Would you prefer us to require more active involvement from users in beta testing? Let us know on our user-discuss mailing list , through our social media channels, or speak with our volunteers to share your thoughts. If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"How will we improve?"},{"location":"blog/whois_to_close/","text":"PeeringDB Whois Service to Close We will close down the whois.peeringdb.com service at the end of January 2024. The PeeringDB whois service is a relic of PeeringDB v1, where there was no API to query the database. PeeringDB v2 can be queried and updated through our API as well as the web. The whois service is just another way to get data from our API that is less supported and infrequently used. Keeping the service incurs a maintenance cost. We believe that closing the service is the best use of PeeringDB resources. User comments are welcome on the user-discuss list , or direct to the Product Committee . If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB Whois Service to Close"},{"location":"blog/whois_to_close/#peeringdb-whois-service-to-close","text":"We will close down the whois.peeringdb.com service at the end of January 2024. The PeeringDB whois service is a relic of PeeringDB v1, where there was no API to query the database. PeeringDB v2 can be queried and updated through our API as well as the web. The whois service is just another way to get data from our API that is less supported and infrequently used. Keeping the service incurs a maintenance cost. We believe that closing the service is the best use of PeeringDB resources. User comments are welcome on the user-discuss list , or direct to the Product Committee . If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"PeeringDB Whois Service to Close"},{"location":"blog/your_logo_goes_here/","text":"Your Logo Goes Here! We\u2019ve just deployed 2.31.0-beta and it\u2019s an opportunity to test out how your logo will look alongside your organization\u2019s name. Make sure you have your logo ready. Logos can have a height of up to 75 pixels and a width of up to 150. They must be uploaded in JPG, JPEG, or PNG. Log in to beta.peeringdb.com , upload your logo and check that it shows up well. This release didn\u2019t just add one feature. We have also made improvements for search, ix\u2019s, and facilities. Facilities can now specify a continental region, so searchers don\u2019t need to specify countries one at a time on the advanced search page. We added dynamic summaries and facilities. ASNs are now displayed at the top of search results for numeric queries. Sales contacts can now be added to IX objects If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Your Logo Goes Here!"},{"location":"blog/your_logo_goes_here/#your-logo-goes-here","text":"We\u2019ve just deployed 2.31.0-beta and it\u2019s an opportunity to test out how your logo will look alongside your organization\u2019s name. Make sure you have your logo ready. Logos can have a height of up to 75 pixels and a width of up to 150. They must be uploaded in JPG, JPEG, or PNG. Log in to beta.peeringdb.com , upload your logo and check that it shows up well. This release didn\u2019t just add one feature. We have also made improvements for search, ix\u2019s, and facilities. Facilities can now specify a continental region, so searchers don\u2019t need to specify countries one at a time on the advanced search page. We added dynamic summaries and facilities. ASNs are now displayed at the top of search results for numeric queries. Sales contacts can now be added to IX objects If you have an idea to improve PeeringDB you can share it on our low traffic mailing lists or create an issue directly on GitHub . If you find a data quality issue, please let us know at support@peeringdb.com . PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.","title":"Your Logo Goes Here!"},{"location":"committee/common/","text":"PeeringDB Common Committee Charter Provisions: Dispute resolution If the committee handles an issue in a manner in which a user believes that their view has not been adequately considered, their first action should be to raise the concern with the Committee Chair for further consideration. If the dispute is between the user and the Committee Chair then the issue may alternatively be raised with the Committee Vice Chair. If the dispute cannot be resolved the matter may be brought forward to the PeeringDB Board. The decision by the PeeringDB Board shall be final. Committee Chair and Vice Chair The committee elects their Chair and Vice Chair from among their members, subject to PeeringDB Board approval. The Chair and Vice Chair work as a team and distribute the workload between themselves as they deem appropriate. Decisions should be unanimous, however the final decision on any matter is with the Chair. In case the Chair becomes unavailable, the Vice Chair may assume the position of Acting Chair. If the Chair or Vice Chair become permanently unavailable, replacement(s) are elected from the remaining committee members, subject to PeeringDB Board approval.","title":"Common"},{"location":"committee/common/#dispute-resolution","text":"If the committee handles an issue in a manner in which a user believes that their view has not been adequately considered, their first action should be to raise the concern with the Committee Chair for further consideration. If the dispute is between the user and the Committee Chair then the issue may alternatively be raised with the Committee Vice Chair. If the dispute cannot be resolved the matter may be brought forward to the PeeringDB Board. The decision by the PeeringDB Board shall be final.","title":"Dispute resolution"},{"location":"committee/common/#committee-chair-and-vice-chair","text":"The committee elects their Chair and Vice Chair from among their members, subject to PeeringDB Board approval. The Chair and Vice Chair work as a team and distribute the workload between themselves as they deem appropriate. Decisions should be unanimous, however the final decision on any matter is with the Chair. In case the Chair becomes unavailable, the Vice Chair may assume the position of Acting Chair. If the Chair or Vice Chair become permanently unavailable, replacement(s) are elected from the remaining committee members, subject to PeeringDB Board approval.","title":"Committee Chair and Vice Chair"},{"location":"committee/admin/","text":"PeeringDB Admin Committee Purpose is to oversee the administrator mission and volunteers. Interested in volunteering? Contact admincom@lists.peeringdb.com . Documentation Admin Committee Guidelines and Criteria for Approving Networks, IXPs, and Facilities PeeringDB Admin Committee Charter Approved by Board July 9th, 2020 Scope The PeeringDB Admin Committee (AC) is responsible for the day to day end-user support of PeeringDB. The Admin Committee functions as the first point of contact for any inquiries to PeeringDB. The Admin Committee produces definitions for enhancements to the workflow and Admin GUI and works with the Product Committee to plan a coherent roadmap for the PeeringDB software. Out of scope Work covered in the charter of the Operations, Outreach, Product, and further to be established Committees Deliverables Take care of support tickets, the Admin Committee strives to answer tickets within 24 hours Gather input from end-users regarding the improvement of PeeringDB in terms of bugs and product features and channel them towards the Product Committee via GitHub Improve PeeringDB Admin GUI to help expedient resolution of support tickets Collaboration The Admin Committee works with other PeeringDB committees to ensure an equitable division of development resources in recognition of the volunteer efforts that are ensuring the daily operations. Participation The PeeringDB Admin Committee members serve a one-year renewable term. Volunteers can submit their candidacy to the Admin Committee Chair. The Chair and Vice Chair will choose a new Admin Committee member at any time they see the necessity to ensure the continuity of the Admin Committee. There is a trial period of one month. New members are onboarded by a more experienced committee member (WebEx / Google Hangouts / 3 example tickets). After the trial period appointment is confirmed by the Chair and Vice Chair for one year. Expectations Individual committee members should do their fair share of tickets measured over a month If a committee member is away for an extended period of time, inform the Chair, Vice Chair, and a notification sent to the Admin Committee mailing list One month probation where they get taught/mentored by an experienced admin, and where if they do not do the work, they get booted Chairs perform a quarterly review. If you don't meet a fair portion of the work you'll be nudged. Also, three months of inactivity is an automatic ejection Communication Questions and suggestions for the Admin Committee can be sent to the Admincom Mailing List On- and de-boarding is handled via the Admincom GitHub All other issues, also for Admin GUI bugs and features must go to the regular GitHub Any support questions should be directed to the Support Address Admin Committee uses slack and emails for internal communication Regular (4-6 week interval) conference calls are used to stay synced and discuss issues Decision policy Admin Committee members will decide on their own when handling support tickets according to the Admin Committee BCP laid out in the Admin Committee How-To Folder. Otherwise, they will decide by simple majority vote on contested issues called by the Admin Committee Chair. If there is a tie the Chair's vote is counted double. Workflow Admincom uses DeskPRO and GitHub as well as direct communication with the main service contractor 20C to achieve its deliverables. In communicating with 3rd parties the Admin Committee should be kept in the loop if the issue is of general interest. PeeringDB Common Committee Charter Provisions: Dispute resolution If the committee handles an issue in a manner in which a user believes that their view has not been adequately considered, their first action should be to raise the concern with the Committee Chair for further consideration. If the dispute is between the user and the Committee Chair then the issue may alternatively be raised with the Committee Vice Chair. If the dispute cannot be resolved the matter may be brought forward to the PeeringDB Board. The decision by the PeeringDB Board shall be final. Committee Chair and Vice Chair The committee elects their Chair and Vice Chair from among their members, subject to PeeringDB Board approval. The Chair and Vice Chair work as a team and distribute the workload between themselves as they deem appropriate. Decisions should be unanimous, however the final decision on any matter is with the Chair. In case the Chair becomes unavailable, the Vice Chair may assume the position of Acting Chair. If the Chair or Vice Chair become permanently unavailable, replacement(s) are elected from the remaining committee members, subject to PeeringDB Board approval. Meeting notes June 23rd, 2020: Meeting Notes May 12th, 2020: Meeting Notes November 21st, 2019: Meeting Notes July 18th, 2019: Meeting Notes May 2nd, 2019: Meeting Notes Members Ankesh Anand Austin Brower John Brown Budiwijaya Shaun Coffey Ron Grant Chriztoffer Hansen - Chair Peter Helmenstine - Vice Chair Ga\u00ebl Hernandez Adam Korab Christopher Malayter - Board Liaison Aquinas Masakha Cris\u00f3stomo Mbundu Julimar Lunguinho Mendes Laura Yepes","title":"Admin Committee"},{"location":"committee/admin/#peeringdb-admin-committee","text":"Purpose is to oversee the administrator mission and volunteers. Interested in volunteering? Contact admincom@lists.peeringdb.com .","title":"PeeringDB Admin Committee"},{"location":"committee/admin/#documentation","text":"Admin Committee Guidelines and Criteria for Approving Networks, IXPs, and Facilities","title":"Documentation"},{"location":"committee/admin/#peeringdb-admin-committee-charter","text":"Approved by Board July 9th, 2020","title":"PeeringDB Admin Committee Charter"},{"location":"committee/admin/#scope","text":"The PeeringDB Admin Committee (AC) is responsible for the day to day end-user support of PeeringDB. The Admin Committee functions as the first point of contact for any inquiries to PeeringDB. The Admin Committee produces definitions for enhancements to the workflow and Admin GUI and works with the Product Committee to plan a coherent roadmap for the PeeringDB software.","title":"Scope"},{"location":"committee/admin/#out-of-scope","text":"Work covered in the charter of the Operations, Outreach, Product, and further to be established Committees","title":"Out of scope"},{"location":"committee/admin/#deliverables","text":"Take care of support tickets, the Admin Committee strives to answer tickets within 24 hours Gather input from end-users regarding the improvement of PeeringDB in terms of bugs and product features and channel them towards the Product Committee via GitHub Improve PeeringDB Admin GUI to help expedient resolution of support tickets","title":"Deliverables"},{"location":"committee/admin/#collaboration","text":"The Admin Committee works with other PeeringDB committees to ensure an equitable division of development resources in recognition of the volunteer efforts that are ensuring the daily operations.","title":"Collaboration"},{"location":"committee/admin/#participation","text":"The PeeringDB Admin Committee members serve a one-year renewable term. Volunteers can submit their candidacy to the Admin Committee Chair. The Chair and Vice Chair will choose a new Admin Committee member at any time they see the necessity to ensure the continuity of the Admin Committee. There is a trial period of one month. New members are onboarded by a more experienced committee member (WebEx / Google Hangouts / 3 example tickets). After the trial period appointment is confirmed by the Chair and Vice Chair for one year.","title":"Participation"},{"location":"committee/admin/#expectations","text":"Individual committee members should do their fair share of tickets measured over a month If a committee member is away for an extended period of time, inform the Chair, Vice Chair, and a notification sent to the Admin Committee mailing list One month probation where they get taught/mentored by an experienced admin, and where if they do not do the work, they get booted Chairs perform a quarterly review. If you don't meet a fair portion of the work you'll be nudged. Also, three months of inactivity is an automatic ejection","title":"Expectations"},{"location":"committee/admin/#communication","text":"Questions and suggestions for the Admin Committee can be sent to the Admincom Mailing List On- and de-boarding is handled via the Admincom GitHub All other issues, also for Admin GUI bugs and features must go to the regular GitHub Any support questions should be directed to the Support Address Admin Committee uses slack and emails for internal communication Regular (4-6 week interval) conference calls are used to stay synced and discuss issues","title":"Communication"},{"location":"committee/admin/#decision-policy","text":"Admin Committee members will decide on their own when handling support tickets according to the Admin Committee BCP laid out in the Admin Committee How-To Folder. Otherwise, they will decide by simple majority vote on contested issues called by the Admin Committee Chair. If there is a tie the Chair's vote is counted double.","title":"Decision policy"},{"location":"committee/admin/#workflow","text":"Admincom uses DeskPRO and GitHub as well as direct communication with the main service contractor 20C to achieve its deliverables. In communicating with 3rd parties the Admin Committee should be kept in the loop if the issue is of general interest. PeeringDB Common Committee Charter Provisions:","title":"Workflow"},{"location":"committee/admin/#dispute-resolution","text":"If the committee handles an issue in a manner in which a user believes that their view has not been adequately considered, their first action should be to raise the concern with the Committee Chair for further consideration. If the dispute is between the user and the Committee Chair then the issue may alternatively be raised with the Committee Vice Chair. If the dispute cannot be resolved the matter may be brought forward to the PeeringDB Board. The decision by the PeeringDB Board shall be final.","title":"Dispute resolution"},{"location":"committee/admin/#committee-chair-and-vice-chair","text":"The committee elects their Chair and Vice Chair from among their members, subject to PeeringDB Board approval. The Chair and Vice Chair work as a team and distribute the workload between themselves as they deem appropriate. Decisions should be unanimous, however the final decision on any matter is with the Chair. In case the Chair becomes unavailable, the Vice Chair may assume the position of Acting Chair. If the Chair or Vice Chair become permanently unavailable, replacement(s) are elected from the remaining committee members, subject to PeeringDB Board approval.","title":"Committee Chair and Vice Chair"},{"location":"committee/admin/#meeting-notes","text":"June 23rd, 2020: Meeting Notes May 12th, 2020: Meeting Notes November 21st, 2019: Meeting Notes July 18th, 2019: Meeting Notes May 2nd, 2019: Meeting Notes","title":"Meeting notes"},{"location":"committee/admin/#members","text":"Ankesh Anand Austin Brower John Brown Budiwijaya Shaun Coffey Ron Grant Chriztoffer Hansen - Chair Peter Helmenstine - Vice Chair Ga\u00ebl Hernandez Adam Korab Christopher Malayter - Board Liaison Aquinas Masakha Cris\u00f3stomo Mbundu Julimar Lunguinho Mendes Laura Yepes","title":"Members"},{"location":"committee/admin/approval-guidelines/","text":"Admin Committee Guidelines and Criteria for Approving Networks, IXPs, and Facilities Authors Chris Malayter Arnold Nipper Job Snijders Document history v1. Initial document. v2. Added multiple mechanisms to validate IXP and Network. v3. Added mechanism to validate facility. v4. Added draft flowcharts and placed explanatory text in an appendix. Minor readability revisions. Guideline goals This guide does not seek to define what an Internet Exchange, or Network operator, or Facility is. PeeringDB is a registry of information. What people do with the information is up to them. In these guidelines, we attempt to merely document PeeringDB\u2019s approval process. Key goals include: The Admin Committee can use multiple to validate and facilitate the creation of objects. Workflows are shown and always include the option to fall back to an exception process. This process brings more eyes and helps PeeringDB identify areas for improvement. Provide a few tangible examples of how to apply the guidelines. Definitions User - a person submitting a new object to the PeeringDB database RIR - A Regional Internet Registry (AFRINIC, APNIC, ARIN, LACNIC or the RIPE NCC) NIR - A National Internet Registry recognized by one of the RIRs Additional terminology is described in Section 4 of the PeeringDB Data Ownership Policy Document . Approving Network ( net ) objects The key to approving Network objects is to confirm the User has a relationship to the specified Autonomous System Number (ASN) and is authorized to represent that ASN in some form. PeeringDB follows industry best practices and has the following requirements for the Autonomous System numbers, regardless of who the User is: ASNs must be registered through an RIR or NIR The ASN must not already be registered in PeeringDB This means that \u201cPrivate\u201d ASNs, as listed in the IANA Autonomous System (AS) Numbers Registry or \u201cBogon\u201d ASNs, those which have not yet been assigned by an RIR or NIR, cannot be registered in PeeringDB. Flowchart There are various mechanisms to verify the relationship between the User and a given Autonomous System number: The registration details listed in WHOIS match the registration details in the sign-up request (same email domain) The registration details listed in RDAP match the registration details in the sign-up request (same email domain) The user can confirm the relationship to the ASN through a RPKI based challenge/response (work in progress: draft-ietf-sidrops-rpki-rsc) The user can confirm the relationship to the ASN by entering a PeeringDB suggested random string in their WHOIS record in a comments/remarks field (not yet implemented, a similar strategy to how Amazon AWS does BYOIP) Exception approval follows the standard process PeeringDB encourages but does not require its users to follow industry best practices. This means we recommend: Making a BGP looking glass publicly available, or A website listing the Network services, and a publicly documented Routing Policy Approving IXP ( ix ) objects The key to approving IXP objects is to confirm the User has a relationship to the specified Peering LAN Prefix, and is authorized to represent this IP block in some form. Flowchart Globally unique IP prefix requirements IP prefix must be registered through an RIR or NIR. The prefix must not overlap with any existing IXP object in PeeringDB IPv4 prefixes must not be longer than a /27 or shorter than /19 IPv6 prefixes must not be shorter than /64 but may be longer i.e. a /120 is allowed but a /63 is not Users can verify their relationship to an IP prefix in several ways: The registration details listed in WHOIS match the registration details in the sign-up request (same email domain). The registration details listed in RDAP match the registration details in the sign-up request (same email domain). The user can confirm the relationship to the IP prefix through a RPKI based challenge/response (work in progress - draft-ietf-sidrops-rpki-rsc). The user can confirm the relationship to the IP prefix by entering a PeeringDB suggested random string in their inetnum record in the authoritative RIR or NIR database in a comments/remarks field (note: IRR route/route6 objects cannot be used for this purpose). RDAP should be used to discover which RIR or NIR is authoritative For Legacy IPv4 space, a PeeringDB suggested random string can be placed in a TXT record for the reverse DNS label representing the first IPv4 address in the prefix. (This is a variant of the Amazon AWS BYOIP process). The assumption is that if someone controls Reverse DNS for a given prefix, they have full control over the prefix. Exception approval follows the standard process PeeringDB encourages but does not require its users to follow industry best practices. This means we recommend: A website detailing the IXP service A public overview of connected members and locations, service level, and terms of membership. Approving Facility ( fac ) objects A \u201cfacility\u201d is a physical location where two or more IP Networks or IXPs interconnect with each other. The key to approving Facility objects is to confirm with multiple existing PeeringDB users that a facility exists. Note: We will need to extend PeeringDB's software to support the workflow described here. Note: The IP addresses used in the attestation process will be logged. Validation mechanisms The owner of the facility is an existing PeeringDB user, and adds the facility to their record themselves. In this approval flow the facility is \u2018claimed\u2019. For this workflow the facility owner should already have one facility previously validated via one of the following mechanisms: The owner of the facility is not a PeeringDB user, but interested parties (who are PeeringDB users) wish the Facility object to be registered. The result is an unclaimed Facility object. The building has a website that has an interconnection or colocation section or One user will suggest the facility (peeringdb.com/suggest/fac), after filling in the details the form will generate a unique URL where the attestations can be collected. The user then distributes the URL (which can only be accessed by logged-in users) to the other interested parties, who can then attest or disprove the facility. When 3 PeeringDB users positively attest the facility exists, the facility is approved. The owner of the facility is a new peeringdb user and does not have any objects associated with their account. There are two mechanisms to claim a Facility object. The building has a website that has an interconnection or colocation section or An attestation process similar to how new facilities are suggested by existing users is followed, where the attempting-to-claim PeeringDB user must collect 3 positive attestations from three existing PeeringDB users. Exception approval follows the standard process Flowchart - Facility Flowchart - Attestation Flagging as \"junk\" PeeringDB users can flag a facility as \u201cjunk\u201d. This puts the Facility object in a review queue. The Admin Committee can resolve in the following ways: The facility owner becomes a PeeringDB user and claims the facility. The 3 people who attested that the facility exists can point at two existing PeeringDB IXP or Network object owners who are willing to attest they are present in the facility. The Admin Committee contacts the IXP or Network object owners and asks them to confirm their presence in the facility. At this point the facility record will list at least two network and/or IXP objects. A facility without networks or IXPs is considered potential \u201cjunk\u201d. Empty facilities will be deleted after 90 days. This happens when neither the owner of the facility, nor any other PeeringDB users were willing to indicate a relationship to the facility. The \u201cjunk\u201d button only appears in the UI for objects which are both unclaimed, and where no networks or IXPs indicate a presence. Checklist to help find entities present at the facility and or understand who the facility owner is Website operated by the facility owner: recommended and SHOULD list colocation or interconnection as a service Government or Industry Association website listing facilities. (Example: CLLI locators in the United States) Website of IXPs or Networks publishing they operate in the building Example facility object approval scenarios Facility approval example 1 Facility located at 100 W Main Street, Nowhere, WV, USA. Facility has four ISPs that interconnect in the basement of the building. Three out of the four ISPs have staff with PeeringDB accounts. Building owner has provided a closet for this to occur. Building has no website, the building owner does not know anything about interconnection, and has no plans to market the building as an interconnection location. Start ISP operator A files a request to suggest a Facility object to be entered into PeeringDB. Validation Process The facility owner is not a PeeringDB user, so the mechanism of the facility owner themselves suggesting the facility cannot be applied. The act of suggesting the facility in the PeeringDB user interface generates a unique URL which ISP Operator A can share with the fellow ISPs. If at least 2 other PeeringDB users attest the facility exists, the Facility object is created and marked as \u201cunclaimed\u201d. Facility approval example 2 A PeeringDB user noticed the Facility object created (as a result of Example 1), and reports it as \u201cjunk\u201d. The object continues to exist, but is added to a review queue for the PeeringDB Admin Committee to help resolve the situation. The Admin Committee\u2019s task is to find positive proof the facility exists and interconnection happens. Validation Process The AC committee first contacts the original PeeringDB users that provided attestations the facility exists. (Note: these PeeringDB users themselves might not be present in the facility). The AC can request the original attesters to provide a list of ISPs or IXPs they think are present in the facility. The AC can then contact the ISPs and/or IXPs who were suggested to have a presence in the facility and ask them to either attest the facility exists, or to add themselves as \u2018present\u2019 in the facility. It is possible these ISPs and/or IXPs are not yet PeeringDB users. If the AC can\u2019t collect the attestations the facility will be deleted in 90 days. Facility approval example 3 A Facility owner is a PeeringDB user and wishes to add its facility to PeeringDB using the \u201cSuggest a Facility\u201d function. The building owner is leasing suites to carriers in the basement of his facility, but primarily focuses on leasing office space. The building has a webpage, but data center/interconnection services are not listed on the webpage. The building owner has provided a list of four carriers who have leased space in the building. Validation Process The building owner can add webpage showing that they provide interconnection services. The attestation process can be used to demonstrate the building is used for interconnection. Facility approval example 4 An existing facility operator with other facilities listed in PeeringDB submits a new facility that does not yet have any customers. Validation Process None - The facility should be immediately added. After the Facility object has been added, networks and IXPs can indicate their presence. Exception process We know that these guidelines will need to be improved and updated as we learn, so we have built in an \u201cexception\u201d process to help with that. Whenever an easy path is not possible, the requester can ask for more review of their registration request. The first step in this process is to get input from all the volunteers on the Admin Committee. If more eyes are needed, the request can be shared with all of PeeringDB\u2019s Stewards, a group made from the committee chairs and board members. Where a formal decision is needed, the board can vote on a request and make a final decision. Flowchart Appendix Why must peering LANs be between /27 and /19 (IPv4) and not shorter than /64 (IPv6)? This limit is intended to reduce the likelihood of a typo that goes undetected and causes operational issues. Where a peering LAN uses a /28 or a /18 (IPv4) the Admin Committee can manually process the prefix after verifying its prefix length is correct. The technical standards do not allow LANs to have prefixes shorter than a /64, so a /63 would be rejected to avoid causing operational issues to operator equipment that is standards compliant.","title":"Admin Committee Guidelines and Criteria for Approving Networks, IXPs, and Facilities"},{"location":"committee/admin/approval-guidelines/#admin-committee-guidelines-and-criteria-for-approving-networks-ixps-and-facilities","text":"","title":"Admin Committee Guidelines and Criteria for Approving Networks, IXPs, and Facilities"},{"location":"committee/admin/approval-guidelines/#authors","text":"Chris Malayter Arnold Nipper Job Snijders","title":"Authors"},{"location":"committee/admin/approval-guidelines/#document-history","text":"v1. Initial document. v2. Added multiple mechanisms to validate IXP and Network. v3. Added mechanism to validate facility. v4. Added draft flowcharts and placed explanatory text in an appendix. Minor readability revisions.","title":"Document history"},{"location":"committee/admin/approval-guidelines/#guideline-goals","text":"This guide does not seek to define what an Internet Exchange, or Network operator, or Facility is. PeeringDB is a registry of information. What people do with the information is up to them. In these guidelines, we attempt to merely document PeeringDB\u2019s approval process. Key goals include: The Admin Committee can use multiple to validate and facilitate the creation of objects. Workflows are shown and always include the option to fall back to an exception process. This process brings more eyes and helps PeeringDB identify areas for improvement. Provide a few tangible examples of how to apply the guidelines.","title":"Guideline goals"},{"location":"committee/admin/approval-guidelines/#definitions","text":"User - a person submitting a new object to the PeeringDB database RIR - A Regional Internet Registry (AFRINIC, APNIC, ARIN, LACNIC or the RIPE NCC) NIR - A National Internet Registry recognized by one of the RIRs Additional terminology is described in Section 4 of the PeeringDB Data Ownership Policy Document .","title":"Definitions"},{"location":"committee/admin/approval-guidelines/#approving-network-net-objects","text":"The key to approving Network objects is to confirm the User has a relationship to the specified Autonomous System Number (ASN) and is authorized to represent that ASN in some form. PeeringDB follows industry best practices and has the following requirements for the Autonomous System numbers, regardless of who the User is: ASNs must be registered through an RIR or NIR The ASN must not already be registered in PeeringDB This means that \u201cPrivate\u201d ASNs, as listed in the IANA Autonomous System (AS) Numbers Registry or \u201cBogon\u201d ASNs, those which have not yet been assigned by an RIR or NIR, cannot be registered in PeeringDB.","title":"Approving Network (net) objects"},{"location":"committee/admin/approval-guidelines/#flowchart","text":"There are various mechanisms to verify the relationship between the User and a given Autonomous System number: The registration details listed in WHOIS match the registration details in the sign-up request (same email domain) The registration details listed in RDAP match the registration details in the sign-up request (same email domain) The user can confirm the relationship to the ASN through a RPKI based challenge/response (work in progress: draft-ietf-sidrops-rpki-rsc) The user can confirm the relationship to the ASN by entering a PeeringDB suggested random string in their WHOIS record in a comments/remarks field (not yet implemented, a similar strategy to how Amazon AWS does BYOIP) Exception approval follows the standard process PeeringDB encourages but does not require its users to follow industry best practices. This means we recommend: Making a BGP looking glass publicly available, or A website listing the Network services, and a publicly documented Routing Policy","title":"Flowchart"},{"location":"committee/admin/approval-guidelines/#approving-ixp-ix-objects","text":"The key to approving IXP objects is to confirm the User has a relationship to the specified Peering LAN Prefix, and is authorized to represent this IP block in some form.","title":"Approving IXP (ix) objects"},{"location":"committee/admin/approval-guidelines/#flowchart_1","text":"","title":"Flowchart"},{"location":"committee/admin/approval-guidelines/#globally-unique-ip-prefix-requirements","text":"IP prefix must be registered through an RIR or NIR. The prefix must not overlap with any existing IXP object in PeeringDB IPv4 prefixes must not be longer than a /27 or shorter than /19 IPv6 prefixes must not be shorter than /64 but may be longer i.e. a /120 is allowed but a /63 is not Users can verify their relationship to an IP prefix in several ways: The registration details listed in WHOIS match the registration details in the sign-up request (same email domain). The registration details listed in RDAP match the registration details in the sign-up request (same email domain). The user can confirm the relationship to the IP prefix through a RPKI based challenge/response (work in progress - draft-ietf-sidrops-rpki-rsc). The user can confirm the relationship to the IP prefix by entering a PeeringDB suggested random string in their inetnum record in the authoritative RIR or NIR database in a comments/remarks field (note: IRR route/route6 objects cannot be used for this purpose). RDAP should be used to discover which RIR or NIR is authoritative For Legacy IPv4 space, a PeeringDB suggested random string can be placed in a TXT record for the reverse DNS label representing the first IPv4 address in the prefix. (This is a variant of the Amazon AWS BYOIP process). The assumption is that if someone controls Reverse DNS for a given prefix, they have full control over the prefix. Exception approval follows the standard process PeeringDB encourages but does not require its users to follow industry best practices. This means we recommend: A website detailing the IXP service A public overview of connected members and locations, service level, and terms of membership.","title":"Globally unique IP prefix requirements"},{"location":"committee/admin/approval-guidelines/#approving-facility-fac-objects","text":"A \u201cfacility\u201d is a physical location where two or more IP Networks or IXPs interconnect with each other. The key to approving Facility objects is to confirm with multiple existing PeeringDB users that a facility exists. Note: We will need to extend PeeringDB's software to support the workflow described here. Note: The IP addresses used in the attestation process will be logged.","title":"Approving Facility (fac) objects"},{"location":"committee/admin/approval-guidelines/#validation-mechanisms","text":"The owner of the facility is an existing PeeringDB user, and adds the facility to their record themselves. In this approval flow the facility is \u2018claimed\u2019. For this workflow the facility owner should already have one facility previously validated via one of the following mechanisms: The owner of the facility is not a PeeringDB user, but interested parties (who are PeeringDB users) wish the Facility object to be registered. The result is an unclaimed Facility object. The building has a website that has an interconnection or colocation section or One user will suggest the facility (peeringdb.com/suggest/fac), after filling in the details the form will generate a unique URL where the attestations can be collected. The user then distributes the URL (which can only be accessed by logged-in users) to the other interested parties, who can then attest or disprove the facility. When 3 PeeringDB users positively attest the facility exists, the facility is approved. The owner of the facility is a new peeringdb user and does not have any objects associated with their account. There are two mechanisms to claim a Facility object. The building has a website that has an interconnection or colocation section or An attestation process similar to how new facilities are suggested by existing users is followed, where the attempting-to-claim PeeringDB user must collect 3 positive attestations from three existing PeeringDB users. Exception approval follows the standard process","title":"Validation mechanisms"},{"location":"committee/admin/approval-guidelines/#flowchart-facility","text":"","title":"Flowchart - Facility"},{"location":"committee/admin/approval-guidelines/#flowchart-attestation","text":"","title":"Flowchart - Attestation"},{"location":"committee/admin/approval-guidelines/#flagging-as-junk","text":"PeeringDB users can flag a facility as \u201cjunk\u201d. This puts the Facility object in a review queue. The Admin Committee can resolve in the following ways: The facility owner becomes a PeeringDB user and claims the facility. The 3 people who attested that the facility exists can point at two existing PeeringDB IXP or Network object owners who are willing to attest they are present in the facility. The Admin Committee contacts the IXP or Network object owners and asks them to confirm their presence in the facility. At this point the facility record will list at least two network and/or IXP objects. A facility without networks or IXPs is considered potential \u201cjunk\u201d. Empty facilities will be deleted after 90 days. This happens when neither the owner of the facility, nor any other PeeringDB users were willing to indicate a relationship to the facility. The \u201cjunk\u201d button only appears in the UI for objects which are both unclaimed, and where no networks or IXPs indicate a presence.","title":"Flagging as \"junk\""},{"location":"committee/admin/approval-guidelines/#checklist-to-help-find-entities-present-at-the-facility-and-or-understand-who-the-facility-owner-is","text":"Website operated by the facility owner: recommended and SHOULD list colocation or interconnection as a service Government or Industry Association website listing facilities. (Example: CLLI locators in the United States) Website of IXPs or Networks publishing they operate in the building","title":"Checklist to help find entities present at the facility and or understand who the facility owner is"},{"location":"committee/admin/approval-guidelines/#example-facility-object-approval-scenarios","text":"","title":"Example facility object approval scenarios"},{"location":"committee/admin/approval-guidelines/#facility-approval-example-1","text":"Facility located at 100 W Main Street, Nowhere, WV, USA. Facility has four ISPs that interconnect in the basement of the building. Three out of the four ISPs have staff with PeeringDB accounts. Building owner has provided a closet for this to occur. Building has no website, the building owner does not know anything about interconnection, and has no plans to market the building as an interconnection location. Start ISP operator A files a request to suggest a Facility object to be entered into PeeringDB. Validation Process The facility owner is not a PeeringDB user, so the mechanism of the facility owner themselves suggesting the facility cannot be applied. The act of suggesting the facility in the PeeringDB user interface generates a unique URL which ISP Operator A can share with the fellow ISPs. If at least 2 other PeeringDB users attest the facility exists, the Facility object is created and marked as \u201cunclaimed\u201d.","title":"Facility approval example 1"},{"location":"committee/admin/approval-guidelines/#facility-approval-example-2","text":"A PeeringDB user noticed the Facility object created (as a result of Example 1), and reports it as \u201cjunk\u201d. The object continues to exist, but is added to a review queue for the PeeringDB Admin Committee to help resolve the situation. The Admin Committee\u2019s task is to find positive proof the facility exists and interconnection happens. Validation Process The AC committee first contacts the original PeeringDB users that provided attestations the facility exists. (Note: these PeeringDB users themselves might not be present in the facility). The AC can request the original attesters to provide a list of ISPs or IXPs they think are present in the facility. The AC can then contact the ISPs and/or IXPs who were suggested to have a presence in the facility and ask them to either attest the facility exists, or to add themselves as \u2018present\u2019 in the facility. It is possible these ISPs and/or IXPs are not yet PeeringDB users. If the AC can\u2019t collect the attestations the facility will be deleted in 90 days.","title":"Facility approval example 2"},{"location":"committee/admin/approval-guidelines/#facility-approval-example-3","text":"A Facility owner is a PeeringDB user and wishes to add its facility to PeeringDB using the \u201cSuggest a Facility\u201d function. The building owner is leasing suites to carriers in the basement of his facility, but primarily focuses on leasing office space. The building has a webpage, but data center/interconnection services are not listed on the webpage. The building owner has provided a list of four carriers who have leased space in the building. Validation Process The building owner can add webpage showing that they provide interconnection services. The attestation process can be used to demonstrate the building is used for interconnection.","title":"Facility approval example 3"},{"location":"committee/admin/approval-guidelines/#facility-approval-example-4","text":"An existing facility operator with other facilities listed in PeeringDB submits a new facility that does not yet have any customers. Validation Process None - The facility should be immediately added. After the Facility object has been added, networks and IXPs can indicate their presence.","title":"Facility approval example 4"},{"location":"committee/admin/approval-guidelines/#exception-process","text":"We know that these guidelines will need to be improved and updated as we learn, so we have built in an \u201cexception\u201d process to help with that. Whenever an easy path is not possible, the requester can ask for more review of their registration request. The first step in this process is to get input from all the volunteers on the Admin Committee. If more eyes are needed, the request can be shared with all of PeeringDB\u2019s Stewards, a group made from the committee chairs and board members. Where a formal decision is needed, the board can vote on a request and make a final decision.","title":"Exception process"},{"location":"committee/admin/approval-guidelines/#flowchart_2","text":"","title":"Flowchart"},{"location":"committee/admin/approval-guidelines/#appendix","text":"","title":"Appendix"},{"location":"committee/admin/approval-guidelines/#why-must-peering-lans-be-between-27-and-19-ipv4-and-not-shorter-than-64-ipv6","text":"This limit is intended to reduce the likelihood of a typo that goes undetected and causes operational issues. Where a peering LAN uses a /28 or a /18 (IPv4) the Admin Committee can manually process the prefix after verifying its prefix length is correct. The technical standards do not allow LANs to have prefixes shorter than a /64, so a /63 would be rejected to avoid causing operational issues to operator equipment that is standards compliant.","title":"Why must peering LANs be between /27 and /19 (IPv4) and not shorter than /64 (IPv6)?"},{"location":"committee/admin/charter/","text":"PeeringDB Admin Committee Charter Approved by Board July 9th, 2020 Scope The PeeringDB Admin Committee (AC) is responsible for the day to day end-user support of PeeringDB. The Admin Committee functions as the first point of contact for any inquiries to PeeringDB. The Admin Committee produces definitions for enhancements to the workflow and Admin GUI and works with the Product Committee to plan a coherent roadmap for the PeeringDB software. Out of scope Work covered in the charter of the Operations, Outreach, Product, and further to be established Committees Deliverables Take care of support tickets, the Admin Committee strives to answer tickets within 24 hours Gather input from end-users regarding the improvement of PeeringDB in terms of bugs and product features and channel them towards the Product Committee via GitHub Improve PeeringDB Admin GUI to help expedient resolution of support tickets Collaboration The Admin Committee works with other PeeringDB committees to ensure an equitable division of development resources in recognition of the volunteer efforts that are ensuring the daily operations. Participation The PeeringDB Admin Committee members serve a one-year renewable term. Volunteers can submit their candidacy to the Admin Committee Chair. The Chair and Vice Chair will choose a new Admin Committee member at any time they see the necessity to ensure the continuity of the Admin Committee. There is a trial period of one month. New members are onboarded by a more experienced committee member (WebEx / Google Hangouts / 3 example tickets). After the trial period appointment is confirmed by the Chair and Vice Chair for one year. Expectations Individual committee members should do their fair share of tickets measured over a month If a committee member is away for an extended period of time, inform the Chair, Vice Chair, and a notification sent to the Admin Committee mailing list One month probation where they get taught/mentored by an experienced admin, and where if they do not do the work, they get booted Chairs perform a quarterly review. If you don't meet a fair portion of the work you'll be nudged. Also, three months of inactivity is an automatic ejection Communication Questions and suggestions for the Admin Committee can be sent to the Admincom Mailing List On- and de-boarding is handled via the Admincom GitHub All other issues, also for Admin GUI bugs and features must go to the regular GitHub Any support questions should be directed to the Support Address Admin Committee uses slack and emails for internal communication Regular (4-6 week interval) conference calls are used to stay synced and discuss issues Decision policy Admin Committee members will decide on their own when handling support tickets according to the Admin Committee BCP laid out in the Admin Committee How-To Folder. Otherwise, they will decide by simple majority vote on contested issues called by the Admin Committee Chair. If there is a tie the Chair's vote is counted double. Workflow Admincom uses DeskPRO and GitHub as well as direct communication with the main service contractor 20C to achieve its deliverables. In communicating with 3rd parties the Admin Committee should be kept in the loop if the issue is of general interest. PeeringDB Common Committee Charter Provisions: Dispute resolution If the committee handles an issue in a manner in which a user believes that their view has not been adequately considered, their first action should be to raise the concern with the Committee Chair for further consideration. If the dispute is between the user and the Committee Chair then the issue may alternatively be raised with the Committee Vice Chair. If the dispute cannot be resolved the matter may be brought forward to the PeeringDB Board. The decision by the PeeringDB Board shall be final. Committee Chair and Vice Chair The committee elects their Chair and Vice Chair from among their members, subject to PeeringDB Board approval. The Chair and Vice Chair work as a team and distribute the workload between themselves as they deem appropriate. Decisions should be unanimous, however the final decision on any matter is with the Chair. In case the Chair becomes unavailable, the Vice Chair may assume the position of Acting Chair. If the Chair or Vice Chair become permanently unavailable, replacement(s) are elected from the remaining committee members, subject to PeeringDB Board approval.","title":"Charter"},{"location":"committee/admin/charter/#peeringdb-admin-committee-charter","text":"Approved by Board July 9th, 2020","title":"PeeringDB Admin Committee Charter"},{"location":"committee/admin/charter/#scope","text":"The PeeringDB Admin Committee (AC) is responsible for the day to day end-user support of PeeringDB. The Admin Committee functions as the first point of contact for any inquiries to PeeringDB. The Admin Committee produces definitions for enhancements to the workflow and Admin GUI and works with the Product Committee to plan a coherent roadmap for the PeeringDB software.","title":"Scope"},{"location":"committee/admin/charter/#out-of-scope","text":"Work covered in the charter of the Operations, Outreach, Product, and further to be established Committees","title":"Out of scope"},{"location":"committee/admin/charter/#deliverables","text":"Take care of support tickets, the Admin Committee strives to answer tickets within 24 hours Gather input from end-users regarding the improvement of PeeringDB in terms of bugs and product features and channel them towards the Product Committee via GitHub Improve PeeringDB Admin GUI to help expedient resolution of support tickets","title":"Deliverables"},{"location":"committee/admin/charter/#collaboration","text":"The Admin Committee works with other PeeringDB committees to ensure an equitable division of development resources in recognition of the volunteer efforts that are ensuring the daily operations.","title":"Collaboration"},{"location":"committee/admin/charter/#participation","text":"The PeeringDB Admin Committee members serve a one-year renewable term. Volunteers can submit their candidacy to the Admin Committee Chair. The Chair and Vice Chair will choose a new Admin Committee member at any time they see the necessity to ensure the continuity of the Admin Committee. There is a trial period of one month. New members are onboarded by a more experienced committee member (WebEx / Google Hangouts / 3 example tickets). After the trial period appointment is confirmed by the Chair and Vice Chair for one year.","title":"Participation"},{"location":"committee/admin/charter/#expectations","text":"Individual committee members should do their fair share of tickets measured over a month If a committee member is away for an extended period of time, inform the Chair, Vice Chair, and a notification sent to the Admin Committee mailing list One month probation where they get taught/mentored by an experienced admin, and where if they do not do the work, they get booted Chairs perform a quarterly review. If you don't meet a fair portion of the work you'll be nudged. Also, three months of inactivity is an automatic ejection","title":"Expectations"},{"location":"committee/admin/charter/#communication","text":"Questions and suggestions for the Admin Committee can be sent to the Admincom Mailing List On- and de-boarding is handled via the Admincom GitHub All other issues, also for Admin GUI bugs and features must go to the regular GitHub Any support questions should be directed to the Support Address Admin Committee uses slack and emails for internal communication Regular (4-6 week interval) conference calls are used to stay synced and discuss issues","title":"Communication"},{"location":"committee/admin/charter/#decision-policy","text":"Admin Committee members will decide on their own when handling support tickets according to the Admin Committee BCP laid out in the Admin Committee How-To Folder. Otherwise, they will decide by simple majority vote on contested issues called by the Admin Committee Chair. If there is a tie the Chair's vote is counted double.","title":"Decision policy"},{"location":"committee/admin/charter/#workflow","text":"Admincom uses DeskPRO and GitHub as well as direct communication with the main service contractor 20C to achieve its deliverables. In communicating with 3rd parties the Admin Committee should be kept in the loop if the issue is of general interest. PeeringDB Common Committee Charter Provisions:","title":"Workflow"},{"location":"committee/admin/charter/#dispute-resolution","text":"If the committee handles an issue in a manner in which a user believes that their view has not been adequately considered, their first action should be to raise the concern with the Committee Chair for further consideration. If the dispute is between the user and the Committee Chair then the issue may alternatively be raised with the Committee Vice Chair. If the dispute cannot be resolved the matter may be brought forward to the PeeringDB Board. The decision by the PeeringDB Board shall be final.","title":"Dispute resolution"},{"location":"committee/admin/charter/#committee-chair-and-vice-chair","text":"The committee elects their Chair and Vice Chair from among their members, subject to PeeringDB Board approval. The Chair and Vice Chair work as a team and distribute the workload between themselves as they deem appropriate. Decisions should be unanimous, however the final decision on any matter is with the Chair. In case the Chair becomes unavailable, the Vice Chair may assume the position of Acting Chair. If the Chair or Vice Chair become permanently unavailable, replacement(s) are elected from the remaining committee members, subject to PeeringDB Board approval.","title":"Committee Chair and Vice Chair"},{"location":"committee/outreach/","text":"PeeringDB Outreach Committee Purpose is to coordinate outreach and evangelism in the community. Interested in volunteering? Contact outreachcom@lists.peeringdb.com . PeeringDB Outreach Committee Charter Approved by Board July 9th, 2020 Scope The PeeringDB Outreach Committee (OC) is charged with the marketing efforts and running the organization's external engagement to continuously improve the value that PeeringDB delivers to the organizations registered with PeeringDB, and the broader community. Out of scope The OC Committee does not work on other areas, such as product development, as these are managed by the other respective committees and defined in their respective charters. Deliverables Gather inputs from the other respective PeeringDB committees on developments and significant updates and ensure these are communicated the community Coordinate with partner committees and prepare presentations with relevant PeeringDB updates Identify and attend relevant community events to publicize PeeringDB developments and engage the community to drive additional records to be created Identify marketing opportunities for relevant PeeringDB activities Share key milestones and engage with the community through social media channels Participation The PeeringDB Outreach Committee members serve a one-year renewable term. Volunteers can submit their candidacy to the Outreach Committee Chair. The Chair and Vice Chair will choose a new Outreach Committee member at any time they see the necessity to ensure the continuity of the Outreach Committee. Communication Questions and suggestions for the Outreach Committee can be sent to outreachcom@lists.peeringdb.com Decision policy Outreach Committee members will decide by simple majority vote on contested issues called by the Outreach Committee Chair. PeeringDB Common Committee Charter Provisions: Dispute resolution If the committee handles an issue in a manner in which a user believes that their view has not been adequately considered, their first action should be to raise the concern with the Committee Chair for further consideration. If the dispute is between the user and the Committee Chair then the issue may alternatively be raised with the Committee Vice Chair. If the dispute cannot be resolved the matter may be brought forward to the PeeringDB Board. The decision by the PeeringDB Board shall be final. Committee Chair and Vice Chair The committee elects their Chair and Vice Chair from among their members, subject to PeeringDB Board approval. The Chair and Vice Chair work as a team and distribute the workload between themselves as they deem appropriate. Decisions should be unanimous, however the final decision on any matter is with the Chair. In case the Chair becomes unavailable, the Vice Chair may assume the position of Acting Chair. If the Chair or Vice Chair become permanently unavailable, replacement(s) are elected from the remaining committee members, subject to PeeringDB Board approval. Meeting notes 2024 October 9th, 2024: Meeting Notes September 19th, 2024: Meeting Notes August 13th, 2024: Meeting Notes July 9th, 2024: Meeting Notes June 17th, 2024: Meeting Notes May 14th, 2024: Meeting Notes April 9th, 2024: Meeting Notes 2021 No formal meeting in December 2021 November 2nd, 2021: Meeting Notes October 5th, 2021: Meeting Notes September 7th, 2021: Meeting Notes No formal meeting in August 2021 July 6th, 2021: Meeting Notes June 1st, 2021: Meeting Notes May 5th, 2021: Meeting Notes April 6th, 2021: Meeting Notes March 1st, 2021: Meeting Notes February 8th, 2021: Meeting Notes January 12th, 2021: Meeting Notes 2020 No formal meeting in December 2020 November 12th, 2020: Meeting Notes No formal meeting in October 2020 No formal meeting in September 2020 August 4th, 2020: Meeting Notes July 7th, 2020: Meeting Notes June 2nd, 2020: Meeting Notes May 7th, 2020: Meeting Notes April 7th, 2020: Meeting Notes March 17th, 2020: Meeting Notes February 4th, 2020: Meeting Notes January 7th, 2020: Meeting Notes 2019 December 3rd, 2019: Meeting Notes Members Obinna Adumike Lynsey Buckingham Yana Glaub Greg Hankins Aaron Hughes - Board Liaison Tarryn Kidd Livio Morina Arnold Nipper Ester Paal Ben Ryall - Chair Leo Vegoda - Product Manager","title":"Outreach Committee"},{"location":"committee/outreach/#peeringdb-outreach-committee","text":"Purpose is to coordinate outreach and evangelism in the community. Interested in volunteering? Contact outreachcom@lists.peeringdb.com .","title":"PeeringDB Outreach Committee"},{"location":"committee/outreach/#peeringdb-outreach-committee-charter","text":"Approved by Board July 9th, 2020","title":"PeeringDB Outreach Committee Charter"},{"location":"committee/outreach/#scope","text":"The PeeringDB Outreach Committee (OC) is charged with the marketing efforts and running the organization's external engagement to continuously improve the value that PeeringDB delivers to the organizations registered with PeeringDB, and the broader community.","title":"Scope"},{"location":"committee/outreach/#out-of-scope","text":"The OC Committee does not work on other areas, such as product development, as these are managed by the other respective committees and defined in their respective charters.","title":"Out of scope"},{"location":"committee/outreach/#deliverables","text":"Gather inputs from the other respective PeeringDB committees on developments and significant updates and ensure these are communicated the community Coordinate with partner committees and prepare presentations with relevant PeeringDB updates Identify and attend relevant community events to publicize PeeringDB developments and engage the community to drive additional records to be created Identify marketing opportunities for relevant PeeringDB activities Share key milestones and engage with the community through social media channels","title":"Deliverables"},{"location":"committee/outreach/#participation","text":"The PeeringDB Outreach Committee members serve a one-year renewable term. Volunteers can submit their candidacy to the Outreach Committee Chair. The Chair and Vice Chair will choose a new Outreach Committee member at any time they see the necessity to ensure the continuity of the Outreach Committee.","title":"Participation"},{"location":"committee/outreach/#communication","text":"Questions and suggestions for the Outreach Committee can be sent to outreachcom@lists.peeringdb.com","title":"Communication"},{"location":"committee/outreach/#decision-policy","text":"Outreach Committee members will decide by simple majority vote on contested issues called by the Outreach Committee Chair. PeeringDB Common Committee Charter Provisions:","title":"Decision policy"},{"location":"committee/outreach/#dispute-resolution","text":"If the committee handles an issue in a manner in which a user believes that their view has not been adequately considered, their first action should be to raise the concern with the Committee Chair for further consideration. If the dispute is between the user and the Committee Chair then the issue may alternatively be raised with the Committee Vice Chair. If the dispute cannot be resolved the matter may be brought forward to the PeeringDB Board. The decision by the PeeringDB Board shall be final.","title":"Dispute resolution"},{"location":"committee/outreach/#committee-chair-and-vice-chair","text":"The committee elects their Chair and Vice Chair from among their members, subject to PeeringDB Board approval. The Chair and Vice Chair work as a team and distribute the workload between themselves as they deem appropriate. Decisions should be unanimous, however the final decision on any matter is with the Chair. In case the Chair becomes unavailable, the Vice Chair may assume the position of Acting Chair. If the Chair or Vice Chair become permanently unavailable, replacement(s) are elected from the remaining committee members, subject to PeeringDB Board approval.","title":"Committee Chair and Vice Chair"},{"location":"committee/outreach/#meeting-notes","text":"","title":"Meeting notes"},{"location":"committee/outreach/#2024","text":"October 9th, 2024: Meeting Notes September 19th, 2024: Meeting Notes August 13th, 2024: Meeting Notes July 9th, 2024: Meeting Notes June 17th, 2024: Meeting Notes May 14th, 2024: Meeting Notes April 9th, 2024: Meeting Notes","title":"2024"},{"location":"committee/outreach/#2021","text":"No formal meeting in December 2021 November 2nd, 2021: Meeting Notes October 5th, 2021: Meeting Notes September 7th, 2021: Meeting Notes No formal meeting in August 2021 July 6th, 2021: Meeting Notes June 1st, 2021: Meeting Notes May 5th, 2021: Meeting Notes April 6th, 2021: Meeting Notes March 1st, 2021: Meeting Notes February 8th, 2021: Meeting Notes January 12th, 2021: Meeting Notes","title":"2021"},{"location":"committee/outreach/#2020","text":"No formal meeting in December 2020 November 12th, 2020: Meeting Notes No formal meeting in October 2020 No formal meeting in September 2020 August 4th, 2020: Meeting Notes July 7th, 2020: Meeting Notes June 2nd, 2020: Meeting Notes May 7th, 2020: Meeting Notes April 7th, 2020: Meeting Notes March 17th, 2020: Meeting Notes February 4th, 2020: Meeting Notes January 7th, 2020: Meeting Notes","title":"2020"},{"location":"committee/outreach/#2019","text":"December 3rd, 2019: Meeting Notes","title":"2019"},{"location":"committee/outreach/#members","text":"Obinna Adumike Lynsey Buckingham Yana Glaub Greg Hankins Aaron Hughes - Board Liaison Tarryn Kidd Livio Morina Arnold Nipper Ester Paal Ben Ryall - Chair Leo Vegoda - Product Manager","title":"Members"},{"location":"committee/outreach/charter/","text":"PeeringDB Outreach Committee Charter Approved by Board July 9th, 2020 Scope The PeeringDB Outreach Committee (OC) is charged with the marketing efforts and running the organization's external engagement to continuously improve the value that PeeringDB delivers to the organizations registered with PeeringDB, and the broader community. Out of scope The OC Committee does not work on other areas, such as product development, as these are managed by the other respective committees and defined in their respective charters. Deliverables Gather inputs from the other respective PeeringDB committees on developments and significant updates and ensure these are communicated the community Coordinate with partner committees and prepare presentations with relevant PeeringDB updates Identify and attend relevant community events to publicize PeeringDB developments and engage the community to drive additional records to be created Identify marketing opportunities for relevant PeeringDB activities Share key milestones and engage with the community through social media channels Participation The PeeringDB Outreach Committee members serve a one-year renewable term. Volunteers can submit their candidacy to the Outreach Committee Chair. The Chair and Vice Chair will choose a new Outreach Committee member at any time they see the necessity to ensure the continuity of the Outreach Committee. Communication Questions and suggestions for the Outreach Committee can be sent to outreachcom@lists.peeringdb.com Decision policy Outreach Committee members will decide by simple majority vote on contested issues called by the Outreach Committee Chair. PeeringDB Common Committee Charter Provisions: Dispute resolution If the committee handles an issue in a manner in which a user believes that their view has not been adequately considered, their first action should be to raise the concern with the Committee Chair for further consideration. If the dispute is between the user and the Committee Chair then the issue may alternatively be raised with the Committee Vice Chair. If the dispute cannot be resolved the matter may be brought forward to the PeeringDB Board. The decision by the PeeringDB Board shall be final. Committee Chair and Vice Chair The committee elects their Chair and Vice Chair from among their members, subject to PeeringDB Board approval. The Chair and Vice Chair work as a team and distribute the workload between themselves as they deem appropriate. Decisions should be unanimous, however the final decision on any matter is with the Chair. In case the Chair becomes unavailable, the Vice Chair may assume the position of Acting Chair. If the Chair or Vice Chair become permanently unavailable, replacement(s) are elected from the remaining committee members, subject to PeeringDB Board approval.","title":"Charter"},{"location":"committee/outreach/charter/#peeringdb-outreach-committee-charter","text":"Approved by Board July 9th, 2020","title":"PeeringDB Outreach Committee Charter"},{"location":"committee/outreach/charter/#scope","text":"The PeeringDB Outreach Committee (OC) is charged with the marketing efforts and running the organization's external engagement to continuously improve the value that PeeringDB delivers to the organizations registered with PeeringDB, and the broader community.","title":"Scope"},{"location":"committee/outreach/charter/#out-of-scope","text":"The OC Committee does not work on other areas, such as product development, as these are managed by the other respective committees and defined in their respective charters.","title":"Out of scope"},{"location":"committee/outreach/charter/#deliverables","text":"Gather inputs from the other respective PeeringDB committees on developments and significant updates and ensure these are communicated the community Coordinate with partner committees and prepare presentations with relevant PeeringDB updates Identify and attend relevant community events to publicize PeeringDB developments and engage the community to drive additional records to be created Identify marketing opportunities for relevant PeeringDB activities Share key milestones and engage with the community through social media channels","title":"Deliverables"},{"location":"committee/outreach/charter/#participation","text":"The PeeringDB Outreach Committee members serve a one-year renewable term. Volunteers can submit their candidacy to the Outreach Committee Chair. The Chair and Vice Chair will choose a new Outreach Committee member at any time they see the necessity to ensure the continuity of the Outreach Committee.","title":"Participation"},{"location":"committee/outreach/charter/#communication","text":"Questions and suggestions for the Outreach Committee can be sent to outreachcom@lists.peeringdb.com","title":"Communication"},{"location":"committee/outreach/charter/#decision-policy","text":"Outreach Committee members will decide by simple majority vote on contested issues called by the Outreach Committee Chair. PeeringDB Common Committee Charter Provisions:","title":"Decision policy"},{"location":"committee/outreach/charter/#dispute-resolution","text":"If the committee handles an issue in a manner in which a user believes that their view has not been adequately considered, their first action should be to raise the concern with the Committee Chair for further consideration. If the dispute is between the user and the Committee Chair then the issue may alternatively be raised with the Committee Vice Chair. If the dispute cannot be resolved the matter may be brought forward to the PeeringDB Board. The decision by the PeeringDB Board shall be final.","title":"Dispute resolution"},{"location":"committee/outreach/charter/#committee-chair-and-vice-chair","text":"The committee elects their Chair and Vice Chair from among their members, subject to PeeringDB Board approval. The Chair and Vice Chair work as a team and distribute the workload between themselves as they deem appropriate. Decisions should be unanimous, however the final decision on any matter is with the Chair. In case the Chair becomes unavailable, the Vice Chair may assume the position of Acting Chair. If the Chair or Vice Chair become permanently unavailable, replacement(s) are elected from the remaining committee members, subject to PeeringDB Board approval.","title":"Committee Chair and Vice Chair"},{"location":"committee/product/","text":"PeeringDB Product Committee Purpose is to study and recommend feature needs. Interested in volunteering? Contact productcom@lists.peeringdb.com . PeeringDB Product Committee Charter Approved by Board July 7th, 2017 Scope The PeeringDB Product Committee (PC) is charged with steering the future product development and running the market outreach efforts to continuously improve the value that PeeringDB delivers to the networks registered with PeeringDB, and the broader community. Out of scope The PC does not drive PeeringDB improvements related to the administrative interfaces & functions used by the PeeringDB Admin Committee. The PC does not consider PeeringDB improvements related to the server, storage, hosting or network infrastructure. Deliverables Gather inputs from stakeholders regarding the evolution of PeeringDB in terms of product features and overall long term objectives. Formulate the long term objectives and validate them with the PeeringDB Board and the members of the PeeringDB Governance mailing list. Document and maintain workflow process to handle requests and issues. Maintain the product roadmap and feature request backlog and makes them publicly accessible. Create and maintain PeeringDB product documentation and presentation materials. Develop market outreach and evangelization to increase the uptake of PeeringDB use and improve data quality. Propose new features or enhancements based on the long term objectives and validates significant product evolutions with key stakeholders. Collaboration The PC shall work with other PeeringDB committees to ensure an equitable division of development resources in recognition of the volunteer efforts that are ensuring the daily operations. Participation The PeeringDB Product Committee members serve a 2 years renewable term, potential volunteers may submit their candidacy to the PeeringDB Board. The product committee will select their own Chair and Vice Chair by simple majority vote. The Board may add or remove members at any time it deems necessary. Communication Questions and suggestions for the Product Committee can be sent to productcom@lists.peeringdb.com The committee will use a range of mechanisms for communication and community input gathering efforts, including the PeeringDB Governance Mailinglist pdb-gov@lists.peeringdb.com Decisions, including their rationale, will be documented in GitHub issues All issues and the product roadmap and feature backlog can be found at in GitHub issues Decision policy Product Committee members will decide by simple majority vote on contested issues called by the Product Committee Chair. PeeringDB Common Committee Charter Provisions: Dispute resolution If the committee handles an issue in a manner in which a user believes that their view has not been adequately considered, their first action should be to raise the concern with the Committee Chair for further consideration. If the dispute is between the user and the Committee Chair then the issue may alternatively be raised with the Committee Vice Chair. If the dispute cannot be resolved the matter may be brought forward to the PeeringDB Board. The decision by the PeeringDB Board shall be final. Committee Chair and Vice Chair The committee elects their Chair and Vice Chair from among their members, subject to PeeringDB Board approval. The Chair and Vice Chair work as a team and distribute the workload between themselves as they deem appropriate. Decisions should be unanimous, however the final decision on any matter is with the Chair. In case the Chair becomes unavailable, the Vice Chair may assume the position of Acting Chair. If the Chair or Vice Chair become permanently unavailable, replacement(s) are elected from the remaining committee members, subject to PeeringDB Board approval. Decision making process and workflow Product Committee members are responsible for driving the development of PeeringDB. To do this, GitHub issues are used to track proposed and in progress work. Product Committee members play two roles in driving forward work: 1) As a shepherd - responsible for driving consensus for a given issue 2) As a stakeholder - voting on a consensus that has been reached Each Product Committee member will choose issues to shepherd to a decision. They will indicate responsibility for this task by assigning the issue to themselves and placing it in the Decide queue. To decide whether we act on a given issue that has been reported, a stakeholder group will be formed. This group will consist of Product Committee members, who are responsible for representing the users of PeeringDB. A stakeholder group on a given issue must consist of at least three Product Committee members, including the shepherding member. Any Product Committee member can be a stakeholder in the decision on an issue. They become a stakeholder on a given issue by either commenting on the issue on GitHub or participating in discussion of the issue on the Product Committee Mailing list. It is up to the shepherding member to help reach a unanimous consensus within the stakeholder group on what should be done with the issue - including not acting on it. If and only if there are opposing views on how to proceed, and unanimous consensus cannot be reached by the stakeholder committee members, decisions fall to the entire Product Committee (see below). The final proposal of how to resolve each issue, along with votes from stakeholders must be documented in the GitHub issue to be considered to have reached consensus. Product Committee members must document any offline discussion in the GitHub issue to ensure transparency of the discussion process. Issues in the Decide queue are regularly reviewed by the Product Committee to make sure the most impactful issues are being moved along to resolution. All issues in the Decide queue will be reviewed in the monthly Product Committee call to ensure stakeholders have reached consensus and to give members who have not participated in the issue an opportunity to participate. After an issue with consensus has been reviewed, Product Committee members who disagree with the proposal have five days after the monthly Product Committee call to vote against the proposed solution, otherwise the issue will move to the backlog. For any issues where consensus cannot be reached, an issue may move forward only if a quorum of 50% or more of the Product Committee has no more than 25% of the quorum in opposition to the issue. Meeting notes 2024 November 7th, 2024: Meeting Notes October 3rd, 2024: Meeting Notes September 5th, 2024: Meeting Notes August 1st, 2024: Meeting Notes July 11th, 2024: Meeting Notes June 6th, 2024: Meeting Notes May 2nd, 2024: Meeting Notes April 4th, 2024: Meeting Notes March 14th, 2024: Meeting Notes February 1st, 2024: Meeting Notes January 4th, 2024: Meeting Notes 2023 December 7th, 2023: Meeting Notes November 2nd, 2023: Meeting Notes October 5th, 2023: Meeting Notes September 7th, 2023: Meeting Notes August 3rd, 2023: Meeting Notes July 6th, 2023: Meeting Notes June 1st, 2023: Meeting Notes May 4th, 2023: Meeting Notes April 6th, 2023: Meeting Notes March 2nd, 2023: Meeting Notes February 14th, 2023: Meeting Notes February 2nd, 2023: Meeting Notes January 5th, 2023: Meeting Notes 2022 No formal meeting in December 2022 November 3rd, 2022: Meeting Notes October 17th, 2022: Meeting Notes October 6th, 2022: Meeting Notes September 8th, 2022: Meeting Notes August 4th, 2022: Meeting Notes July 7th, 2022: Meeting Notes June 2nd, 2022: Meeting Notes May 5th, 2022: Meeting Notes April 7th, 2022: Meeting Notes March 3rd, 2022: Meeting Notes February 3rd, 2022: Meeting Notes January 6th, 2022: Meeting Notes 2021 December 2nd, 2021: Meeting Notes No formal meeting in November 2021 October 7th, 2021: Meeting Notes No formal meeting in September 2021 No formal meeting in August 2021 No formal meeting in July 2021 No formal meeting in June 2021 May 6th, 2021: Meeting Notes April 1st, 2021: Meeting Notes March 11th, 2021: Meeting Notes February 4th, 2021: Meeting Notes January 7th, 2021: Meeting Notes 2020 December 3rd, 2020: Meeting Notes November 5th, 2020: Meeting Notes October 1st, 2020: Meeting Notes September 3rd, 2020: Meeting Notes August 6th, 2020: Meeting Notes July 2nd, 2020: Meeting Notes June 4th, 2020: Meeting Notes May 7th, 2020: Meeting Notes April 2nd, 2020: Meeting Notes No formal meeting in March 2020 February 6th, 2020: Meeting Notes January 9th, 2020: Meeting Notes 2019 No formal meeting in December 2019 November 14th, 2019: Meeting Notes October 3rd, 2019: Meeting Notes September 5th, 2019: Meeting Notes August 8th, 2019: Meeting Notes July 11th, 2019: Meeting Notes June 7th, 2019: Meeting Notes May 2nd, 2019: Meeting Notes No formal meeting in April 2019 March 7th, 2019: Meeting Notes February 7th, 2019: Meeting Notes January 3rd, 2019: Meeting Notes 2018 December 6th, 2018: Meeting Notes November 1st, 2018: Meeting Notes October 4th, 2018: Meeting Notes September 6th, 2018: Meeting Notes No formal meeting in August 2018 July 5th, 2018: Meeting Notes June 7th, 2018: Meeting Notes No formal meeting in May 2018 April 5th, 2018: Meeting Notes March 14th, 2018: Meeting Notes No formal meeting in February 2018 January 4th, 2018: Meeting Notes 2017 December 7th, 2017: Meeting Notes No formal meeting in November 2017 October 12th, 2017: Meeting Notes No formal meeting in September 2017 August 3rd, 2017: Meeting Notes July 6th, 2017: Meeting Notes June 1st, 2017: Meeting Notes No formal meeting in May 2017 April 13th, 2017: Meeting Notes March 21st, 2017: Meeting Notes Members Jeff Bartig Yan Berthier Jack Carrozzo - Chair Yolandi Cloete Matt Griswold - Vice Chair Martin Hannigan Peter Helmenstine Paul Hoogsteder Aaron Hughes - Board Liaison Laurent Jarbinet Stephen McManus Arnold Nipper Terry Sweetser Leo Vegoda - Product Manager","title":"Product Committee"},{"location":"committee/product/#peeringdb-product-committee","text":"Purpose is to study and recommend feature needs. Interested in volunteering? Contact productcom@lists.peeringdb.com .","title":"PeeringDB Product Committee"},{"location":"committee/product/#peeringdb-product-committee-charter","text":"Approved by Board July 7th, 2017","title":"PeeringDB Product Committee Charter"},{"location":"committee/product/#scope","text":"The PeeringDB Product Committee (PC) is charged with steering the future product development and running the market outreach efforts to continuously improve the value that PeeringDB delivers to the networks registered with PeeringDB, and the broader community.","title":"Scope"},{"location":"committee/product/#out-of-scope","text":"The PC does not drive PeeringDB improvements related to the administrative interfaces & functions used by the PeeringDB Admin Committee. The PC does not consider PeeringDB improvements related to the server, storage, hosting or network infrastructure.","title":"Out of scope"},{"location":"committee/product/#deliverables","text":"Gather inputs from stakeholders regarding the evolution of PeeringDB in terms of product features and overall long term objectives. Formulate the long term objectives and validate them with the PeeringDB Board and the members of the PeeringDB Governance mailing list. Document and maintain workflow process to handle requests and issues. Maintain the product roadmap and feature request backlog and makes them publicly accessible. Create and maintain PeeringDB product documentation and presentation materials. Develop market outreach and evangelization to increase the uptake of PeeringDB use and improve data quality. Propose new features or enhancements based on the long term objectives and validates significant product evolutions with key stakeholders.","title":"Deliverables"},{"location":"committee/product/#collaboration","text":"The PC shall work with other PeeringDB committees to ensure an equitable division of development resources in recognition of the volunteer efforts that are ensuring the daily operations.","title":"Collaboration"},{"location":"committee/product/#participation","text":"The PeeringDB Product Committee members serve a 2 years renewable term, potential volunteers may submit their candidacy to the PeeringDB Board. The product committee will select their own Chair and Vice Chair by simple majority vote. The Board may add or remove members at any time it deems necessary.","title":"Participation"},{"location":"committee/product/#communication","text":"Questions and suggestions for the Product Committee can be sent to productcom@lists.peeringdb.com The committee will use a range of mechanisms for communication and community input gathering efforts, including the PeeringDB Governance Mailinglist pdb-gov@lists.peeringdb.com Decisions, including their rationale, will be documented in GitHub issues All issues and the product roadmap and feature backlog can be found at in GitHub issues","title":"Communication"},{"location":"committee/product/#decision-policy","text":"Product Committee members will decide by simple majority vote on contested issues called by the Product Committee Chair. PeeringDB Common Committee Charter Provisions:","title":"Decision policy"},{"location":"committee/product/#dispute-resolution","text":"If the committee handles an issue in a manner in which a user believes that their view has not been adequately considered, their first action should be to raise the concern with the Committee Chair for further consideration. If the dispute is between the user and the Committee Chair then the issue may alternatively be raised with the Committee Vice Chair. If the dispute cannot be resolved the matter may be brought forward to the PeeringDB Board. The decision by the PeeringDB Board shall be final.","title":"Dispute resolution"},{"location":"committee/product/#committee-chair-and-vice-chair","text":"The committee elects their Chair and Vice Chair from among their members, subject to PeeringDB Board approval. The Chair and Vice Chair work as a team and distribute the workload between themselves as they deem appropriate. Decisions should be unanimous, however the final decision on any matter is with the Chair. In case the Chair becomes unavailable, the Vice Chair may assume the position of Acting Chair. If the Chair or Vice Chair become permanently unavailable, replacement(s) are elected from the remaining committee members, subject to PeeringDB Board approval.","title":"Committee Chair and Vice Chair"},{"location":"committee/product/#decision-making-process-and-workflow","text":"Product Committee members are responsible for driving the development of PeeringDB. To do this, GitHub issues are used to track proposed and in progress work. Product Committee members play two roles in driving forward work: 1) As a shepherd - responsible for driving consensus for a given issue 2) As a stakeholder - voting on a consensus that has been reached Each Product Committee member will choose issues to shepherd to a decision. They will indicate responsibility for this task by assigning the issue to themselves and placing it in the Decide queue. To decide whether we act on a given issue that has been reported, a stakeholder group will be formed. This group will consist of Product Committee members, who are responsible for representing the users of PeeringDB. A stakeholder group on a given issue must consist of at least three Product Committee members, including the shepherding member. Any Product Committee member can be a stakeholder in the decision on an issue. They become a stakeholder on a given issue by either commenting on the issue on GitHub or participating in discussion of the issue on the Product Committee Mailing list. It is up to the shepherding member to help reach a unanimous consensus within the stakeholder group on what should be done with the issue - including not acting on it. If and only if there are opposing views on how to proceed, and unanimous consensus cannot be reached by the stakeholder committee members, decisions fall to the entire Product Committee (see below). The final proposal of how to resolve each issue, along with votes from stakeholders must be documented in the GitHub issue to be considered to have reached consensus. Product Committee members must document any offline discussion in the GitHub issue to ensure transparency of the discussion process. Issues in the Decide queue are regularly reviewed by the Product Committee to make sure the most impactful issues are being moved along to resolution. All issues in the Decide queue will be reviewed in the monthly Product Committee call to ensure stakeholders have reached consensus and to give members who have not participated in the issue an opportunity to participate. After an issue with consensus has been reviewed, Product Committee members who disagree with the proposal have five days after the monthly Product Committee call to vote against the proposed solution, otherwise the issue will move to the backlog. For any issues where consensus cannot be reached, an issue may move forward only if a quorum of 50% or more of the Product Committee has no more than 25% of the quorum in opposition to the issue.","title":"Decision making process and workflow"},{"location":"committee/product/#meeting-notes","text":"","title":"Meeting notes"},{"location":"committee/product/#2024","text":"November 7th, 2024: Meeting Notes October 3rd, 2024: Meeting Notes September 5th, 2024: Meeting Notes August 1st, 2024: Meeting Notes July 11th, 2024: Meeting Notes June 6th, 2024: Meeting Notes May 2nd, 2024: Meeting Notes April 4th, 2024: Meeting Notes March 14th, 2024: Meeting Notes February 1st, 2024: Meeting Notes January 4th, 2024: Meeting Notes","title":"2024"},{"location":"committee/product/#2023","text":"December 7th, 2023: Meeting Notes November 2nd, 2023: Meeting Notes October 5th, 2023: Meeting Notes September 7th, 2023: Meeting Notes August 3rd, 2023: Meeting Notes July 6th, 2023: Meeting Notes June 1st, 2023: Meeting Notes May 4th, 2023: Meeting Notes April 6th, 2023: Meeting Notes March 2nd, 2023: Meeting Notes February 14th, 2023: Meeting Notes February 2nd, 2023: Meeting Notes January 5th, 2023: Meeting Notes","title":"2023"},{"location":"committee/product/#2022","text":"No formal meeting in December 2022 November 3rd, 2022: Meeting Notes October 17th, 2022: Meeting Notes October 6th, 2022: Meeting Notes September 8th, 2022: Meeting Notes August 4th, 2022: Meeting Notes July 7th, 2022: Meeting Notes June 2nd, 2022: Meeting Notes May 5th, 2022: Meeting Notes April 7th, 2022: Meeting Notes March 3rd, 2022: Meeting Notes February 3rd, 2022: Meeting Notes January 6th, 2022: Meeting Notes","title":"2022"},{"location":"committee/product/#2021","text":"December 2nd, 2021: Meeting Notes No formal meeting in November 2021 October 7th, 2021: Meeting Notes No formal meeting in September 2021 No formal meeting in August 2021 No formal meeting in July 2021 No formal meeting in June 2021 May 6th, 2021: Meeting Notes April 1st, 2021: Meeting Notes March 11th, 2021: Meeting Notes February 4th, 2021: Meeting Notes January 7th, 2021: Meeting Notes","title":"2021"},{"location":"committee/product/#2020","text":"December 3rd, 2020: Meeting Notes November 5th, 2020: Meeting Notes October 1st, 2020: Meeting Notes September 3rd, 2020: Meeting Notes August 6th, 2020: Meeting Notes July 2nd, 2020: Meeting Notes June 4th, 2020: Meeting Notes May 7th, 2020: Meeting Notes April 2nd, 2020: Meeting Notes No formal meeting in March 2020 February 6th, 2020: Meeting Notes January 9th, 2020: Meeting Notes","title":"2020"},{"location":"committee/product/#2019","text":"No formal meeting in December 2019 November 14th, 2019: Meeting Notes October 3rd, 2019: Meeting Notes September 5th, 2019: Meeting Notes August 8th, 2019: Meeting Notes July 11th, 2019: Meeting Notes June 7th, 2019: Meeting Notes May 2nd, 2019: Meeting Notes No formal meeting in April 2019 March 7th, 2019: Meeting Notes February 7th, 2019: Meeting Notes January 3rd, 2019: Meeting Notes","title":"2019"},{"location":"committee/product/#2018","text":"December 6th, 2018: Meeting Notes November 1st, 2018: Meeting Notes October 4th, 2018: Meeting Notes September 6th, 2018: Meeting Notes No formal meeting in August 2018 July 5th, 2018: Meeting Notes June 7th, 2018: Meeting Notes No formal meeting in May 2018 April 5th, 2018: Meeting Notes March 14th, 2018: Meeting Notes No formal meeting in February 2018 January 4th, 2018: Meeting Notes","title":"2018"},{"location":"committee/product/#2017","text":"December 7th, 2017: Meeting Notes No formal meeting in November 2017 October 12th, 2017: Meeting Notes No formal meeting in September 2017 August 3rd, 2017: Meeting Notes July 6th, 2017: Meeting Notes June 1st, 2017: Meeting Notes No formal meeting in May 2017 April 13th, 2017: Meeting Notes March 21st, 2017: Meeting Notes","title":"2017"},{"location":"committee/product/#members","text":"Jeff Bartig Yan Berthier Jack Carrozzo - Chair Yolandi Cloete Matt Griswold - Vice Chair Martin Hannigan Peter Helmenstine Paul Hoogsteder Aaron Hughes - Board Liaison Laurent Jarbinet Stephen McManus Arnold Nipper Terry Sweetser Leo Vegoda - Product Manager","title":"Members"},{"location":"committee/product/charter/","text":"PeeringDB Product Committee Charter Approved by Board July 7th, 2017 Scope The PeeringDB Product Committee (PC) is charged with steering the future product development and running the market outreach efforts to continuously improve the value that PeeringDB delivers to the networks registered with PeeringDB, and the broader community. Out of scope The PC does not drive PeeringDB improvements related to the administrative interfaces & functions used by the PeeringDB Admin Committee. The PC does not consider PeeringDB improvements related to the server, storage, hosting or network infrastructure. Deliverables Gather inputs from stakeholders regarding the evolution of PeeringDB in terms of product features and overall long term objectives. Formulate the long term objectives and validate them with the PeeringDB Board and the members of the PeeringDB Governance mailing list. Document and maintain workflow process to handle requests and issues. Maintain the product roadmap and feature request backlog and makes them publicly accessible. Create and maintain PeeringDB product documentation and presentation materials. Develop market outreach and evangelization to increase the uptake of PeeringDB use and improve data quality. Propose new features or enhancements based on the long term objectives and validates significant product evolutions with key stakeholders. Collaboration The PC shall work with other PeeringDB committees to ensure an equitable division of development resources in recognition of the volunteer efforts that are ensuring the daily operations. Participation The PeeringDB Product Committee members serve a 2 years renewable term, potential volunteers may submit their candidacy to the PeeringDB Board. The product committee will select their own Chair and Vice Chair by simple majority vote. The Board may add or remove members at any time it deems necessary. Communication Questions and suggestions for the Product Committee can be sent to productcom@lists.peeringdb.com The committee will use a range of mechanisms for communication and community input gathering efforts, including the PeeringDB Governance Mailinglist pdb-gov@lists.peeringdb.com Decisions, including their rationale, will be documented in GitHub issues All issues and the product roadmap and feature backlog can be found at in GitHub issues Decision policy Product Committee members will decide by simple majority vote on contested issues called by the Product Committee Chair. PeeringDB Common Committee Charter Provisions: Dispute resolution If the committee handles an issue in a manner in which a user believes that their view has not been adequately considered, their first action should be to raise the concern with the Committee Chair for further consideration. If the dispute is between the user and the Committee Chair then the issue may alternatively be raised with the Committee Vice Chair. If the dispute cannot be resolved the matter may be brought forward to the PeeringDB Board. The decision by the PeeringDB Board shall be final. Committee Chair and Vice Chair The committee elects their Chair and Vice Chair from among their members, subject to PeeringDB Board approval. The Chair and Vice Chair work as a team and distribute the workload between themselves as they deem appropriate. Decisions should be unanimous, however the final decision on any matter is with the Chair. In case the Chair becomes unavailable, the Vice Chair may assume the position of Acting Chair. If the Chair or Vice Chair become permanently unavailable, replacement(s) are elected from the remaining committee members, subject to PeeringDB Board approval.","title":"Charter"},{"location":"committee/product/charter/#peeringdb-product-committee-charter","text":"Approved by Board July 7th, 2017","title":"PeeringDB Product Committee Charter"},{"location":"committee/product/charter/#scope","text":"The PeeringDB Product Committee (PC) is charged with steering the future product development and running the market outreach efforts to continuously improve the value that PeeringDB delivers to the networks registered with PeeringDB, and the broader community.","title":"Scope"},{"location":"committee/product/charter/#out-of-scope","text":"The PC does not drive PeeringDB improvements related to the administrative interfaces & functions used by the PeeringDB Admin Committee. The PC does not consider PeeringDB improvements related to the server, storage, hosting or network infrastructure.","title":"Out of scope"},{"location":"committee/product/charter/#deliverables","text":"Gather inputs from stakeholders regarding the evolution of PeeringDB in terms of product features and overall long term objectives. Formulate the long term objectives and validate them with the PeeringDB Board and the members of the PeeringDB Governance mailing list. Document and maintain workflow process to handle requests and issues. Maintain the product roadmap and feature request backlog and makes them publicly accessible. Create and maintain PeeringDB product documentation and presentation materials. Develop market outreach and evangelization to increase the uptake of PeeringDB use and improve data quality. Propose new features or enhancements based on the long term objectives and validates significant product evolutions with key stakeholders.","title":"Deliverables"},{"location":"committee/product/charter/#collaboration","text":"The PC shall work with other PeeringDB committees to ensure an equitable division of development resources in recognition of the volunteer efforts that are ensuring the daily operations.","title":"Collaboration"},{"location":"committee/product/charter/#participation","text":"The PeeringDB Product Committee members serve a 2 years renewable term, potential volunteers may submit their candidacy to the PeeringDB Board. The product committee will select their own Chair and Vice Chair by simple majority vote. The Board may add or remove members at any time it deems necessary.","title":"Participation"},{"location":"committee/product/charter/#communication","text":"Questions and suggestions for the Product Committee can be sent to productcom@lists.peeringdb.com The committee will use a range of mechanisms for communication and community input gathering efforts, including the PeeringDB Governance Mailinglist pdb-gov@lists.peeringdb.com Decisions, including their rationale, will be documented in GitHub issues All issues and the product roadmap and feature backlog can be found at in GitHub issues","title":"Communication"},{"location":"committee/product/charter/#decision-policy","text":"Product Committee members will decide by simple majority vote on contested issues called by the Product Committee Chair. PeeringDB Common Committee Charter Provisions:","title":"Decision policy"},{"location":"committee/product/charter/#dispute-resolution","text":"If the committee handles an issue in a manner in which a user believes that their view has not been adequately considered, their first action should be to raise the concern with the Committee Chair for further consideration. If the dispute is between the user and the Committee Chair then the issue may alternatively be raised with the Committee Vice Chair. If the dispute cannot be resolved the matter may be brought forward to the PeeringDB Board. The decision by the PeeringDB Board shall be final.","title":"Dispute resolution"},{"location":"committee/product/charter/#committee-chair-and-vice-chair","text":"The committee elects their Chair and Vice Chair from among their members, subject to PeeringDB Board approval. The Chair and Vice Chair work as a team and distribute the workload between themselves as they deem appropriate. Decisions should be unanimous, however the final decision on any matter is with the Chair. In case the Chair becomes unavailable, the Vice Chair may assume the position of Acting Chair. If the Chair or Vice Chair become permanently unavailable, replacement(s) are elected from the remaining committee members, subject to PeeringDB Board approval.","title":"Committee Chair and Vice Chair"},{"location":"committee/product/workflow/","text":"Decision making process and workflow Product Committee members are responsible for driving the development of PeeringDB. To do this, GitHub issues are used to track proposed and in progress work. Product Committee members play two roles in driving forward work: 1) As a shepherd - responsible for driving consensus for a given issue 2) As a stakeholder - voting on a consensus that has been reached Each Product Committee member will choose issues to shepherd to a decision. They will indicate responsibility for this task by assigning the issue to themselves and placing it in the Decide queue. To decide whether we act on a given issue that has been reported, a stakeholder group will be formed. This group will consist of Product Committee members, who are responsible for representing the users of PeeringDB. A stakeholder group on a given issue must consist of at least three Product Committee members, including the shepherding member. Any Product Committee member can be a stakeholder in the decision on an issue. They become a stakeholder on a given issue by either commenting on the issue on GitHub or participating in discussion of the issue on the Product Committee Mailing list. It is up to the shepherding member to help reach a unanimous consensus within the stakeholder group on what should be done with the issue - including not acting on it. If and only if there are opposing views on how to proceed, and unanimous consensus cannot be reached by the stakeholder committee members, decisions fall to the entire Product Committee (see below). The final proposal of how to resolve each issue, along with votes from stakeholders must be documented in the GitHub issue to be considered to have reached consensus. Product Committee members must document any offline discussion in the GitHub issue to ensure transparency of the discussion process. Issues in the Decide queue are regularly reviewed by the Product Committee to make sure the most impactful issues are being moved along to resolution. All issues in the Decide queue will be reviewed in the monthly Product Committee call to ensure stakeholders have reached consensus and to give members who have not participated in the issue an opportunity to participate. After an issue with consensus has been reviewed, Product Committee members who disagree with the proposal have five days after the monthly Product Committee call to vote against the proposed solution, otherwise the issue will move to the backlog. For any issues where consensus cannot be reached, an issue may move forward only if a quorum of 50% or more of the Product Committee has no more than 25% of the quorum in opposition to the issue.","title":"Workflow"},{"location":"committee/product/workflow/#decision-making-process-and-workflow","text":"Product Committee members are responsible for driving the development of PeeringDB. To do this, GitHub issues are used to track proposed and in progress work. Product Committee members play two roles in driving forward work: 1) As a shepherd - responsible for driving consensus for a given issue 2) As a stakeholder - voting on a consensus that has been reached Each Product Committee member will choose issues to shepherd to a decision. They will indicate responsibility for this task by assigning the issue to themselves and placing it in the Decide queue. To decide whether we act on a given issue that has been reported, a stakeholder group will be formed. This group will consist of Product Committee members, who are responsible for representing the users of PeeringDB. A stakeholder group on a given issue must consist of at least three Product Committee members, including the shepherding member. Any Product Committee member can be a stakeholder in the decision on an issue. They become a stakeholder on a given issue by either commenting on the issue on GitHub or participating in discussion of the issue on the Product Committee Mailing list. It is up to the shepherding member to help reach a unanimous consensus within the stakeholder group on what should be done with the issue - including not acting on it. If and only if there are opposing views on how to proceed, and unanimous consensus cannot be reached by the stakeholder committee members, decisions fall to the entire Product Committee (see below). The final proposal of how to resolve each issue, along with votes from stakeholders must be documented in the GitHub issue to be considered to have reached consensus. Product Committee members must document any offline discussion in the GitHub issue to ensure transparency of the discussion process. Issues in the Decide queue are regularly reviewed by the Product Committee to make sure the most impactful issues are being moved along to resolution. All issues in the Decide queue will be reviewed in the monthly Product Committee call to ensure stakeholders have reached consensus and to give members who have not participated in the issue an opportunity to participate. After an issue with consensus has been reviewed, Product Committee members who disagree with the proposal have five days after the monthly Product Committee call to vote against the proposed solution, otherwise the issue will move to the backlog. For any issues where consensus cannot be reached, an issue may move forward only if a quorum of 50% or more of the Product Committee has no more than 25% of the quorum in opposition to the issue.","title":"Decision making process and workflow"},{"location":"howto/api_keys/","text":"HOWTO: Get Started with API Keys 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, which prevents the database from 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. API What is our API? An Application Programming Interface (API) is a way for computer software to communicate with other computers software. Our API allows PeeringDB users to query and update PeeringDB programmatically. That means they can automate work instead of using the website. What Are API keys? An API key is a secret token for identifying and authenticating a user. That user can be an individual or an organization. That\u2019s why we support both user and organizational API keys. PeeringDB offers API keys for authenticating API requests. There are two main forms of API keys: User-level Organizational-level User-level API keys These API keys are tied to an individual user account and can be created from the user profile page. There are only two permission levels: a normal key will mirror the same permissions of the user, while a readonly key will have read only permissions to all the same namespaces as the user. Organization-level API keys These API keys are created and revoked from the organization admin panel. Each key gets its own custom permissions, which can be modified from the API Key Permissions panel. Each key must have an email attached to it. This is because keys may be allowed to create and modify data in PeeringDB, and we need a contact to reach out to in case of questions. You should use an organization-level API key for automation that should not be tied to individual users. Copy or write down keys immediately The full API key string is only ever exposed to the user or organization at its moment of creation . If this string is lost, then the user or organization should revoke that key and create and permission a new one. Command line example using Python and requests API keys allow developers to interact with their PeeringDB account programmatically, rather than through the website. Here is an example script in Python. It uses the module Requests to GET data about a particular Facility, and then sends a PUT request to modify that data. This example assumes we have an environment variable set with our API key. To do that from the command line, we can run: export API_KEY=\"[created api key string]\" Then the Python script would look like the following. First we get the API key from the environment: import os import requests API_KEY = os.environ.get(\"API_KEY\") We set the url for the Facility we want to interact with. Note the /api in the URL, which signals we are making calls to the REST API. URL = \"https://www.peeringdb.com/api/fac/1\" We set the headers to include our API key as authorization. Printing the headers variable should allow us to see the API key. headers = {\"Authorization\": \"Api-Key \" + API_KEY} print(headers) First we make a GET request, to simply get data about example Facility number 1 response = requests.get(URL, headers=headers) data = response.json()[\"data\"][0] print(data) Printing this data allows us to see what fields we would like to change. Let's say we decide to change the name of this facility. We overwrite the value for key \"name\" data[\"name\"] = \"Newly decided name\" Then we use a PUT request to send that modified data back to PeeringDB. Note that this time, we must provide data to the API, using the keyword argument \"data\" put_response = requests.put(URL, headers=headers, data=data) We can print the status code to see if our request was successful. print(put_response.status_code) This will return a code 200 to signal success. Additionally the content of the request should include data for the now modified Facility print(put_response.json()) Would return a dictionary of the values of the now modified Facility. Command line example using curl API keys provide a cleaner way to authenticate API requests. PeeringDB recommends the command line user creates a API_KEY variable like so export API_KEY=\"[created api key string]\" then requests can be made with Curl like in the following examples: GET The following request would return JSON data coresponding to the ChiX Internet Exchange. curl -H \"Authorization: Api-Key $API_KEY\" -H \"Content-Type: application/json\" -X GET https://www.peeringdb.com/api/ix/239 POST The following request would create a new Network under the organization United IX . curl -H \"Authorization: Api-Key $API_KEY\" -H \"Content-Type: application/json\" -X POST --data \"{\\\"\"org_id\"\\\":\\\"10843\\\", \\\"\"name\"\\\":\\\"Brand New Network\\\", \\\"\"asn\"\\\":\\\"63311\\\"}\" https://www.peeringdb.com/api/net PUT The following request would update the data about a particular Network, ChIX Route Servers , in particular changing the name to \"Edited Name\". curl -H \"Authorization: Api-Key $API_KEY\" -H \"Content-Type: application/json\" -X PUT --data \"{\\\"\"org_id\"\\\":\\\"10843\\\", \\\"\"name\"\\\":\\\"Edited Name\\\", \\\"\"asn\"\\\":\\\"33713\\\"}\" https://www.peeringdb.com/api/net/7889 DELETE The following request would delete the ChiX Internet Exchange. The API key holder would need delete privileges to that particular Exchange. curl -H \"Authorization: Api-Key $API_KEY\" -H \"Content-Type: application/json\" -X DELETE https://www.peeringdb.com/api/ix/239","title":"HOWTO: Get Started with API Keys"},{"location":"howto/api_keys/#howto-get-started-with-api-keys","text":"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, which prevents the database from 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.","title":"HOWTO: Get Started with API Keys"},{"location":"howto/api_keys/#api","text":"","title":"API"},{"location":"howto/api_keys/#what-is-our-api","text":"An Application Programming Interface (API) is a way for computer software to communicate with other computers software. Our API allows PeeringDB users to query and update PeeringDB programmatically. That means they can automate work instead of using the website.","title":"What is our API?"},{"location":"howto/api_keys/#what-are-api-keys","text":"An API key is a secret token for identifying and authenticating a user. That user can be an individual or an organization. That\u2019s why we support both user and organizational API keys. PeeringDB offers API keys for authenticating API requests. There are two main forms of API keys: User-level Organizational-level","title":"What Are API keys?"},{"location":"howto/api_keys/#user-level-api-keys","text":"These API keys are tied to an individual user account and can be created from the user profile page. There are only two permission levels: a normal key will mirror the same permissions of the user, while a readonly key will have read only permissions to all the same namespaces as the user.","title":"User-level API keys"},{"location":"howto/api_keys/#organization-level-api-keys","text":"These API keys are created and revoked from the organization admin panel. Each key gets its own custom permissions, which can be modified from the API Key Permissions panel. Each key must have an email attached to it. This is because keys may be allowed to create and modify data in PeeringDB, and we need a contact to reach out to in case of questions. You should use an organization-level API key for automation that should not be tied to individual users.","title":"Organization-level API keys"},{"location":"howto/api_keys/#copy-or-write-down-keys-immediately","text":"The full API key string is only ever exposed to the user or organization at its moment of creation . If this string is lost, then the user or organization should revoke that key and create and permission a new one.","title":"Copy or write down keys immediately"},{"location":"howto/api_keys/#command-line-example-using-python-and-requests","text":"API keys allow developers to interact with their PeeringDB account programmatically, rather than through the website. Here is an example script in Python. It uses the module Requests to GET data about a particular Facility, and then sends a PUT request to modify that data. This example assumes we have an environment variable set with our API key. To do that from the command line, we can run: export API_KEY=\"[created api key string]\" Then the Python script would look like the following. First we get the API key from the environment: import os import requests API_KEY = os.environ.get(\"API_KEY\") We set the url for the Facility we want to interact with. Note the /api in the URL, which signals we are making calls to the REST API. URL = \"https://www.peeringdb.com/api/fac/1\" We set the headers to include our API key as authorization. Printing the headers variable should allow us to see the API key. headers = {\"Authorization\": \"Api-Key \" + API_KEY} print(headers) First we make a GET request, to simply get data about example Facility number 1 response = requests.get(URL, headers=headers) data = response.json()[\"data\"][0] print(data) Printing this data allows us to see what fields we would like to change. Let's say we decide to change the name of this facility. We overwrite the value for key \"name\" data[\"name\"] = \"Newly decided name\" Then we use a PUT request to send that modified data back to PeeringDB. Note that this time, we must provide data to the API, using the keyword argument \"data\" put_response = requests.put(URL, headers=headers, data=data) We can print the status code to see if our request was successful. print(put_response.status_code) This will return a code 200 to signal success. Additionally the content of the request should include data for the now modified Facility print(put_response.json()) Would return a dictionary of the values of the now modified Facility.","title":"Command line example using Python and requests"},{"location":"howto/api_keys/#command-line-example-using-curl","text":"API keys provide a cleaner way to authenticate API requests. PeeringDB recommends the command line user creates a API_KEY variable like so export API_KEY=\"[created api key string]\" then requests can be made with Curl like in the following examples:","title":"Command line example using curl"},{"location":"howto/api_keys/#get","text":"The following request would return JSON data coresponding to the ChiX Internet Exchange. curl -H \"Authorization: Api-Key $API_KEY\" -H \"Content-Type: application/json\" -X GET https://www.peeringdb.com/api/ix/239","title":"GET"},{"location":"howto/api_keys/#post","text":"The following request would create a new Network under the organization United IX . curl -H \"Authorization: Api-Key $API_KEY\" -H \"Content-Type: application/json\" -X POST --data \"{\\\"\"org_id\"\\\":\\\"10843\\\", \\\"\"name\"\\\":\\\"Brand New Network\\\", \\\"\"asn\"\\\":\\\"63311\\\"}\" https://www.peeringdb.com/api/net","title":"POST"},{"location":"howto/api_keys/#put","text":"The following request would update the data about a particular Network, ChIX Route Servers , in particular changing the name to \"Edited Name\". curl -H \"Authorization: Api-Key $API_KEY\" -H \"Content-Type: application/json\" -X PUT --data \"{\\\"\"org_id\"\\\":\\\"10843\\\", \\\"\"name\"\\\":\\\"Edited Name\\\", \\\"\"asn\"\\\":\\\"33713\\\"}\" https://www.peeringdb.com/api/net/7889","title":"PUT"},{"location":"howto/api_keys/#delete","text":"The following request would delete the ChiX Internet Exchange. The API key holder would need delete privileges to that particular Exchange. curl -H \"Authorization: Api-Key $API_KEY\" -H \"Content-Type: application/json\" -X DELETE https://www.peeringdb.com/api/ix/239","title":"DELETE"},{"location":"howto/authenticate/","text":"HOWTO: Authenticate to PeeringDB This article explains the authentication mechanisms we offer. It also explains how organizations can apply policies for their affiliated users. Why authenticate? You don't need to login to make single queries to PeeringDB. But some features do require you to authenticate. Update the database If you want to make updates then you need to authenticate. You can update PeeringDB via the API if you want. So you can either login to the website to make changes, or automate them with tools if you prefer. Access contact data We encourage you to publish contact information for your facility, IXP, or network. You can choose to make contact information public but many organizations limit it to other PeeringDB users. So you\u2019ll need to authenticate if you want access to most contact information. Higher query limits Authenticated users are allowed more frequent API queries. They are also able to repeat an identical API query more frequently without being throttled. Help PeeringDB\u2019s operations team If you authenticate when you send queries, we can contact you if your PeeringDB use starts to cause an unexpected problem. If you don\u2019t authenticate then all we can do is restrict queries from your IP address. Password You can use password authentication. We recommend adding MFA to password authentication. Multi-factor authentication We support two MFA methods. You can either use a time-based one-time password, as defined in RFC 6238 or a FIDO U2F hardware token. You can configure these in your account profile. OAuth Some external services allow or require you to authenticate using your PeeringDB account. One example is networks' peering portals. They might use PeeringDB's OAuth service to ensure they can automate configuration. We have a guide to implementing PeeringDB's OAuth service for your application. Automating PeeringDB access API keys We support both user and organizational API keys. You should use organizational API keys when you don't want to tie your application to an individual. We have a detailed guide on how to create, configure, and use API keys. Authentication HTTP header The HTTP authentication header must use the same character set the connection is using. This example shows a request and HTTP response: $ curl -v -sG https://www.peeringdb.com/api/net/416 -H 'Authorization: Api-Key example.valid_apikey' 2>&1 | grep \\<\\ HTTP < HTTP/2 200 This example shows what happens if the API key is not authorized: $ curl -v -sG https://www.peeringdb.com/api/net/416 -H 'Authorization: Api-Key example.invalid_apikey' 2>&1 | grep \\<\\ HTTP < HTTP/2 401 Canonical URL The canonical URL for PeeringDB is https://www.peeringdb.com . There is a redirect from https://peeringdb.com but we strongly encourage use of the canonical URL since industry practice in software packages is to drop the authentication header upon redirect, as a safety precaution. Password authentication Using an API key for command line access is simple and more secure. Our guide on API keys explains how to create and manage keys, including setting read-only permissions, with examples.","title":"HOWTO: Authenticate to PeeringDB"},{"location":"howto/authenticate/#howto-authenticate-to-peeringdb","text":"This article explains the authentication mechanisms we offer. It also explains how organizations can apply policies for their affiliated users.","title":"HOWTO: Authenticate to PeeringDB"},{"location":"howto/authenticate/#why-authenticate","text":"You don't need to login to make single queries to PeeringDB. But some features do require you to authenticate.","title":"Why authenticate?"},{"location":"howto/authenticate/#update-the-database","text":"If you want to make updates then you need to authenticate. You can update PeeringDB via the API if you want. So you can either login to the website to make changes, or automate them with tools if you prefer.","title":"Update the database"},{"location":"howto/authenticate/#access-contact-data","text":"We encourage you to publish contact information for your facility, IXP, or network. You can choose to make contact information public but many organizations limit it to other PeeringDB users. So you\u2019ll need to authenticate if you want access to most contact information.","title":"Access contact data"},{"location":"howto/authenticate/#higher-query-limits","text":"Authenticated users are allowed more frequent API queries. They are also able to repeat an identical API query more frequently without being throttled.","title":"Higher query limits"},{"location":"howto/authenticate/#help-peeringdbs-operations-team","text":"If you authenticate when you send queries, we can contact you if your PeeringDB use starts to cause an unexpected problem. If you don\u2019t authenticate then all we can do is restrict queries from your IP address.","title":"Help PeeringDB\u2019s operations team"},{"location":"howto/authenticate/#password","text":"You can use password authentication. We recommend adding MFA to password authentication.","title":"Password"},{"location":"howto/authenticate/#multi-factor-authentication","text":"We support two MFA methods. You can either use a time-based one-time password, as defined in RFC 6238 or a FIDO U2F hardware token. You can configure these in your account profile.","title":"Multi-factor authentication"},{"location":"howto/authenticate/#oauth","text":"Some external services allow or require you to authenticate using your PeeringDB account. One example is networks' peering portals. They might use PeeringDB's OAuth service to ensure they can automate configuration. We have a guide to implementing PeeringDB's OAuth service for your application.","title":"OAuth"},{"location":"howto/authenticate/#automating-peeringdb-access","text":"","title":"Automating PeeringDB access"},{"location":"howto/authenticate/#api-keys","text":"We support both user and organizational API keys. You should use organizational API keys when you don't want to tie your application to an individual. We have a detailed guide on how to create, configure, and use API keys.","title":"API keys"},{"location":"howto/authenticate/#authentication-http-header","text":"The HTTP authentication header must use the same character set the connection is using. This example shows a request and HTTP response: $ curl -v -sG https://www.peeringdb.com/api/net/416 -H 'Authorization: Api-Key example.valid_apikey' 2>&1 | grep \\<\\ HTTP < HTTP/2 200 This example shows what happens if the API key is not authorized: $ curl -v -sG https://www.peeringdb.com/api/net/416 -H 'Authorization: Api-Key example.invalid_apikey' 2>&1 | grep \\<\\ HTTP < HTTP/2 401","title":"Authentication HTTP header"},{"location":"howto/authenticate/#canonical-url","text":"The canonical URL for PeeringDB is https://www.peeringdb.com . There is a redirect from https://peeringdb.com but we strongly encourage use of the canonical URL since industry practice in software packages is to drop the authentication header upon redirect, as a safety precaution.","title":"Canonical URL"},{"location":"howto/authenticate/#password-authentication","text":"Using an API key for command line access is simple and more secure. Our guide on API keys explains how to create and manage keys, including setting read-only permissions, with examples.","title":"Password authentication"},{"location":"howto/enable_require_2fa/","text":"HOWTO: Turn on 2FA and Require Users to Enable It What is 2FA? 2FA is two-factor authentication. Enabling 2FA for PeeringDB means you must both have an account password and another factor. We support both TOTP and U2F tokens as additional factors. There are many popular software and hardware devices supporting these standards. How do users enable 2FA? Click on your account name. Then click on the green \"Manage Two-Factor Authentication\" box and follow the instructions. How do organizations require users to enable it? In the Manage panel at the bottom of the screen, select the Users tab and check the box \"Require users in your organization to enable 2FA.\"","title":"HOWTO: Turn on 2FA and Require Users to Enable It"},{"location":"howto/enable_require_2fa/#howto-turn-on-2fa-and-require-users-to-enable-it","text":"","title":"HOWTO: Turn on 2FA and Require Users to Enable It"},{"location":"howto/enable_require_2fa/#what-is-2fa","text":"2FA is two-factor authentication. Enabling 2FA for PeeringDB means you must both have an account password and another factor. We support both TOTP and U2F tokens as additional factors. There are many popular software and hardware devices supporting these standards.","title":"What is 2FA?"},{"location":"howto/enable_require_2fa/#how-do-users-enable-2fa","text":"Click on your account name. Then click on the green \"Manage Two-Factor Authentication\" box and follow the instructions.","title":"How do users enable 2FA?"},{"location":"howto/enable_require_2fa/#how-do-organizations-require-users-to-enable-it","text":"In the Manage panel at the bottom of the screen, select the Users tab and check the box \"Require users in your organization to enable 2FA.\"","title":"How do organizations require users to enable it?"},{"location":"howto/get-started-carrier/","text":"HOWTO: Get Started with PeeringDB as a Carrier Operator About PeeringDB 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, which prevents the database from 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. Why? PeeringDB is the interconnection database. Registering information about your carrier in PeeringDB makes it visible to IXPs and network operators who want to use your services to bring in peer or connect to other parts of their own network. Getting started Routine use of PeeringDB can be automated using our API but this document is intended to help new carrier administrators get started. Carriers are set up using the web interface. Once this is done you can use the API to automate things that change regularly. This document focuses on the key steps for establishing your presence in PeeringDB and assumes you are using the web interface, which is available in 14 languages. If you need additional help getting started, please contact us at: support@peeringdb.com . What is a Carrier? The carrier object is used to describe providers offering L1 or L2 services in a facility . It is different from a net because that describes services provided at L3 and is linked to its autonomous system number. Information required You will need to create several database records, known as objects, to establish your presence in PeeringDB. Database objects organize relevant information. Most information is optional but sharing all the relevant information maximizes the benefit you get from listing in PeeringDB. You can create your entry with the minimum required data and add and update the information you share over time. To maximize the value of your entry in PeeringDB you\u2019ll probably want to include more than the minimum required information. Your company name is required. This information is not required but is useful: AKA - If your carrier has an alternative name you can show it here to improve visibility in searches Long name - If your carrier has a long name, you can show it here to improve visibility in searches Notes - this field, which supports Markdown , can be used to describe the characteristics of your carrier that would be most useful to PeeringDB users You can look at the information shared by other PeeringDB users to work out what your organization should be sharing. Database records to create User The org is the parent for the carrier but you will need to start the process by creating a user account. If you use a role account for a PeeringDB user you should update the password when people who had access to the role account leave your organization. If you use a ticketing system, please make sure it does not auto-respond in a way that generates a slew of new tickets. Org The org object is your organization\u2019s core record in PeeringDB. All it needs is an organization name but you can add extra value by including information about where your organization is located. You could specify as little as a country name or as much as a full postal address. Your org object will be assigned a numeric identifier, called its id . This is what will be referenced by any child carrier object. Carrier Once you have created your organization you may add the carrier object. You do this by using the Add Carrier tab in the \u201cManage\u201d menu below your organization. You then click the edit button in the top right of the carrier screen and indicate which facilities your carrier has a presence in. The manager of the facility needs to approve the association. Next steps This short document describes the first steps for getting set up in PeeringDB. Once you have established your presence you should consider sharing information that would be helpful to potential new participants.","title":"HOWTO: Get Started with PeeringDB as a Carrier Operator"},{"location":"howto/get-started-carrier/#howto-get-started-with-peeringdb-as-a-carrier-operator","text":"","title":"HOWTO: Get Started with PeeringDB as a Carrier Operator"},{"location":"howto/get-started-carrier/#about-peeringdb","text":"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, which prevents the database from 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.","title":"About PeeringDB"},{"location":"howto/get-started-carrier/#why","text":"PeeringDB is the interconnection database. Registering information about your carrier in PeeringDB makes it visible to IXPs and network operators who want to use your services to bring in peer or connect to other parts of their own network.","title":"Why?"},{"location":"howto/get-started-carrier/#getting-started","text":"Routine use of PeeringDB can be automated using our API but this document is intended to help new carrier administrators get started. Carriers are set up using the web interface. Once this is done you can use the API to automate things that change regularly. This document focuses on the key steps for establishing your presence in PeeringDB and assumes you are using the web interface, which is available in 14 languages. If you need additional help getting started, please contact us at: support@peeringdb.com .","title":"Getting started"},{"location":"howto/get-started-carrier/#what-is-a-carrier","text":"The carrier object is used to describe providers offering L1 or L2 services in a facility . It is different from a net because that describes services provided at L3 and is linked to its autonomous system number.","title":"What is a Carrier?"},{"location":"howto/get-started-carrier/#information-required","text":"You will need to create several database records, known as objects, to establish your presence in PeeringDB. Database objects organize relevant information. Most information is optional but sharing all the relevant information maximizes the benefit you get from listing in PeeringDB. You can create your entry with the minimum required data and add and update the information you share over time. To maximize the value of your entry in PeeringDB you\u2019ll probably want to include more than the minimum required information. Your company name is required. This information is not required but is useful: AKA - If your carrier has an alternative name you can show it here to improve visibility in searches Long name - If your carrier has a long name, you can show it here to improve visibility in searches Notes - this field, which supports Markdown , can be used to describe the characteristics of your carrier that would be most useful to PeeringDB users You can look at the information shared by other PeeringDB users to work out what your organization should be sharing.","title":"Information required"},{"location":"howto/get-started-carrier/#database-records-to-create","text":"","title":"Database records to create"},{"location":"howto/get-started-carrier/#user","text":"The org is the parent for the carrier but you will need to start the process by creating a user account. If you use a role account for a PeeringDB user you should update the password when people who had access to the role account leave your organization. If you use a ticketing system, please make sure it does not auto-respond in a way that generates a slew of new tickets.","title":"User"},{"location":"howto/get-started-carrier/#org","text":"The org object is your organization\u2019s core record in PeeringDB. All it needs is an organization name but you can add extra value by including information about where your organization is located. You could specify as little as a country name or as much as a full postal address. Your org object will be assigned a numeric identifier, called its id . This is what will be referenced by any child carrier object.","title":"Org"},{"location":"howto/get-started-carrier/#carrier","text":"Once you have created your organization you may add the carrier object. You do this by using the Add Carrier tab in the \u201cManage\u201d menu below your organization. You then click the edit button in the top right of the carrier screen and indicate which facilities your carrier has a presence in. The manager of the facility needs to approve the association.","title":"Carrier"},{"location":"howto/get-started-carrier/#next-steps","text":"This short document describes the first steps for getting set up in PeeringDB. Once you have established your presence you should consider sharing information that would be helpful to potential new participants.","title":"Next steps"},{"location":"howto/get-started-developing/","text":"HOWTO: Get Started with Developing for PeeringDB Technology We use Python with Django and MySQL. Django manages interaction with the database. We publish all our code on GitHub. We have documented how to set up our development environment. What to develop PeeringDB users can request features and report bugs by creating issues on GitHub . Review open issues to either find a project you\u2019d like to work on, or to see if there\u2019s an existing issue for the feature you want. If you want to develop a feature that has not been discussed on GitHub, you should either create an issue or contact us to discuss what you need. You can send a message to productcom@lists.peeringdb.com or contact any of the members of the Product Committee . If you want to develop code for an issue that has achieved consensus on GitHub, we suggest starting with issues labeled as \"Good first issue\". These are simple issues that will help you get a feel for PeeringDB. Style Before you start developing code look at how similar functions have been implemented. Use the same design as existing functions and develop unit tests for your code. We aim for 80% unit test coverage. You also need to run black on your code before submitting a pull request. We use black to ensure that all of our code has the same formatting. Reusing designs, developing unit tests, and using consistent formatting makes it easier for us to maintain the code over time. We keep the feature parity between the web interface and the API. A feature added to one needs to be added to the other. The implementation details documented in issues should be detailed enough to use as documentation for the web interface. Documentation is also needed for the API. The minimum we need for API documentation is an example of how to format the request and a pointer to the document section to update. Pull requests It's good to let us know which issues you are working on when you start work. It's also helpful if you include the issues being fixed in your pull request. Please include \"Fixes #issue\" for each issue addressed in your pull request. We can then close those issues when we deploy your code. What happens next? When you submit your pull request we will run continuous integration tests on the code. We'll also review it ourselves. We'll report on the output of the tests in comments on the pull request and let you know if you need to make any changes.","title":"HOWTO: Get Started with Developing for PeeringDB"},{"location":"howto/get-started-developing/#howto-get-started-with-developing-for-peeringdb","text":"","title":"HOWTO: Get Started with Developing for PeeringDB"},{"location":"howto/get-started-developing/#technology","text":"We use Python with Django and MySQL. Django manages interaction with the database. We publish all our code on GitHub. We have documented how to set up our development environment.","title":"Technology"},{"location":"howto/get-started-developing/#what-to-develop","text":"PeeringDB users can request features and report bugs by creating issues on GitHub . Review open issues to either find a project you\u2019d like to work on, or to see if there\u2019s an existing issue for the feature you want. If you want to develop a feature that has not been discussed on GitHub, you should either create an issue or contact us to discuss what you need. You can send a message to productcom@lists.peeringdb.com or contact any of the members of the Product Committee . If you want to develop code for an issue that has achieved consensus on GitHub, we suggest starting with issues labeled as \"Good first issue\". These are simple issues that will help you get a feel for PeeringDB.","title":"What to develop"},{"location":"howto/get-started-developing/#style","text":"Before you start developing code look at how similar functions have been implemented. Use the same design as existing functions and develop unit tests for your code. We aim for 80% unit test coverage. You also need to run black on your code before submitting a pull request. We use black to ensure that all of our code has the same formatting. Reusing designs, developing unit tests, and using consistent formatting makes it easier for us to maintain the code over time. We keep the feature parity between the web interface and the API. A feature added to one needs to be added to the other. The implementation details documented in issues should be detailed enough to use as documentation for the web interface. Documentation is also needed for the API. The minimum we need for API documentation is an example of how to format the request and a pointer to the document section to update.","title":"Style"},{"location":"howto/get-started-developing/#pull-requests","text":"It's good to let us know which issues you are working on when you start work. It's also helpful if you include the issues being fixed in your pull request. Please include \"Fixes #issue\" for each issue addressed in your pull request. We can then close those issues when we deploy your code.","title":"Pull requests"},{"location":"howto/get-started-developing/#what-happens-next","text":"When you submit your pull request we will run continuous integration tests on the code. We'll also review it ourselves. We'll report on the output of the tests in comments on the pull request and let you know if you need to make any changes.","title":"What happens next?"},{"location":"howto/get-started-exchange/","text":"HOWTO: Get Started with PeeringDB as an Exchange Operator About PeeringDB 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, which prevents the database from 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. Why? PeeringDB is the interconnection database. Registering information about your exchange in PeeringDB makes it visible to network operators who want to peer with others across your fabric. Getting started Routine use of PeeringDB can be automated using our API but this document is intended to help new exchange operators get started. Most exchange networks get set up using the web interface and then use the API to automate things that change regularly. This document focuses on the key steps for establishing your exchange\u2019s presence in PeeringDB and assumes you are using the web interface, which is available in 14 languages. If you need additional help getting started, please contact us at: support@peeringdb.com . Information required You will need to create several database records, known as objects, to establish your presence in PeeringDB. Database objects organize relevant information and document your exchange\u2019s current participants, making it attractive to new ones. Most information is optional but sharing all the relevant information maximises the benefit you get from listing in PeeringDB. You can create your entry with the minimum required data and add and update the information you share over time. To maximize the value of your entry in PeeringDB you\u2019ll probably want to include more than the minimum required information. This information is required: Company Name IPv4 and IPv6 Prefixes Contact information This information is not required but is useful: Facilities, where your service is available Link to traffic statistics Geographical information: city/country/continental region. That will help networks locate your exchange. Some exchanges share additional information. You can look at the information shared by other exchange operators to work out what your organization should be sharing. Database records to create User The org is the parent for the IX but you will need to start the process by creating a user account. If you use a role account for a PeeringDB user you should update the password when people who had access to the role account leave your organization. If you use a ticketing system, please make sure it does not auto-respond in a way that generates a slew of new tickets. Org The org object is your organization\u2019s core record in PeeringDB. All it needs is an organization name but you can add extra value by including information about where your organization is located. You could specify as little as a country name or as much as a full postal address. Your org object will be assigned a numeric identifier, called its id. This is what will be referenced by any child net objects. Ix Once you have created your organization you may add the ix object. You do this by using the Add Exchange tab in the \u201cManage\u201d menu below your organization. You\u2019ll be able to input either your IPv4 or IPv6 LAN prefix through this form and will then need to add the other by editing the object once it is created. Prefixes An IPv4 or IPv6 prefix is needed to register your IX. Once your IX is approved, please also provide the other prefix. For the IPv6 prefix a /64 mask is highly recommended. Please talk to support if you would like to use another mask. The prefix information is used to verify connections from your participants. Next steps This short document describes the first steps for getting set up in PeeringDB. Once you have established your presence you should consider sharing information that would be helpful to potential new participants. Things to consider sharing: Encourage your exchange participants to add PeeringDB entries when they join, leave or upgrade the capacity they have with the exchange We recommend you automate the process of publishing details about networks that peer at your exchange using an IX-F JSON export . For that provide an URL at \u201cIX-F Member Export URL\u201d and enable the import. The visibility flag lets you set who is able to see your URL. And the \u201cPreview\u201d button pops a new window showing what actions the next import causes. Many networks are building automation that relies on PeeringDB. If networks peering at your exchange don't have an up to date PeeringDB record this might stop their automation configuring sessions. Use the \u201cMTU\u201d field to specify the MTU at your exchange. The field \u201cDOT1Q\u201d may go away, so it is not recommended to use it. More information The PeeringDB Data Ownership Policy describes all the objects in PeeringDB.","title":"HOWTO: Get Started with PeeringDB as an Exchange Operator"},{"location":"howto/get-started-exchange/#howto-get-started-with-peeringdb-as-an-exchange-operator","text":"","title":"HOWTO: Get Started with PeeringDB as an Exchange Operator"},{"location":"howto/get-started-exchange/#about-peeringdb","text":"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, which prevents the database from 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.","title":"About PeeringDB"},{"location":"howto/get-started-exchange/#why","text":"PeeringDB is the interconnection database. Registering information about your exchange in PeeringDB makes it visible to network operators who want to peer with others across your fabric.","title":"Why?"},{"location":"howto/get-started-exchange/#getting-started","text":"Routine use of PeeringDB can be automated using our API but this document is intended to help new exchange operators get started. Most exchange networks get set up using the web interface and then use the API to automate things that change regularly. This document focuses on the key steps for establishing your exchange\u2019s presence in PeeringDB and assumes you are using the web interface, which is available in 14 languages. If you need additional help getting started, please contact us at: support@peeringdb.com .","title":"Getting started"},{"location":"howto/get-started-exchange/#information-required","text":"You will need to create several database records, known as objects, to establish your presence in PeeringDB. Database objects organize relevant information and document your exchange\u2019s current participants, making it attractive to new ones. Most information is optional but sharing all the relevant information maximises the benefit you get from listing in PeeringDB. You can create your entry with the minimum required data and add and update the information you share over time. To maximize the value of your entry in PeeringDB you\u2019ll probably want to include more than the minimum required information. This information is required: Company Name IPv4 and IPv6 Prefixes Contact information This information is not required but is useful: Facilities, where your service is available Link to traffic statistics Geographical information: city/country/continental region. That will help networks locate your exchange. Some exchanges share additional information. You can look at the information shared by other exchange operators to work out what your organization should be sharing.","title":"Information required"},{"location":"howto/get-started-exchange/#database-records-to-create","text":"","title":"Database records to create"},{"location":"howto/get-started-exchange/#user","text":"The org is the parent for the IX but you will need to start the process by creating a user account. If you use a role account for a PeeringDB user you should update the password when people who had access to the role account leave your organization. If you use a ticketing system, please make sure it does not auto-respond in a way that generates a slew of new tickets.","title":"User"},{"location":"howto/get-started-exchange/#org","text":"The org object is your organization\u2019s core record in PeeringDB. All it needs is an organization name but you can add extra value by including information about where your organization is located. You could specify as little as a country name or as much as a full postal address. Your org object will be assigned a numeric identifier, called its id. This is what will be referenced by any child net objects.","title":"Org"},{"location":"howto/get-started-exchange/#ix","text":"Once you have created your organization you may add the ix object. You do this by using the Add Exchange tab in the \u201cManage\u201d menu below your organization. You\u2019ll be able to input either your IPv4 or IPv6 LAN prefix through this form and will then need to add the other by editing the object once it is created.","title":"Ix"},{"location":"howto/get-started-exchange/#prefixes","text":"An IPv4 or IPv6 prefix is needed to register your IX. Once your IX is approved, please also provide the other prefix. For the IPv6 prefix a /64 mask is highly recommended. Please talk to support if you would like to use another mask. The prefix information is used to verify connections from your participants.","title":"Prefixes"},{"location":"howto/get-started-exchange/#next-steps","text":"This short document describes the first steps for getting set up in PeeringDB. Once you have established your presence you should consider sharing information that would be helpful to potential new participants. Things to consider sharing: Encourage your exchange participants to add PeeringDB entries when they join, leave or upgrade the capacity they have with the exchange We recommend you automate the process of publishing details about networks that peer at your exchange using an IX-F JSON export . For that provide an URL at \u201cIX-F Member Export URL\u201d and enable the import. The visibility flag lets you set who is able to see your URL. And the \u201cPreview\u201d button pops a new window showing what actions the next import causes. Many networks are building automation that relies on PeeringDB. If networks peering at your exchange don't have an up to date PeeringDB record this might stop their automation configuring sessions. Use the \u201cMTU\u201d field to specify the MTU at your exchange. The field \u201cDOT1Q\u201d may go away, so it is not recommended to use it.","title":"Next steps"},{"location":"howto/get-started-exchange/#more-information","text":"The PeeringDB Data Ownership Policy describes all the objects in PeeringDB.","title":"More information"},{"location":"howto/get-started-facility/","text":"HOWTO: Get Started with PeeringDB as a Facility or Campus Operator About PeeringDB 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, which prevents the database from 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. Why? PeeringDB is the interconnection database. Registering information about your facility in PeeringDB makes it visible to network operators who want to connect to exchanges or other networks in your facility. Getting started Routine use of PeeringDB can be automated using our API but this document is intended to help new facility administrators get started. Facilities are set up using the web interface. Once this is done you can use the API to automate things that change regularly. This document focuses on the key steps for establishing your facility's presence in PeeringDB and assumes you are using the web interface, which is available in 14 languages. If you need additional help getting started, please contact us at: support@peeringdb.com . Information required You will need to create several database records, known as objects, to establish your presence in PeeringDB. Database objects organize relevant information. Your facility\u2019s current participants can add their presence in your facility, making it attractive to others. Most information is optional but sharing all the relevant information maximizes the benefit you get from listing in PeeringDB. You can create your entry with the minimum required data and add and update the information you share over time. To maximize the value of your entry in PeeringDB you\u2019ll probably want to include more than the minimum required information. This information is required: Company Name Full street address This information is not required but is useful: AKA - If your facility has an alternative name you can show it here to improve visibility in searches Long name - If your facility has a long name, you can show it here to improve visibility in searches Floor - If your facility does not fill an entire building Suite - If your facility does not fill an entire building CLLI - this is a location code used in parts of the US telecommunications industry and is most useful to facilities located in the USA Notes - this field, which supports Markdown , can be used to describe the characteristics of your facility that would be most useful to PeeringDB users You can look at the information shared by other facility managers to work out what your organization should be sharing. Database records to create User The org is the parent for the facility but you will need to start the process by creating a user account. If you use a role account for a PeeringDB user you should update the password when people who had access to the role account leave your organization. If you use a ticketing system, please make sure it does not auto-respond in a way that generates a slew of new tickets. Org The org object is your organization\u2019s core record in PeeringDB. All it needs is an organization name but you can add extra value by including information about where your organization is located. You could specify as little as a country name or as much as a full postal address. Your org object will be assigned a numeric identifier, called its id . This is what will be referenced by any child facility object. Facility Once you have created your organization you may add the facility object. You do this by using the Add Facility tab in the \u201cManage\u201d menu below your organization. Campus A campus is two or more facilities owned by the same organization where customers can get inter-facility cross-connects. When you have two facilities you can create a campus using the Add Campus tab in the \u201cManage\u201d menu below your organization. PeeringDB relies on facility operators to decide whether their interconnected facilities should be listed as a campus. Facilities need to be within 50 kilometers of each other. The software enforces this limit to help users avoid configuration mistakes. Next steps This short document describes the first steps for getting set up in PeeringDB. Once you have established your presence you should consider sharing information that would be helpful to potential new participants. Things to consider sharing: Encourage the networks and Internet Exchanges to also register with PeeringDB, and to indicate their presence in your facility. Thus making their presence visible to others and so increasing the possibility of interconnection with other networks. More information The PeeringDB Data Ownership Policy describes all the objects in PeeringDB.","title":"HOWTO: Get Started with PeeringDB as a Facility or Campus Operator"},{"location":"howto/get-started-facility/#howto-get-started-with-peeringdb-as-a-facility-or-campus-operator","text":"","title":"HOWTO: Get Started with PeeringDB as a Facility or Campus Operator"},{"location":"howto/get-started-facility/#about-peeringdb","text":"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, which prevents the database from 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.","title":"About PeeringDB"},{"location":"howto/get-started-facility/#why","text":"PeeringDB is the interconnection database. Registering information about your facility in PeeringDB makes it visible to network operators who want to connect to exchanges or other networks in your facility.","title":"Why?"},{"location":"howto/get-started-facility/#getting-started","text":"Routine use of PeeringDB can be automated using our API but this document is intended to help new facility administrators get started. Facilities are set up using the web interface. Once this is done you can use the API to automate things that change regularly. This document focuses on the key steps for establishing your facility's presence in PeeringDB and assumes you are using the web interface, which is available in 14 languages. If you need additional help getting started, please contact us at: support@peeringdb.com .","title":"Getting started"},{"location":"howto/get-started-facility/#information-required","text":"You will need to create several database records, known as objects, to establish your presence in PeeringDB. Database objects organize relevant information. Your facility\u2019s current participants can add their presence in your facility, making it attractive to others. Most information is optional but sharing all the relevant information maximizes the benefit you get from listing in PeeringDB. You can create your entry with the minimum required data and add and update the information you share over time. To maximize the value of your entry in PeeringDB you\u2019ll probably want to include more than the minimum required information. This information is required: Company Name Full street address This information is not required but is useful: AKA - If your facility has an alternative name you can show it here to improve visibility in searches Long name - If your facility has a long name, you can show it here to improve visibility in searches Floor - If your facility does not fill an entire building Suite - If your facility does not fill an entire building CLLI - this is a location code used in parts of the US telecommunications industry and is most useful to facilities located in the USA Notes - this field, which supports Markdown , can be used to describe the characteristics of your facility that would be most useful to PeeringDB users You can look at the information shared by other facility managers to work out what your organization should be sharing.","title":"Information required"},{"location":"howto/get-started-facility/#database-records-to-create","text":"","title":"Database records to create"},{"location":"howto/get-started-facility/#user","text":"The org is the parent for the facility but you will need to start the process by creating a user account. If you use a role account for a PeeringDB user you should update the password when people who had access to the role account leave your organization. If you use a ticketing system, please make sure it does not auto-respond in a way that generates a slew of new tickets.","title":"User"},{"location":"howto/get-started-facility/#org","text":"The org object is your organization\u2019s core record in PeeringDB. All it needs is an organization name but you can add extra value by including information about where your organization is located. You could specify as little as a country name or as much as a full postal address. Your org object will be assigned a numeric identifier, called its id . This is what will be referenced by any child facility object.","title":"Org"},{"location":"howto/get-started-facility/#facility","text":"Once you have created your organization you may add the facility object. You do this by using the Add Facility tab in the \u201cManage\u201d menu below your organization.","title":"Facility"},{"location":"howto/get-started-facility/#campus","text":"A campus is two or more facilities owned by the same organization where customers can get inter-facility cross-connects. When you have two facilities you can create a campus using the Add Campus tab in the \u201cManage\u201d menu below your organization. PeeringDB relies on facility operators to decide whether their interconnected facilities should be listed as a campus. Facilities need to be within 50 kilometers of each other. The software enforces this limit to help users avoid configuration mistakes.","title":"Campus"},{"location":"howto/get-started-facility/#next-steps","text":"This short document describes the first steps for getting set up in PeeringDB. Once you have established your presence you should consider sharing information that would be helpful to potential new participants. Things to consider sharing: Encourage the networks and Internet Exchanges to also register with PeeringDB, and to indicate their presence in your facility. Thus making their presence visible to others and so increasing the possibility of interconnection with other networks.","title":"Next steps"},{"location":"howto/get-started-facility/#more-information","text":"The PeeringDB Data Ownership Policy describes all the objects in PeeringDB.","title":"More information"},{"location":"howto/get-started-operator/","text":"HOWTO: Get Started with PeeringDB as a Network Operator About PeeringDB 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, which prevents the database from 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. Why should I add my network? Almost one-third of Autonomous System Numbers (ASNs) register their interconnection data in the PeeringDB database. That means, by using PeeringDB and adding your own interconnection data, you\u2019ll be able to confidently find information about networks looking to interconnect, where and how to connect with them, and they\u2019ll be able to find the same information about your network. Since the database is user-maintained and validated by our volunteers, you can trust that the information is accurate and up-to-date. This data will help you to accelerate the process of finding and connecting with other networks while supporting a faster and more decisive deployment of your own network expansion and development plans. Many networks are building automation that relies on PeeringDB. If you don't have an up to date PeeringDB record this might stop their automation configuring sessions. Getting started Routine use of PeeringDB can be automated using our API but this document is intended to help new networks get started. Most networks get set up using the web interface and then use the API to automate things that change regularly. This document focuses on the key steps for establishing your network\u2019s presence in PeeringDB and assumes you are using the web interface, which is available in 14 languages. If you need additional help getting started, please contact us at: support@peeringdb.com . Information required You will need to create several database records, known as objects, to establish your presence in PeeringDB. Database objects organize relevant information and document the connections making your network attractive to potential peers. Most information is optional but the less you share the less likely your network will benefit from listing itself in PeeringDB. You can create your entry with the minimum required data and add and update the information you share over time. To maximize the value of your entry in PeeringDB you\u2019ll probably want to include more than the minimum required information. This information is required: Company name AS number Contact information (mandatory for networks with a connection to an Internet Exchange) This information is not required but is useful: IRR information Network type Network operational area (so-called geographic scope) Some networks share additional information. You can look at the information shared by your peers and potential peers to work out what your network should be sharing. Database records to create Some objects have a notes field to share additional information. You can use Markdown formatting for the notes to make them more readable. User The org is the parent for the network but you will need to start the process by creating a user account. We recommend that you use an e-mail address that exists in the publicly available contact information for the network\u2019s ASN so that we can automatically validate your affiliation with the network. If you use a role account for a PeeringDB user you should update the password when people who had access to the role account leave your organization. If you use a ticketing system, please make sure it does not auto-respond in a way that generates a slew of new tickets. Org The org object is your organization\u2019s core record in PeeringDB. All it needs is an organization name but you can add extra value by including information about where your organization is located. You could specify as little as a country name or as much as a full postal address. Your org object will be assigned a numeric identifier, called its id . This is what will be referenced by any child net objects. Net Basic network information is automatically retrieved from the RIR or NIR\u2019s database based on the AS Number. Brand names or other identifiers can be listed in the aka field. For example: name: Example Org Legal Entity aka: Example Superfast Networks, Example Reliable Hosting Permissions to grant Once you are up and running you can create POC (Point of Contact) objects for functional contacts with your network. Not all networks need all POCs. These are: Abuse Maintenance NOC Policy Public Relations Sales Technical The information for each type of contact is the same, with optional telephone numbers, e-mail addresses, and URLs. Visibility of the POC information can be different for each POC. Each of the POCs associated with your network can have different visibility permissions. The options are: Users (meaning that only other PeeringDB users can see the POC), and Public (meaning that the record is shown to anonymous users as well as authenticated users). Some organizations will want to make their Abuse, Public Relations, and/or Sales POCs Public but limit the visibility of other POCs to authenticated Users . If your network will be present at Public Peering Exchange Points you can grant them permission to add and modify entries for your network via their ixp_member data . You grant permission using the \u201cAllow IXP Update\u201d box, which will show when you add a Public Peering Exchange Point. Next steps This short document describes the first steps for getting set up in PeeringDB. Once you have established your presence you should consider sharing information with current and potential peers about your network(s). Things to consider sharing: We recommend you include the name of your AS-SET or ROUTE-SET if you have multiple net objects. Edit your network object to provide information about your routing policy, traffic ratios and more. What is the maximum number of IPv4 and/or IPv6 prefixes should peers expect to see advertised by your network? You can use the info_prefixes4 and info_prefixes6 with integer values to share this information. How much traffic crosses your network and in which direction? You can share this information using the info_traffic and info_ratio attributes in your net object. You can enter numbers or pre-defined ranges for both attributes. Do you have a peering policy? If you do you can use the various policy attributes on your net object to communicate it to potential peers. More information The PeeringDB Data Ownership Policy describes all the objects in PeeringDB.","title":"HOWTO: Get Started with PeeringDB as a Network Operator"},{"location":"howto/get-started-operator/#howto-get-started-with-peeringdb-as-a-network-operator","text":"","title":"HOWTO: Get Started with PeeringDB as a Network Operator"},{"location":"howto/get-started-operator/#about-peeringdb","text":"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, which prevents the database from 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.","title":"About PeeringDB"},{"location":"howto/get-started-operator/#why-should-i-add-my-network","text":"Almost one-third of Autonomous System Numbers (ASNs) register their interconnection data in the PeeringDB database. That means, by using PeeringDB and adding your own interconnection data, you\u2019ll be able to confidently find information about networks looking to interconnect, where and how to connect with them, and they\u2019ll be able to find the same information about your network. Since the database is user-maintained and validated by our volunteers, you can trust that the information is accurate and up-to-date. This data will help you to accelerate the process of finding and connecting with other networks while supporting a faster and more decisive deployment of your own network expansion and development plans. Many networks are building automation that relies on PeeringDB. If you don't have an up to date PeeringDB record this might stop their automation configuring sessions.","title":"Why should I add my network?"},{"location":"howto/get-started-operator/#getting-started","text":"Routine use of PeeringDB can be automated using our API but this document is intended to help new networks get started. Most networks get set up using the web interface and then use the API to automate things that change regularly. This document focuses on the key steps for establishing your network\u2019s presence in PeeringDB and assumes you are using the web interface, which is available in 14 languages. If you need additional help getting started, please contact us at: support@peeringdb.com .","title":"Getting started"},{"location":"howto/get-started-operator/#information-required","text":"You will need to create several database records, known as objects, to establish your presence in PeeringDB. Database objects organize relevant information and document the connections making your network attractive to potential peers. Most information is optional but the less you share the less likely your network will benefit from listing itself in PeeringDB. You can create your entry with the minimum required data and add and update the information you share over time. To maximize the value of your entry in PeeringDB you\u2019ll probably want to include more than the minimum required information. This information is required: Company name AS number Contact information (mandatory for networks with a connection to an Internet Exchange) This information is not required but is useful: IRR information Network type Network operational area (so-called geographic scope) Some networks share additional information. You can look at the information shared by your peers and potential peers to work out what your network should be sharing.","title":"Information required"},{"location":"howto/get-started-operator/#database-records-to-create","text":"Some objects have a notes field to share additional information. You can use Markdown formatting for the notes to make them more readable.","title":"Database records to create"},{"location":"howto/get-started-operator/#user","text":"The org is the parent for the network but you will need to start the process by creating a user account. We recommend that you use an e-mail address that exists in the publicly available contact information for the network\u2019s ASN so that we can automatically validate your affiliation with the network. If you use a role account for a PeeringDB user you should update the password when people who had access to the role account leave your organization. If you use a ticketing system, please make sure it does not auto-respond in a way that generates a slew of new tickets.","title":"User"},{"location":"howto/get-started-operator/#org","text":"The org object is your organization\u2019s core record in PeeringDB. All it needs is an organization name but you can add extra value by including information about where your organization is located. You could specify as little as a country name or as much as a full postal address. Your org object will be assigned a numeric identifier, called its id . This is what will be referenced by any child net objects.","title":"Org"},{"location":"howto/get-started-operator/#net","text":"Basic network information is automatically retrieved from the RIR or NIR\u2019s database based on the AS Number. Brand names or other identifiers can be listed in the aka field. For example: name: Example Org Legal Entity aka: Example Superfast Networks, Example Reliable Hosting","title":"Net"},{"location":"howto/get-started-operator/#permissions-to-grant","text":"Once you are up and running you can create POC (Point of Contact) objects for functional contacts with your network. Not all networks need all POCs. These are: Abuse Maintenance NOC Policy Public Relations Sales Technical The information for each type of contact is the same, with optional telephone numbers, e-mail addresses, and URLs. Visibility of the POC information can be different for each POC. Each of the POCs associated with your network can have different visibility permissions. The options are: Users (meaning that only other PeeringDB users can see the POC), and Public (meaning that the record is shown to anonymous users as well as authenticated users). Some organizations will want to make their Abuse, Public Relations, and/or Sales POCs Public but limit the visibility of other POCs to authenticated Users . If your network will be present at Public Peering Exchange Points you can grant them permission to add and modify entries for your network via their ixp_member data . You grant permission using the \u201cAllow IXP Update\u201d box, which will show when you add a Public Peering Exchange Point.","title":"Permissions to grant"},{"location":"howto/get-started-operator/#next-steps","text":"This short document describes the first steps for getting set up in PeeringDB. Once you have established your presence you should consider sharing information with current and potential peers about your network(s). Things to consider sharing: We recommend you include the name of your AS-SET or ROUTE-SET if you have multiple net objects. Edit your network object to provide information about your routing policy, traffic ratios and more. What is the maximum number of IPv4 and/or IPv6 prefixes should peers expect to see advertised by your network? You can use the info_prefixes4 and info_prefixes6 with integer values to share this information. How much traffic crosses your network and in which direction? You can share this information using the info_traffic and info_ratio attributes in your net object. You can enter numbers or pre-defined ranges for both attributes. Do you have a peering policy? If you do you can use the various policy attributes on your net object to communicate it to potential peers.","title":"Next steps"},{"location":"howto/get-started-operator/#more-information","text":"The PeeringDB Data Ownership Policy describes all the objects in PeeringDB.","title":"More information"},{"location":"howto/make-a-security-report/","text":"HOWTO: Report a Security Issue to PeeringDB PeeringDB works hard to keep its systems and data as secure as possible. If you are a security researcher and have discovered a security vulnerability in one of our services, we appreciate your help in disclosing it to us in a responsible manner. Our responsible disclosure policy is not an invitation to actively hack and potentially disrupt our system and services. We reserve the right to sue researchers for penetrating or attempting to penetrate our systems. PeeringDB does not permit the following types of security research While we encourage you to discover and report to us any vulnerabilities you find in a responsible manner, the following conduct is prohibited: Performing actions that may negatively affect PeeringDB or its users (e.g. any form of Denial of Service attacks) Accessing, or attempting to access, data or information that does not belong to you Destroying or corrupting, or attempting to destroy or corrupt, data or information that does not belong to you Conducting any kind of physical or electronic attack on PeeringDB personnel, property or data centers Using social engineering to target any PeeringDB team member Violating any laws or breaching any agreements to discover vulnerabilities Scope of the network The following is in scope: The www.peeringdb.com website and any of its sub-domains, services, APIs and infrastructure. Any (internet-facing) infrastructure owned and operated by PeeringDB. Exclusions The following list of issues have already been reported to our Security team, reviewed, and deemed out of scope for the purposes of this program. Please do not report any of the following classes of issues. Unless there are exceptional circumstances or novel attacks, these issues will be rejected: Missing, or not 'properly' configured SPF, DKIM or DMARC records. The presence of public services such as robots.txt or FTP. The availability of DNS zone transfers. Reports of old software versions without a working Proof of Concept of an exploit. This is not an exclusive list. If you report a vulnerability that has already been reported by someone else, we will let you know. In that case you are not eligible for our Security Hall of Fame or swag. What we request from you Please do not share the issue with others until it has been resolved. Please do not publish anything about the resolved issue unless this has been discussed with us. Email your findings to security@peeringdb.com. You may submit a notification under a pseudonym. Please provide enough information for us to reproduce the issue so that we can resolve it as soon as possible. Please delete all confidential information obtained through the vulnerability as soon as possible after reporting it. Please do this after consulting us to make sure that we can reproduce the issue. What we promise We will act with urgency and necessary resources to resolve the issue. We will strive to respond to your report within three business days with our evaluation of the report and an expected resolution date. We will handle your report with strict confidentiality and not pass on your personal details to third parties without your permission. After a major security issue has been solved, we will publish a report on our website explaining the vulnerability discovered and how we fixed it. If you agree to have your name used in the report, we will credit you. Note that we will only credit the first person that reported a specific vulnerability to us. After your vulnerability report is verified, the security team will inform you if you are eligible. We will send you a unique token of our gratitude, such as a personalized cup, hat, or hoodie. We do not issue monetary rewards for reported vulnerabilities.","title":"HOWTO: Report a Security Issue to PeeringDB"},{"location":"howto/make-a-security-report/#howto-report-a-security-issue-to-peeringdb","text":"PeeringDB works hard to keep its systems and data as secure as possible. If you are a security researcher and have discovered a security vulnerability in one of our services, we appreciate your help in disclosing it to us in a responsible manner. Our responsible disclosure policy is not an invitation to actively hack and potentially disrupt our system and services. We reserve the right to sue researchers for penetrating or attempting to penetrate our systems.","title":"HOWTO: Report a Security Issue to PeeringDB"},{"location":"howto/make-a-security-report/#peeringdb-does-not-permit-the-following-types-of-security-research","text":"While we encourage you to discover and report to us any vulnerabilities you find in a responsible manner, the following conduct is prohibited: Performing actions that may negatively affect PeeringDB or its users (e.g. any form of Denial of Service attacks) Accessing, or attempting to access, data or information that does not belong to you Destroying or corrupting, or attempting to destroy or corrupt, data or information that does not belong to you Conducting any kind of physical or electronic attack on PeeringDB personnel, property or data centers Using social engineering to target any PeeringDB team member Violating any laws or breaching any agreements to discover vulnerabilities","title":"PeeringDB does not permit the following types of security research"},{"location":"howto/make-a-security-report/#scope-of-the-network","text":"The following is in scope: The www.peeringdb.com website and any of its sub-domains, services, APIs and infrastructure. Any (internet-facing) infrastructure owned and operated by PeeringDB.","title":"Scope of the network"},{"location":"howto/make-a-security-report/#exclusions","text":"The following list of issues have already been reported to our Security team, reviewed, and deemed out of scope for the purposes of this program. Please do not report any of the following classes of issues. Unless there are exceptional circumstances or novel attacks, these issues will be rejected: Missing, or not 'properly' configured SPF, DKIM or DMARC records. The presence of public services such as robots.txt or FTP. The availability of DNS zone transfers. Reports of old software versions without a working Proof of Concept of an exploit. This is not an exclusive list. If you report a vulnerability that has already been reported by someone else, we will let you know. In that case you are not eligible for our Security Hall of Fame or swag.","title":"Exclusions"},{"location":"howto/make-a-security-report/#what-we-request-from-you","text":"Please do not share the issue with others until it has been resolved. Please do not publish anything about the resolved issue unless this has been discussed with us. Email your findings to security@peeringdb.com. You may submit a notification under a pseudonym. Please provide enough information for us to reproduce the issue so that we can resolve it as soon as possible. Please delete all confidential information obtained through the vulnerability as soon as possible after reporting it. Please do this after consulting us to make sure that we can reproduce the issue.","title":"What we request from you"},{"location":"howto/make-a-security-report/#what-we-promise","text":"We will act with urgency and necessary resources to resolve the issue. We will strive to respond to your report within three business days with our evaluation of the report and an expected resolution date. We will handle your report with strict confidentiality and not pass on your personal details to third parties without your permission. After a major security issue has been solved, we will publish a report on our website explaining the vulnerability discovered and how we fixed it. If you agree to have your name used in the report, we will credit you. Note that we will only credit the first person that reported a specific vulnerability to us. After your vulnerability report is verified, the security team will inform you if you are eligible. We will send you a unique token of our gratitude, such as a personalized cup, hat, or hoodie. We do not issue monetary rewards for reported vulnerabilities.","title":"What we promise"},{"location":"howto/manage-permissions/","text":"HOWTO: Manage User Permissions Do I need a PeeringDB account? You only need a PeeringDB user account if you want to do one of three things: Access contact information Create, update, or delete entries in PeeringDB Use PeeringDB to login to external services, using the PeeringDB OAuth service . If you just want to look up information about networks, exchanges, or facilities in PeeringDB, you can do that without an account using the web interface or the API . How can I manage permissions for users affiliated with my organization? Unless you want your users to manage parts of the data your organization publishes, they don\u2019t need to be affiliated with your organization. When you allow a user account to affiliate with your organization, you can delegate some permissions to it. You can delegate them permissions related to exchanges, facilities, and networks. For each type of entry you can delegate permissions to create, update, or delete. The table below shows an example for an affiliated user who has only been delegated permission to update the organization\u2019s net object. Create Update Delete Campus No No No Carriers No No No Exchanges No No No Facilities No No No Networks No Yes No Admin users for an organization can do all these things and can delegate granular permissions to users based on the needs of their organization. How do I give permissions to a user who is already affiliated with other organizations? User accounts can be associated with multiple organizations. For instance, a consultant could be associated with each of their client\u2019s organizations. Similarly, a large organization composed of several operating companies could have a different organization for each operating company in PeeringDB and have some users affiliated with those instead of trying to centralize control. The user just needs to request, and be granted affiliation with each organization whose data they will be updating in PeeringDB. How do I authenticate at external services using my PeeringDB account? If your organization operates a network and has the Autonomous System registered with PeeringDB, your users can use their PeeringDB accounts to authenticate at external services that have enabled PeeringDB\u2019s OAuth service. In mid-2021 about 150 applications had enabled PeeringDB OAuth. It is used to facilitate peering requests, use network telemetry services, and more.","title":"HOWTO: Manage User Permissions"},{"location":"howto/manage-permissions/#howto-manage-user-permissions","text":"","title":"HOWTO: Manage User Permissions"},{"location":"howto/manage-permissions/#do-i-need-a-peeringdb-account","text":"You only need a PeeringDB user account if you want to do one of three things: Access contact information Create, update, or delete entries in PeeringDB Use PeeringDB to login to external services, using the PeeringDB OAuth service . If you just want to look up information about networks, exchanges, or facilities in PeeringDB, you can do that without an account using the web interface or the API .","title":"Do I need a PeeringDB account?"},{"location":"howto/manage-permissions/#how-can-i-manage-permissions-for-users-affiliated-with-my-organization","text":"Unless you want your users to manage parts of the data your organization publishes, they don\u2019t need to be affiliated with your organization. When you allow a user account to affiliate with your organization, you can delegate some permissions to it. You can delegate them permissions related to exchanges, facilities, and networks. For each type of entry you can delegate permissions to create, update, or delete. The table below shows an example for an affiliated user who has only been delegated permission to update the organization\u2019s net object. Create Update Delete Campus No No No Carriers No No No Exchanges No No No Facilities No No No Networks No Yes No Admin users for an organization can do all these things and can delegate granular permissions to users based on the needs of their organization.","title":"How can I manage permissions for users affiliated with my organization?"},{"location":"howto/manage-permissions/#how-do-i-give-permissions-to-a-user-who-is-already-affiliated-with-other-organizations","text":"User accounts can be associated with multiple organizations. For instance, a consultant could be associated with each of their client\u2019s organizations. Similarly, a large organization composed of several operating companies could have a different organization for each operating company in PeeringDB and have some users affiliated with those instead of trying to centralize control. The user just needs to request, and be granted affiliation with each organization whose data they will be updating in PeeringDB.","title":"How do I give permissions to a user who is already affiliated with other organizations?"},{"location":"howto/manage-permissions/#how-do-i-authenticate-at-external-services-using-my-peeringdb-account","text":"If your organization operates a network and has the Autonomous System registered with PeeringDB, your users can use their PeeringDB accounts to authenticate at external services that have enabled PeeringDB\u2019s OAuth service. In mid-2021 about 150 applications had enabled PeeringDB OAuth. It is used to facilitate peering requests, use network telemetry services, and more.","title":"How do I authenticate at external services using my PeeringDB account?"},{"location":"howto/member_vote/","text":"HOWTO: Become a PeeringDB Member and Vote PeeringDB is a membership organization. We do not charge for membership. You become a member when you have data in PeeringDB and subscribe to our governance mailing list. When you are a member, you may attend Members\u2019 Meetings and vote in elections. How is PeeringDB governed? PeeringDB members elect our board. The board elects officers (President, Vice President, Secretary/Treasurer) and appoints committees. The board, the officers, the chairs of the committees, and the Product Manager are the PeeringDB Stewards. Non-board Stewards are responsible for keeping the board informed. The board and officers hold fiduciary responsibility for PeeringDB as a legal entity. How do I become a member? Make sure you have data in PeeringDB (see other HOWTOs ). Join the pdb-gov mailing list . You are now a member. How can I vote? Each member is entitled to one vote. Members who are affiliated with each other share a single vote. For instance, if Big Company owns Small Company they may only have one vote between them, not one vote each. At the start of the election process, the Secretary/Treasurer will ask each member to nominate a single authorized voter. The Secretary will send each authorized voter an invitation to vote. Can I join a committee? Yes! Volunteers run our committees. They are: Admin \u2013 provides support to our users Operations \u2013 keeps PeeringDB services running smoothly Outreach \u2013 keeps the interconnection community aware of PeeringDB activity Product \u2013 reviews and refines PeeringDB\u2019s product design If you want to join a committee, send a message to stewards@peeringdb.com . Where can I learn more? We publish detailed governance documentation and records on our governance website .","title":"HOWTO: Become a PeeringDB Member and Vote"},{"location":"howto/member_vote/#howto-become-a-peeringdb-member-and-vote","text":"PeeringDB is a membership organization. We do not charge for membership. You become a member when you have data in PeeringDB and subscribe to our governance mailing list. When you are a member, you may attend Members\u2019 Meetings and vote in elections.","title":"HOWTO: Become a PeeringDB Member and Vote"},{"location":"howto/member_vote/#how-is-peeringdb-governed","text":"PeeringDB members elect our board. The board elects officers (President, Vice President, Secretary/Treasurer) and appoints committees. The board, the officers, the chairs of the committees, and the Product Manager are the PeeringDB Stewards. Non-board Stewards are responsible for keeping the board informed. The board and officers hold fiduciary responsibility for PeeringDB as a legal entity.","title":"How is PeeringDB governed?"},{"location":"howto/member_vote/#how-do-i-become-a-member","text":"Make sure you have data in PeeringDB (see other HOWTOs ). Join the pdb-gov mailing list . You are now a member.","title":"How do I become a member?"},{"location":"howto/member_vote/#how-can-i-vote","text":"Each member is entitled to one vote. Members who are affiliated with each other share a single vote. For instance, if Big Company owns Small Company they may only have one vote between them, not one vote each. At the start of the election process, the Secretary/Treasurer will ask each member to nominate a single authorized voter. The Secretary will send each authorized voter an invitation to vote.","title":"How can I vote?"},{"location":"howto/member_vote/#can-i-join-a-committee","text":"Yes! Volunteers run our committees. They are: Admin \u2013 provides support to our users Operations \u2013 keeps PeeringDB services running smoothly Outreach \u2013 keeps the interconnection community aware of PeeringDB activity Product \u2013 reviews and refines PeeringDB\u2019s product design If you want to join a committee, send a message to stewards@peeringdb.com .","title":"Can I join a committee?"},{"location":"howto/member_vote/#where-can-i-learn-more","text":"We publish detailed governance documentation and records on our governance website .","title":"Where can I learn more?"},{"location":"howto/organizational_policy/","text":"HOWTO: Manage Organizational Policy Your organization can apply policies for its users in the Manage section of the organization profile. Restrict email domains You can set a policy that only allows users to affiliate when their email address uses a specific domain. You can set a list of the domains your organization allows. If users do not meet the policy when it is configured they will not lose their affiliation. You will be notified so you can manage the change with your users. A user with multiple email addresses associated with their account only needs one address to match. For instance, if the policy requires users to have an example.com address and the user has both an example.com and an example.net address, the user can affiliate. Periodic validation of user\u2019s contact information You can require users to validate the contact information for their PeeringDB user account. You set the time after which the validation process will be run. The default is 1 year but you can set it as short as 1 week. This options is managed in the same control panel shown in the image above. When an unvalidated user tries to login a link will be sent to their email address. They will need to go to that web page to validate their contact information before they can login. Some users are affiliated with multiple organizations. When this is the case, the link will be sent to the most suitable address for that organization. When a user is affiliated with multiple organizations, those organizations can set different revalidation periods. The user\u2019s affiliation is suspended at the end of the validation counter only for that organization. For example, Alice is affiliated to Example Networks and Example Facilities. Example Networks requires users to validate after 90 days but Example Facilities requires users to revalidate after a year. If Alice validates to both organizations on 1 January, she will remain a valid user for Example Facilities until the end of the year but will need to validate for Example Networks on 1 April. Multiple email addresses per user Users may have multiple email addresses associated with their account. They must select one address as the primary address and this will be used for notifications. This is managed in each user's own profile, which is located in the hamburger menu by the user's username. Each email address can only be associated with one user. When a user with multiple email addresses associated with their account wants to remove the primary address, they will have to select another address as the primary address.","title":"HOWTO: Manage Organizational Policy"},{"location":"howto/organizational_policy/#howto-manage-organizational-policy","text":"Your organization can apply policies for its users in the Manage section of the organization profile.","title":"HOWTO: Manage Organizational Policy"},{"location":"howto/organizational_policy/#restrict-email-domains","text":"You can set a policy that only allows users to affiliate when their email address uses a specific domain. You can set a list of the domains your organization allows. If users do not meet the policy when it is configured they will not lose their affiliation. You will be notified so you can manage the change with your users. A user with multiple email addresses associated with their account only needs one address to match. For instance, if the policy requires users to have an example.com address and the user has both an example.com and an example.net address, the user can affiliate.","title":"Restrict email domains"},{"location":"howto/organizational_policy/#periodic-validation-of-users-contact-information","text":"You can require users to validate the contact information for their PeeringDB user account. You set the time after which the validation process will be run. The default is 1 year but you can set it as short as 1 week. This options is managed in the same control panel shown in the image above. When an unvalidated user tries to login a link will be sent to their email address. They will need to go to that web page to validate their contact information before they can login. Some users are affiliated with multiple organizations. When this is the case, the link will be sent to the most suitable address for that organization. When a user is affiliated with multiple organizations, those organizations can set different revalidation periods. The user\u2019s affiliation is suspended at the end of the validation counter only for that organization. For example, Alice is affiliated to Example Networks and Example Facilities. Example Networks requires users to validate after 90 days but Example Facilities requires users to revalidate after a year. If Alice validates to both organizations on 1 January, she will remain a valid user for Example Facilities until the end of the year but will need to validate for Example Networks on 1 April.","title":"Periodic validation of user\u2019s contact information"},{"location":"howto/organizational_policy/#multiple-email-addresses-per-user","text":"Users may have multiple email addresses associated with their account. They must select one address as the primary address and this will be used for notifications. This is managed in each user's own profile, which is located in the hamburger menu by the user's username. Each email address can only be associated with one user. When a user with multiple email addresses associated with their account wants to remove the primary address, they will have to select another address as the primary address.","title":"Multiple email addresses per user"},{"location":"howto/peeringdb-py/","text":"HOWTO: Install peeringdb-py You can install peeringdb-py on a wide selection of operating systems. Users have installed it on several Linux distributions, macOS, and Windows Subsystem for Linux. It will give you a local version of PeeringDB\u2019s SQL database. Unlike the PeeringDB API, the SQL data structure might change without notice. Please do not build tools that make SQL queries. We suggest using our library to make API calls on your local cache. We maintain the library and commit to maintaining the API functionality, even if the underlying database structure changes. Please let us know if you find a query that is only possible with SQL and not via the API. Either create an issue in GitHub , or send a mail describing the problems to support@peeringdb.com . PeeringDB credentials You only need a PeeringDB account if you want to synchronize the contact information to your peeringdb-py cache. If you want to synchronize the whole database, including the contact data, you will need an API Key. If you are installing peeringdb-py for organizational use you should use an organizational API Key. You can use an API Key tied to a user account for personal use. We have a HOWTO guide for API Keys . Software requirements You must ensure these these packages are installed to install and use peeringdb-py : - git - pip - python - virtualenv You will also need to have a database installed. The configuration defaults to using SQLite. Database peeringdb-py \u2019s defaults to an SQLite3 database. You can choose to use a different database. If you want to do this you must adjust the database engine statement in the config.yaml , which is placed in your .peeringdb/config.yaml , which sits in your home directory. Whichever database you choose, it must use UTF-8 as the character set. Installation instructions for peeringdb-py Create a directory for peeringdb-py and go there mkdir ~/peeringdb-py && cd ~/peeringdb-py Create a virtual environment virtualenv --python=python3 pdbvenv Activate the virtual environment source pdbvenv/bin/activate Install peeringdb-py Run pip to install the local cache and Django. sh pip install --upgrade pip setuptools pip install peeringdb django-peeringdb # check for which version of django suits you # when in doubt use the LTS version from https://www.djangoproject.com/download/ pip install \"django>=3.2,<3.3\" Create a peeringdb-py configuration file peeringdb config set -n Edit your configuration edit [HOME]/.peeringdb/config.yaml . Make sure you adjust the directory name. Replace [HOME] with the relevant file path. Replace [CENSORED] with your own API Key, if you are authenticating. Remove [CENSORED] if you choose to remain anonymous. Anonymous users cannot see some contact information. orm: backend: django_peeringdb database: engine: sqlite3 host: '' name: [HOME]/peeringdb-py/peeringdb.sqlite3 password: '' port: 0 user: '' migrate: true secret_key: '' sync: api_key: [CENSORED] only: [] password: '' strip_tz: 1 timeout: 0 url: https://www.peeringdb.com/api user: '' Check that the software is installed This will confirm that peeringdb-py is running by showing you the software version: peeringdb --version You will see something like: peeringdb 1.2.1.1 This will confirm that Django is running by showing you the software version: django-admin --version You will see something like: 2.2.28 This will show that you have django-peeringdb installed and what version it is. pip freeze | grep django-peeringdb You will see something like this: django-peeringdb==2.14.1 Synchronize your new local cache This will synchronize your local cache with the server and tell you how long it took. time peeringdb sync You will see something like this: real 14m47.515s user 14m27.077s sys 0m1.939s If you wait and then synchronize again you'll get the changes since your initial sync. The process does not pull the full database, making it a very efficient update process. You will see a faster synchronization for updates than the initial pull. time peeringdb sync The times you see will look something like this: real 0m3.110s user 0m1.074s sys 0m0.088s Fetch private data The initial sync will happen from the public cache, which does not contain data that isn't available to unauthenticated requests, such as network contacts that are set to Users visibility. In order to fetch this data you can pass the --fetch-private argument. Note that you will need to have valid authentication set up for this (preferably with an API key), for example: peeringdb sync --fetch-private Automatically refreshing data You can schedule automatic database updates by creating an entry in your crontab. We recommend synchronizing every hour. You should not synchronize on the hour but offset at a random minute in the hour. This distributes users across the hour and reduces the burden on the server. This will open your default editor and allow you to create a scheduled task. crontab -e Place this entry in your crontab and save the file, changing [HOME] to the relevant file path. 00 * * * * sleep $[RANDOM\\%300] ; cd [HOME]/peeringdb-py ; touch peeringdb.sync.log ; date >> peeringdb.sync.log ; ./pdbvenv/bin/peeringdb sync >> peeringdb.sync.log 2>&1 Confirm what is scheduled: crontab -l Upgrade peeringdb-py to the latest version sh pip install --upgrade peeringdb django-peeringdb Example usage The SQL data structure might change without notice. Please do not build tools that make SQL queries. We suggest using our library to make API calls on your local cache. We maintain the library and commit to maintaining the API functionality, even if the underlying database structure changes.","title":"HOWTO: Install peeringdb-py"},{"location":"howto/peeringdb-py/#howto-install-peeringdb-py","text":"You can install peeringdb-py on a wide selection of operating systems. Users have installed it on several Linux distributions, macOS, and Windows Subsystem for Linux. It will give you a local version of PeeringDB\u2019s SQL database. Unlike the PeeringDB API, the SQL data structure might change without notice. Please do not build tools that make SQL queries. We suggest using our library to make API calls on your local cache. We maintain the library and commit to maintaining the API functionality, even if the underlying database structure changes. Please let us know if you find a query that is only possible with SQL and not via the API. Either create an issue in GitHub , or send a mail describing the problems to support@peeringdb.com .","title":"HOWTO: Install peeringdb-py"},{"location":"howto/peeringdb-py/#peeringdb-credentials","text":"You only need a PeeringDB account if you want to synchronize the contact information to your peeringdb-py cache. If you want to synchronize the whole database, including the contact data, you will need an API Key. If you are installing peeringdb-py for organizational use you should use an organizational API Key. You can use an API Key tied to a user account for personal use. We have a HOWTO guide for API Keys .","title":"PeeringDB credentials"},{"location":"howto/peeringdb-py/#software-requirements","text":"You must ensure these these packages are installed to install and use peeringdb-py : - git - pip - python - virtualenv You will also need to have a database installed. The configuration defaults to using SQLite.","title":"Software requirements"},{"location":"howto/peeringdb-py/#database","text":"peeringdb-py \u2019s defaults to an SQLite3 database. You can choose to use a different database. If you want to do this you must adjust the database engine statement in the config.yaml , which is placed in your .peeringdb/config.yaml , which sits in your home directory. Whichever database you choose, it must use UTF-8 as the character set.","title":"Database"},{"location":"howto/peeringdb-py/#installation-instructions-for-peeringdb-py","text":"","title":"Installation instructions for peeringdb-py"},{"location":"howto/peeringdb-py/#create-a-directory-for-peeringdb-py-and-go-there","text":"mkdir ~/peeringdb-py && cd ~/peeringdb-py","title":"Create a directory for peeringdb-py and go there"},{"location":"howto/peeringdb-py/#create-a-virtual-environment","text":"virtualenv --python=python3 pdbvenv","title":"Create a virtual environment"},{"location":"howto/peeringdb-py/#activate-the-virtual-environment","text":"source pdbvenv/bin/activate","title":"Activate the virtual environment"},{"location":"howto/peeringdb-py/#install-peeringdb-py","text":"Run pip to install the local cache and Django. sh pip install --upgrade pip setuptools pip install peeringdb django-peeringdb # check for which version of django suits you # when in doubt use the LTS version from https://www.djangoproject.com/download/ pip install \"django>=3.2,<3.3\"","title":"Install peeringdb-py"},{"location":"howto/peeringdb-py/#create-a-peeringdb-py-configuration-file","text":"peeringdb config set -n","title":"Create a peeringdb-py configuration file"},{"location":"howto/peeringdb-py/#edit-your-configuration","text":"edit [HOME]/.peeringdb/config.yaml . Make sure you adjust the directory name. Replace [HOME] with the relevant file path. Replace [CENSORED] with your own API Key, if you are authenticating. Remove [CENSORED] if you choose to remain anonymous. Anonymous users cannot see some contact information. orm: backend: django_peeringdb database: engine: sqlite3 host: '' name: [HOME]/peeringdb-py/peeringdb.sqlite3 password: '' port: 0 user: '' migrate: true secret_key: '' sync: api_key: [CENSORED] only: [] password: '' strip_tz: 1 timeout: 0 url: https://www.peeringdb.com/api user: ''","title":"Edit your configuration"},{"location":"howto/peeringdb-py/#check-that-the-software-is-installed","text":"This will confirm that peeringdb-py is running by showing you the software version: peeringdb --version You will see something like: peeringdb 1.2.1.1 This will confirm that Django is running by showing you the software version: django-admin --version You will see something like: 2.2.28 This will show that you have django-peeringdb installed and what version it is. pip freeze | grep django-peeringdb You will see something like this: django-peeringdb==2.14.1","title":"Check that the software is installed"},{"location":"howto/peeringdb-py/#synchronize-your-new-local-cache","text":"This will synchronize your local cache with the server and tell you how long it took. time peeringdb sync You will see something like this: real 14m47.515s user 14m27.077s sys 0m1.939s If you wait and then synchronize again you'll get the changes since your initial sync. The process does not pull the full database, making it a very efficient update process. You will see a faster synchronization for updates than the initial pull. time peeringdb sync The times you see will look something like this: real 0m3.110s user 0m1.074s sys 0m0.088s","title":"Synchronize your new local cache"},{"location":"howto/peeringdb-py/#fetch-private-data","text":"The initial sync will happen from the public cache, which does not contain data that isn't available to unauthenticated requests, such as network contacts that are set to Users visibility. In order to fetch this data you can pass the --fetch-private argument. Note that you will need to have valid authentication set up for this (preferably with an API key), for example: peeringdb sync --fetch-private","title":"Fetch private data"},{"location":"howto/peeringdb-py/#automatically-refreshing-data","text":"You can schedule automatic database updates by creating an entry in your crontab. We recommend synchronizing every hour. You should not synchronize on the hour but offset at a random minute in the hour. This distributes users across the hour and reduces the burden on the server. This will open your default editor and allow you to create a scheduled task. crontab -e Place this entry in your crontab and save the file, changing [HOME] to the relevant file path. 00 * * * * sleep $[RANDOM\\%300] ; cd [HOME]/peeringdb-py ; touch peeringdb.sync.log ; date >> peeringdb.sync.log ; ./pdbvenv/bin/peeringdb sync >> peeringdb.sync.log 2>&1 Confirm what is scheduled: crontab -l","title":"Automatically refreshing data"},{"location":"howto/peeringdb-py/#upgrade-peeringdb-py-to-the-latest-version","text":"sh pip install --upgrade peeringdb django-peeringdb","title":"Upgrade peeringdb-py to the latest version"},{"location":"howto/peeringdb-py/#example-usage","text":"The SQL data structure might change without notice. Please do not build tools that make SQL queries. We suggest using our library to make API calls on your local cache. We maintain the library and commit to maintaining the API functionality, even if the underlying database structure changes.","title":"Example usage"},{"location":"howto/run_development_container/","text":"HOWTO: Setup a PeeringDB Development Environment Install and run Docker PeeringDB runs inside a Docker container. Docker Compose is used to build both the PeeringDB container and a MySQL server container for testing. Make sure the docker and docker-compose commands are installed on your system, and that the Docker Engine is running. Docker Desktop for Mac/Windows (>=2.5.0.1) includes these tools and they are also available for various POSIX systems. Ensure that docker-compose version indicates at least version 1.25.4, and that docker version indicates Engine version at least 19.03.5 and does not report any connection errors to Docker Engine. Connection errors may indicate a need to start the engine. Fork the PeeringDB repository, clone it, set upstream Your development and experimentation with the PeeringDB code base should take place in a fork of the project . When you have improvements or fixes to share, you will be able to point other developers to your code, or submit a pull request. Navigate to https://github.com/peeringdb/peeringdb . In the top-right corner of the page, click Fork . On GitHub, navigate to your fork of the PeeringDB repository. Above the list of files, click Code . Copy the HTTPS URL. It will be something like: https://github.com/YOUR-USERNAME/peeringdb.git Perform the following: PDBHOME=~/src/peeringdb # Adjust as appropriate to your environment. mkdir -p $PDBHOME && cd $PDBHOME git clone https://github.com/YOUR-USERNAME/peeringdb.git cd $PDBHOME/peeringdb # Henceforth commands on this page assume you are in this working directory. git remote add upstream https://github.com/peeringdb/peeringdb.git git remote -v > origin https://github.com/YOUR-USERNAME/peeringdb.git (fetch) > origin https://github.com/YOUR-USERNAME/peeringdb.git (push) > upstream https://github.com/peeringdb/peeringdb.git (fetch) > upstream https://github.com/peeringdb/peeringdb.git (push) Keep your fork up-to-date with the upstream repository: https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/syncing-a-fork git fetch upstream git checkout master # or other branch you are working on git merge upstream/master Create environment variable override file Environment variables for the server config can be added in Ctl/dev/.env . This file can be empty which will make the django SECRET_KEY ephemeral, but the file does need to exist. Empty file: touch Ctl/dev/.env Alternatively, create a SECRET_KEY using uuidgen or replace with something similar on your system: echo SECRET_KEY=\\\"$(uuidgen)\\\" > Ctl/dev/.env If you are serving from anywhere but localhost you will also need to specify the SESSION_COOKIE_DOMAIN echo \"SESSION_COOKIE_DOMAIN=example.com\" >> Ctl/dev/.env If you want to enable OIDC's JWT RS256 token signing, you need to specify the file with the RSA secret key found inside the container with the OIDC_RSA_PRIVATE_KEY_ACTIVE_PATH variable. You can create the key with open ssl and place it in Ctl/dev/jwks/filename.key or let the build system auto generated from the path specified with the variable. echo \"OIDC_RSA_PRIVATE_KEY_ACTIVE_PATH=/srv/www.peeringdb.com/var/jwks/oidc.key\" >> Ctl/dev/.env Build the container and set up your developement instance ./Ctl/dev/compose.sh build peeringdb ./Ctl/dev/compose.sh up -d database ./Ctl/dev/run.sh migrate # Re-run if there are errors. The database may not yet have started. ./Ctl/dev/run.sh loaddata fixtures/initial_data.json ./Ctl/dev/run.sh createsuperuser ./Ctl/dev/run.sh createcachetable ./Ctl/dev/compose.sh up -d peeringdb On some docker versions build can fail with a ERROR: Service 'peeringdb' failed to build: failed to export image: failed to create image: failed to get layer error. Simply running it again should fix the issue. If you want a copy of the current public production data, run this command which often takes more than 15 minutes: ./Ctl/dev/run.sh pdb_load_data --commit After it is done you should have a PeeringDB instance exposed on port :8000 : http://localhost:8000/ (should you want to change this port you can do so by setting the environment variable DJANGO_PORT ) Migration notes Organization management of OAuth applications Once migration 0085 has been applied you should override the OAUTH2_PROVIDER_APPLICATION_MODEL environment variable to \"peeringdb_server.OAuthApplication\" in order to enable organization management of oauth applications. Warning: Overriding before migration 0085 has been applied will result in the following migration error and a broken migration state. Related model 'peeringdb_server.oauthapplication` cannot be resolved Stop and start the containers ./Ctl/dev/compose.sh down ./Ctl/dev/compose.sh up -d Environment variables Edit Ctl/dev/.env and then stop and start the containers. PDB_NO_MIGRATE : If set to anything, will skip migrations when running the uwsgi command, otherwise, migrations will always be applied first thing while running uwsgi . DATABASE_ENGINE default \"mysql\" DATABASE_HOST default \"127.0.0.1\" DATABASE_PORT default \"\" DATABASE_NAME default \"peeringdb\" DATABASE_USER default \"peeringdb\" DATABASE_PASSWORD default \"\" EMAIL_HOST default \"localhost\" EMAIL_PORT default \"25\" EMAIL_HOST_USERHOST default \"\" EMAIL_HOST_PASSWORD default \"\" Mount points /srv/www.peeringdb.com/api-cache : api cache /srv/www.peeringdb.com/locale : translations /srv/www.peeringdb.com/mainsite : site settings /srv/www.peeringdb.com/media : media files /srv/www.peeringdb.com/peeringdb_server : server code /srv/www.peeringdb.com/static : static files /srv/www.peeringdb.com/var/log : log files Entry point With the exception of some specific commands (see below) the entry point will pass directly to django's manage script. ./Ctl/dev/run.sh help Other options: migrate apply database migrations run_tests run unit tests uwsgi start the uwsgi process /bin/sh to drop to shell inetd run the inetd whois server Contributing your code After testing and carefully code-reviewing your changes, commit and push them to your repository. You can then share the changes with other developers, such as those on the pdb-tech@lists.peeringdb.com mailing list: https://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech . When ready to contribute the change to the project, create a pull request to the main repository along with a description of your goals for the change and/or what you are fixing.","title":"HOWTO: Setup a PeeringDB Development Environment"},{"location":"howto/run_development_container/#howto-setup-a-peeringdb-development-environment","text":"","title":"HOWTO: Setup a PeeringDB Development Environment"},{"location":"howto/run_development_container/#install-and-run-docker","text":"PeeringDB runs inside a Docker container. Docker Compose is used to build both the PeeringDB container and a MySQL server container for testing. Make sure the docker and docker-compose commands are installed on your system, and that the Docker Engine is running. Docker Desktop for Mac/Windows (>=2.5.0.1) includes these tools and they are also available for various POSIX systems. Ensure that docker-compose version indicates at least version 1.25.4, and that docker version indicates Engine version at least 19.03.5 and does not report any connection errors to Docker Engine. Connection errors may indicate a need to start the engine.","title":"Install and run Docker"},{"location":"howto/run_development_container/#fork-the-peeringdb-repository-clone-it-set-upstream","text":"Your development and experimentation with the PeeringDB code base should take place in a fork of the project . When you have improvements or fixes to share, you will be able to point other developers to your code, or submit a pull request. Navigate to https://github.com/peeringdb/peeringdb . In the top-right corner of the page, click Fork . On GitHub, navigate to your fork of the PeeringDB repository. Above the list of files, click Code . Copy the HTTPS URL. It will be something like: https://github.com/YOUR-USERNAME/peeringdb.git Perform the following: PDBHOME=~/src/peeringdb # Adjust as appropriate to your environment. mkdir -p $PDBHOME && cd $PDBHOME git clone https://github.com/YOUR-USERNAME/peeringdb.git cd $PDBHOME/peeringdb # Henceforth commands on this page assume you are in this working directory. git remote add upstream https://github.com/peeringdb/peeringdb.git git remote -v > origin https://github.com/YOUR-USERNAME/peeringdb.git (fetch) > origin https://github.com/YOUR-USERNAME/peeringdb.git (push) > upstream https://github.com/peeringdb/peeringdb.git (fetch) > upstream https://github.com/peeringdb/peeringdb.git (push) Keep your fork up-to-date with the upstream repository: https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/syncing-a-fork git fetch upstream git checkout master # or other branch you are working on git merge upstream/master","title":"Fork the PeeringDB repository, clone it, set upstream"},{"location":"howto/run_development_container/#create-environment-variable-override-file","text":"Environment variables for the server config can be added in Ctl/dev/.env . This file can be empty which will make the django SECRET_KEY ephemeral, but the file does need to exist. Empty file: touch Ctl/dev/.env Alternatively, create a SECRET_KEY using uuidgen or replace with something similar on your system: echo SECRET_KEY=\\\"$(uuidgen)\\\" > Ctl/dev/.env If you are serving from anywhere but localhost you will also need to specify the SESSION_COOKIE_DOMAIN echo \"SESSION_COOKIE_DOMAIN=example.com\" >> Ctl/dev/.env If you want to enable OIDC's JWT RS256 token signing, you need to specify the file with the RSA secret key found inside the container with the OIDC_RSA_PRIVATE_KEY_ACTIVE_PATH variable. You can create the key with open ssl and place it in Ctl/dev/jwks/filename.key or let the build system auto generated from the path specified with the variable. echo \"OIDC_RSA_PRIVATE_KEY_ACTIVE_PATH=/srv/www.peeringdb.com/var/jwks/oidc.key\" >> Ctl/dev/.env","title":"Create environment variable override file"},{"location":"howto/run_development_container/#build-the-container-and-set-up-your-developement-instance","text":"./Ctl/dev/compose.sh build peeringdb ./Ctl/dev/compose.sh up -d database ./Ctl/dev/run.sh migrate # Re-run if there are errors. The database may not yet have started. ./Ctl/dev/run.sh loaddata fixtures/initial_data.json ./Ctl/dev/run.sh createsuperuser ./Ctl/dev/run.sh createcachetable ./Ctl/dev/compose.sh up -d peeringdb On some docker versions build can fail with a ERROR: Service 'peeringdb' failed to build: failed to export image: failed to create image: failed to get layer error. Simply running it again should fix the issue. If you want a copy of the current public production data, run this command which often takes more than 15 minutes: ./Ctl/dev/run.sh pdb_load_data --commit After it is done you should have a PeeringDB instance exposed on port :8000 : http://localhost:8000/ (should you want to change this port you can do so by setting the environment variable DJANGO_PORT )","title":"Build the container and set up your developement instance"},{"location":"howto/run_development_container/#migration-notes","text":"","title":"Migration notes"},{"location":"howto/run_development_container/#organization-management-of-oauth-applications","text":"Once migration 0085 has been applied you should override the OAUTH2_PROVIDER_APPLICATION_MODEL environment variable to \"peeringdb_server.OAuthApplication\" in order to enable organization management of oauth applications. Warning: Overriding before migration 0085 has been applied will result in the following migration error and a broken migration state. Related model 'peeringdb_server.oauthapplication` cannot be resolved","title":"Organization management of OAuth applications"},{"location":"howto/run_development_container/#stop-and-start-the-containers","text":"./Ctl/dev/compose.sh down ./Ctl/dev/compose.sh up -d","title":"Stop and start the containers"},{"location":"howto/run_development_container/#environment-variables","text":"Edit Ctl/dev/.env and then stop and start the containers. PDB_NO_MIGRATE : If set to anything, will skip migrations when running the uwsgi command, otherwise, migrations will always be applied first thing while running uwsgi . DATABASE_ENGINE default \"mysql\" DATABASE_HOST default \"127.0.0.1\" DATABASE_PORT default \"\" DATABASE_NAME default \"peeringdb\" DATABASE_USER default \"peeringdb\" DATABASE_PASSWORD default \"\" EMAIL_HOST default \"localhost\" EMAIL_PORT default \"25\" EMAIL_HOST_USERHOST default \"\" EMAIL_HOST_PASSWORD default \"\"","title":"Environment variables"},{"location":"howto/run_development_container/#mount-points","text":"/srv/www.peeringdb.com/api-cache : api cache /srv/www.peeringdb.com/locale : translations /srv/www.peeringdb.com/mainsite : site settings /srv/www.peeringdb.com/media : media files /srv/www.peeringdb.com/peeringdb_server : server code /srv/www.peeringdb.com/static : static files /srv/www.peeringdb.com/var/log : log files","title":"Mount points"},{"location":"howto/run_development_container/#entry-point","text":"With the exception of some specific commands (see below) the entry point will pass directly to django's manage script. ./Ctl/dev/run.sh help Other options: migrate apply database migrations run_tests run unit tests uwsgi start the uwsgi process /bin/sh to drop to shell inetd run the inetd whois server","title":"Entry point"},{"location":"howto/run_development_container/#contributing-your-code","text":"After testing and carefully code-reviewing your changes, commit and push them to your repository. You can then share the changes with other developers, such as those on the pdb-tech@lists.peeringdb.com mailing list: https://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech . When ready to contribute the change to the project, create a pull request to the main repository along with a description of your goals for the change and/or what you are fixing.","title":"Contributing your code"},{"location":"howto/search/","text":"HOWTO: Get Started with Search in PeeringDB Introduction to PeeringDB PeeringDB is a publicly available network database that is the go-to location for interconnection data. The database facilitates global network connections at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and it serves as a starting point for interconnection decisions. This online database is a non-profit, community-driven effort that encourages the exchange of Peering-related information and is totally managed and maintained by volunteers. It's a tool for the Internet's growth and enhancement. Why use PeeringDB to search for networks, exchange and data centers? About a third of networks (Autonomous Systems) use PeeringDB to share information about how they interconnect. You can use PeeringDB to find information about other networks, exchanges, and more. You make your services easier to find when you contribute your data to PeeringDB. You don't need an account to use the basic search functionality. But if you want to access private contact information and use advanced search features, like radius search, you'll need to sign up for an account. How to search for campuses, carriers, exchanges, facilities and networks in PeeringDB There is a s simple search box on the front page of PeeringDB. You can use it to search for campuses, carriers, exchanges, facilities and networks listed in PeeringDB by simply entering the name you want. Let\u2019s demonstrate with some examples to see how this works. Place name normalization PeeringDB normalizes place names at the presentation layer. For example, M\u00fcnchen will always be normalized to Munich in search output. This ensures that users can get all the results for Munich in a single search. Users can search using multiple names. As long as the name selected is well known, the search will be centered on the correct place. Networks For this example, we have this network KENET which is a non-profit operator for education and research and we want to search for it on PeeringDB. There are two ways to search for networks in PeeringDB: Name search You can search for networks by using the name of the networks by: - Entering the name of the network as seen below - From the search result, under the Networks section, locate the network you have searched - It would be visible if it is in the PeeringDB database ASN search You can search for networks using their ASN by: - Entering the name of the network as seen below, for the example below the ASN is (36914) - From the search result, under the Networks section, locate the network you have searched Note : Either of the two methods will get the same search results. Exchanges For this example, let\u2019s consider this exchange UNY-IX which is an open Internet exchange located in Universitas Negeri Yogyakarta. To search for an exchange: - Enter the name of the exchange as shown below - From the search result, under the exchanges section, locate the exchange you have searched Facilities Data centers are also referred to as facilities. For this example, let\u2019s consider this university University of Oslo which is an institution in Oslo. To search for a facility: - Enter the name of the data center or facility as shown below - From the search result, under the facilities section, locate the facility or data center you have searched How to search for your own organization If your organization already uses PeeringDB, when you are logged in to the website you can always find your own information using the self search. If you are not logged in, these links will take you to some PeeringDB examples objects. Organization Campus Carrier Facility Internet Exchange Point Network The self identifier also works for queries made using our API. We encourage the use of multi-factor authentication . This means using an API Key instead of basic authentication for API queries. How to use the search in PeeringDB extension The PeeringDB search extension is a free to use Google Chrome extension with which you can use to search for ASNs, networks, and exchanges in PeeringDB. To get started, go to the Chrome Web Store and download the extension, then enable it and add it to your extension bar. There are two ways to use the extension once it has been enabled: Using the Extension Bar Icon : Click the icon and type your search term into the box. The search will open in a new tab with the search result. Below is the result: Using the Context Menu : Right-click on any text on a page and select \"Search in PeeringDB\". The search will open in a new tab with the search result. Below is the result: If the query or highlighted text contains a number, the extension will attempt to find an ASN. How to search based on a partial name You can search based on a partial name. When an organization, network, facility or exchange name has two parts, you can search for just the first or second part and then select from all the organizations that share that name. This makes it easier to find the organization you want. This can also be helpful in a situation where you can not remember the name of the organization in full. In the example below, we want to search for \u201cinternet archive\u201d. We will search for it with a single part and not with the full name. In the search box, input \u201carchive''. This brings out a search result that have similar parts in their names. You can now search through the results to find the what you want. What is an advanced search? Advanced search in PeeringDB lets you explicitly filter a search location, network presence, service level and a wide range of other features. You get the results you\u2019re looking for and can export them in structured data formats (JSON or CSV), so you can import the data into tools that will help you make decisions. Note : You need to be logged in to PeeringDB in order to use some of the advanced search features, including the radius search. Let\u2019s take a look at this example below to demonstrate how advanced search works. We are going to search for an exchange within a particular region. On the front page of PeeringDB you will see the Advanced Search box which you can use to search for campuses, exchanges, facilities and networks that are in PeeringDB. Click on the Advanced Search link. This takes you to the advanced search landing page. The search page shows the campus, exchanges, facilities, networks, and organizations tabs. Go to the Exchanges tab, in the country field select a country of your choice by scrolling through the different options. On the right hand side, in the Network Presence field, enter the name of the network. You can follow the example shown below and add KENET. Click on the drop down list that appears as you input the network name. Click on Search. Scroll down to view information regarding the exchange that you searched for. Click on JSON or CSV to download the information in a structured format. Geographic search As new facilities are created in our database they will be linked to geographic coordinates. PeeringDB has improved search by changing the way it records data for location in its database. You can now search for facilities with a distance radius of a chosen coordinate. How to search for a campus You can search for a campus of facilities using the Advanced Search interface. Users can search from a country and city, and select a radius in kilometers or miles. Of course, you can achieve the same results using the API or the web interface, which means you can integrate this feature into your own tools. Note : You need to be logged in to PeeringDB in order to search for a campus of facilities. How to search for facilities within a given radius You can search for facilities within a given radius, using the Advanced Search interface. Users can search from a country and city, and select a radius in kilometers or miles. Of course, you can achieve the same results using the API or the web interface, which means you can integrate this feature into your own tools. Note : You need to be logged in to PeeringDB in order to search for facilities within a given radius. Login in or register an account on PeeringDB. On the front page of PeeringDB, click on the Advanced Search link. Go to the Facilities Tab and in the city/postal field add a city or postal of your choice. In the country field select a country of your choice. In the Within Distance field add a specified distance of your choice. On the right hand side of the page, click on search. Scroll down to view the information you searched for. The search result will bring up facilities which are in that country, city and state. You can download your information in a JSON or CSV format. Querying with the PeeringDB API Throughout this article up to this point, we have been talking on how to use PeeringDB to find information about potential peers, and then after peering has been arranged, using PeeringDB to obtain the peering details. The PeeringDB website is very helpful in these regards, but using the website still requires a lot of manual work. It\u2019s also possible to use the PeeringDB API to automate some parts of this. Why use the PeeringDB API? The PeeringDB API makes it easy to integrate PeeringDB in your environment. The PeeringDB database can be queried using a REST API. REST allows a client to request information from a server over HTTP or HTTPS. The server then returns the requested information in JSON format. Object types Each object has an associated shorthand tag you can use. Object types are not case sensitive and the output is an array. For example: https://www.peeringdb.com/api/OBJ . The endpoint is: /api/OBJ . Below are the categories of objects types (OBJ) in PeeringDB: - Basic Objects : org, fac, ix, net, poc - Derived Objects : ixlan, ixpfx, netixlan, netfac Basic objects Below is a description of what each of the object types mean and what information they return org : Root object for fac, ix, net, this holds information about an organization. fac : Describes a facility / colocation record, more useful information are in derived records netfac. ix : Describes an exchange, more useful information are in derived records ixlan, ixpfx and netixlan. net : Describes a network / ASN, more useful information are in netfac and netixlan. poc : Describes various role accounts (point of contact), this is currently only for net objects. as_set : Array of all AS-SETs corresponding to a network / ASN, this was introduced recently. Derived objects Below is a description of what each of the object types mean and what information they return. Ixlan : Describes the LAN of an ix, one ix may have multiple ixlan. This feature may go away in PeeringDB 3.0. ixpfx : Describes the IP range (IPv4 and IPv6) for an ixlan, one ixlan may have multiple ixpfx. netixlan : Describes the presence of a network at an exchange. netfac : Describes the presence of a network at a facility. Authentication Authentication is done through basic HTTP authorization. People who are accessing the API as a guest do not need any authentication. For example: curl -sG https://username:password@www.peeringdb.com/api/net/961 curl -u username:password https://www.peeringdb.com/api/net/961 Note : Access to contact information may be restricted if you are using the API as a guest without authentication. API usage is subject to query limits and these are set at a lower threshold for unauthenticated users. Making a request When making a request, the URL base is added with /api/ , followed by the object type and, if applicable, the object primary key (if applicable). For example: https://www.peeringdb.com/api/OBJ/id . If you want to select the output format, either use the Accept: HTTP header or use the extension type parameter: - Accept Header: Accept: application/json - Extension type: https://www.peeringdb.com/api/network/42.json Operations Using the GET operation you can retrieve information from the PeeringDB database. You can retrieve both a single object and multiple objects in an array. Let\u2019s look at each of them individually. Single object To retrieve a single object you need to use this URL: https://www.peeringdb.com/api/OBJ/ID with this endpoint GET: /api/OBJ/id . The ID is a unique identifier and should be added to the URL when retrieving a single object. Let\u2019s look at an example: - HTTP: GET /api/OBJ/38 where 38 is the ID - curl: curl -H \"Accept: application/json\" -X GET https://<username>:<password>@peeringdb.com/api/OBJ/38 There are optional parameters you can add to your URL: - str : which retrieves a comma separated list of field names - only matching fields will be returned in the data - int : which retrieves two nested sets and objects Nested sets and objects A nested set or object is any field ending in the suffix: set. For example: net_set will hold network objects. The naming schema of the field will always tell you which type of object the set is holding and will correspond with the object's endpoint on the API <object_type>_set . So a set called net_set will hold network objects (API endpoint /net). Note : unlike GET multiple, depth here will also expand single relationships in addition to sets. So net_id would get expanded into a network object. Unexpanded { ... \"net_id\" : 1 } Expanded { ... \"net_id\" : 1 \"net\" : { ... network object ... } } Depth - 0: don't expand anything (default) - 1: expand all first level sets to ids - 2: expand all first level sets to objects Multiple objects To retrieve a single object you need to use this URL: https://www.peeringdb.com/api/OBJ/ with this endpoint GET: /api/OBJ/ . Let\u2019s look at an example: - HTTP: GET /api/OBJ/ which is the endpoint - curl: curl -X GET https://<username>:<password>@www.peeringdb.com/api/OBJ There are optional parameters you can add to your URL: - limit : int limits rows in the result set - skip : int skips n rows in the result set - depth : int nested sets will be loaded (slow) - fields : str comma separated list of field names - only matching fields will be returned in the data - since : int retrieve all objects updated since specified time (unix timestamp, seconds) - [field_name] : int|string queries for fields with matching value Real world use cases We will show you different use cases on how to use the PeeringDB API. How do I query by ASN? To query for an ASN using the PeeringDB API, you will need to use this URL: GET https://www.peeringdb.com/api/net?asn=42 , where asn=42 is the query parameter. How do I query for an IXs in a particular state? To query for IXs based in a state (in countries with a state system), you will need to use a URL like this: GET https://www.peeringdb.com/api/ixfac?fac__state=NSW , where fac__state tells the API to look at the state field in the facility record and NSW is the normalized code for the state. In this example, NSW is the Australian state of New South Wales. Similarly, https://www.peeringdb.com/api/ixfac?fac__state=NV gets IXs in facilities in the US state of Nevada. Using curl Use this curl example to get this specific network. Copy and paste the following to your command line interface: curl GET https://www.peeringdb.com/api/net?asn=42 . Using Python To make use of this Python code, first, you\u2019ll have to first install Python if you don\u2019t have it installed. Then, install pip and requests . After that create a Python file and copy and paste the following code. import requests r = requests.get('https://www.peeringdb.com/api/net?asn=42') print(r.text) with open('output.csv', 'w+') as f: f.write(r.text) From the above code, we make a request to the API using the request module and print out the response which would be in a JSON format. However, reading a JSON file can be quite hectic and tasking so we convert the JSON file to a CSV file. Our CSV file will open in output.csv. Using jq You can use jq to make a request to your API and get your output in a CSV format. First, you need to install Jq . Next, we use this curl command to prepare our JSON file. Change to a directory and copy and paste this code on your terminal: curl https://www.peeringdb.com/api/net?asn=42 > test.json . This creates a new file named test.json. To convert the JSON input file to the CSV format, copy and paste the following command: jq -r '(.data[0] | keys_unsorted), (.data[] | to_entries | map(.value))|@csv' test.json Using an online converter Alternatively you can use an online tool such as https://www.convertcsv.com/json-to-csv.htm to convert the raw JSON file to CSV. Note : For the purpose of this article we will focus on the curl method but you can conveniently try out the other proposed methods. How to get all the objects owned by https://www.peeringdb.com/net/961 and convert the data to CSV? To get all the objects owned by this https://www.peeringdb.com/net/961 using the PeeringDB API. Copy and paste the following to your command line interface: curl GET https://www.peeringdb.com/net/961 . I want the list of networks and their 'type' peering at MICE in Minneapolis. To get the list of networks and their type peering at Mice in Minneapolis, copy and paste the following command in your terminal: curl -s -X GET https://www.peeringdb.com/api/net?ix=446&__in=Minneapolis | jq '.data[] . How to find all the exchanges where my organization has a presence? Use this curl example. Copy and paste the following to your command line interface: curl -s -X GET https://www.peeringdb.com/api/netixlan\\?ixlan_id=62 | jq '.data[]' .","title":"HOWTO: Get Started with Search in PeeringDB"},{"location":"howto/search/#howto-get-started-with-search-in-peeringdb","text":"","title":"HOWTO: Get Started with Search in PeeringDB"},{"location":"howto/search/#introduction-to-peeringdb","text":"PeeringDB is a publicly available network database that is the go-to location for interconnection data. The database facilitates global network connections at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and it serves as a starting point for interconnection decisions. This online database is a non-profit, community-driven effort that encourages the exchange of Peering-related information and is totally managed and maintained by volunteers. It's a tool for the Internet's growth and enhancement.","title":"Introduction to PeeringDB"},{"location":"howto/search/#why-use-peeringdb-to-search-for-networks-exchange-and-data-centers","text":"About a third of networks (Autonomous Systems) use PeeringDB to share information about how they interconnect. You can use PeeringDB to find information about other networks, exchanges, and more. You make your services easier to find when you contribute your data to PeeringDB. You don't need an account to use the basic search functionality. But if you want to access private contact information and use advanced search features, like radius search, you'll need to sign up for an account.","title":"Why use PeeringDB to search for networks, exchange and data centers?"},{"location":"howto/search/#how-to-search-for-campuses-carriers-exchanges-facilities-and-networks-in-peeringdb","text":"There is a s simple search box on the front page of PeeringDB. You can use it to search for campuses, carriers, exchanges, facilities and networks listed in PeeringDB by simply entering the name you want. Let\u2019s demonstrate with some examples to see how this works.","title":"How to search for campuses, carriers, exchanges, facilities and networks in PeeringDB"},{"location":"howto/search/#place-name-normalization","text":"PeeringDB normalizes place names at the presentation layer. For example, M\u00fcnchen will always be normalized to Munich in search output. This ensures that users can get all the results for Munich in a single search. Users can search using multiple names. As long as the name selected is well known, the search will be centered on the correct place.","title":"Place name normalization"},{"location":"howto/search/#networks","text":"For this example, we have this network KENET which is a non-profit operator for education and research and we want to search for it on PeeringDB. There are two ways to search for networks in PeeringDB:","title":"Networks"},{"location":"howto/search/#name-search","text":"You can search for networks by using the name of the networks by: - Entering the name of the network as seen below - From the search result, under the Networks section, locate the network you have searched - It would be visible if it is in the PeeringDB database","title":"Name search"},{"location":"howto/search/#asn-search","text":"You can search for networks using their ASN by: - Entering the name of the network as seen below, for the example below the ASN is (36914) - From the search result, under the Networks section, locate the network you have searched Note : Either of the two methods will get the same search results.","title":"ASN search"},{"location":"howto/search/#exchanges","text":"For this example, let\u2019s consider this exchange UNY-IX which is an open Internet exchange located in Universitas Negeri Yogyakarta. To search for an exchange: - Enter the name of the exchange as shown below - From the search result, under the exchanges section, locate the exchange you have searched","title":"Exchanges"},{"location":"howto/search/#facilities","text":"Data centers are also referred to as facilities. For this example, let\u2019s consider this university University of Oslo which is an institution in Oslo. To search for a facility: - Enter the name of the data center or facility as shown below - From the search result, under the facilities section, locate the facility or data center you have searched","title":"Facilities"},{"location":"howto/search/#how-to-search-for-your-own-organization","text":"If your organization already uses PeeringDB, when you are logged in to the website you can always find your own information using the self search. If you are not logged in, these links will take you to some PeeringDB examples objects. Organization Campus Carrier Facility Internet Exchange Point Network The self identifier also works for queries made using our API. We encourage the use of multi-factor authentication . This means using an API Key instead of basic authentication for API queries.","title":"How to search for your own organization"},{"location":"howto/search/#how-to-use-the-search-in-peeringdb-extension","text":"The PeeringDB search extension is a free to use Google Chrome extension with which you can use to search for ASNs, networks, and exchanges in PeeringDB. To get started, go to the Chrome Web Store and download the extension, then enable it and add it to your extension bar. There are two ways to use the extension once it has been enabled: Using the Extension Bar Icon : Click the icon and type your search term into the box. The search will open in a new tab with the search result. Below is the result: Using the Context Menu : Right-click on any text on a page and select \"Search in PeeringDB\". The search will open in a new tab with the search result. Below is the result: If the query or highlighted text contains a number, the extension will attempt to find an ASN.","title":"How to use the search in PeeringDB extension"},{"location":"howto/search/#how-to-search-based-on-a-partial-name","text":"You can search based on a partial name. When an organization, network, facility or exchange name has two parts, you can search for just the first or second part and then select from all the organizations that share that name. This makes it easier to find the organization you want. This can also be helpful in a situation where you can not remember the name of the organization in full. In the example below, we want to search for \u201cinternet archive\u201d. We will search for it with a single part and not with the full name. In the search box, input \u201carchive''. This brings out a search result that have similar parts in their names. You can now search through the results to find the what you want.","title":"How to search based on a partial name"},{"location":"howto/search/#what-is-an-advanced-search","text":"Advanced search in PeeringDB lets you explicitly filter a search location, network presence, service level and a wide range of other features. You get the results you\u2019re looking for and can export them in structured data formats (JSON or CSV), so you can import the data into tools that will help you make decisions. Note : You need to be logged in to PeeringDB in order to use some of the advanced search features, including the radius search. Let\u2019s take a look at this example below to demonstrate how advanced search works. We are going to search for an exchange within a particular region. On the front page of PeeringDB you will see the Advanced Search box which you can use to search for campuses, exchanges, facilities and networks that are in PeeringDB. Click on the Advanced Search link. This takes you to the advanced search landing page. The search page shows the campus, exchanges, facilities, networks, and organizations tabs. Go to the Exchanges tab, in the country field select a country of your choice by scrolling through the different options. On the right hand side, in the Network Presence field, enter the name of the network. You can follow the example shown below and add KENET. Click on the drop down list that appears as you input the network name. Click on Search. Scroll down to view information regarding the exchange that you searched for. Click on JSON or CSV to download the information in a structured format.","title":"What is an advanced search?"},{"location":"howto/search/#geographic-search","text":"As new facilities are created in our database they will be linked to geographic coordinates. PeeringDB has improved search by changing the way it records data for location in its database. You can now search for facilities with a distance radius of a chosen coordinate.","title":"Geographic search"},{"location":"howto/search/#how-to-search-for-a-campus","text":"You can search for a campus of facilities using the Advanced Search interface. Users can search from a country and city, and select a radius in kilometers or miles. Of course, you can achieve the same results using the API or the web interface, which means you can integrate this feature into your own tools. Note : You need to be logged in to PeeringDB in order to search for a campus of facilities.","title":"How to search for a campus"},{"location":"howto/search/#how-to-search-for-facilities-within-a-given-radius","text":"You can search for facilities within a given radius, using the Advanced Search interface. Users can search from a country and city, and select a radius in kilometers or miles. Of course, you can achieve the same results using the API or the web interface, which means you can integrate this feature into your own tools. Note : You need to be logged in to PeeringDB in order to search for facilities within a given radius. Login in or register an account on PeeringDB. On the front page of PeeringDB, click on the Advanced Search link. Go to the Facilities Tab and in the city/postal field add a city or postal of your choice. In the country field select a country of your choice. In the Within Distance field add a specified distance of your choice. On the right hand side of the page, click on search. Scroll down to view the information you searched for. The search result will bring up facilities which are in that country, city and state. You can download your information in a JSON or CSV format.","title":"How to search for facilities within a given radius"},{"location":"howto/search/#querying-with-the-peeringdb-api","text":"Throughout this article up to this point, we have been talking on how to use PeeringDB to find information about potential peers, and then after peering has been arranged, using PeeringDB to obtain the peering details. The PeeringDB website is very helpful in these regards, but using the website still requires a lot of manual work. It\u2019s also possible to use the PeeringDB API to automate some parts of this. Why use the PeeringDB API? The PeeringDB API makes it easy to integrate PeeringDB in your environment. The PeeringDB database can be queried using a REST API. REST allows a client to request information from a server over HTTP or HTTPS. The server then returns the requested information in JSON format.","title":"Querying with the PeeringDB API"},{"location":"howto/search/#object-types","text":"Each object has an associated shorthand tag you can use. Object types are not case sensitive and the output is an array. For example: https://www.peeringdb.com/api/OBJ . The endpoint is: /api/OBJ . Below are the categories of objects types (OBJ) in PeeringDB: - Basic Objects : org, fac, ix, net, poc - Derived Objects : ixlan, ixpfx, netixlan, netfac","title":"Object types"},{"location":"howto/search/#basic-objects","text":"Below is a description of what each of the object types mean and what information they return org : Root object for fac, ix, net, this holds information about an organization. fac : Describes a facility / colocation record, more useful information are in derived records netfac. ix : Describes an exchange, more useful information are in derived records ixlan, ixpfx and netixlan. net : Describes a network / ASN, more useful information are in netfac and netixlan. poc : Describes various role accounts (point of contact), this is currently only for net objects. as_set : Array of all AS-SETs corresponding to a network / ASN, this was introduced recently.","title":"Basic objects"},{"location":"howto/search/#derived-objects","text":"Below is a description of what each of the object types mean and what information they return. Ixlan : Describes the LAN of an ix, one ix may have multiple ixlan. This feature may go away in PeeringDB 3.0. ixpfx : Describes the IP range (IPv4 and IPv6) for an ixlan, one ixlan may have multiple ixpfx. netixlan : Describes the presence of a network at an exchange. netfac : Describes the presence of a network at a facility.","title":"Derived objects"},{"location":"howto/search/#authentication","text":"Authentication is done through basic HTTP authorization. People who are accessing the API as a guest do not need any authentication. For example: curl -sG https://username:password@www.peeringdb.com/api/net/961 curl -u username:password https://www.peeringdb.com/api/net/961 Note : Access to contact information may be restricted if you are using the API as a guest without authentication. API usage is subject to query limits and these are set at a lower threshold for unauthenticated users.","title":"Authentication"},{"location":"howto/search/#making-a-request","text":"When making a request, the URL base is added with /api/ , followed by the object type and, if applicable, the object primary key (if applicable). For example: https://www.peeringdb.com/api/OBJ/id . If you want to select the output format, either use the Accept: HTTP header or use the extension type parameter: - Accept Header: Accept: application/json - Extension type: https://www.peeringdb.com/api/network/42.json","title":"Making a request"},{"location":"howto/search/#operations","text":"Using the GET operation you can retrieve information from the PeeringDB database. You can retrieve both a single object and multiple objects in an array. Let\u2019s look at each of them individually.","title":"Operations"},{"location":"howto/search/#single-object","text":"To retrieve a single object you need to use this URL: https://www.peeringdb.com/api/OBJ/ID with this endpoint GET: /api/OBJ/id . The ID is a unique identifier and should be added to the URL when retrieving a single object. Let\u2019s look at an example: - HTTP: GET /api/OBJ/38 where 38 is the ID - curl: curl -H \"Accept: application/json\" -X GET https://<username>:<password>@peeringdb.com/api/OBJ/38 There are optional parameters you can add to your URL: - str : which retrieves a comma separated list of field names - only matching fields will be returned in the data - int : which retrieves two nested sets and objects","title":"Single object"},{"location":"howto/search/#nested-sets-and-objects","text":"A nested set or object is any field ending in the suffix: set. For example: net_set will hold network objects. The naming schema of the field will always tell you which type of object the set is holding and will correspond with the object's endpoint on the API <object_type>_set . So a set called net_set will hold network objects (API endpoint /net). Note : unlike GET multiple, depth here will also expand single relationships in addition to sets. So net_id would get expanded into a network object. Unexpanded { ... \"net_id\" : 1 } Expanded { ... \"net_id\" : 1 \"net\" : { ... network object ... } } Depth - 0: don't expand anything (default) - 1: expand all first level sets to ids - 2: expand all first level sets to objects","title":"Nested sets and objects"},{"location":"howto/search/#multiple-objects","text":"To retrieve a single object you need to use this URL: https://www.peeringdb.com/api/OBJ/ with this endpoint GET: /api/OBJ/ . Let\u2019s look at an example: - HTTP: GET /api/OBJ/ which is the endpoint - curl: curl -X GET https://<username>:<password>@www.peeringdb.com/api/OBJ There are optional parameters you can add to your URL: - limit : int limits rows in the result set - skip : int skips n rows in the result set - depth : int nested sets will be loaded (slow) - fields : str comma separated list of field names - only matching fields will be returned in the data - since : int retrieve all objects updated since specified time (unix timestamp, seconds) - [field_name] : int|string queries for fields with matching value","title":"Multiple objects"},{"location":"howto/search/#real-world-use-cases","text":"We will show you different use cases on how to use the PeeringDB API.","title":"Real world use cases"},{"location":"howto/search/#how-do-i-query-by-asn","text":"To query for an ASN using the PeeringDB API, you will need to use this URL: GET https://www.peeringdb.com/api/net?asn=42 , where asn=42 is the query parameter.","title":"How do I query by ASN?"},{"location":"howto/search/#how-do-i-query-for-an-ixs-in-a-particular-state","text":"To query for IXs based in a state (in countries with a state system), you will need to use a URL like this: GET https://www.peeringdb.com/api/ixfac?fac__state=NSW , where fac__state tells the API to look at the state field in the facility record and NSW is the normalized code for the state. In this example, NSW is the Australian state of New South Wales. Similarly, https://www.peeringdb.com/api/ixfac?fac__state=NV gets IXs in facilities in the US state of Nevada.","title":"How do I query for an IXs in a particular state?"},{"location":"howto/search/#using-curl","text":"Use this curl example to get this specific network. Copy and paste the following to your command line interface: curl GET https://www.peeringdb.com/api/net?asn=42 .","title":"Using curl"},{"location":"howto/search/#using-python","text":"To make use of this Python code, first, you\u2019ll have to first install Python if you don\u2019t have it installed. Then, install pip and requests . After that create a Python file and copy and paste the following code. import requests r = requests.get('https://www.peeringdb.com/api/net?asn=42') print(r.text) with open('output.csv', 'w+') as f: f.write(r.text) From the above code, we make a request to the API using the request module and print out the response which would be in a JSON format. However, reading a JSON file can be quite hectic and tasking so we convert the JSON file to a CSV file. Our CSV file will open in output.csv.","title":"Using Python"},{"location":"howto/search/#using-jq","text":"You can use jq to make a request to your API and get your output in a CSV format. First, you need to install Jq . Next, we use this curl command to prepare our JSON file. Change to a directory and copy and paste this code on your terminal: curl https://www.peeringdb.com/api/net?asn=42 > test.json . This creates a new file named test.json. To convert the JSON input file to the CSV format, copy and paste the following command: jq -r '(.data[0] | keys_unsorted), (.data[] | to_entries | map(.value))|@csv' test.json","title":"Using jq"},{"location":"howto/search/#using-an-online-converter","text":"Alternatively you can use an online tool such as https://www.convertcsv.com/json-to-csv.htm to convert the raw JSON file to CSV. Note : For the purpose of this article we will focus on the curl method but you can conveniently try out the other proposed methods.","title":"Using an online converter"},{"location":"howto/search/#how-to-get-all-the-objects-owned-by-httpswwwpeeringdbcomnet961-and-convert-the-data-to-csv","text":"To get all the objects owned by this https://www.peeringdb.com/net/961 using the PeeringDB API. Copy and paste the following to your command line interface: curl GET https://www.peeringdb.com/net/961 .","title":"How to get all the objects owned by https://www.peeringdb.com/net/961 and convert the data to CSV?"},{"location":"howto/search/#i-want-the-list-of-networks-and-their-type-peering-at-mice-in-minneapolis","text":"To get the list of networks and their type peering at Mice in Minneapolis, copy and paste the following command in your terminal: curl -s -X GET https://www.peeringdb.com/api/net?ix=446&__in=Minneapolis | jq '.data[] .","title":"I want the list of networks and their 'type' peering at MICE in Minneapolis."},{"location":"howto/search/#how-to-find-all-the-exchanges-where-my-organization-has-a-presence","text":"Use this curl example. Copy and paste the following to your command line interface: curl -s -X GET https://www.peeringdb.com/api/netixlan\\?ixlan_id=62 | jq '.data[]' .","title":"How to find all the exchanges where my organization has a presence?"},{"location":"howto/updates-for-as112/","text":"HOWTO: What is AS112? Many networks using private address space ( RFC 1918 ) leak the reverse DNS lookups instead of running a local DNS server to respond to them. To stop this traffic from overwhelming root nameservers, volunteers run AS112 nameservers , which provide authoritative, local answers. What is PeeringDB? PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions. The database is a non-profit, community-driven initiative run and promoted by volunteers. It is a public tool for the growth and good of the Internet. Join the community and support the continued development of the Internet. How Does PeeringDB Visibility Help? The listing for AS112 in PeeringDB contains the peering LAN IP addresses of the routers for the network. This can be used as a source of configuration information for the peering routers of other networks at the same IXP. What you need to do IXPs sharing technical information using the IX-F Member Export Schema When an IXP shares technical information about its infrastructure using the IX-F Member Export Schema the existence of the AS112 node, and its peering LAN address, will automatically be populated in PeeringDB. You, as the operators of the node do not need to do anything. This is because AS112 has enabled the option to allow the IXPs' IX-F data to automatically populate its entry in PeeringDB. IXPs not sharing technical information using the IX-F Member Export Schema If your IXP does not share technical information about its infrastructure using the IX-F Member Export Schema you can ask them to do so. You can also reach out to ops@as112.net and the PeeringDB entry for AS112 will be manually updated.","title":"HOWTO: What is AS112?"},{"location":"howto/updates-for-as112/#howto-what-is-as112","text":"Many networks using private address space ( RFC 1918 ) leak the reverse DNS lookups instead of running a local DNS server to respond to them. To stop this traffic from overwhelming root nameservers, volunteers run AS112 nameservers , which provide authoritative, local answers.","title":"HOWTO: What is AS112?"},{"location":"howto/updates-for-as112/#what-is-peeringdb","text":"PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions. The database is a non-profit, community-driven initiative run and promoted by volunteers. It is a public tool for the growth and good of the Internet. Join the community and support the continued development of the Internet.","title":"What is PeeringDB?"},{"location":"howto/updates-for-as112/#how-does-peeringdb-visibility-help","text":"The listing for AS112 in PeeringDB contains the peering LAN IP addresses of the routers for the network. This can be used as a source of configuration information for the peering routers of other networks at the same IXP.","title":"How Does PeeringDB Visibility Help?"},{"location":"howto/updates-for-as112/#what-you-need-to-do","text":"","title":"What you need to do"},{"location":"howto/updates-for-as112/#ixps-sharing-technical-information-using-the-ix-f-member-export-schema","text":"When an IXP shares technical information about its infrastructure using the IX-F Member Export Schema the existence of the AS112 node, and its peering LAN address, will automatically be populated in PeeringDB. You, as the operators of the node do not need to do anything. This is because AS112 has enabled the option to allow the IXPs' IX-F data to automatically populate its entry in PeeringDB.","title":"IXPs sharing technical information using the IX-F Member Export Schema"},{"location":"howto/updates-for-as112/#ixps-not-sharing-technical-information-using-the-ix-f-member-export-schema","text":"If your IXP does not share technical information about its infrastructure using the IX-F Member Export Schema you can ask them to do so. You can also reach out to ops@as112.net and the PeeringDB entry for AS112 will be manually updated.","title":"IXPs not sharing technical information using the IX-F Member Export Schema"},{"location":"howto/v2_search/","text":"HOWTO: v2 Search We are testing v2 search in parallel with our production v1 search tools. We encourage you to test it and give us feedback . Is it faster? Does it simplify the search process? Does it give you the results you expect? Your input helps us deliver the tools you want. When you click one the link for v2 search , you just type your query in the box and hit enter, like normal. Concept v2 lets you use some natural language queries in combination with the name for an area. It helps you get the results in fewer searches, ideally just one! Search for a network Searches for numbers can be interpreted as a search for a location as well as a network. When searching for a network prefixed with 'AS', partial matches show all relevant networks while direct matches take you straight to the network's page. Fig 1: A search for as333 shows results for AS3330 and AS33309 Support for metro sizes For many areas it will automatically set an appropriate radius. When a common business area crosses a jurisdictional boundary, the search is based on the common business area and not limited to the named metro area. Fig 2: A search for fac near new york includes results for facilities in Jersey City, NJ When you want a different radius, our Advanced Search tool lets you manually set a specific radius based on any street address. Searching directly for IXs v2 search finds exchanges based on the facilities they are in. You don\u2019t need to search for facilities in a metro area and then find the exchanges they host. You can do it in a single search. Fig 3: A search for ix in tokyo finds exchanges at facilities we know about in Tokyo Support for campus v2 search knows about campus objects \u2013 interconnected facilities under common ownership \u2013 so you can find campuses for an area as well a getting a full list of facilities. Fig 4: Searching for a campus in amsterdam shows just three entries Fig 5: Searching for a fac in amsterdam shows many more results","title":"HOWTO: v2 Search"},{"location":"howto/v2_search/#howto-v2-search","text":"We are testing v2 search in parallel with our production v1 search tools. We encourage you to test it and give us feedback . Is it faster? Does it simplify the search process? Does it give you the results you expect? Your input helps us deliver the tools you want. When you click one the link for v2 search , you just type your query in the box and hit enter, like normal.","title":"HOWTO: v2 Search"},{"location":"howto/v2_search/#concept","text":"v2 lets you use some natural language queries in combination with the name for an area. It helps you get the results in fewer searches, ideally just one!","title":"Concept"},{"location":"howto/v2_search/#search-for-a-network","text":"Searches for numbers can be interpreted as a search for a location as well as a network. When searching for a network prefixed with 'AS', partial matches show all relevant networks while direct matches take you straight to the network's page. Fig 1: A search for as333 shows results for AS3330 and AS33309","title":"Search for a network"},{"location":"howto/v2_search/#support-for-metro-sizes","text":"For many areas it will automatically set an appropriate radius. When a common business area crosses a jurisdictional boundary, the search is based on the common business area and not limited to the named metro area. Fig 2: A search for fac near new york includes results for facilities in Jersey City, NJ When you want a different radius, our Advanced Search tool lets you manually set a specific radius based on any street address.","title":"Support for metro sizes"},{"location":"howto/v2_search/#searching-directly-for-ixs","text":"v2 search finds exchanges based on the facilities they are in. You don\u2019t need to search for facilities in a metro area and then find the exchanges they host. You can do it in a single search. Fig 3: A search for ix in tokyo finds exchanges at facilities we know about in Tokyo","title":"Searching directly for IXs"},{"location":"howto/v2_search/#support-for-campus","text":"v2 search knows about campus objects \u2013 interconnected facilities under common ownership \u2013 so you can find campuses for an area as well a getting a full list of facilities. Fig 4: Searching for a campus in amsterdam shows just three entries Fig 5: Searching for a fac in amsterdam shows many more results","title":"Support for campus"},{"location":"howto/work_within_peeringdbs_query_limits/","text":"HOWTO: Work Within PeeringDB\u2019s Query Limits PeeringDB implements query throttling to encourage efficiently formatted queries and/or local caching. Many popular tools have been upgraded to use PeeringDB more efficiently. Query limits Duplicate queries: Repeated anonymous identical requests with a response size above 100kb are being limited to 1/hour Repeated anonymous identical requests of any size are being limited to 2/minute Query rate limit: Anonymous queries limited to 20/minute per IP address Authenticated queries limited to 40/minute per user or organization (when an organizational API key is used) Efficient queries We encourage users to make fewer, larger queries instead of making many small queries. Instead of sending each ASN you want to learn about as a separate query, create a list of ASNs and send them in a single query. The query element would look like this: asn__in=$list_of_ASN_separated_by_comma We encourage sending lists of up to 150 ASNs in a single query. We have a HOWTO article describing the basics of using our API using popular command line tools such as curl, Python, and jq. Please use API Keys when automating queries to PeeringDB and set a User-Agent header that identifies the unique software you are using, rather than just a generic query library name. We also encourage you to leave at least two seconds between queries. Local cache We encourage you to use a local cache and synchronize it every hour or less frequently in accordance with your organization's needs. When you use a local cache you will only be sent changes since the last sync. We publish peeringdb-py, which can be used directly or as a reference implementation. Code is here and documentation is here . Use of an API key with peeringdb-py is highly recommended. If you want to implement a local cache using different tools and would like advice, we are happy to talk. Contact us at support@peeringdb.com . Tools Popular tools, including arouteserver have been updated to include support for API Keys and to make more efficient queries. We publish a list of tools that we know use PeeringDB. Check the list for tools that you use and upgrade old versions to take advantage of new features and improve everyone\u2019s PeeringDB experience.","title":"HOWTO: Work Within PeeringDB\u2019s Query Limits"},{"location":"howto/work_within_peeringdbs_query_limits/#howto-work-within-peeringdbs-query-limits","text":"PeeringDB implements query throttling to encourage efficiently formatted queries and/or local caching. Many popular tools have been upgraded to use PeeringDB more efficiently.","title":"HOWTO: Work Within PeeringDB\u2019s Query Limits"},{"location":"howto/work_within_peeringdbs_query_limits/#query-limits","text":"Duplicate queries: Repeated anonymous identical requests with a response size above 100kb are being limited to 1/hour Repeated anonymous identical requests of any size are being limited to 2/minute Query rate limit: Anonymous queries limited to 20/minute per IP address Authenticated queries limited to 40/minute per user or organization (when an organizational API key is used)","title":"Query limits"},{"location":"howto/work_within_peeringdbs_query_limits/#efficient-queries","text":"We encourage users to make fewer, larger queries instead of making many small queries. Instead of sending each ASN you want to learn about as a separate query, create a list of ASNs and send them in a single query. The query element would look like this: asn__in=$list_of_ASN_separated_by_comma We encourage sending lists of up to 150 ASNs in a single query. We have a HOWTO article describing the basics of using our API using popular command line tools such as curl, Python, and jq. Please use API Keys when automating queries to PeeringDB and set a User-Agent header that identifies the unique software you are using, rather than just a generic query library name. We also encourage you to leave at least two seconds between queries.","title":"Efficient queries"},{"location":"howto/work_within_peeringdbs_query_limits/#local-cache","text":"We encourage you to use a local cache and synchronize it every hour or less frequently in accordance with your organization's needs. When you use a local cache you will only be sent changes since the last sync. We publish peeringdb-py, which can be used directly or as a reference implementation. Code is here and documentation is here . Use of an API key with peeringdb-py is highly recommended. If you want to implement a local cache using different tools and would like advice, we are happy to talk. Contact us at support@peeringdb.com .","title":"Local cache"},{"location":"howto/work_within_peeringdbs_query_limits/#tools","text":"Popular tools, including arouteserver have been updated to include support for API Keys and to make more efficient queries. We publish a list of tools that we know use PeeringDB. Check the list for tools that you use and upgrade old versions to take advantage of new features and improve everyone\u2019s PeeringDB experience.","title":"Tools"},{"location":"release_notes/","text":"Release Notes and Schedule The release notes list the GitHub issues and a summary of what has changed in PeeringDB software releases. Each new release has a one week beta test period on the beta server before it goes live. The beta and new releases are announced on the PeeringDB Announce Mailing List and on Facebook , LinkedIn and X . Release schedule This schedule provides planned dates for PeeringDB\u2019s future releases. We are sharing these dates to help PeeringDB users plan ahead for testing new and improved features in beta. We also want to help volunteer developers know the date on which their code changes are needed for internal testing before beta release. We provide a rolling schedule. Dates can change, so if you have a question or request please contact us at: support@peeringdb.com . Our releases are generally deployed at around 04:00 UTC. Release number Internal testing Beta release Production release 2.63.0 2024-11-06 2024-11-13 2024-11-20 2.64.0 2024-01-08 2024-01-15 2024-01-22 2.65.0 2025-02-05 2025-02-12 2025-02-19 2.66.0 2025-03-14 2025-03-23 2025-03-30 2.67.0 2025-04-22 2025-04-29 2025-04-30 2.68.0 2025-05-07 2025-05-14 2025-05-21 2.69.0 2025-06-11 2025-06-18 2025-05-25 Release 2.63.0 Beta Announcement Date: 13 November 2024 Release Date: 20 November 2024 GitHub issue Summary #1671 Inconsistent netixlan ASN data can result in inability for deleted netixlan to be claimed by new user Nullify the local asn field of netixlan objects and make it a read only view of $network.asn.. #1666 Schedule reset of tutorial server database As title. #1635 ops: add read-only server side switch PeeringDB can now be placed into read-only mode when needed. #1593 Dev module docs auto generation broken Fixes a bug that broke autogeneration of documentation. #1690 New net_side and ix_side fields on netixlan breaks sync once django-peeringdb is released Fixes a bug that blocked the release of an updated django-peeringdb because of the new new net_side and ix_side fields added to netixlan in 2.62.0. peeringdb-py #65 Make spinning up peeringdb-py fully automated As title. Release 2.62.1 Release Date: 24 October 2024 GitHub issue Summary #1692 Fix otp email one time password Fixes compatibility issues after two-factor library upgrade, causing issues with emailing one time passwords. Release 2.62.0 Beta Announcement Date: 9 October 2024 Release Date: 16 October 2024 GitHub issue Summary #1584 Passkey support for login Adds a new 2FA method, Passkeys . #1612 Feature Parity for Carrier Object: Search and Export to JSON, CSV, KMZ As title. #1555 Remove \"Media Type\" field for Internet Exchange object As title. #1563 CSV and JSON exports truncate at 250 records Exports no longer truncate at 250 records. #607 Add location of Physical IX-Port & Router Port IXPs can now indicate the location of their switch using the pdb_facility_id attribute of the switch statement in their IX-F JSON export . peeringdb-py #95 Make client more robust when dealing with api errors. As title. peeringdb-py #86 DB sync fails due to validation error Bug fix as title. #1635 ops: add read-only server side switch Server can go into read-only mode, while allowing user login. This mode allows basic service to be sustained in adverse situations. #1654 Direct query access to Elasticsearch to aid search improvements Direct query access to ElasticSearch for internal PeeringDB users. #1653 Update dependencies and modernise As title. peeringdb-py #94 Update deps and modernize As title. django-peeringdb #103 Update dependencies and modernise As title. #340 switch to uv, update deps Dependency update for docs.peeringdb.com. Release 2.61.0 Beta Announcement Date: 14 August 2024 Release Date: 21 August 2024 GitHub issue Summary #1617 Snag list for preview.beta.peeringdb.com Updates preview.beta.peeringdb.com to improve the UI. #1142 Email one time password button should be less prominent As title. #766 For any forbidden actions set a 403 and give a \"Not Allowed\" header As title. #1302 Fix OpenAPI types where needed As title. peeringdb-py #76 Client should handle rate limiting errors gracefully As title. #1583 bfd_support undocumented parameter in API Documentation improved. django-peeringdb #98 ORM configuration Options is missing (postgreSQL) Config option updated. #1014 When removing a network, removing all netixlans have to happen before removing pocs Fixes blocking of network deletion due to to Prevent deletion of a last technical contact if there is an existing netixlan object #923. Release 2.60.0 Beta Announcement Date: 17 July 2024 Release Date: 24 July 2024 GitHub issue Summary #1452 Normalizing the presentation of place names Place names are now normalized, improving the consistency of search results. #1189 Data export buttons for Network, Exchange, and Facilities As title. #1561 Deploy www on ECS/Fargate www.peeringdb.com will be deployed using containers. peeringdb-py #67 Allow option for logging to co-exist with existing loggers Improves logging support in peeringdb-py local cache. peeringdb-py #72 --output-format in cli does not seem to be working Fixes bug as per title. #1322 Give API writes high priority and limits As title. #1610 possible for ixpfx object with empty prefix to exist in a soft-deleted state Fixes bug as per title. #1040 Verification queue ticket subject changes Fixes bug as per title. Release 2.59.0 Beta Announcement Date: 19 June 2024 Release Date: 26 June 2024 GitHub issue Summary #1585 Publish OAuth authorization server metadata endpoint As title. #1483 Address Change UI Fixes an error where it was not possible to reject the suggestion for an address. #1561 Deploy www on ECS/Fargate Switch www.peeringdb.com to ECS/Fargate. Initial deployment will be on beta.peeringdb.com with www.peeringdb.com following at a later date. peeringdb-py #49 Automatically update docs site on code release As title. peeringdb-py #88 docs need updating to reflect some api changes to the Client.update_all() call As title. #1603 Organization API key table formatting broken Improves the display of Organizational API Keys. #1604 API limit=x does not work when response type set in URL Limits to response sizes were ignored as per title. #971 Remove white space from strings As title. #1606 rir_status update handler: intermittent bug that may attempt to delete a network too early Fixes an over eager data cleanup process. #1608 pdb_delete_outdated_pending_affil_request failure Fixes an error is a data cleanup process. Release 2.58.0 Beta Announcement Date: 29 May 2024 Release Date: 5 June 2024 GitHub issue Summary #1343 Inconsistent return results when querying facilities by state (Datafill) Enforces state naming on validation and normalize data. #1502 Create preview.peeringdb.com with updated web UI Preview site for new PeeringDB web design. #1414 Tooltip with Full IX Name on Mouse-Over IX-Abbreviation As title. #1115 Enhancement to Ownership Information Field Lessee tooltip now says \"Leased or Rented\". #1487 URL Referrer Behavior Clicking on a link now opens it in a new tab or window. #840 Add help text to \"Traffic Levels\" Add tooltip \"Total, self-classified traffic in/out to this network.\". #1491 Add logo watermark and peeringdb.com URL to kmz As title. #975 \"Incomplete data\" complainer for Peering Policy even with General Policy \"None\" or \"Open\" No longer show missing data warning for empty Peering Policy field if General Policy is set to \"Open\" or \"No\". #1580 Validator: Add validator for X usernames, were requirements Validator for usernames on the X social media network. #1481 Network Registration fail results in AC action and retry failure Improved network registration process where email address does not match RDAP output. #1500 pdb_stats needs to be updated to include Campuses, Carriers, etc. & possible bug with user counts Improvements to internal stats package. #1503 Is it possible to create an affiliation request even when the ASN (~Net) has been deleted? (But the ORG still exist) As title. #1038 add default for config key MELISSA_KEY now defaults to a blank string. #1048 TOTP devices sort is by id. However, only username is shown Fixes a UI bug with internal support tools. #85 DB sync fails due to duplicate entries Fixes a peeringdb-py data sync bug. Release 2.57.0 Beta Announcement Date: 17 April 2024 Release Date: 24 April 2024 GitHub issue Summary #1545 Feature request: Allow permissions to be given per user on Carrier As title. #1123 Make a Technical POC mandatory when enabling \"Allow IXP Update\" As title. #1231 Change ix-f to IX-F As title. #1577 Remove more clutter from KMZ Metadata Makes data easier to read and slims download size. #1475 KML Placemark/Point Meta Data Not Displaying Correctly Fixes a bug that broke the way metadata displayed for .KMZ pins. #1546 v2 search: 500 error when last character is a colon As title. #1530 missing search results when doing a city location search for facilities Fixes a bug that did not show fac entries located in a city in simple search. #1533 Exchange Advanced search fails and returns bad search data Fixes and intermittent Advanced Search failure. #1451 Cosmetic issue with affiliation emails and double-slash in URL Fixes a cosmetic bug in autogenerated support messages. #1416 Add (PeeringDB Support) after superuser name in public notifications Support messages now more clearly identified as coming from PeeringDB Support. #1415 Auto-CleanUp old pending \"User to Organization Affiliation Request\" Pending affiliation requests are now cleaned up after 3 months. #1494 drop any facilities without location data (PDB Example) No fac without a geocode is now listed in the .KMZ export. #1528 pdb_rir_status task errors on deskpro ticket creation Fixes a bug in an internal support tool. #1453 DELETION PREVENTED: Link is not formatted as html element Fixes a bug in an internal support tool. #1484 Update ORG Social Media Option \"Twitter\" to \"X\" As title. Release 2.56.1 Release Date: 27 March 2024 GitHub issue Summary #1581 rdap to 1.5.2 Merge third-party library needed for complete fix of #1455 . Release 2.56.0 Beta Announcement Date: 13 March 2024 Release Date: 20 March 2024 GitHub issue Summary #1447 v2 search - support for ISO 3166 alpha-2 country codes v2 search now has support for ISO 3166 alpha-2 codes. #1495 Enable .KMZ export for Advanced Search results As title. #1489 Remove unneeded fields from the KMZ Removes field clutter to optimize file size. #1490 Spelling fix for KMZ Fixes spelling of 'Latitude'. #1099 Expose authentication methods on outbound federation Adds Authentication Method Reference field to OAuth profile, with choices from Section 2 of RFC8176 , documentation, and scope. #1133 Return auth error when multiple auth methods are used Now returns a 401 code with a helpful message when Authorization: Basic fails with corrupt base64 input. #1456 Duplicate AS-SET name Adds a tooltip suggesting hierarchical AS-SET names and a warning if a duplicate name is entered. #1331 BFD support field in Global and IX specific views Adds a boolean value for BFD support per IP address and a mouseover icon on the website when it's true. #1478 Social link controls showing up when not logged in Fixes a cosmetic bug that showed non-operational social media controls when not logged in. #1425 Update social media icons in footer Updates social media icons in the footer. #1152 Tab URLs don't work anymore Fixes tab URLs in the admin interface. Release 2.55.0 Beta Announcement Date: 21 February 2024 Release Date: 28 February 2024 GitHub issue Summary #1410 Adjust IPv4/6 prefix limits automatically Max prefix limit is now automatically adjusted based on the DFZ. #1455 Org name RIPE-NCC-END-MNT for new networks Fixes a bug that named orgs RIPE-NCC-END-MNT. #1468 translation refresh and dependency update translate.peeringdb.com updated to weblate 5.0 and other dependency updates. #1480 pdb_load_data no longer creates necessary org usergroups Fixes a bug with data sync tool. Release 2.54.2 Release Date: 31 January 2024 GitHub issue Summary #1536 Support 202311 rollback ux changes Reverted web UI changes that caused issues. Release 2.54.1 Release Date: 30 January 2024 GitHub issue Summary #1511 Non-obvious search box on the front page Search bar in header is now auto deployed. #1513 Mobile interface front page has lots of misaligned sections Fixes layout issues for some mobile devices. #1514 Two different search boxes on a network page information page in the same area As title. #1515 Bottom search box on some pages does not work correctly As title. Release 2.54.0 Beta Announcement Date: 18 January 2024 Release Date: 24 January 2024 GitHub issue Summary #1463 Update website to take advantage of wider screen and improve mobile device support As title. #1357 Clarifying the Network Type field Add multi-select for Network Type field. #1341 Only indicate availability of DC voltage for facilities Limits power options to non-standard voltages. #1476 v2 search not able to find organization and network - Marconi Solutions Srls Fixes a bug where bad search results are returned. #170 Add a \"flag bad data\" button on various places Adds a box web users can click to report bad data. #1430 Changing ASN field on \"Add Network\" to be numbers only The text box is now restricted to numbers, reducing scope for data entry issues. #1455 Org name RIPE-NCC-END-MNT for new networks Fixes a bug tat set some networks' names to RIPE-NCC-END-MNT. #1280 Improve RIR Update Procedure Improves the process for removing stale networks from PeeringDB. #1065 api-cache improvements As title. #1303 Add headers to API requests Adds a mechanism to indicate that behavior/schema has changed to API consumers. #1410 Adjust IPv4/6 prefix limits automatically Now automatically sets the maximum to 25% of the DFZ. #410 Add a \"last synced at $date\" to beta.peeringdb.com As title. #1468 translation refresh and dependency update As title. #1466 Analysis: Investigate use of ECS/Fargate As title. #1412 Improve performance by updating Python client code As title. Older releases 2023 Release Notes 2022 Release Notes 2021 Release Notes 2020 Release Notes","title":"Release Notes"},{"location":"release_notes/#release-notes-and-schedule","text":"The release notes list the GitHub issues and a summary of what has changed in PeeringDB software releases. Each new release has a one week beta test period on the beta server before it goes live. The beta and new releases are announced on the PeeringDB Announce Mailing List and on Facebook , LinkedIn and X .","title":"Release Notes and Schedule"},{"location":"release_notes/#release-schedule","text":"This schedule provides planned dates for PeeringDB\u2019s future releases. We are sharing these dates to help PeeringDB users plan ahead for testing new and improved features in beta. We also want to help volunteer developers know the date on which their code changes are needed for internal testing before beta release. We provide a rolling schedule. Dates can change, so if you have a question or request please contact us at: support@peeringdb.com . Our releases are generally deployed at around 04:00 UTC. Release number Internal testing Beta release Production release 2.63.0 2024-11-06 2024-11-13 2024-11-20 2.64.0 2024-01-08 2024-01-15 2024-01-22 2.65.0 2025-02-05 2025-02-12 2025-02-19 2.66.0 2025-03-14 2025-03-23 2025-03-30 2.67.0 2025-04-22 2025-04-29 2025-04-30 2.68.0 2025-05-07 2025-05-14 2025-05-21 2.69.0 2025-06-11 2025-06-18 2025-05-25","title":"Release schedule"},{"location":"release_notes/#release-2630","text":"Beta Announcement Date: 13 November 2024 Release Date: 20 November 2024 GitHub issue Summary #1671 Inconsistent netixlan ASN data can result in inability for deleted netixlan to be claimed by new user Nullify the local asn field of netixlan objects and make it a read only view of $network.asn.. #1666 Schedule reset of tutorial server database As title. #1635 ops: add read-only server side switch PeeringDB can now be placed into read-only mode when needed. #1593 Dev module docs auto generation broken Fixes a bug that broke autogeneration of documentation. #1690 New net_side and ix_side fields on netixlan breaks sync once django-peeringdb is released Fixes a bug that blocked the release of an updated django-peeringdb because of the new new net_side and ix_side fields added to netixlan in 2.62.0. peeringdb-py #65 Make spinning up peeringdb-py fully automated As title.","title":"Release 2.63.0"},{"location":"release_notes/#release-2621","text":"Release Date: 24 October 2024 GitHub issue Summary #1692 Fix otp email one time password Fixes compatibility issues after two-factor library upgrade, causing issues with emailing one time passwords.","title":"Release 2.62.1"},{"location":"release_notes/#release-2620","text":"Beta Announcement Date: 9 October 2024 Release Date: 16 October 2024 GitHub issue Summary #1584 Passkey support for login Adds a new 2FA method, Passkeys . #1612 Feature Parity for Carrier Object: Search and Export to JSON, CSV, KMZ As title. #1555 Remove \"Media Type\" field for Internet Exchange object As title. #1563 CSV and JSON exports truncate at 250 records Exports no longer truncate at 250 records. #607 Add location of Physical IX-Port & Router Port IXPs can now indicate the location of their switch using the pdb_facility_id attribute of the switch statement in their IX-F JSON export . peeringdb-py #95 Make client more robust when dealing with api errors. As title. peeringdb-py #86 DB sync fails due to validation error Bug fix as title. #1635 ops: add read-only server side switch Server can go into read-only mode, while allowing user login. This mode allows basic service to be sustained in adverse situations. #1654 Direct query access to Elasticsearch to aid search improvements Direct query access to ElasticSearch for internal PeeringDB users. #1653 Update dependencies and modernise As title. peeringdb-py #94 Update deps and modernize As title. django-peeringdb #103 Update dependencies and modernise As title. #340 switch to uv, update deps Dependency update for docs.peeringdb.com.","title":"Release 2.62.0"},{"location":"release_notes/#release-2610","text":"Beta Announcement Date: 14 August 2024 Release Date: 21 August 2024 GitHub issue Summary #1617 Snag list for preview.beta.peeringdb.com Updates preview.beta.peeringdb.com to improve the UI. #1142 Email one time password button should be less prominent As title. #766 For any forbidden actions set a 403 and give a \"Not Allowed\" header As title. #1302 Fix OpenAPI types where needed As title. peeringdb-py #76 Client should handle rate limiting errors gracefully As title. #1583 bfd_support undocumented parameter in API Documentation improved. django-peeringdb #98 ORM configuration Options is missing (postgreSQL) Config option updated. #1014 When removing a network, removing all netixlans have to happen before removing pocs Fixes blocking of network deletion due to to Prevent deletion of a last technical contact if there is an existing netixlan object #923.","title":"Release 2.61.0"},{"location":"release_notes/#release-2600","text":"Beta Announcement Date: 17 July 2024 Release Date: 24 July 2024 GitHub issue Summary #1452 Normalizing the presentation of place names Place names are now normalized, improving the consistency of search results. #1189 Data export buttons for Network, Exchange, and Facilities As title. #1561 Deploy www on ECS/Fargate www.peeringdb.com will be deployed using containers. peeringdb-py #67 Allow option for logging to co-exist with existing loggers Improves logging support in peeringdb-py local cache. peeringdb-py #72 --output-format in cli does not seem to be working Fixes bug as per title. #1322 Give API writes high priority and limits As title. #1610 possible for ixpfx object with empty prefix to exist in a soft-deleted state Fixes bug as per title. #1040 Verification queue ticket subject changes Fixes bug as per title.","title":"Release 2.60.0"},{"location":"release_notes/#release-2590","text":"Beta Announcement Date: 19 June 2024 Release Date: 26 June 2024 GitHub issue Summary #1585 Publish OAuth authorization server metadata endpoint As title. #1483 Address Change UI Fixes an error where it was not possible to reject the suggestion for an address. #1561 Deploy www on ECS/Fargate Switch www.peeringdb.com to ECS/Fargate. Initial deployment will be on beta.peeringdb.com with www.peeringdb.com following at a later date. peeringdb-py #49 Automatically update docs site on code release As title. peeringdb-py #88 docs need updating to reflect some api changes to the Client.update_all() call As title. #1603 Organization API key table formatting broken Improves the display of Organizational API Keys. #1604 API limit=x does not work when response type set in URL Limits to response sizes were ignored as per title. #971 Remove white space from strings As title. #1606 rir_status update handler: intermittent bug that may attempt to delete a network too early Fixes an over eager data cleanup process. #1608 pdb_delete_outdated_pending_affil_request failure Fixes an error is a data cleanup process.","title":"Release 2.59.0"},{"location":"release_notes/#release-2580","text":"Beta Announcement Date: 29 May 2024 Release Date: 5 June 2024 GitHub issue Summary #1343 Inconsistent return results when querying facilities by state (Datafill) Enforces state naming on validation and normalize data. #1502 Create preview.peeringdb.com with updated web UI Preview site for new PeeringDB web design. #1414 Tooltip with Full IX Name on Mouse-Over IX-Abbreviation As title. #1115 Enhancement to Ownership Information Field Lessee tooltip now says \"Leased or Rented\". #1487 URL Referrer Behavior Clicking on a link now opens it in a new tab or window. #840 Add help text to \"Traffic Levels\" Add tooltip \"Total, self-classified traffic in/out to this network.\". #1491 Add logo watermark and peeringdb.com URL to kmz As title. #975 \"Incomplete data\" complainer for Peering Policy even with General Policy \"None\" or \"Open\" No longer show missing data warning for empty Peering Policy field if General Policy is set to \"Open\" or \"No\". #1580 Validator: Add validator for X usernames, were requirements Validator for usernames on the X social media network. #1481 Network Registration fail results in AC action and retry failure Improved network registration process where email address does not match RDAP output. #1500 pdb_stats needs to be updated to include Campuses, Carriers, etc. & possible bug with user counts Improvements to internal stats package. #1503 Is it possible to create an affiliation request even when the ASN (~Net) has been deleted? (But the ORG still exist) As title. #1038 add default for config key MELISSA_KEY now defaults to a blank string. #1048 TOTP devices sort is by id. However, only username is shown Fixes a UI bug with internal support tools. #85 DB sync fails due to duplicate entries Fixes a peeringdb-py data sync bug.","title":"Release 2.58.0"},{"location":"release_notes/#release-2570","text":"Beta Announcement Date: 17 April 2024 Release Date: 24 April 2024 GitHub issue Summary #1545 Feature request: Allow permissions to be given per user on Carrier As title. #1123 Make a Technical POC mandatory when enabling \"Allow IXP Update\" As title. #1231 Change ix-f to IX-F As title. #1577 Remove more clutter from KMZ Metadata Makes data easier to read and slims download size. #1475 KML Placemark/Point Meta Data Not Displaying Correctly Fixes a bug that broke the way metadata displayed for .KMZ pins. #1546 v2 search: 500 error when last character is a colon As title. #1530 missing search results when doing a city location search for facilities Fixes a bug that did not show fac entries located in a city in simple search. #1533 Exchange Advanced search fails and returns bad search data Fixes and intermittent Advanced Search failure. #1451 Cosmetic issue with affiliation emails and double-slash in URL Fixes a cosmetic bug in autogenerated support messages. #1416 Add (PeeringDB Support) after superuser name in public notifications Support messages now more clearly identified as coming from PeeringDB Support. #1415 Auto-CleanUp old pending \"User to Organization Affiliation Request\" Pending affiliation requests are now cleaned up after 3 months. #1494 drop any facilities without location data (PDB Example) No fac without a geocode is now listed in the .KMZ export. #1528 pdb_rir_status task errors on deskpro ticket creation Fixes a bug in an internal support tool. #1453 DELETION PREVENTED: Link is not formatted as html element Fixes a bug in an internal support tool. #1484 Update ORG Social Media Option \"Twitter\" to \"X\" As title.","title":"Release 2.57.0"},{"location":"release_notes/#release-2561","text":"Release Date: 27 March 2024 GitHub issue Summary #1581 rdap to 1.5.2 Merge third-party library needed for complete fix of #1455 .","title":"Release 2.56.1"},{"location":"release_notes/#release-2560","text":"Beta Announcement Date: 13 March 2024 Release Date: 20 March 2024 GitHub issue Summary #1447 v2 search - support for ISO 3166 alpha-2 country codes v2 search now has support for ISO 3166 alpha-2 codes. #1495 Enable .KMZ export for Advanced Search results As title. #1489 Remove unneeded fields from the KMZ Removes field clutter to optimize file size. #1490 Spelling fix for KMZ Fixes spelling of 'Latitude'. #1099 Expose authentication methods on outbound federation Adds Authentication Method Reference field to OAuth profile, with choices from Section 2 of RFC8176 , documentation, and scope. #1133 Return auth error when multiple auth methods are used Now returns a 401 code with a helpful message when Authorization: Basic fails with corrupt base64 input. #1456 Duplicate AS-SET name Adds a tooltip suggesting hierarchical AS-SET names and a warning if a duplicate name is entered. #1331 BFD support field in Global and IX specific views Adds a boolean value for BFD support per IP address and a mouseover icon on the website when it's true. #1478 Social link controls showing up when not logged in Fixes a cosmetic bug that showed non-operational social media controls when not logged in. #1425 Update social media icons in footer Updates social media icons in the footer. #1152 Tab URLs don't work anymore Fixes tab URLs in the admin interface.","title":"Release 2.56.0"},{"location":"release_notes/#release-2550","text":"Beta Announcement Date: 21 February 2024 Release Date: 28 February 2024 GitHub issue Summary #1410 Adjust IPv4/6 prefix limits automatically Max prefix limit is now automatically adjusted based on the DFZ. #1455 Org name RIPE-NCC-END-MNT for new networks Fixes a bug that named orgs RIPE-NCC-END-MNT. #1468 translation refresh and dependency update translate.peeringdb.com updated to weblate 5.0 and other dependency updates. #1480 pdb_load_data no longer creates necessary org usergroups Fixes a bug with data sync tool.","title":"Release 2.55.0"},{"location":"release_notes/#release-2542","text":"Release Date: 31 January 2024 GitHub issue Summary #1536 Support 202311 rollback ux changes Reverted web UI changes that caused issues.","title":"Release 2.54.2"},{"location":"release_notes/#release-2541","text":"Release Date: 30 January 2024 GitHub issue Summary #1511 Non-obvious search box on the front page Search bar in header is now auto deployed. #1513 Mobile interface front page has lots of misaligned sections Fixes layout issues for some mobile devices. #1514 Two different search boxes on a network page information page in the same area As title. #1515 Bottom search box on some pages does not work correctly As title.","title":"Release 2.54.1"},{"location":"release_notes/#release-2540","text":"Beta Announcement Date: 18 January 2024 Release Date: 24 January 2024 GitHub issue Summary #1463 Update website to take advantage of wider screen and improve mobile device support As title. #1357 Clarifying the Network Type field Add multi-select for Network Type field. #1341 Only indicate availability of DC voltage for facilities Limits power options to non-standard voltages. #1476 v2 search not able to find organization and network - Marconi Solutions Srls Fixes a bug where bad search results are returned. #170 Add a \"flag bad data\" button on various places Adds a box web users can click to report bad data. #1430 Changing ASN field on \"Add Network\" to be numbers only The text box is now restricted to numbers, reducing scope for data entry issues. #1455 Org name RIPE-NCC-END-MNT for new networks Fixes a bug tat set some networks' names to RIPE-NCC-END-MNT. #1280 Improve RIR Update Procedure Improves the process for removing stale networks from PeeringDB. #1065 api-cache improvements As title. #1303 Add headers to API requests Adds a mechanism to indicate that behavior/schema has changed to API consumers. #1410 Adjust IPv4/6 prefix limits automatically Now automatically sets the maximum to 25% of the DFZ. #410 Add a \"last synced at $date\" to beta.peeringdb.com As title. #1468 translation refresh and dependency update As title. #1466 Analysis: Investigate use of ECS/Fargate As title. #1412 Improve performance by updating Python client code As title.","title":"Release 2.54.0"},{"location":"release_notes/#older-releases","text":"2023 Release Notes 2022 Release Notes 2021 Release Notes 2020 Release Notes","title":"Older releases"},{"location":"release_notes/release_notes_2020/","text":"2020 Release Notes The release notes list the GitHub issues and a summary of what has changed in PeeringDB software releases in 2020. Release notes for the current year are available on the Release Notes page. Each new release has a one week beta test period on the beta server before it goes live. The beta and new releases are announced on the PeeringDB Announce Mailing List and on Twitter , LinkedIn and Facebook . Release 2.24.0 Beta Announcement Date: 4 November, 2020 Release Date: 11 November, 2020 GitHub issue Summary #381 Network type: Add \"Government\" \u201cGovernment\u201d added as a network type. #463 Add new network type for networks that provide network services \u201cNetwork Services\" for networks whose function is to provide specialized services, like DNS, RDAP, Whois or DDoS protection added as a network type. #745 Add \u201cRoute Collector\u201d network type \u201cRoute Collector\u201d added as a network type. #747 Clean up info_type if name contains \"Route Servers\" or \"Route Collector\" Data cleanup related to #745. All networks with route collectors have now been properly classified. #665 Drop ixlan name from displaying at \"Peers at this Exchange Point\" Simplified the user interface by removing the name of the ixlan as there is now just one ixlan per exchange point. #775 Misleading tooltip of prefix limit fields NO Improved the user interface with better language in the tooltip. The distinction between maximum prefix length and maximum number of prefixes should now be clearer. #814 Suppress RDAP call for contact data/handles for NIC.br // AUTOTOOL Internal tool change. This change suppresses calls for contact data over RDAP because NIC.br is no longer allowed to provide direct calls for personal data. #803 Searching for a user in /cp/peeringdb_server/userorgaffiliationrequest results in 500 Internal tool change. Fixed an error that could return a 500 error on some searches. #688 Automate creation of Release Notes Internal tool change. A new script that extracts data from Github milestones to build the markdown for the release notes page. #851 sponsorship_notify RuntimeWarning (was: End of Sponsorship notification email is no longer working) Internal tool change to improve the tracking of sponsorship renewals. #861 add explicit order for fields in admin control panel Internal tool change. Display fields in an explicit order. #850 IX-F Importer: Repeated emails are being generated for things already emailed Internal procedure optimisation. A series of improvements to the IX-F importer tool. These changes are all related to improving notifications about data quality that were developed by the Data Ownership Task Force. #856 IX-F Importer: Make hyperlinks clickable when creating DeskPRO tickets See #850. #857 IX-F Importer: intermittent issue with speed validation See #850. #858 IX-F Importer: Make pdb_deskpro_publish command ignore importer tickets See #850. #859 IX-F Importer: ERROR: 'IXFMemberData' object has no attribute 'ixf_log_entry' See #850. #860 IX-F Importer Blocker: \"Days until DeskPRO ticket is created\" should now be ignored/removed, such that no ticket or emails happen after a delay See #850. Release 2.23.0 Beta Announcement Date: 30 September, 2020 Release Date: 7 October, 2020 GitHub issue Summary #833 - IX-F Importer: Add failed email resending Implement re-send mechanic for emails that could not be sent (indicated by a sent value of null). When re-sending an email add a note to the email stating \"This email could not be delivered initially and may contain stale information\". Add a field to the admin-com import emails table to show this note as well. Update sent if send is successful #832 - IX-F Importer: suggested update when it should be add + remove In some edge cases a deletion will end up as a requirement incorrectly to a legitimate new entry still. See #770 #816 #831 - [prod] IX-F importer: NameError: name 'EmailMultiAlternatives' is not defined Fixes broken email function of ix-f importer #826 - Make technical poc mandatory when adding a netixlan Upon creating a netixlan object check that net has at least one ( Technical , NOC , Policy ) poc and that the poc has an e-mail address. If not ask them to create one first. Visibility of at least one ( Technical , NOC , Policy ) poc has to be \"Users\" resp. \"Public\" #825 - [beta] IX-F importer: Make Importer return non-zero when there is an error that Ops should see Improvements to ix-f importer that allow for easier notification and tracking of errors for the Ops team #824 - IX-F Preview - shows the consolidated delete operation when it shouldn't Simplified the UI for consolidated modifications to improve user understanding #759 - Describe the 'never-via-routeservers' flag Add tooltip for never-via-routeservers option: \"Indicates if this network will announce its routes via route servers or not\" #571 - Facility registration tool adds identifier Fixes small UI bug in facility registration tool used by the Admin Committee #481 - Add min_speed and max_speed to ixlan Based on the discussion in #475 adds a new global setting that limits netixlan speed values now. It's not a property on the ixlan anymore. #371 - Clean up users in verification queue A tool to delete user entries older than 90 days from the so-called verification queue and run it on a regular schedule #370 - Make Website mandatory for suggesting a facility Website is now mandatory when suggesting a facility but zipcode only mandatory for countries that have zipcodes #321 - Typos in locale Fixes a number of typographical errors Release 2.22.0 Beta Announcement Date: 15 July, 2020 Release Date: 26 August, 2020 GitHub issue Summary #249 - Add the IX-F Member Export URL to the ixlan API endpoint There are two new fields in the ixlan section resp. the ixlan object, called ixf_ixp_member_list_url and ixf_ixp_member_list_url_visible. The first one contains the URL to the IX-F import file while the second governs the visibility of the URL. Values are the same as for the poc object, namely \"Public\", \"Users\" and \"Private\", defaulting to \"Private\" (i.e. or users who are members of the org). #268 - Database: unique constraints This issue fixes internal DB behaviour. #358 - Lock ASN once the record is created Once a network has been created, the field asn is made read-only. As the ASN is unique there is no reason to change it. Making the field read-only is to prevent unwanted side effects. #431 - Null 'rencode' from facility Null out all values for legacy unused rencode field, and make it read only to prepare for removal in PDB v3 [#625] (https://github.com/peeringdb/peeringdb/issues/625). #600 - Visibility for \"Allow IXP update\" switch A new field is added to the API net object, called allow_ixp_update. Furthermore, a line is added in global stats in the footer with a count (called \"Automated Networks\") of the networks which have \"Allow IXP Update\" enabled. #649 - Possible for 'ok' ixpfx to exist in 'pending' ixlan This issue fixes an internal bug. #683 - Add net_count_ixf field to ix object A field is added to the API object ix, called net_count_ixf, which indicates the number of net objects the exchange has in their IX-F JSON if they provide one. Otherwise, the value is null. #696 - Lock some objects from being deleted by the owner To protect operational data objects fac, ix, ixlan and org are prevented from being deleted as long as there are other objects related to it. First, these objects must be deleted before the object itself can be deleted. The attempt to delete such a protected object gives an error message and also opens a ticket with the PeeringDB support. #697 - Creating, changing, and deleting a netixlan object We completely re-implemented the way a connection to an exchange is handled. This new procedure allows both for a safe heads up a network can give to their peers as well as a safe way for exchanges to get rid of stale entries. Moreover, it allows networks to easily acknowledge new entries at exchanges which use the IX-F importer feature. See also the webinar for detailed information on this new procedure. Release 2.21.0 Beta Announcement Date: 24 June, 2020 Release Date: 1 July, 2020 GitHub issue Summary #72 - Enable sort and reverse sort of IP column in IX display Sort and reverse sort of IP column in IX display are added. Sort of the IP addresses in the expected natural order. The IPv4 address is the primary sort key. The IPv6 address is the secondary key. #121 - missing delete button for organizations New feature. An admin user is able to delete an org if it has no live objects under it. #290 - Offer 2FA 2FA is offered now. The implementation includes optional 2FA using TOTP is offered there is a knob in the user profile to enable and set it up email recovery is added using the verified user email address an icon is added in the org admin section to denote to org admins if users have 2FA enabled #352 - Mark IXP peering LAN as bogon Allow IXP to tag their LAN prefixes as bogons. In general, LAN prefixes should not be visible in the DFZ. If it should be visible, IXPs are able to debogonise them #356 - Sorting by clicking table headers should use local-compare Bugfix. Sorting now honours locale-sorting #519 - Make spelling of traffic levels consistent This is a bug fix and a minor improvement. Spelling is made consistent and traffic levels up to 100+Tbps are added. #526 - Show \"Last Updated\" fields on fac, ix, org records A \"Last Updated\" field is visible now for fac, ix, and org objects #537 - Posting https://www.peeringdb.com onto social media doesn't select a good preview image Add opengraph image for page preview. #566 - Should deleted personal data be accessable through the API? If a poc object is deleted it is made immediately non-gettable via the API, too. In case the corresponding net object was deleted unintentionally the object is still kept in the DB. After 30 days it will be hard-deleted. #569 - Don't return any POC data with status=deleted POC objects do have a visibility scope. If a POC record is deleted it should not be able to retrieve it at all, even if visibility had been set to \"public\" before. The data will still be kept internally for 30 days for rollback if the deletion happened unintentionally. After 30 days the record will be hard-deleted. #580 - Add a clear error message, when user tries to re-add a previously deleted facility Bug fix for an unclear behaviour. If a connection from a network to a facility was deleted the user was unable to re-add this connection by themselves and an unclear error message was given. Now, the user is able to re-add the connection. #618 - Support alternative direction of writing, e.g. Arabic For right-to-left written languages, the entire layout of the PeeringDB website has to be flipped around. #644 - Undeleting an ixlan with an emtpy IPv4 XOR IPv6 field throws a silly error Bugfix for the Admin Committee UI. An empty field was considered to be a legit non-null value and the system hence enforced uniqueness #650 - Add pointer from API docs to tutorial A URL is added from the API documentation website to the PeeringDB tutorials #654 - Add pointer from API docs to tutorial Bugfix for the Admin Committee UI. #663 - change default encoding of API calls to 'utf-8' The output of API calls will change from content-type: application/json; charset=iso-8859-1 to content-type: application/json; charset=utf-8 #664 - Selection should only present undeleted objects Admin Committee only related. Only non-deleted should be presented for selection #666 - Selection should only present undeleted objects When changing owner of an ix admin GUI borks because of \"Ixlan for exchange already exists\" #669 - Add help text to \"Add {Facility, Network, Exchange} tab Added a better help text to make crystal clear that adding a Facility, Network, or Exchange means that you are owning this object. #679 - Add read-only Superuser Provide PC members with a read-only access to the Admin UI. #712 - User is unable to update their net record Bug fix. Missing pointer to where the non-compliant value is Release 2.20.2 Release Date: 23 April, 2020 GitHub issue Summary #707 - Make source not required for IRR records Making source not required for IRR records. This requirement was an oversight during implementation of [#151 - Validation of IRR Records] (https://github.com/peeringdb/peeringdb/issues/151) that was released with 2.20.0 - see below. Product Committee revisited the issue after 2.20.0 and reports of concern from community and decided to retract the requirement in an emergency release Release 2.20.1 Release Date: 21 April, 2020 GitHub issue Summary #702 - Requests from peeringdb-py error 500 Emergency release for a config change Release 2.20.0 Beta Announcement Date: 15 April, 2020 Release Date: 21 April, 2020 GitHub issue Summary #151 - Validation of IRR Records To make the IRR as-set/route-set field of more operational value, strict rules apply the as-set/rs-set name has to conform to RFC 2622 (5.1 and 5.2) the source may be specified by AS-SET@SOURCE or SOURCE::AS-SET (preferred) valid sources are taken from the list of known IRRs multiple values must be separated by either ,, , or , (i.e. comma, space or comma followed by space) #189 - Improve explanatory and help text A clear help text is added for requesting affiliation to an organization. #251 - Limit number of concurrent affiliation requests per user In order to reduce organization affiliation request spamming, the number of pending organization requests has been limited to 5. #295 Desk pro tickets -> DeskPRO tickets This is a bug fix and only affects the Admin UI. #378 - Add contact information for Facilities (fac) the same way as for ix and net Contact information is added to Facilities and IXP. #452 - Org/Network name of a sponsor should not link to /sponsors, only the sponsor badge should This is a bug fix. From now on only when clicking on the sponsor badge will direct to the sponsor page. #462 - Route-server URL starting with ssh:// Add SSH as supported protocol. #539 - Add attribute 'operational' to 'netixlan' This is a new feature and allows networks to give early notice to their peers that they soon will show up at an IXP. There is a new check box when adding an IXP connection. By default, a connection is considered operational and the box is ticked. When the connection is still in provisioning status, please untick the box. When viewing, the warning glyphicon is shown right to the network name. The correspondent API object netixlan is enhanced by a boolean field operational defaulting to true. This feature is in line with the Data Ownership Policy . #548 - containerize server Internal software deployment system has been changed to use containers which reduces time spent by the ops team for deployments, allows for better scaling, and reduces the cost of entry for new developers to write and test their code. #555 - Notes field translate button disappears This is a bug fix. The \"Translate\" button is there for a moment and then disappeared. #557 - Show all languages on beta, even if translation is not ready for prod As soon as a new translation is starting it is available on the beta to help the translators and to encourage the community for input. #598 - bug caused by the org affiliationship request without an asn This is a bug fix and is only relevant for the PeeringDB Admin Committee. #609 - When creating an ix via the API also return ixlan_id and ixpfx_id When creating an IX record via API, the call will also return the implicitly created ixlan_id and ixpfx_id. This makes it simpler and reduces the number of calls that need to be made to the API. #615 - Insert links into ID fields in DESKPRO AUTOASN tickets This only affects tickets generated for PeeringDB Admin Committee. A link to the object in the UI is added. #626 - Update API docs Internal mechanisms for generating the API docs have been updated to current standards. This also allows for easier user contributions to the docs themselves. #634 - Remove support for python2 Python 2.7 and 3.4 support is being removed from PeeringDB packages. #636 - Don't create a new net object, when there only is an ASN block This is a bug fix and is only relevant for the PeeringDB Admin Committee. #667 - Fix use autocomplete fields in the admincom controlpanel to speed up loading times This is a bug fix and is only relevant for the PeeringDB Admin Committee.","title":"2020 Release Notes"},{"location":"release_notes/release_notes_2020/#2020-release-notes","text":"The release notes list the GitHub issues and a summary of what has changed in PeeringDB software releases in 2020. Release notes for the current year are available on the Release Notes page. Each new release has a one week beta test period on the beta server before it goes live. The beta and new releases are announced on the PeeringDB Announce Mailing List and on Twitter , LinkedIn and Facebook .","title":"2020 Release Notes"},{"location":"release_notes/release_notes_2020/#release-2240","text":"Beta Announcement Date: 4 November, 2020 Release Date: 11 November, 2020 GitHub issue Summary #381 Network type: Add \"Government\" \u201cGovernment\u201d added as a network type. #463 Add new network type for networks that provide network services \u201cNetwork Services\" for networks whose function is to provide specialized services, like DNS, RDAP, Whois or DDoS protection added as a network type. #745 Add \u201cRoute Collector\u201d network type \u201cRoute Collector\u201d added as a network type. #747 Clean up info_type if name contains \"Route Servers\" or \"Route Collector\" Data cleanup related to #745. All networks with route collectors have now been properly classified. #665 Drop ixlan name from displaying at \"Peers at this Exchange Point\" Simplified the user interface by removing the name of the ixlan as there is now just one ixlan per exchange point. #775 Misleading tooltip of prefix limit fields NO Improved the user interface with better language in the tooltip. The distinction between maximum prefix length and maximum number of prefixes should now be clearer. #814 Suppress RDAP call for contact data/handles for NIC.br // AUTOTOOL Internal tool change. This change suppresses calls for contact data over RDAP because NIC.br is no longer allowed to provide direct calls for personal data. #803 Searching for a user in /cp/peeringdb_server/userorgaffiliationrequest results in 500 Internal tool change. Fixed an error that could return a 500 error on some searches. #688 Automate creation of Release Notes Internal tool change. A new script that extracts data from Github milestones to build the markdown for the release notes page. #851 sponsorship_notify RuntimeWarning (was: End of Sponsorship notification email is no longer working) Internal tool change to improve the tracking of sponsorship renewals. #861 add explicit order for fields in admin control panel Internal tool change. Display fields in an explicit order. #850 IX-F Importer: Repeated emails are being generated for things already emailed Internal procedure optimisation. A series of improvements to the IX-F importer tool. These changes are all related to improving notifications about data quality that were developed by the Data Ownership Task Force. #856 IX-F Importer: Make hyperlinks clickable when creating DeskPRO tickets See #850. #857 IX-F Importer: intermittent issue with speed validation See #850. #858 IX-F Importer: Make pdb_deskpro_publish command ignore importer tickets See #850. #859 IX-F Importer: ERROR: 'IXFMemberData' object has no attribute 'ixf_log_entry' See #850. #860 IX-F Importer Blocker: \"Days until DeskPRO ticket is created\" should now be ignored/removed, such that no ticket or emails happen after a delay See #850.","title":"Release 2.24.0"},{"location":"release_notes/release_notes_2020/#release-2230","text":"Beta Announcement Date: 30 September, 2020 Release Date: 7 October, 2020 GitHub issue Summary #833 - IX-F Importer: Add failed email resending Implement re-send mechanic for emails that could not be sent (indicated by a sent value of null). When re-sending an email add a note to the email stating \"This email could not be delivered initially and may contain stale information\". Add a field to the admin-com import emails table to show this note as well. Update sent if send is successful #832 - IX-F Importer: suggested update when it should be add + remove In some edge cases a deletion will end up as a requirement incorrectly to a legitimate new entry still. See #770 #816 #831 - [prod] IX-F importer: NameError: name 'EmailMultiAlternatives' is not defined Fixes broken email function of ix-f importer #826 - Make technical poc mandatory when adding a netixlan Upon creating a netixlan object check that net has at least one ( Technical , NOC , Policy ) poc and that the poc has an e-mail address. If not ask them to create one first. Visibility of at least one ( Technical , NOC , Policy ) poc has to be \"Users\" resp. \"Public\" #825 - [beta] IX-F importer: Make Importer return non-zero when there is an error that Ops should see Improvements to ix-f importer that allow for easier notification and tracking of errors for the Ops team #824 - IX-F Preview - shows the consolidated delete operation when it shouldn't Simplified the UI for consolidated modifications to improve user understanding #759 - Describe the 'never-via-routeservers' flag Add tooltip for never-via-routeservers option: \"Indicates if this network will announce its routes via route servers or not\" #571 - Facility registration tool adds identifier Fixes small UI bug in facility registration tool used by the Admin Committee #481 - Add min_speed and max_speed to ixlan Based on the discussion in #475 adds a new global setting that limits netixlan speed values now. It's not a property on the ixlan anymore. #371 - Clean up users in verification queue A tool to delete user entries older than 90 days from the so-called verification queue and run it on a regular schedule #370 - Make Website mandatory for suggesting a facility Website is now mandatory when suggesting a facility but zipcode only mandatory for countries that have zipcodes #321 - Typos in locale Fixes a number of typographical errors","title":"Release 2.23.0"},{"location":"release_notes/release_notes_2020/#release-2220","text":"Beta Announcement Date: 15 July, 2020 Release Date: 26 August, 2020 GitHub issue Summary #249 - Add the IX-F Member Export URL to the ixlan API endpoint There are two new fields in the ixlan section resp. the ixlan object, called ixf_ixp_member_list_url and ixf_ixp_member_list_url_visible. The first one contains the URL to the IX-F import file while the second governs the visibility of the URL. Values are the same as for the poc object, namely \"Public\", \"Users\" and \"Private\", defaulting to \"Private\" (i.e. or users who are members of the org). #268 - Database: unique constraints This issue fixes internal DB behaviour. #358 - Lock ASN once the record is created Once a network has been created, the field asn is made read-only. As the ASN is unique there is no reason to change it. Making the field read-only is to prevent unwanted side effects. #431 - Null 'rencode' from facility Null out all values for legacy unused rencode field, and make it read only to prepare for removal in PDB v3 [#625] (https://github.com/peeringdb/peeringdb/issues/625). #600 - Visibility for \"Allow IXP update\" switch A new field is added to the API net object, called allow_ixp_update. Furthermore, a line is added in global stats in the footer with a count (called \"Automated Networks\") of the networks which have \"Allow IXP Update\" enabled. #649 - Possible for 'ok' ixpfx to exist in 'pending' ixlan This issue fixes an internal bug. #683 - Add net_count_ixf field to ix object A field is added to the API object ix, called net_count_ixf, which indicates the number of net objects the exchange has in their IX-F JSON if they provide one. Otherwise, the value is null. #696 - Lock some objects from being deleted by the owner To protect operational data objects fac, ix, ixlan and org are prevented from being deleted as long as there are other objects related to it. First, these objects must be deleted before the object itself can be deleted. The attempt to delete such a protected object gives an error message and also opens a ticket with the PeeringDB support. #697 - Creating, changing, and deleting a netixlan object We completely re-implemented the way a connection to an exchange is handled. This new procedure allows both for a safe heads up a network can give to their peers as well as a safe way for exchanges to get rid of stale entries. Moreover, it allows networks to easily acknowledge new entries at exchanges which use the IX-F importer feature. See also the webinar for detailed information on this new procedure.","title":"Release 2.22.0"},{"location":"release_notes/release_notes_2020/#release-2210","text":"Beta Announcement Date: 24 June, 2020 Release Date: 1 July, 2020 GitHub issue Summary #72 - Enable sort and reverse sort of IP column in IX display Sort and reverse sort of IP column in IX display are added. Sort of the IP addresses in the expected natural order. The IPv4 address is the primary sort key. The IPv6 address is the secondary key. #121 - missing delete button for organizations New feature. An admin user is able to delete an org if it has no live objects under it. #290 - Offer 2FA 2FA is offered now. The implementation includes optional 2FA using TOTP is offered there is a knob in the user profile to enable and set it up email recovery is added using the verified user email address an icon is added in the org admin section to denote to org admins if users have 2FA enabled #352 - Mark IXP peering LAN as bogon Allow IXP to tag their LAN prefixes as bogons. In general, LAN prefixes should not be visible in the DFZ. If it should be visible, IXPs are able to debogonise them #356 - Sorting by clicking table headers should use local-compare Bugfix. Sorting now honours locale-sorting #519 - Make spelling of traffic levels consistent This is a bug fix and a minor improvement. Spelling is made consistent and traffic levels up to 100+Tbps are added. #526 - Show \"Last Updated\" fields on fac, ix, org records A \"Last Updated\" field is visible now for fac, ix, and org objects #537 - Posting https://www.peeringdb.com onto social media doesn't select a good preview image Add opengraph image for page preview. #566 - Should deleted personal data be accessable through the API? If a poc object is deleted it is made immediately non-gettable via the API, too. In case the corresponding net object was deleted unintentionally the object is still kept in the DB. After 30 days it will be hard-deleted. #569 - Don't return any POC data with status=deleted POC objects do have a visibility scope. If a POC record is deleted it should not be able to retrieve it at all, even if visibility had been set to \"public\" before. The data will still be kept internally for 30 days for rollback if the deletion happened unintentionally. After 30 days the record will be hard-deleted. #580 - Add a clear error message, when user tries to re-add a previously deleted facility Bug fix for an unclear behaviour. If a connection from a network to a facility was deleted the user was unable to re-add this connection by themselves and an unclear error message was given. Now, the user is able to re-add the connection. #618 - Support alternative direction of writing, e.g. Arabic For right-to-left written languages, the entire layout of the PeeringDB website has to be flipped around. #644 - Undeleting an ixlan with an emtpy IPv4 XOR IPv6 field throws a silly error Bugfix for the Admin Committee UI. An empty field was considered to be a legit non-null value and the system hence enforced uniqueness #650 - Add pointer from API docs to tutorial A URL is added from the API documentation website to the PeeringDB tutorials #654 - Add pointer from API docs to tutorial Bugfix for the Admin Committee UI. #663 - change default encoding of API calls to 'utf-8' The output of API calls will change from content-type: application/json; charset=iso-8859-1 to content-type: application/json; charset=utf-8 #664 - Selection should only present undeleted objects Admin Committee only related. Only non-deleted should be presented for selection #666 - Selection should only present undeleted objects When changing owner of an ix admin GUI borks because of \"Ixlan for exchange already exists\" #669 - Add help text to \"Add {Facility, Network, Exchange} tab Added a better help text to make crystal clear that adding a Facility, Network, or Exchange means that you are owning this object. #679 - Add read-only Superuser Provide PC members with a read-only access to the Admin UI. #712 - User is unable to update their net record Bug fix. Missing pointer to where the non-compliant value is","title":"Release 2.21.0"},{"location":"release_notes/release_notes_2020/#release-2202","text":"Release Date: 23 April, 2020 GitHub issue Summary #707 - Make source not required for IRR records Making source not required for IRR records. This requirement was an oversight during implementation of [#151 - Validation of IRR Records] (https://github.com/peeringdb/peeringdb/issues/151) that was released with 2.20.0 - see below. Product Committee revisited the issue after 2.20.0 and reports of concern from community and decided to retract the requirement in an emergency release","title":"Release 2.20.2"},{"location":"release_notes/release_notes_2020/#release-2201","text":"Release Date: 21 April, 2020 GitHub issue Summary #702 - Requests from peeringdb-py error 500 Emergency release for a config change","title":"Release 2.20.1"},{"location":"release_notes/release_notes_2020/#release-2200","text":"Beta Announcement Date: 15 April, 2020 Release Date: 21 April, 2020 GitHub issue Summary #151 - Validation of IRR Records To make the IRR as-set/route-set field of more operational value, strict rules apply the as-set/rs-set name has to conform to RFC 2622 (5.1 and 5.2) the source may be specified by AS-SET@SOURCE or SOURCE::AS-SET (preferred) valid sources are taken from the list of known IRRs multiple values must be separated by either ,, , or , (i.e. comma, space or comma followed by space) #189 - Improve explanatory and help text A clear help text is added for requesting affiliation to an organization. #251 - Limit number of concurrent affiliation requests per user In order to reduce organization affiliation request spamming, the number of pending organization requests has been limited to 5. #295 Desk pro tickets -> DeskPRO tickets This is a bug fix and only affects the Admin UI. #378 - Add contact information for Facilities (fac) the same way as for ix and net Contact information is added to Facilities and IXP. #452 - Org/Network name of a sponsor should not link to /sponsors, only the sponsor badge should This is a bug fix. From now on only when clicking on the sponsor badge will direct to the sponsor page. #462 - Route-server URL starting with ssh:// Add SSH as supported protocol. #539 - Add attribute 'operational' to 'netixlan' This is a new feature and allows networks to give early notice to their peers that they soon will show up at an IXP. There is a new check box when adding an IXP connection. By default, a connection is considered operational and the box is ticked. When the connection is still in provisioning status, please untick the box. When viewing, the warning glyphicon is shown right to the network name. The correspondent API object netixlan is enhanced by a boolean field operational defaulting to true. This feature is in line with the Data Ownership Policy . #548 - containerize server Internal software deployment system has been changed to use containers which reduces time spent by the ops team for deployments, allows for better scaling, and reduces the cost of entry for new developers to write and test their code. #555 - Notes field translate button disappears This is a bug fix. The \"Translate\" button is there for a moment and then disappeared. #557 - Show all languages on beta, even if translation is not ready for prod As soon as a new translation is starting it is available on the beta to help the translators and to encourage the community for input. #598 - bug caused by the org affiliationship request without an asn This is a bug fix and is only relevant for the PeeringDB Admin Committee. #609 - When creating an ix via the API also return ixlan_id and ixpfx_id When creating an IX record via API, the call will also return the implicitly created ixlan_id and ixpfx_id. This makes it simpler and reduces the number of calls that need to be made to the API. #615 - Insert links into ID fields in DESKPRO AUTOASN tickets This only affects tickets generated for PeeringDB Admin Committee. A link to the object in the UI is added. #626 - Update API docs Internal mechanisms for generating the API docs have been updated to current standards. This also allows for easier user contributions to the docs themselves. #634 - Remove support for python2 Python 2.7 and 3.4 support is being removed from PeeringDB packages. #636 - Don't create a new net object, when there only is an ASN block This is a bug fix and is only relevant for the PeeringDB Admin Committee. #667 - Fix use autocomplete fields in the admincom controlpanel to speed up loading times This is a bug fix and is only relevant for the PeeringDB Admin Committee.","title":"Release 2.20.0"},{"location":"release_notes/release_notes_2021/","text":"2021 Release Notes The release notes list the GitHub issues and a summary of what has changed in PeeringDB software releases. Release notes for the current year are available on the Release Notes page. Each new release has a one week beta test period on the beta server before it goes live. The beta and new releases are announced on the PeeringDB Announce Mailing List and on Twitter , LinkedIn and Facebook . Release 2.32.0 Beta Announcement Date: 10 November 2021 Release Date: 17 November 2021 GitHub issue Summary #695 Auto focus cursor on search field on main website Places cursor in search box on first opening https://www.peeringdb.com #954 Rework ordering of dependencies Improved load speed for pages with large lists #748 PeeringDB website has a poor choice of line-breaks for IPv6 addresses IP addresses now have a no wrap style option so their numeric values aren't broken across lines #949 Add sales email and phone contact to ix object ix objects can now have a sales_email and sales_phone #838 Delete childless org objects Notifies admins of childless org s that they have no objects and deletes the org after 30 days if none are added #956 api documentation generate broken Fixes a bug that stopped the https://www.peeringdb.com/apidocs/ beingh updated automatically #962 Increase timeout timer for IX-F JSON importer to 30s Adds setting to control IX-F importer request timeout and default to 30 seconds #1054 IX-F manually triggered import bugs Fixes bugs triggered by manually importing IX-F data #807 [beta] IX-F importer: manual add followed by IX-F prompted add can result in \"The server rejected your data\" Resolves a bug triggered by manually adding netixlan in rare situations Release 2.31.0 Beta Announcement Date: 12 October 2021 Release Date: 20 October 2021 GitHub issue Summary #995 Block registering private ASN ranges Improves error message to user when attempting to register private ASNs and no longer automatically creates a support ticket #1007 Add a continental region field for facilities Continental region is now recorded for fac and is searchable from the advanced search page #18 IXP and Facility summary Presents a short statistical summary for ix 's and fac s #232 Incorrect order of search results ASNs will be moved to the top of the search results when a numeric search is an exact match for that ASN #346 Allow users to upload a small logo to their record orgs can now include a small logo in their record #453 Missing sponsor status in translations Fixed a bug so sponsor badges now show up properly in translations Release 2.30.0 Beta Announcement Date: 14 September 2021 Release Date: 22 September 2021 GitHub issue Summary #1944 Remove visibility \"Private\" from POC Make the \"Private\" visibility status invalid and requires an admin to review and update contacts when next making an update to their poc information #800 Additional self-selection fields for Facilities Adds additional fields to Facilities: Offered Space, Offered Power, Offered Resilience with appropriate details #1016 Add additional advanced search filters for new facility fields from #800 Adds the ability to search based on the new elements defined in #800 using Advanced Search #1032 Issue with api relationship filtering via __id Fixes a bug that impacted filtered searches made via the API #500 When network sets netixlan speed to 1200000 only 1T is shown instead of 1.2T ... sometimes Fixes a bug for speeds above 1Tb #1021 504 Gateway Time-out Fixes a timeout problem with the adminsitrative interface #1019 IX-F Importer: needless saves to deleted netixlans Fixes a bug that unnecessarily saved data to deleted objects Release 2.29.1 Release Date: 26 August 2021 GitHub issue Summary #1034 CORS Access-Control-Allow-Origin header missing in API responses Fixes an issue that stopped cross site API requests in the browser #1036 Issue with verification queue and deskpro ticket creation Fixes an issue that stopped newly created objects creating verification queue entries and a deskpro ticket Release 2.29.0 Beta Announcement Date: 18 August 2021 Release Date: 25 August 2021 GitHub issue Summary #779 Allow IXP to trigger ix-f importer for their exchange Exchanges can now trigger theIX-F importer and the UI communicates the status of the request #920 IX-F Importer: ticket status change when posting re-occuring conflict to existing resolved ticket Improve internal handling of IX-F importer conflicts #967 IX-F Importer: fix command output buffering Improve handling of output from IX-F importer command #903 Describe the 'DOT1Q' flag Set the field to false and made it read only (with a tooltip for the web interface) until v3 of the API #715 Support for Django 3 Upgrade to Django 3.2.1 and upgrade dependencies where possible #166 Add name, city, country to ixfac (GET operation) Add read-only fields name , city and country to object ixfac . The values for these fields are fac.name , fac.city and fac.country from the facility fac with id == fac_id #1023 Bug with email reports for internal errors Fixes an error with e-mail notifications for internal errors #1026 Fallback captcha solution is broken Fixes the fallback CAPTCHA on the account signup page #1013 The process to permanently remove old soft-deleted network contacts pdb_delete_pocs raises a false ProtectedAction Fixes a problem with adminsitrators permanently deleting contacts. #1015 Fallback captcha solution is broken Fixes a CAPTCHA bug affecting the AC through work on #715 Release 2.28.0 Beta Announcement Date: 14 July 2021 Release Date: 21 July 2021 GitHub issue Summary #23 make websearch smarter Provide a better search experience for quick search, advanced search and API filtering. The key features are properly indexed search, which supports search based on partial name matches, and geocoded search, which supports search based on coordinates. #965 IX-F importer: intermittent bug during consolidation of notifications Fixes a bug with the IX-F Member Export importer that resulted in intermittent import failures. #863 Improve error handling when a user tries to add an object which is already there Increases visibility of field validation error notes by increasing size and font weight. #375 On changing email address rescan open affiliation requests When a user changes their e-mail address we now automatically re-evaluate any open affiliation request that the user has that are tied to an ASN. #923 Prevent deletion of a last technical contact if there is an existing netixlan object Prevents deletion of the last technical contact of existing netixlan , i.e. enforce that netixlan should always have at least one technical contact Release 2.27.1 Beta Announcement Date: 19 May, 2021 Release Date: 26 May, 2021 GitHub issue Summary #946 Evaluate non-google map/geo sources Evaluated alternative geo data APIs and selected Melissa. #802 Extend Advanced Search for IXes and Facilities Adds search filters to advanced search (ix capacity search, organization presence search, and network presence search.) #799 Additional self-selection fields for IX objects Added service_level and terms fields to InternetExchange objects to allow exchanges to share additional ifnormation about their offering. These are supported as filters in the advanced search. #834 Add ix_count to object fac In the API, added a read-only field to fac called ix_count that counts the number of exchanges the linked to the facility). #835 Add {ix,fac}_count to object net In the API, added read-only fields to net called ix_count and fac_count that count the number of exchanges and facilities linked to the network). #836 Add fac_count to object ix In the API, added a read-only field to ix called fac_count that counts the number of facilities in which the exchange has a presence. #922 Circumvent approval of a facility by deleting and re-adding Fixed bug where if a user deletes a status \"pending\" fac, they can re-add it and it will be status \"ok\" (should be \"pending\"). #810 Get rid of the 'Protocols supported' fields / UI for IXes Removed proto_unicast , proto_multicast , and proto_ipv6 fields from ix UI. The fields remain in the v2 api but proto_ipv6 and proto_unicast will be populated from the existance of protocols in the exchange's ixpfx records. #985 500 Error on advanced search Resolved an issue where unauthenticated users got a 500 error in advanced search. Release 2.26.1 Beta Announcement Date: 14 April, 2021 Release Date: 21 April, 2021 GitHub issue Summary #883 IXF-Importer: minimise emails to Support/DeskPRO/AC This change collates all importer suggestions into a single e-mail notification. #931 Limit the number of requests for affiliation to an ASN/org to 1 Limits the number of affiliation request to an ASN to just one. Provides visual feedback on subsequent request attempts. #913 API should do an IP6 address instead of a string match Normalizes how IPv6 addresses are stored in the database and updates existing IPv6 addresses in the databases and elsewhere. Release 2.26.0 Beta Announcement Date: 10 March, 2021 Release Date: 24 March, 2021 GitHub issue Summary #266 Add API Keys This release introduces organization level API Keys . #827 Make GUI and API feature equivalent PeeringDB has a GUI and an API. This issue is a reminder to keep both feature equivalent. #865 Allow arbitrary decimal places as input for longitude and latitude. Systems rounds to six Allow arbitrary length of inputs to latitude and longitude. Round to 6 digits (including Google Maps output). #902 Add \"long name\" or \"aka\" field to 'fac' records add fields aka and name_long to object fac , ix , net , and org . #937 Geocode for org is broken This was fixed through work on #940. #939 Replace Validation Error with Validation \"Warning\" for geolocation validation If our address validation service cannot find an address corresponding to the user-inputed address it will allow the object to be saved and raise a \"validation warning\" in the meta object of the API response. The web UI will display a pop-up based on this warning. #940 Return geo-normalized fields as \"suggested address\" In an effort to normalize addresses, the system may overwrite the user input. In case of a mismatch, the user now is prompted with a \"suggested address\" and either confirms or rejects. In case of rejection, the address is taken as provided by the user. Please keep an eye on what you provided and what is suggested. The suggestion may flip street name and house name as well as cut off postal codes. #918 drop travis ci and move to github actions Changed CI environment to improve deployment speed. Release 2.25.0 Release Date: 3 February, 2021 GitHub issue Summary #246 IXF should be IX-F This release introduces various spelling corrections. #828 IX-F importer: Handle ipv4/ipv6 on same vlan but separate connections This issue deals with how the IX-F importer handles information from the IX-F JSON import. PeeringDB handles both the IPv4 as well as the IPv6 address in the same object ( netixlan ). And from a peering partner pov this is ok as it doesn't matter whether these addresses are on the same interface or even same router. However, IX-F JSON differentiates. For the time being, the importer combines IPv4 and IPv6 if both are set to an operational status in the IX-F JSON. #846 IX-F importer: if ixf_ixp_member_list_url is null then ixf_ixp_import_enabled can't be true Apply logic to the meaning of ixf_ixp_member_list_url . i.e. only allow ixf_ixp_import_enabled to be set to true if a URL is specified. #875 \"IXF-Importer: improved handling of how contacts are joined into direct conflict resolution deskpro tickets\" Resolved an issue where responses to automatically generated Deskpro tickets were routed to the wrong ticket. #878 IXF-Importer: reorder of email content This is mainly an internal improvement. And fixes also not disclosing private IXP information to the public. #882 IXF-Importer: don't abort when there is nothing to import If there is nothing to import from an IX-F JSON don't abort with an error message. #893 IX-F Importer: history of changes per ixlan & netixlan Fixed bug related to the logging of importer changes. #896 IX-F Importer: Bogus output of \"Preview\" tool Fixed a bug in the preview tool, where invalid member type ignored messages weren't filtered for the network viewing the preview. #888 Type issue when overriding settings through environment variables for numeric types Fixed a bug and now ensure that overrides are coerced to the correct expected type. #872 Update dependencies Updated container to python 3.9 and addressed all dependencies. #694 add syntactic sugar for entering port speeds Simplifies the UI for editing port speeds to make it more human friendly. #717 Loading time issue /cp facility view Fixed slow load or timeouts for loading data for some facilities #837 Provide a friendlier explanation when entering / changing a phone number Provides a tooltip to help people enter E.164 formatted telephone numbers. #541 When looking at a network record, show last updated ix<->net or fac<->net date Improved information about when records were last updated.","title":"2021 Release Notes"},{"location":"release_notes/release_notes_2021/#2021-release-notes","text":"The release notes list the GitHub issues and a summary of what has changed in PeeringDB software releases. Release notes for the current year are available on the Release Notes page. Each new release has a one week beta test period on the beta server before it goes live. The beta and new releases are announced on the PeeringDB Announce Mailing List and on Twitter , LinkedIn and Facebook .","title":"2021 Release Notes"},{"location":"release_notes/release_notes_2021/#release-2320","text":"Beta Announcement Date: 10 November 2021 Release Date: 17 November 2021 GitHub issue Summary #695 Auto focus cursor on search field on main website Places cursor in search box on first opening https://www.peeringdb.com #954 Rework ordering of dependencies Improved load speed for pages with large lists #748 PeeringDB website has a poor choice of line-breaks for IPv6 addresses IP addresses now have a no wrap style option so their numeric values aren't broken across lines #949 Add sales email and phone contact to ix object ix objects can now have a sales_email and sales_phone #838 Delete childless org objects Notifies admins of childless org s that they have no objects and deletes the org after 30 days if none are added #956 api documentation generate broken Fixes a bug that stopped the https://www.peeringdb.com/apidocs/ beingh updated automatically #962 Increase timeout timer for IX-F JSON importer to 30s Adds setting to control IX-F importer request timeout and default to 30 seconds #1054 IX-F manually triggered import bugs Fixes bugs triggered by manually importing IX-F data #807 [beta] IX-F importer: manual add followed by IX-F prompted add can result in \"The server rejected your data\" Resolves a bug triggered by manually adding netixlan in rare situations","title":"Release 2.32.0"},{"location":"release_notes/release_notes_2021/#release-2310","text":"Beta Announcement Date: 12 October 2021 Release Date: 20 October 2021 GitHub issue Summary #995 Block registering private ASN ranges Improves error message to user when attempting to register private ASNs and no longer automatically creates a support ticket #1007 Add a continental region field for facilities Continental region is now recorded for fac and is searchable from the advanced search page #18 IXP and Facility summary Presents a short statistical summary for ix 's and fac s #232 Incorrect order of search results ASNs will be moved to the top of the search results when a numeric search is an exact match for that ASN #346 Allow users to upload a small logo to their record orgs can now include a small logo in their record #453 Missing sponsor status in translations Fixed a bug so sponsor badges now show up properly in translations","title":"Release 2.31.0"},{"location":"release_notes/release_notes_2021/#release-2300","text":"Beta Announcement Date: 14 September 2021 Release Date: 22 September 2021 GitHub issue Summary #1944 Remove visibility \"Private\" from POC Make the \"Private\" visibility status invalid and requires an admin to review and update contacts when next making an update to their poc information #800 Additional self-selection fields for Facilities Adds additional fields to Facilities: Offered Space, Offered Power, Offered Resilience with appropriate details #1016 Add additional advanced search filters for new facility fields from #800 Adds the ability to search based on the new elements defined in #800 using Advanced Search #1032 Issue with api relationship filtering via __id Fixes a bug that impacted filtered searches made via the API #500 When network sets netixlan speed to 1200000 only 1T is shown instead of 1.2T ... sometimes Fixes a bug for speeds above 1Tb #1021 504 Gateway Time-out Fixes a timeout problem with the adminsitrative interface #1019 IX-F Importer: needless saves to deleted netixlans Fixes a bug that unnecessarily saved data to deleted objects","title":"Release 2.30.0"},{"location":"release_notes/release_notes_2021/#release-2291","text":"Release Date: 26 August 2021 GitHub issue Summary #1034 CORS Access-Control-Allow-Origin header missing in API responses Fixes an issue that stopped cross site API requests in the browser #1036 Issue with verification queue and deskpro ticket creation Fixes an issue that stopped newly created objects creating verification queue entries and a deskpro ticket","title":"Release 2.29.1"},{"location":"release_notes/release_notes_2021/#release-2290","text":"Beta Announcement Date: 18 August 2021 Release Date: 25 August 2021 GitHub issue Summary #779 Allow IXP to trigger ix-f importer for their exchange Exchanges can now trigger theIX-F importer and the UI communicates the status of the request #920 IX-F Importer: ticket status change when posting re-occuring conflict to existing resolved ticket Improve internal handling of IX-F importer conflicts #967 IX-F Importer: fix command output buffering Improve handling of output from IX-F importer command #903 Describe the 'DOT1Q' flag Set the field to false and made it read only (with a tooltip for the web interface) until v3 of the API #715 Support for Django 3 Upgrade to Django 3.2.1 and upgrade dependencies where possible #166 Add name, city, country to ixfac (GET operation) Add read-only fields name , city and country to object ixfac . The values for these fields are fac.name , fac.city and fac.country from the facility fac with id == fac_id #1023 Bug with email reports for internal errors Fixes an error with e-mail notifications for internal errors #1026 Fallback captcha solution is broken Fixes the fallback CAPTCHA on the account signup page #1013 The process to permanently remove old soft-deleted network contacts pdb_delete_pocs raises a false ProtectedAction Fixes a problem with adminsitrators permanently deleting contacts. #1015 Fallback captcha solution is broken Fixes a CAPTCHA bug affecting the AC through work on #715","title":"Release 2.29.0"},{"location":"release_notes/release_notes_2021/#release-2280","text":"Beta Announcement Date: 14 July 2021 Release Date: 21 July 2021 GitHub issue Summary #23 make websearch smarter Provide a better search experience for quick search, advanced search and API filtering. The key features are properly indexed search, which supports search based on partial name matches, and geocoded search, which supports search based on coordinates. #965 IX-F importer: intermittent bug during consolidation of notifications Fixes a bug with the IX-F Member Export importer that resulted in intermittent import failures. #863 Improve error handling when a user tries to add an object which is already there Increases visibility of field validation error notes by increasing size and font weight. #375 On changing email address rescan open affiliation requests When a user changes their e-mail address we now automatically re-evaluate any open affiliation request that the user has that are tied to an ASN. #923 Prevent deletion of a last technical contact if there is an existing netixlan object Prevents deletion of the last technical contact of existing netixlan , i.e. enforce that netixlan should always have at least one technical contact","title":"Release 2.28.0"},{"location":"release_notes/release_notes_2021/#release-2271","text":"Beta Announcement Date: 19 May, 2021 Release Date: 26 May, 2021 GitHub issue Summary #946 Evaluate non-google map/geo sources Evaluated alternative geo data APIs and selected Melissa. #802 Extend Advanced Search for IXes and Facilities Adds search filters to advanced search (ix capacity search, organization presence search, and network presence search.) #799 Additional self-selection fields for IX objects Added service_level and terms fields to InternetExchange objects to allow exchanges to share additional ifnormation about their offering. These are supported as filters in the advanced search. #834 Add ix_count to object fac In the API, added a read-only field to fac called ix_count that counts the number of exchanges the linked to the facility). #835 Add {ix,fac}_count to object net In the API, added read-only fields to net called ix_count and fac_count that count the number of exchanges and facilities linked to the network). #836 Add fac_count to object ix In the API, added a read-only field to ix called fac_count that counts the number of facilities in which the exchange has a presence. #922 Circumvent approval of a facility by deleting and re-adding Fixed bug where if a user deletes a status \"pending\" fac, they can re-add it and it will be status \"ok\" (should be \"pending\"). #810 Get rid of the 'Protocols supported' fields / UI for IXes Removed proto_unicast , proto_multicast , and proto_ipv6 fields from ix UI. The fields remain in the v2 api but proto_ipv6 and proto_unicast will be populated from the existance of protocols in the exchange's ixpfx records. #985 500 Error on advanced search Resolved an issue where unauthenticated users got a 500 error in advanced search.","title":"Release 2.27.1"},{"location":"release_notes/release_notes_2021/#release-2261","text":"Beta Announcement Date: 14 April, 2021 Release Date: 21 April, 2021 GitHub issue Summary #883 IXF-Importer: minimise emails to Support/DeskPRO/AC This change collates all importer suggestions into a single e-mail notification. #931 Limit the number of requests for affiliation to an ASN/org to 1 Limits the number of affiliation request to an ASN to just one. Provides visual feedback on subsequent request attempts. #913 API should do an IP6 address instead of a string match Normalizes how IPv6 addresses are stored in the database and updates existing IPv6 addresses in the databases and elsewhere.","title":"Release 2.26.1"},{"location":"release_notes/release_notes_2021/#release-2260","text":"Beta Announcement Date: 10 March, 2021 Release Date: 24 March, 2021 GitHub issue Summary #266 Add API Keys This release introduces organization level API Keys . #827 Make GUI and API feature equivalent PeeringDB has a GUI and an API. This issue is a reminder to keep both feature equivalent. #865 Allow arbitrary decimal places as input for longitude and latitude. Systems rounds to six Allow arbitrary length of inputs to latitude and longitude. Round to 6 digits (including Google Maps output). #902 Add \"long name\" or \"aka\" field to 'fac' records add fields aka and name_long to object fac , ix , net , and org . #937 Geocode for org is broken This was fixed through work on #940. #939 Replace Validation Error with Validation \"Warning\" for geolocation validation If our address validation service cannot find an address corresponding to the user-inputed address it will allow the object to be saved and raise a \"validation warning\" in the meta object of the API response. The web UI will display a pop-up based on this warning. #940 Return geo-normalized fields as \"suggested address\" In an effort to normalize addresses, the system may overwrite the user input. In case of a mismatch, the user now is prompted with a \"suggested address\" and either confirms or rejects. In case of rejection, the address is taken as provided by the user. Please keep an eye on what you provided and what is suggested. The suggestion may flip street name and house name as well as cut off postal codes. #918 drop travis ci and move to github actions Changed CI environment to improve deployment speed.","title":"Release 2.26.0"},{"location":"release_notes/release_notes_2021/#release-2250","text":"Release Date: 3 February, 2021 GitHub issue Summary #246 IXF should be IX-F This release introduces various spelling corrections. #828 IX-F importer: Handle ipv4/ipv6 on same vlan but separate connections This issue deals with how the IX-F importer handles information from the IX-F JSON import. PeeringDB handles both the IPv4 as well as the IPv6 address in the same object ( netixlan ). And from a peering partner pov this is ok as it doesn't matter whether these addresses are on the same interface or even same router. However, IX-F JSON differentiates. For the time being, the importer combines IPv4 and IPv6 if both are set to an operational status in the IX-F JSON. #846 IX-F importer: if ixf_ixp_member_list_url is null then ixf_ixp_import_enabled can't be true Apply logic to the meaning of ixf_ixp_member_list_url . i.e. only allow ixf_ixp_import_enabled to be set to true if a URL is specified. #875 \"IXF-Importer: improved handling of how contacts are joined into direct conflict resolution deskpro tickets\" Resolved an issue where responses to automatically generated Deskpro tickets were routed to the wrong ticket. #878 IXF-Importer: reorder of email content This is mainly an internal improvement. And fixes also not disclosing private IXP information to the public. #882 IXF-Importer: don't abort when there is nothing to import If there is nothing to import from an IX-F JSON don't abort with an error message. #893 IX-F Importer: history of changes per ixlan & netixlan Fixed bug related to the logging of importer changes. #896 IX-F Importer: Bogus output of \"Preview\" tool Fixed a bug in the preview tool, where invalid member type ignored messages weren't filtered for the network viewing the preview. #888 Type issue when overriding settings through environment variables for numeric types Fixed a bug and now ensure that overrides are coerced to the correct expected type. #872 Update dependencies Updated container to python 3.9 and addressed all dependencies. #694 add syntactic sugar for entering port speeds Simplifies the UI for editing port speeds to make it more human friendly. #717 Loading time issue /cp facility view Fixed slow load or timeouts for loading data for some facilities #837 Provide a friendlier explanation when entering / changing a phone number Provides a tooltip to help people enter E.164 formatted telephone numbers. #541 When looking at a network record, show last updated ix<->net or fac<->net date Improved information about when records were last updated.","title":"Release 2.25.0"},{"location":"release_notes/release_notes_2022/","text":"2022 Release Notes The release notes list the GitHub issues and a summary of what has changed in PeeringDB software releases. Release notes for the current year are available on the Release Notes page. Each new release has a one week beta test period on the beta server before it goes live. The beta and new releases are announced on the PeeringDB Announce Mailing List and on Twitter , LinkedIn and Facebook . Release 2.42.0 Beta Announcement Date: 9 November 2022 Release Date: 16 November 2022 GitHub issue Summary #983 Allow REALPEER to overwrite GHOSTPEER netixlan entry, if asn and IPv6/v4 addresses matches the IX-F Members Export information Improve the quality of IXP data delivered through IX-F Imports for cases when a network disconnects from an IXP but does not update their PeeringDB record. #1153 Exporting Advanced Search broken Fixes a bug that stopped users exporting some searches as structured data. #1091 Adjust \"Add Facility\" menu to include newly defined fields Newly defined fac fields, such as available voltage services, can now be entered when creating the Facility. #1253 Reset IX-F suggestions link non-functional Fixes a link that presents users with suggestions. #758 Lightweight user notification mechanism Introduce a mechanism to alert logged in web users to upcoming changes. #1250 UI shows own email when viewing affiliation requests for an organization Fixes a bug that showed organization admins their own email address instead of the user requesting affiliation. #1234 Transition from lgtm.com before the service ends Migrate to a new CI service. #1168 Ops: Throttle strings with \"Response size\" should be renamed \"Repeated request\" Improve the quality of error messages related to usage throttling. #953 User may request affiliation with a deleted organisation Fixes a bug that allowed users to request affiliation with a deleted organization. #659 Improve readability when users have special permissions Makes a support screen easier to read. #924 Allow change of ixpfx Improves automation for updating records associated with IXP peering LANs. #1270 Enable Google Analytics for beta.peeringdb.com Introduces Google Analytics for beta.peeringdb.com. More details . #1224 Internal admins only: console 504 time-out bug for ix history Fixes a timeout error affecting PeeringDB Admins. #1283 Footer \"Global System Statistics\" should be cached within django instance, not updated with every page load Introduces cacheing for the Global System Statistics data on each page. Release 2.41.1 Release Date: 26 October 2022 GitHub issue Summary #1275 Missing allowed sources for scripts Adds in some missing sources that were stopping /apidocs and CAPTCHA from working. Release 2.41.0 Beta Announcement Date: 12 October 2022 Release Date: 26 October 2022 GitHub issue Summary #586 Add export tool to https://peeringdb.com/cp/peeringdb_server/$type Adds new data exports on CSV format. #1044 Adding a POC must require an email address or phone number Points of Contact must now have either an email address or a phone number. #1244 IX-F importer fails on nulled ipv4 / ipv6 properties in vlan_list entries Fixes a bug where the IX-F importer would raise an error when encountering null values for ipv6 or ipv4 properties in the vlan_list property . #1216 RIR Status update misses ASNs Fixes a bug in the way RIR status is recorded for networks. #1223 Invalid data (in choice fields) found via API Fixes a bug where some records had invalid values. #1198 Add automated testing at the browser level Introduces automated testing for web functionality. #1149 HTTP 404 for dom-purify/purify.min.js.map and showdown/showdown.min.js.map Fixes a JS problem affecting several popular browsers. #1234 Transition from lgtm.com before the service ends Ensures continuity of continuous security analysis now after lgtm.com closes. Release 2.40.0 Beta Announcement Date: 14 September 2022 Release Date: 21 September 2022 GitHub issue Summary #736 Periodic validation of user's contact information Organizations can now require affiliated users to revalidate their accounts after a number of days chosen by the organization. #737 Restrict email domains for organizations Organizations can now require users to have an email address using a specific domain to affiliate with the organization. #484 Show username and email address when user is logged in User will now see their username and email address when logged in to the website. #738 Allow multiple email addresses per user User can have multiple email addresses associated with an account. #907 User email address change should notify previous email Users will now be notified at the old address when replacing their email address. #947 Make it possible to display the TOTP secret in text form instead of QR code only When setting up TOTP MFA, users can now see the secret as well as a QR code. #267 remove users with duplicate emails The user database has been cleaned so that only one user account can have an email address. #380 DB clean-up of elderly ophaned user accounts Users are notified when their account is not associated with an organization for 60 days. The account is removed a month later if not associated with an organization. #1157 An account with admin status can not have permissions When users gain admin status for an organization they now lose all granular permissions as they have all permissions. #468 Have the \"Select language\" drop down sorted Translation language names are now sorted alphabetically in English with the translated version of the language name presented alongside. #1202 Add Support for Enums against Locale Field Validates that languages are supported by translations. #1203 Validate Local Field against set of Enums Improves error handling when users set invalid languages. #499 Trigger IX-F import when network sets allow_ixp_update to \"yes\" An IX-F import is now triggered when a network sets allow_ixp_update to yes. #1213 robots.txt needed, at a minimum to limit bots from creating Django sessions Added robots.txt files to stop search engines indexing pages that shouldn't be indexed. #1210 UX Bugs Fixes several bugs introduced with the big UX dependency updates rolled out with 2.38. #959 ASNAUTO tool broken Fixes an issue with the ASNAuto tool sending out incorrect manual approval requests. #981 Error-handling of failed creation of DeskPRO tickets Fixes a problem with the creation of support tickets. #1150 Ops: Log Melissa payload in django.log Fixes a logging issue for the Ops team. #1228 Change \"Resul length\" to \"Result length\" Fixes a typo. This release also introduced a change for updates made with the API. These operations must now be authenticated with an API Key. Our HOWTO document explains how to get started using API Keys. Release 2.39.0 Beta Announcement Date: 20 July 2022 Release Date: 27 July 2022 GitHub issue Summary #473 add rir_* fields to keep track of ASN status Improve data quality by adding fields that will allow us to perform statical analysis and remove ASNs when no longer assigned. #1203 Validate Local Field against set of Enums Improvements to error handling should a user mischievously send junk data. #1205 Ops: Limit Django sessions to pages that need it Django sessions are now limited to pages that need it. #941 Organization Merging Tool only offers the first 10 matches Improve the organization merge tool for admins. #1043 AC Change User Permission broken Fixes a bug that did not remove users from an organization when it was deleted. #1157 An account with admin status can not have permissions Fixes a bug that did not remove granular permissions for an organization when a users was upgraded to an admin. #1135 #727 RS Peer Checkbox followup changes Cosmetic changes to the RS Peer Checkbox. Release 2.38.2 Release Date: 24 June 2022 GitHub issue Summary #1194 Advanced search issues Fixes a bug that stopped advanced search from delivering results. #1195 UI: active tabs no longer highlighted after switching Fixes a bug that stopped the current tab being highlighted in active search after changing tab. Release 2.38.0 Beta Announcement Date: 15 June 2022 Release Date: 22 June 2022 GitHub issue Summary #930 Admin user is missing the \"Edit\" button Fixes a bug that prevented users from editing their entries. #963 Add the IX name and id to IX-F Import Emails Addresses messages to exchange operators more clearly. #879 Add \"Last login\" to https://peeringdb.com/cp/peeringdb_server/user/ Let's the Admin Committee know who from an organization most recently logged in. #1057 Force users to provide input for first / last names when registering with PeeringDB Use the username instead of formal name in tickets when it's not registered. #660 Bug in renumbering tool Fixes a bug with the renubering tool. #1172 Ops: Exempt superusers (PeeringDB Admin Committee & Operations Committee admins) from throttling API and Melissa request throttling is no longer applied to authenticated admin users. #1177 Locale field update has uncaught exception Fixes a bug where a logged in user could send data that generated DataError and Internal Server Error. Exceptions are now caught appropriately and return relevant errors to users. #1174 Insecure Dependencies Upgrades three dependencies to newer versions that address known vulnerabilities. #1186 Browser caches OAuth2 application client secrets Fixes a bug that allowed browsers to cache the OAuth2 application details page. #1184 Tie CSRF token to session Fixes a bug by binding the session ID and the CSRF token together to reduce the risk that an old token is misused. Release 2.37.0 Beta Announcement Date: 11 May 2022 Release Date: 17 May 2022 GitHub issue Summary #403 Notify a record holder when there is an automated change to the profile Notifications are now sent when PeeringDB administrators make changes to records. #1155 Feature Request: Promote OAuth application to admin-level access? Adds organization level OAuth app management and allows organizations to transfer existing OAuth apps tied to their users to the organization. #942 Failure on Admin Organization Merge Fixes a big that prevented PeeringDB Admins from merging organizations. #960 Change any \"Primary ASN\" to \"ASN\" Replaces the phrase \"Primary ASN\" with \"ASN\" everywhere as the Primary ASN concept does not exist in PeeringDB 2.0. #986 Add link to release notes to the footer of www.peeringdb.com Release notes are now linked from the footer, making them easier for all users to find. Release 2.36.0 Beta Announcement Date: 13 April 2022 Release Date: 11 May 2022 GitHub issue Summary peeringdb-py #62 Support User & Org API keys Adds API keys support for the peeringdb-py cacheing client. #1079 Normalize the names of states & provinces for various objects Normalizes names for states and provinces, improving search experience. #784 Do not show objects in status \"pending\" on the UI Objects that do not have an OK status are no longer returned in search results. #996 500 Error during login for 2FA enabled accounts with unverified email address Fixes a bug that generated a 500 error when logging in with an account whose e-mail address had not been verified. #845 Need consolidated app logs Improvements to logging. #1119 Some command-line-tool executions are not logged Improves logging so AC tools can undo actions. #1120 Ops: response header X-Auth-ID to augment logging Logs the user for requested authenticated by API keys allowing them to be contacted. #1121 Ops: API throttling needs customizable messages API requests can now be throttled with custom return code (HTTP 429). #1122 Logging for melissa (geo-address normalization) queries Adds support for logging geosearch queries to the external API. #1124 Allow rate-limiting of melissa enabled api functionality. Adds support for rate-limiting the geosearch features that rely on an external API. #1126 Ops: API throttling of repeated requests Adds support for throttling repeated requests. #1096 Clicking on Facility history in AC GUI throws 500 Fixes a bug that hid fac history. #1035 Django-Admin: adding a network with existing asn fails with internal error Fixes a bug that returned a 500 error when a user attempted to add a net with the same ASN as an existing object. It now returns a more helpful validation error. Release 2.35.0 Beta Announcement Date: 8 March 2022 Release Date: 22 March 2022 GitHub issue Summary #506 Add \"Management\" search field to Advanced Search of Exchanges Allows users to search for IXPs based on the organization that operates the IXP. #727 RS Peer Checkbox also visible on IX Site Information about networks claiming to peer with the Route Server is now shown on the IXP's page. #512 New Field \"Health Check\" Networks, IXPs, and Facilities can now link to a status dashboard page. #653 missing delete button for user There is now a button to delete a user account directly through the web interface. #656 Sort user IDs in https://www.peeringdb.com/cp/peeringdb_server/userpermission/xxxxx numerically Fixes the sorting order of user IDs, so they are now sorted in numerical order. #881 wrap correctly on mobile The ASN column on mobile view will show seven digits before wrapping the number. #908 2FA Backup Tokens language doesn't seem correct Fixes the backup tokens language for 2FA. #916 To force or not to force www, that is a question Forces https://www.peeringdb.com as the URL for PeeringDB, enabling other improvements. Some clients will need to adjust their endpoints to use www.peeringdb.com. curl users will want to use the -L flag. #1042 Long caching of deleted entries Fixes a problem where deleted objects continued to be returned because of cacheing. #1117 Bad API keys need to return 401 just like a bad user/pass. Presently they return 200 Fixes a problem where corrupt or expired or bogus API key simply resulted in an anonymous user session. Release 2.34.0 Beta Announcement Date: 9 February 2022 Release Date: 16 February 2022 GitHub issue Summary #722 Create a validation tool for syntactically well defined fields Introduces a tool to improve data quality by validating syntactically well defined fields. #853 substantially rate limit unauthenticated /api/ queries to encourage authenticated queries Introduces rate limiting for unauthenticated API queries to reduce the possibility of service impacting queries. #620 Add organisations and registered users to \"Global System Statistics\" in footer Adds the number of registered users to the footer, giving users a better idea of the size of the interconnection community. Release 2.33.0 Beta Announcement Date: 12 January 2022 Release Date: 19 January 2022 GitHub issue Summary #1083 Nanog 83 Hackathon improvements to the PeeringDB Website When using simple search on the front page of www.peeringdb.com (or via the API) searches for numbers return the most relevant results. Key changes include: searching for a short ASN returns just that network, and searches for two segments of an IP address are required to return related ix and net objects. #1070 OpenID Connect integration Allows organizations using PeeringDB to enable an identity federation with a managed service. #692 Add FIDO U2F 2FA support Adds support for FIDO U2F hardware tokens, allowing users to enable 2FA without relying on a TOTP app. #1033 Clicking \"Add\" to add a user api-key without providing a name for the key raises Internal Error Fixes a bug where unnamed user api-keys could not be added and there was just an internal error. #374 make URL required for new objects A URL to a website is now required when adding new objects. #469 Add IXP to AS record / dropdown limited Fixes a bug that limited the number of entries in the dropdown menu when adding an ix to a net . #284 global stats don't show up at login screen Global stats are now shown at the login web page. #874 Better error message when entering the wrong password for email change Improved the error message when entering the wrong password for an e-mail change. #365 Username retrieval non-existant email bug Fixes a bug where we attempted to send mail to non-existant addresses. #735 Cascade delete when performed by superuser Admin users can now cascade delete through the admin interface. #901 Creating a facility that matches the name of a soft-deleted facility will cause the entry to bypass the verification queue Fixes a bug where fac creation could bypass the validation process. #921 irr source validator doesn't allow for hyphens in source IRRs with a hyphen in the name, like ARIN-NONAUTH, are now supported. #1060 \"HARAKIRI ON WORKER\" issues need to be resolved Fixes an operational issue. #1062 Registering a new facility or exchange organization is broken Fixes a bug that prevented new fac and ix objects to be registered. #1077 Possible for \"pending\" exchange to have \"deleted\" ixlan Fixes a bug that allowed linked ix objects to jhave a different status, affecting API sync. #1088 Tweaks for empty organization clean up Fixes a bug that allowed sponsor organizations to be deleted by an automatic process when they should not be.","title":"2022 Release Notes"},{"location":"release_notes/release_notes_2022/#2022-release-notes","text":"The release notes list the GitHub issues and a summary of what has changed in PeeringDB software releases. Release notes for the current year are available on the Release Notes page. Each new release has a one week beta test period on the beta server before it goes live. The beta and new releases are announced on the PeeringDB Announce Mailing List and on Twitter , LinkedIn and Facebook .","title":"2022 Release Notes"},{"location":"release_notes/release_notes_2022/#release-2420","text":"Beta Announcement Date: 9 November 2022 Release Date: 16 November 2022 GitHub issue Summary #983 Allow REALPEER to overwrite GHOSTPEER netixlan entry, if asn and IPv6/v4 addresses matches the IX-F Members Export information Improve the quality of IXP data delivered through IX-F Imports for cases when a network disconnects from an IXP but does not update their PeeringDB record. #1153 Exporting Advanced Search broken Fixes a bug that stopped users exporting some searches as structured data. #1091 Adjust \"Add Facility\" menu to include newly defined fields Newly defined fac fields, such as available voltage services, can now be entered when creating the Facility. #1253 Reset IX-F suggestions link non-functional Fixes a link that presents users with suggestions. #758 Lightweight user notification mechanism Introduce a mechanism to alert logged in web users to upcoming changes. #1250 UI shows own email when viewing affiliation requests for an organization Fixes a bug that showed organization admins their own email address instead of the user requesting affiliation. #1234 Transition from lgtm.com before the service ends Migrate to a new CI service. #1168 Ops: Throttle strings with \"Response size\" should be renamed \"Repeated request\" Improve the quality of error messages related to usage throttling. #953 User may request affiliation with a deleted organisation Fixes a bug that allowed users to request affiliation with a deleted organization. #659 Improve readability when users have special permissions Makes a support screen easier to read. #924 Allow change of ixpfx Improves automation for updating records associated with IXP peering LANs. #1270 Enable Google Analytics for beta.peeringdb.com Introduces Google Analytics for beta.peeringdb.com. More details . #1224 Internal admins only: console 504 time-out bug for ix history Fixes a timeout error affecting PeeringDB Admins. #1283 Footer \"Global System Statistics\" should be cached within django instance, not updated with every page load Introduces cacheing for the Global System Statistics data on each page.","title":"Release 2.42.0"},{"location":"release_notes/release_notes_2022/#release-2411","text":"Release Date: 26 October 2022 GitHub issue Summary #1275 Missing allowed sources for scripts Adds in some missing sources that were stopping /apidocs and CAPTCHA from working.","title":"Release 2.41.1"},{"location":"release_notes/release_notes_2022/#release-2410","text":"Beta Announcement Date: 12 October 2022 Release Date: 26 October 2022 GitHub issue Summary #586 Add export tool to https://peeringdb.com/cp/peeringdb_server/$type Adds new data exports on CSV format. #1044 Adding a POC must require an email address or phone number Points of Contact must now have either an email address or a phone number. #1244 IX-F importer fails on nulled ipv4 / ipv6 properties in vlan_list entries Fixes a bug where the IX-F importer would raise an error when encountering null values for ipv6 or ipv4 properties in the vlan_list property . #1216 RIR Status update misses ASNs Fixes a bug in the way RIR status is recorded for networks. #1223 Invalid data (in choice fields) found via API Fixes a bug where some records had invalid values. #1198 Add automated testing at the browser level Introduces automated testing for web functionality. #1149 HTTP 404 for dom-purify/purify.min.js.map and showdown/showdown.min.js.map Fixes a JS problem affecting several popular browsers. #1234 Transition from lgtm.com before the service ends Ensures continuity of continuous security analysis now after lgtm.com closes.","title":"Release 2.41.0"},{"location":"release_notes/release_notes_2022/#release-2400","text":"Beta Announcement Date: 14 September 2022 Release Date: 21 September 2022 GitHub issue Summary #736 Periodic validation of user's contact information Organizations can now require affiliated users to revalidate their accounts after a number of days chosen by the organization. #737 Restrict email domains for organizations Organizations can now require users to have an email address using a specific domain to affiliate with the organization. #484 Show username and email address when user is logged in User will now see their username and email address when logged in to the website. #738 Allow multiple email addresses per user User can have multiple email addresses associated with an account. #907 User email address change should notify previous email Users will now be notified at the old address when replacing their email address. #947 Make it possible to display the TOTP secret in text form instead of QR code only When setting up TOTP MFA, users can now see the secret as well as a QR code. #267 remove users with duplicate emails The user database has been cleaned so that only one user account can have an email address. #380 DB clean-up of elderly ophaned user accounts Users are notified when their account is not associated with an organization for 60 days. The account is removed a month later if not associated with an organization. #1157 An account with admin status can not have permissions When users gain admin status for an organization they now lose all granular permissions as they have all permissions. #468 Have the \"Select language\" drop down sorted Translation language names are now sorted alphabetically in English with the translated version of the language name presented alongside. #1202 Add Support for Enums against Locale Field Validates that languages are supported by translations. #1203 Validate Local Field against set of Enums Improves error handling when users set invalid languages. #499 Trigger IX-F import when network sets allow_ixp_update to \"yes\" An IX-F import is now triggered when a network sets allow_ixp_update to yes. #1213 robots.txt needed, at a minimum to limit bots from creating Django sessions Added robots.txt files to stop search engines indexing pages that shouldn't be indexed. #1210 UX Bugs Fixes several bugs introduced with the big UX dependency updates rolled out with 2.38. #959 ASNAUTO tool broken Fixes an issue with the ASNAuto tool sending out incorrect manual approval requests. #981 Error-handling of failed creation of DeskPRO tickets Fixes a problem with the creation of support tickets. #1150 Ops: Log Melissa payload in django.log Fixes a logging issue for the Ops team. #1228 Change \"Resul length\" to \"Result length\" Fixes a typo. This release also introduced a change for updates made with the API. These operations must now be authenticated with an API Key. Our HOWTO document explains how to get started using API Keys.","title":"Release 2.40.0"},{"location":"release_notes/release_notes_2022/#release-2390","text":"Beta Announcement Date: 20 July 2022 Release Date: 27 July 2022 GitHub issue Summary #473 add rir_* fields to keep track of ASN status Improve data quality by adding fields that will allow us to perform statical analysis and remove ASNs when no longer assigned. #1203 Validate Local Field against set of Enums Improvements to error handling should a user mischievously send junk data. #1205 Ops: Limit Django sessions to pages that need it Django sessions are now limited to pages that need it. #941 Organization Merging Tool only offers the first 10 matches Improve the organization merge tool for admins. #1043 AC Change User Permission broken Fixes a bug that did not remove users from an organization when it was deleted. #1157 An account with admin status can not have permissions Fixes a bug that did not remove granular permissions for an organization when a users was upgraded to an admin. #1135 #727 RS Peer Checkbox followup changes Cosmetic changes to the RS Peer Checkbox.","title":"Release 2.39.0"},{"location":"release_notes/release_notes_2022/#release-2382","text":"Release Date: 24 June 2022 GitHub issue Summary #1194 Advanced search issues Fixes a bug that stopped advanced search from delivering results. #1195 UI: active tabs no longer highlighted after switching Fixes a bug that stopped the current tab being highlighted in active search after changing tab.","title":"Release 2.38.2"},{"location":"release_notes/release_notes_2022/#release-2380","text":"Beta Announcement Date: 15 June 2022 Release Date: 22 June 2022 GitHub issue Summary #930 Admin user is missing the \"Edit\" button Fixes a bug that prevented users from editing their entries. #963 Add the IX name and id to IX-F Import Emails Addresses messages to exchange operators more clearly. #879 Add \"Last login\" to https://peeringdb.com/cp/peeringdb_server/user/ Let's the Admin Committee know who from an organization most recently logged in. #1057 Force users to provide input for first / last names when registering with PeeringDB Use the username instead of formal name in tickets when it's not registered. #660 Bug in renumbering tool Fixes a bug with the renubering tool. #1172 Ops: Exempt superusers (PeeringDB Admin Committee & Operations Committee admins) from throttling API and Melissa request throttling is no longer applied to authenticated admin users. #1177 Locale field update has uncaught exception Fixes a bug where a logged in user could send data that generated DataError and Internal Server Error. Exceptions are now caught appropriately and return relevant errors to users. #1174 Insecure Dependencies Upgrades three dependencies to newer versions that address known vulnerabilities. #1186 Browser caches OAuth2 application client secrets Fixes a bug that allowed browsers to cache the OAuth2 application details page. #1184 Tie CSRF token to session Fixes a bug by binding the session ID and the CSRF token together to reduce the risk that an old token is misused.","title":"Release 2.38.0"},{"location":"release_notes/release_notes_2022/#release-2370","text":"Beta Announcement Date: 11 May 2022 Release Date: 17 May 2022 GitHub issue Summary #403 Notify a record holder when there is an automated change to the profile Notifications are now sent when PeeringDB administrators make changes to records. #1155 Feature Request: Promote OAuth application to admin-level access? Adds organization level OAuth app management and allows organizations to transfer existing OAuth apps tied to their users to the organization. #942 Failure on Admin Organization Merge Fixes a big that prevented PeeringDB Admins from merging organizations. #960 Change any \"Primary ASN\" to \"ASN\" Replaces the phrase \"Primary ASN\" with \"ASN\" everywhere as the Primary ASN concept does not exist in PeeringDB 2.0. #986 Add link to release notes to the footer of www.peeringdb.com Release notes are now linked from the footer, making them easier for all users to find.","title":"Release 2.37.0"},{"location":"release_notes/release_notes_2022/#release-2360","text":"Beta Announcement Date: 13 April 2022 Release Date: 11 May 2022 GitHub issue Summary peeringdb-py #62 Support User & Org API keys Adds API keys support for the peeringdb-py cacheing client. #1079 Normalize the names of states & provinces for various objects Normalizes names for states and provinces, improving search experience. #784 Do not show objects in status \"pending\" on the UI Objects that do not have an OK status are no longer returned in search results. #996 500 Error during login for 2FA enabled accounts with unverified email address Fixes a bug that generated a 500 error when logging in with an account whose e-mail address had not been verified. #845 Need consolidated app logs Improvements to logging. #1119 Some command-line-tool executions are not logged Improves logging so AC tools can undo actions. #1120 Ops: response header X-Auth-ID to augment logging Logs the user for requested authenticated by API keys allowing them to be contacted. #1121 Ops: API throttling needs customizable messages API requests can now be throttled with custom return code (HTTP 429). #1122 Logging for melissa (geo-address normalization) queries Adds support for logging geosearch queries to the external API. #1124 Allow rate-limiting of melissa enabled api functionality. Adds support for rate-limiting the geosearch features that rely on an external API. #1126 Ops: API throttling of repeated requests Adds support for throttling repeated requests. #1096 Clicking on Facility history in AC GUI throws 500 Fixes a bug that hid fac history. #1035 Django-Admin: adding a network with existing asn fails with internal error Fixes a bug that returned a 500 error when a user attempted to add a net with the same ASN as an existing object. It now returns a more helpful validation error.","title":"Release 2.36.0"},{"location":"release_notes/release_notes_2022/#release-2350","text":"Beta Announcement Date: 8 March 2022 Release Date: 22 March 2022 GitHub issue Summary #506 Add \"Management\" search field to Advanced Search of Exchanges Allows users to search for IXPs based on the organization that operates the IXP. #727 RS Peer Checkbox also visible on IX Site Information about networks claiming to peer with the Route Server is now shown on the IXP's page. #512 New Field \"Health Check\" Networks, IXPs, and Facilities can now link to a status dashboard page. #653 missing delete button for user There is now a button to delete a user account directly through the web interface. #656 Sort user IDs in https://www.peeringdb.com/cp/peeringdb_server/userpermission/xxxxx numerically Fixes the sorting order of user IDs, so they are now sorted in numerical order. #881 wrap correctly on mobile The ASN column on mobile view will show seven digits before wrapping the number. #908 2FA Backup Tokens language doesn't seem correct Fixes the backup tokens language for 2FA. #916 To force or not to force www, that is a question Forces https://www.peeringdb.com as the URL for PeeringDB, enabling other improvements. Some clients will need to adjust their endpoints to use www.peeringdb.com. curl users will want to use the -L flag. #1042 Long caching of deleted entries Fixes a problem where deleted objects continued to be returned because of cacheing. #1117 Bad API keys need to return 401 just like a bad user/pass. Presently they return 200 Fixes a problem where corrupt or expired or bogus API key simply resulted in an anonymous user session.","title":"Release 2.35.0"},{"location":"release_notes/release_notes_2022/#release-2340","text":"Beta Announcement Date: 9 February 2022 Release Date: 16 February 2022 GitHub issue Summary #722 Create a validation tool for syntactically well defined fields Introduces a tool to improve data quality by validating syntactically well defined fields. #853 substantially rate limit unauthenticated /api/ queries to encourage authenticated queries Introduces rate limiting for unauthenticated API queries to reduce the possibility of service impacting queries. #620 Add organisations and registered users to \"Global System Statistics\" in footer Adds the number of registered users to the footer, giving users a better idea of the size of the interconnection community.","title":"Release 2.34.0"},{"location":"release_notes/release_notes_2022/#release-2330","text":"Beta Announcement Date: 12 January 2022 Release Date: 19 January 2022 GitHub issue Summary #1083 Nanog 83 Hackathon improvements to the PeeringDB Website When using simple search on the front page of www.peeringdb.com (or via the API) searches for numbers return the most relevant results. Key changes include: searching for a short ASN returns just that network, and searches for two segments of an IP address are required to return related ix and net objects. #1070 OpenID Connect integration Allows organizations using PeeringDB to enable an identity federation with a managed service. #692 Add FIDO U2F 2FA support Adds support for FIDO U2F hardware tokens, allowing users to enable 2FA without relying on a TOTP app. #1033 Clicking \"Add\" to add a user api-key without providing a name for the key raises Internal Error Fixes a bug where unnamed user api-keys could not be added and there was just an internal error. #374 make URL required for new objects A URL to a website is now required when adding new objects. #469 Add IXP to AS record / dropdown limited Fixes a bug that limited the number of entries in the dropdown menu when adding an ix to a net . #284 global stats don't show up at login screen Global stats are now shown at the login web page. #874 Better error message when entering the wrong password for email change Improved the error message when entering the wrong password for an e-mail change. #365 Username retrieval non-existant email bug Fixes a bug where we attempted to send mail to non-existant addresses. #735 Cascade delete when performed by superuser Admin users can now cascade delete through the admin interface. #901 Creating a facility that matches the name of a soft-deleted facility will cause the entry to bypass the verification queue Fixes a bug where fac creation could bypass the validation process. #921 irr source validator doesn't allow for hyphens in source IRRs with a hyphen in the name, like ARIN-NONAUTH, are now supported. #1060 \"HARAKIRI ON WORKER\" issues need to be resolved Fixes an operational issue. #1062 Registering a new facility or exchange organization is broken Fixes a bug that prevented new fac and ix objects to be registered. #1077 Possible for \"pending\" exchange to have \"deleted\" ixlan Fixes a bug that allowed linked ix objects to jhave a different status, affecting API sync. #1088 Tweaks for empty organization clean up Fixes a bug that allowed sponsor organizations to be deleted by an automatic process when they should not be.","title":"Release 2.33.0"},{"location":"release_notes/release_notes_2023/","text":"2023 Release Notes The release notes list the GitHub issues and a summary of what has changed in PeeringDB software releases. Each new release has a one week beta test period on the beta server before it goes live. The beta and new releases are announced on the PeeringDB Announce Mailing List and on Facebook , LinkedIn and X . Release 2.53.0 Beta Announcement Date: 29 November 2023 Release Date: 6 December 2023 GitHub issue Summary #1362 Show connected networks, exchanges, and carriers on campus results pages Adds an aggregated view of interconnection resources at a campus on the campus page. #1247 Store language preference in the user's profile instead of cookies Improved handling of website language preferences. #1327 Improve visibility of contact data settings Admins now see the visibility settings for their contacts alongside the set values. This makes it easier to identify and correct mistakes. #1385 Keep the list of IRR up to date As title. #1432 Make dates ISO 8601 compliant everywhere in PeeringDB As title. #1252 Display dates consistently As title. #1433 Timestamps should be consistent As title. Release 2.52.0 Beta Announcement Date: 25 October 2023 Release Date: 6 November 2023 GitHub issue Summary #1328 Support web updates from a source of truth Internal sources of truth, like configuration management systems, can now propose PeeringDB updates that a web user can review and either accept or deny. #1374 Search to include new objects: Campus & Carrier Support for new carrier and campus objects in v2 search, which is now the default with v1 search linked for the time being. #1368 Facility data export into Google Earth KMZ PeeringDB facility data is now exported into a Google Earth KMZ file that includes the details of the facility fields and their contents ( ix , net , carrier ). It is linked from the web footer and generated every day. #1394 v2 search failing to find some names Fixes a bug where names with hyphens in them were not handled properly by v2 search. #1313 Improve email confirmation control - add 3 month option & maybe set new default value Improve the design of the periodic reconfirmation control for user email addresses and add a new 3 month value. #1257 Help text covers non-compliant email addresses Non-compliant email addresses of affiliated users are now shown, making it easier to know who to contact. #1164 better rdap error reporting Improved error handling and friendlier error reporting to users. #1260 Add Selenium Grid to CI testing Improve automated browser testing for website. #1380 Reset 'Social Media' to '{}' if field is null Fixes a bug with broken page rendering for backend admin users when a social media field was set to null . Release 2.51.0 Beta Announcement Date: 13 September 2023 Release Date: 20 September 2023 GitHub issue Summary #1364 IX Object Creation Per Policy Automates approval of new ix objects per policy . #1226 Add a \"Delete Affiliation\" button/option to the profile Users can now remove an affiliation from their account. #1431 add redis for caching Improves cacheing performance. #1382 Syntax checker for social media user names broken Fixes a bug that rejected social media names that incorporated a hyphen. #1401 Creating a new network not possible Fixes a bug that stopped net creation when social media fields were sent with request. #1419 replace missing Glyphicons Use Google's \"Sort by Alpha\" icon in table headers. #1182 Manual IX-F import request queue can get stuck Fixes a bug that allowed users to enable IX-F imports without setting a URL. The importers also discards imports without a URL. #1334 IX-F Importer: Cosmetic issue with \"resolved\" emails and double-slashes in URLs after the FQDN Fixes a cosmetic issue with IX-F notification messages. Release 2.50.0 Beta Announcement Date: 16 August 2023 Release Date: 23 August 2023 GitHub issue Summary #1352 Include carrier and campus objects in the API carrier and campus objects were not included in the main API at first as we did not know if users would use them. They are now part of the API, making them usable by tools that rely on the API. #1300 display website URL on all non-org objects The website from org objects is now inherited by all child objects. #1381 Add hover tip to describe meaning of routeserver icon As title. #1361 Add Campus and Carrier Tooltips As title. #1360 IX-F Importer: IX-F Member Data not being nullified after IX stops/changes import Fixes a bug where the IX and participants were being mailed about import issues after the import was turned of by the IX operator. #1239 Add a search field to all AC views Better search for support tools. #1027 Make the search field on cp/peeringdb_server/network/ aware of leading AS/ASN Improved handling of variant syntax in support tools. #1412 Improve performance by updating Python client code Replace old python2 sync code with python3 code. Release 2.49.0 Beta Announcement Date: 12 July 2023 Release Date: 19 July 2023 GitHub issue Summary #1344 Auto approval of new carrierfac objects carrierfac objects are now approved automatically, like netfac objects . #1299 Alphabetize simple search results Exact match search now go at the top, with other results displayed alphabetically. #997 Allow organizations to require affiliated users to enable 2FA Organizations can now require their users to turn on MFA. #1370 Facility Geocode not working Fixed a bug that meant some fac s did not have a geocode. #1225 Evaluate ways to reduce operational costs Operational work to support deployment directly on cloud provider infrastructure, instead of in a VM. #1219 Optimize Cacheing It is now easier to obtain and cache PeeringDB data. #1404 Upgrade the django-oauth-toolkit library Django update deferred from last month. Oauth application owners were given notice of this breaking change. Release 2.48.0 Beta Announcement Date: 21 June 2023 Release Date: 28 June 2023 GitHub issue Summary #1311 Update Dependencies Update all dependencies to new major releases. This year includes Django 4.2 LTS. Release 2.47.0 Beta Announcement Date: 17 May 2023 Release Date: 24 May 2023 GitHub issue Summary #1204 Improve Search Functionality Significant improvements to search via a new backend. #1290 Add permission 'manage peering sessions' Adds a permission for managing peering sessions, that is useful for portal enabling PeeringDB OAuth. #1241 Don't allow the first and last addresses being assigned Added a validation check to fail on network and broadcast addresses. #1238 Put an Icon next to user name on https://www.peeringdb.com/org/nnnn#users if the user is using U2F Added a U2F badge next to user name in organization user listing if the user has set up U2F 2FA #1339 Tie TOTP devices and Webauthn Security Keys to the user account Tie TOTP devices and Webauthn Security Keys to the user account so the AC can see this information. #1291 Show all e-mail addresses associated with a username All e-mail addresses associated with a user are now shown in the users tab. #1372 Facility history still broken Fixes an issue with fac history for AC use. Release 2.46.0 Beta Announcement Date: 12 April 2023 Release Date: 19 April 2023 GitHub issue Summary #1336 Clearly show when a facility is part of a campus Adds a small icon to show that a fac is a part of a campus . #387 Replace \"website\" element in API/UI with social media tags Introduces the ability to include links to social media accounts from PeeringDB pages. #1333 Calling /api/carrier with parameters is broken Fixes a bug in the API support for the new carrier object. #1094 IX-F Importer: duplicate address(es) should result in rejection of JSON export and notification of IXP Fixes a bug in handling duplicate IP addresses in IX-F imports. #1249 Update MkDocs for docs.peeringdb.com Updates the software used by https://docs.peeringdb.com Release 2.45.0 Beta Announcement Date: 15 March 2023 Release Date: 22 March 2023 GitHub issue Summary #1295 Allow anonymous users to change languages It is now possible to select a PeeringDB translation without logging in to the website. #1281 better <title> tags The HTML <title> tag of pages on www.peeringdb.com now shows key information from the page, like a network name or search term. #749 Rename Private Peering Facilities to Interconnection Facilities in the UI Private Peering Facilities have been renamed to Interconnection Facilities in the UI. #1308 Deploy Google Analytics on www and docs We have deployed Google Analytics to measure website traffic. #1271 Implement auto-removal of stale networks according to DOTF recommendations Stay networks are now automatically removed as per the DOTF recommendations . #389 It should be impossible to save an active entity under an entity that is marked as deleted. It is no longer possible to save an object under one that's marked as deleted. Release 2.44.0 Beta Announcement Date: 15 February 2023 Release Date: 22 February 2023 GitHub issue Summary #1110 Add campus object Initial deployment of a Campus object \u2013 a record to describe facilities where inter-facility cross connects are available as easily as intra-facility cross connects. #1191 OAuth logins with 2FA don't complete first time Fixes a bug that broke the OAuth flow when MFA was enabled. #668 Add \"self\" as an object identifier, for documentation purposes Adds a \"self\" object identifier to API and views for GET requests. Authenticated users going to https://www.peeringdb.com/{net Release 2.43.1 Release Date: 10 February 2023 GitHub issue Summary #1315 issues when accepting / denying carrier presence requests Fix permission issues when accepting or rejecting carrier facility presence requests and automatically approve them when they are from the same organization. Release 2.43.0 Beta Announcement Date: 18 January 2023 Release Date: 25 January 2023 GitHub issue Summary #909 Add Carrier Record Type Initial deployment of a Carrier record \u2013 a record to describe providers of high capacity links between facilities, running at layers 1 or 2 . #1140 API keys: disabling of user account by a PeeringDB admin does not disable access via a User API key. Also no disable mech, only revoke. Fixes a bug where user API Keys were not disabled when their account was disabled. #1220 API requests with invalid Authentication headers should notify users in some way Requests with an invalid API key now return appropriate error codes. #1130 Allow user to change account username Users can now change their account name. #970 Cache hints are needed for optimal CDN use Adds cache hints to make CDN deployment more effective. #1278 Commandline tool \"Run command\" button gone Fixes a problem affecting Admins \u2013 a tool was hidden. #1279 RIR status gets deleted when changes are made to the network Improves the new process for validating networks against RIR data (see: #1280 ). #658 Improve MTU field MTUs now default to 1500 and there's a new dropdown list of options to select from. #1282 Ops: Emails to OPERATIONS_EMAIL need to be rate-limited Introduces a rate limit for automatic mail sent to Operations. #1283 Footer \"Global System Statistics\" should be cached within django instance, not updated with every page load Global System Statistics are now generated periodically instead of on each page load. #1284 Ops: django needs lightweight healthcheck route that confirms database connectivity Introduces a lightweight health check for database availability. #1285 Ops: various indexes are needed Introduces new database indexes. #1288 Ops: Expose CSP_CONNECT_SRC to .env Add configuration options for ease of operations. #1296 CSRF cookie not set error from email confirmation view Fix a bug with CSRF cookies not being set. Older releases 2022 Release Notes 2021 Release Notes 2020 Release Notes","title":"2023 Release Notes"},{"location":"release_notes/release_notes_2023/#2023-release-notes","text":"The release notes list the GitHub issues and a summary of what has changed in PeeringDB software releases. Each new release has a one week beta test period on the beta server before it goes live. The beta and new releases are announced on the PeeringDB Announce Mailing List and on Facebook , LinkedIn and X .","title":"2023 Release Notes"},{"location":"release_notes/release_notes_2023/#release-2530","text":"Beta Announcement Date: 29 November 2023 Release Date: 6 December 2023 GitHub issue Summary #1362 Show connected networks, exchanges, and carriers on campus results pages Adds an aggregated view of interconnection resources at a campus on the campus page. #1247 Store language preference in the user's profile instead of cookies Improved handling of website language preferences. #1327 Improve visibility of contact data settings Admins now see the visibility settings for their contacts alongside the set values. This makes it easier to identify and correct mistakes. #1385 Keep the list of IRR up to date As title. #1432 Make dates ISO 8601 compliant everywhere in PeeringDB As title. #1252 Display dates consistently As title. #1433 Timestamps should be consistent As title.","title":"Release 2.53.0"},{"location":"release_notes/release_notes_2023/#release-2520","text":"Beta Announcement Date: 25 October 2023 Release Date: 6 November 2023 GitHub issue Summary #1328 Support web updates from a source of truth Internal sources of truth, like configuration management systems, can now propose PeeringDB updates that a web user can review and either accept or deny. #1374 Search to include new objects: Campus & Carrier Support for new carrier and campus objects in v2 search, which is now the default with v1 search linked for the time being. #1368 Facility data export into Google Earth KMZ PeeringDB facility data is now exported into a Google Earth KMZ file that includes the details of the facility fields and their contents ( ix , net , carrier ). It is linked from the web footer and generated every day. #1394 v2 search failing to find some names Fixes a bug where names with hyphens in them were not handled properly by v2 search. #1313 Improve email confirmation control - add 3 month option & maybe set new default value Improve the design of the periodic reconfirmation control for user email addresses and add a new 3 month value. #1257 Help text covers non-compliant email addresses Non-compliant email addresses of affiliated users are now shown, making it easier to know who to contact. #1164 better rdap error reporting Improved error handling and friendlier error reporting to users. #1260 Add Selenium Grid to CI testing Improve automated browser testing for website. #1380 Reset 'Social Media' to '{}' if field is null Fixes a bug with broken page rendering for backend admin users when a social media field was set to null .","title":"Release 2.52.0"},{"location":"release_notes/release_notes_2023/#release-2510","text":"Beta Announcement Date: 13 September 2023 Release Date: 20 September 2023 GitHub issue Summary #1364 IX Object Creation Per Policy Automates approval of new ix objects per policy . #1226 Add a \"Delete Affiliation\" button/option to the profile Users can now remove an affiliation from their account. #1431 add redis for caching Improves cacheing performance. #1382 Syntax checker for social media user names broken Fixes a bug that rejected social media names that incorporated a hyphen. #1401 Creating a new network not possible Fixes a bug that stopped net creation when social media fields were sent with request. #1419 replace missing Glyphicons Use Google's \"Sort by Alpha\" icon in table headers. #1182 Manual IX-F import request queue can get stuck Fixes a bug that allowed users to enable IX-F imports without setting a URL. The importers also discards imports without a URL. #1334 IX-F Importer: Cosmetic issue with \"resolved\" emails and double-slashes in URLs after the FQDN Fixes a cosmetic issue with IX-F notification messages.","title":"Release 2.51.0"},{"location":"release_notes/release_notes_2023/#release-2500","text":"Beta Announcement Date: 16 August 2023 Release Date: 23 August 2023 GitHub issue Summary #1352 Include carrier and campus objects in the API carrier and campus objects were not included in the main API at first as we did not know if users would use them. They are now part of the API, making them usable by tools that rely on the API. #1300 display website URL on all non-org objects The website from org objects is now inherited by all child objects. #1381 Add hover tip to describe meaning of routeserver icon As title. #1361 Add Campus and Carrier Tooltips As title. #1360 IX-F Importer: IX-F Member Data not being nullified after IX stops/changes import Fixes a bug where the IX and participants were being mailed about import issues after the import was turned of by the IX operator. #1239 Add a search field to all AC views Better search for support tools. #1027 Make the search field on cp/peeringdb_server/network/ aware of leading AS/ASN Improved handling of variant syntax in support tools. #1412 Improve performance by updating Python client code Replace old python2 sync code with python3 code.","title":"Release 2.50.0"},{"location":"release_notes/release_notes_2023/#release-2490","text":"Beta Announcement Date: 12 July 2023 Release Date: 19 July 2023 GitHub issue Summary #1344 Auto approval of new carrierfac objects carrierfac objects are now approved automatically, like netfac objects . #1299 Alphabetize simple search results Exact match search now go at the top, with other results displayed alphabetically. #997 Allow organizations to require affiliated users to enable 2FA Organizations can now require their users to turn on MFA. #1370 Facility Geocode not working Fixed a bug that meant some fac s did not have a geocode. #1225 Evaluate ways to reduce operational costs Operational work to support deployment directly on cloud provider infrastructure, instead of in a VM. #1219 Optimize Cacheing It is now easier to obtain and cache PeeringDB data. #1404 Upgrade the django-oauth-toolkit library Django update deferred from last month. Oauth application owners were given notice of this breaking change.","title":"Release 2.49.0"},{"location":"release_notes/release_notes_2023/#release-2480","text":"Beta Announcement Date: 21 June 2023 Release Date: 28 June 2023 GitHub issue Summary #1311 Update Dependencies Update all dependencies to new major releases. This year includes Django 4.2 LTS.","title":"Release 2.48.0"},{"location":"release_notes/release_notes_2023/#release-2470","text":"Beta Announcement Date: 17 May 2023 Release Date: 24 May 2023 GitHub issue Summary #1204 Improve Search Functionality Significant improvements to search via a new backend. #1290 Add permission 'manage peering sessions' Adds a permission for managing peering sessions, that is useful for portal enabling PeeringDB OAuth. #1241 Don't allow the first and last addresses being assigned Added a validation check to fail on network and broadcast addresses. #1238 Put an Icon next to user name on https://www.peeringdb.com/org/nnnn#users if the user is using U2F Added a U2F badge next to user name in organization user listing if the user has set up U2F 2FA #1339 Tie TOTP devices and Webauthn Security Keys to the user account Tie TOTP devices and Webauthn Security Keys to the user account so the AC can see this information. #1291 Show all e-mail addresses associated with a username All e-mail addresses associated with a user are now shown in the users tab. #1372 Facility history still broken Fixes an issue with fac history for AC use.","title":"Release 2.47.0"},{"location":"release_notes/release_notes_2023/#release-2460","text":"Beta Announcement Date: 12 April 2023 Release Date: 19 April 2023 GitHub issue Summary #1336 Clearly show when a facility is part of a campus Adds a small icon to show that a fac is a part of a campus . #387 Replace \"website\" element in API/UI with social media tags Introduces the ability to include links to social media accounts from PeeringDB pages. #1333 Calling /api/carrier with parameters is broken Fixes a bug in the API support for the new carrier object. #1094 IX-F Importer: duplicate address(es) should result in rejection of JSON export and notification of IXP Fixes a bug in handling duplicate IP addresses in IX-F imports. #1249 Update MkDocs for docs.peeringdb.com Updates the software used by https://docs.peeringdb.com","title":"Release 2.46.0"},{"location":"release_notes/release_notes_2023/#release-2450","text":"Beta Announcement Date: 15 March 2023 Release Date: 22 March 2023 GitHub issue Summary #1295 Allow anonymous users to change languages It is now possible to select a PeeringDB translation without logging in to the website. #1281 better <title> tags The HTML <title> tag of pages on www.peeringdb.com now shows key information from the page, like a network name or search term. #749 Rename Private Peering Facilities to Interconnection Facilities in the UI Private Peering Facilities have been renamed to Interconnection Facilities in the UI. #1308 Deploy Google Analytics on www and docs We have deployed Google Analytics to measure website traffic. #1271 Implement auto-removal of stale networks according to DOTF recommendations Stay networks are now automatically removed as per the DOTF recommendations . #389 It should be impossible to save an active entity under an entity that is marked as deleted. It is no longer possible to save an object under one that's marked as deleted.","title":"Release 2.45.0"},{"location":"release_notes/release_notes_2023/#release-2440","text":"Beta Announcement Date: 15 February 2023 Release Date: 22 February 2023 GitHub issue Summary #1110 Add campus object Initial deployment of a Campus object \u2013 a record to describe facilities where inter-facility cross connects are available as easily as intra-facility cross connects. #1191 OAuth logins with 2FA don't complete first time Fixes a bug that broke the OAuth flow when MFA was enabled. #668 Add \"self\" as an object identifier, for documentation purposes Adds a \"self\" object identifier to API and views for GET requests. Authenticated users going to https://www.peeringdb.com/{net","title":"Release 2.44.0"},{"location":"release_notes/release_notes_2023/#release-2431","text":"Release Date: 10 February 2023 GitHub issue Summary #1315 issues when accepting / denying carrier presence requests Fix permission issues when accepting or rejecting carrier facility presence requests and automatically approve them when they are from the same organization.","title":"Release 2.43.1"},{"location":"release_notes/release_notes_2023/#release-2430","text":"Beta Announcement Date: 18 January 2023 Release Date: 25 January 2023 GitHub issue Summary #909 Add Carrier Record Type Initial deployment of a Carrier record \u2013 a record to describe providers of high capacity links between facilities, running at layers 1 or 2 . #1140 API keys: disabling of user account by a PeeringDB admin does not disable access via a User API key. Also no disable mech, only revoke. Fixes a bug where user API Keys were not disabled when their account was disabled. #1220 API requests with invalid Authentication headers should notify users in some way Requests with an invalid API key now return appropriate error codes. #1130 Allow user to change account username Users can now change their account name. #970 Cache hints are needed for optimal CDN use Adds cache hints to make CDN deployment more effective. #1278 Commandline tool \"Run command\" button gone Fixes a problem affecting Admins \u2013 a tool was hidden. #1279 RIR status gets deleted when changes are made to the network Improves the new process for validating networks against RIR data (see: #1280 ). #658 Improve MTU field MTUs now default to 1500 and there's a new dropdown list of options to select from. #1282 Ops: Emails to OPERATIONS_EMAIL need to be rate-limited Introduces a rate limit for automatic mail sent to Operations. #1283 Footer \"Global System Statistics\" should be cached within django instance, not updated with every page load Global System Statistics are now generated periodically instead of on each page load. #1284 Ops: django needs lightweight healthcheck route that confirms database connectivity Introduces a lightweight health check for database availability. #1285 Ops: various indexes are needed Introduces new database indexes. #1288 Ops: Expose CSP_CONNECT_SRC to .env Add configuration options for ease of operations. #1296 CSRF cookie not set error from email confirmation view Fix a bug with CSRF cookies not being set.","title":"Release 2.43.0"},{"location":"release_notes/release_notes_2023/#older-releases","text":"2022 Release Notes 2021 Release Notes 2020 Release Notes","title":"Older releases"},{"location":"taskforce/dataownership/","text":"PeeringDB Data Ownership Task Force 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 (as in netixlan, ixfac, netfac, etc objects). A call for participation to the task Force was made on September 10th, 2019. Data Ownership Task Force discussions are archived and can be found at: https://lists.peeringdb.com/pipermail/dataownership-tf/ This webpage is where the work of Data Ownership Task Force will be documented, including meeting minutes, draft documents etc. as their work progresses. In April 2020, the Task Force completed its work and published the resulting PeeringDB Data Ownership Policy Document after few cycles of a Review Phase and a final Last Call over a draft document circulated on their mailing list. (Please see the mailing list archives linked above.) The resulting document can be found at: https://docs.peeringdb.com/gov/misc/2020-04-06_PeeringDB_Data_Ownership_Policy_Document_v1.0.pdf 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 publishing the Policy Document, the Task Force ended. Data ownership policy implementation presentation This video and presentation explains how PeeringDB handles IX-F import data, creating, changing or deleting netixlan objects and other changes from the implementation of the PeeringDB Data Ownership Policy. Members Darrell Budic Chris Caputo Patrick Gilmore Shane Kerr Fredrik Korsb\u00e4ck Jhonny Lima Ben Maddison Christopher Malayter William Marantz Jeri McNeill Arnold Nipper Barry O\u2019Donovan Mustafa Timur Sever Bijal Shangani Job Snijders Terry Sweetser Lukas Tribus Stefan Wahl Filiz Yilmaz (Chair)","title":"Data Ownership Task Force"},{"location":"taskforce/dataownership/#peeringdb-data-ownership-task-force","text":"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 (as in netixlan, ixfac, netfac, etc objects). A call for participation to the task Force was made on September 10th, 2019. Data Ownership Task Force discussions are archived and can be found at: https://lists.peeringdb.com/pipermail/dataownership-tf/ This webpage is where the work of Data Ownership Task Force will be documented, including meeting minutes, draft documents etc. as their work progresses. In April 2020, the Task Force completed its work and published the resulting PeeringDB Data Ownership Policy Document after few cycles of a Review Phase and a final Last Call over a draft document circulated on their mailing list. (Please see the mailing list archives linked above.) The resulting document can be found at: https://docs.peeringdb.com/gov/misc/2020-04-06_PeeringDB_Data_Ownership_Policy_Document_v1.0.pdf","title":"PeeringDB Data Ownership Task Force"},{"location":"taskforce/dataownership/#scope","text":"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 publishing the Policy Document, the Task Force ended.","title":"Scope"},{"location":"taskforce/dataownership/#data-ownership-policy-implementation-presentation","text":"This video and presentation explains how PeeringDB handles IX-F import data, creating, changing or deleting netixlan objects and other changes from the implementation of the PeeringDB Data Ownership Policy.","title":"Data ownership policy implementation presentation"},{"location":"taskforce/dataownership/#members","text":"Darrell Budic Chris Caputo Patrick Gilmore Shane Kerr Fredrik Korsb\u00e4ck Jhonny Lima Ben Maddison Christopher Malayter William Marantz Jeri McNeill Arnold Nipper Barry O\u2019Donovan Mustafa Timur Sever Bijal Shangani Job Snijders Terry Sweetser Lukas Tribus Stefan Wahl Filiz Yilmaz (Chair)","title":"Members"}]}
\ No newline at end of file
diff --git a/sitemap.xml b/sitemap.xml
index c4336c25..dbe8c4a0 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -2,492 +2,492 @@
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://docs.peeringdb.com/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/api_specs/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blogs/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/faq/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/glossary/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/gov/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/howtos/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/ix-f-json-import-rules/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/oauth/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/presentations/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/tools/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/translation/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/2022_product_report/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/2023_product_report/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/advanced_search_1/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/advanced_search_2/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/alphabetical_search/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/api_keys/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/api_writes_need_api_key/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/automating_configuration/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/better_data/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/better_search_and_export/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/carrier_object/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/carrier_object_deployed/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/contacts_marked_private/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/containerize/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/contributing_code/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/data_quality_improvements/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/data_quality_removing_closed_networks/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/faster_queries/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/geographic_search/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/guidelines_for_registering/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/improving_beta_and_kmz_export/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/installing_peeringdb-py/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/introducing_analytics/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/more_details_facilities/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/nanog_85_hackathon/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/nanog_87_hackathon_proof_of_concept/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/network_type_what_you_told_us/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/network_type_your_input_sought/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/new_permission_manage_peering_sessions/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/oauth_users/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/october_2024_retrospective/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/organizational_policy/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/peeringdb_2020_satisfaction_survey/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/peeringdb_2020_survey_2021_roadmap/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/peeringdb_2021_survey_2022_roadmap/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/peeringdb_2021_user_survey/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/peeringdb_2022_user_survey/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/peeringdb_2023_roadmap/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/peeringdb_in_your_preferred_language/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/peeringdb_is_developed_by_its_community/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/peeringdb_map_with_kmz/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/peeringdb_release_v2.23.0/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/peeringdb_release_v2.24.0/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/search_gets_better/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/structured_data_and_more/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/u2f_and_url/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/updates_from_an_internal_source_of_truth/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/updating_our_webUI/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/user_developed_tools/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/user_suggestions_improve_PeeringDB_usability/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/what_happened_to_our_web_ui/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/whois_to_close/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/blog/your_logo_goes_here/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/committee/common/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/committee/admin/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/committee/admin/approval-guidelines/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/committee/admin/charter/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/committee/outreach/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/committee/outreach/charter/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/committee/product/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/committee/product/charter/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/committee/product/workflow/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/howto/api_keys/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/howto/authenticate/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/howto/enable_require_2fa/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/howto/get-started-carrier/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/howto/get-started-developing/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/howto/get-started-exchange/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/howto/get-started-facility/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/howto/get-started-operator/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/howto/make-a-security-report/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/howto/manage-permissions/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/howto/member_vote/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/howto/organizational_policy/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/howto/peeringdb-py/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/howto/run_development_container/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/howto/search/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/howto/updates-for-as112/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/howto/v2_search/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/howto/work_within_peeringdbs_query_limits/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/release_notes/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/release_notes/release_notes_2020/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/release_notes/release_notes_2021/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/release_notes/release_notes_2022/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/release_notes/release_notes_2023/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
<url>
<loc>https://docs.peeringdb.com/taskforce/dataownership/</loc>
- <lastmod>2024-11-19</lastmod>
+ <lastmod>2024-11-20</lastmod>
<changefreq>daily</changefreq>
</url>
</urlset>
\ No newline at end of file
diff --git a/sitemap.xml.gz b/sitemap.xml.gz
index 81ef1781..87a39554 100644
Binary files a/sitemap.xml.gz and b/sitemap.xml.gz differ