OFDS 0.5: Call for inputs

[duncandewhurst]

We're kicking off the development of the next minor release of the Open Fibre Data Standard, OFDS 0.5, and we want your input on the issues and changes to prioritise for this version.

History

Established in 2022, OFDS was developed in collaboration with the World Bank, International Telecommunications Union, Mozilla Corporation, Liquid Intelligent Technologies, CSquared, and Digital Council Africa. Subsequently, an interim governance group and thematic working groups were established to guide work on the standard and supporting activities over the subsequent 12 months. In early 2026, a formal governance group was established with responsibility for vision, strategic direction and oversight of the standard and its tooling.

The current version, OFDS 0.4, was released in March 2026 and included updates to the data model, and the addition of GeoPackage as a supported data format. For more information on the changes in each version, refer to the changelog.

Version 0.5 development schedule

OFDS 0.5 will be developed according to the following schedule. Development will be carried out in the open using this GitHub repository, with community input especially needed for the activities marked in bold.

• Community input on proposals and issues: 15th June - 31st July 2026
• Prioritisation: 1st - 14th August 2026
• Community review of priorities: 15th - 31st August 2026
• Development (proposals, schema and docs updates): 1st September - 30th October 2026
• Peer review of draft release: 1st - 14th November 2026
• Final revisions and review: 15th - 30th November 2026
• Update tools and release: 1st - 15th December 2026

Issues and priorities

We will consider all existing open issues for inclusion in version 0.5, along with any new issues opened by 31st July 2026. We will prioritise issues according to community feedback and input from the governance group. The prioritised issues list will be shared with the community for review.

The major themes amongst the existing issues are listed below. We do not expect to address all of these areas in version 0.5, but we invite the community to share feedback on which issues are most pressing:

• Add support for FTTH/FTTX/metro/last-mile networks #352. This is expected to be a main focus for version 0.5. Please share your thoughts, and links to relevant resources, in the issue.
• Draft guidance: What data do I need to share? #354. This expected to be another main focus for version 0.5. A draft is available for review and comment in the GitHub issue.
• Alignment with other standards and data models:
  • Review ArcGIS Data Models #347
  • ITU Guidelines on establishing or strengthening national broadband mapping systems:
    • Review list of technologies for mediums #309
    • Source of funding categorisation #307
    • Number and capacity of interfaces #306
    • Layer (tier) of a node, and destination of a span #305
  • Review ITU-T Recommendation L.72 (01/08) for relevance to modelling infrastructure layers #324
  • Support the upcoming OGC Features and Geometries Standard #290
• Potential additions to the data model:
  • Capturing adherence to quality standards in network build-out #308
  • Modelling poles and manholes (service points) #300
  • Consider allowing accuracy verification processes to be described #200
  • Node/link elevation and deployment depth #11
• Various fixes and improvements to normative documentation, i.e. the reference section, which describes the rules to which OFDS implementations must conform.
• Various additions and improvements to non-normative documentation, i.e. the guidance section, and other documentation outside the reference section. Since these issues relate to non-normative content, they can be addressed either within or without the standard's release cycle.

How to contribute

We want to hear about which issues you want to prioritise for inclusion in version 0.5 by 31st July 2026. You can share your feedback by commenting on an existing issue, opening a new issue, or replying to this discussion.

To keep up to date with the development of OFDS 0.5 and on opportunities to contribute to it, you can receive email notifications by watching this repository.

To watch, comment on, or create discussions and issues, you need to sign up for a free GitHub account. If you prefer to provide feedback via email, you can email outreach@ofds.info. Your comments will be added to the appropriate issue or discussion.

[stevesong]

A data element that the Colombian regulator captures is the topology type of which a span is a part. We might consider this for inclusion as it has implications for resilience. #356

[amreesh]

A key concern for operators is data privacy and sensitivity regarding their infrastructure assets. To encourage broader adoption, operators need a standardized way to specify visibility permissions directly within the dataset. I propose introducing an explicit field or flag at the object/element level (e.g., public_access or access_level) with values such as yes | no (or public | restricted | private).

This would give operators granular control over which specific nodes, spans, or attributes can be published publicly versus those restricted to regulatory or internal mapping use cases. When opensourcing the data, the GIS tool can identify those privacy tags and obsfuscate some information as specified.

[duncandewhurst]

Hi @amreesh, thanks for raising this.

Data privacy and security are indeed key concerns for operators, and similar concerns around confidentiality come up in the context of many different data standards. This is certainly something that needs to be addressed by the standard and its documentation.

Typically, such concerns are more often addressed at the platform/system level, than by adding an explicit visibility field to the data model and schemas, which are concerned with providing a standardised format for data that is shared or published. For example, an API might provide 'tiered' access to authenticated users with different permission levels, with field visibility defined either in the underlying database or as part of the API logic.

There are a few practical challenges to adding a field or flag to specify visibility permissions in the standard's data model:

• In a scenario where operators share data with a regulator, and the regulator publishes a consolidated dataset, operators and the regulator might have differing visibility settings - what's 'shared' for an operator, might be 'internal' for the regulator.
• Permissions might differ by attribute or by feature (node/span).
• Permissions might relate to the precision of location data for different audiences.

Presently, we have some fairly brief guidance on how to decide what data to publish, which links out to guidance on obfuscating location data. We are planning to supplement this with additional guidance on the core data elements that should be included in all OFDS datasets, and groups of data elements needed for key use cases (see #354).

Given the frequency at which these concerns come up in conversations with potential adopters, I think it would make sense to add some content to the Primer to explain OFDS's role in relation to determining what data to share/publish and to explain how differing permission/visibility levels are typically addressed. This can be done as part of integrating the additional guidance mentioned above. Does that sound good?