Specify the duct type associated with a span

[lgs85]

A call with stakeholders today surfaced a need to be able to specify the duct type associated with a span. The stakeholder stated that they use an ISO standard to specify this, and I've requested more details.

We don't currently support anything like a duct type in OFDS. Ducts could be represented as an additional layer of structure in the data model. Alternatively (and preferably if it works) we may be able to add one or more additional fields at the span level to accommodate this.

Flagging here that this may be a priority issue to address

[stevesong]

I think we do have to support this in some way in the standard. It does prompt the question of where exactly the boundaries of Open Fibre Data lie.

[duncandewhurst]

Thanks for sharing this feedback! A couple of questions:

1. What is meant by 'type' in this context?
2. Who would use this data and to what end?

In https://github.com/Open-Telecoms-Data/open-fibre-data-standard/issues/192#issuecomment-1334480868, we discussed creating a Cable class and adding an array of .cables to Span. In which case, Span could represent a duct. However, that would be a major change and would introduce quite a lot of complexity so I think we need to understand more about the use cases before deciding on modelling.

[duncandewhurst]

Noting that if we did want to model ducts in detail, we'd need to consider that ducts can be nested as described on the Wikipedia page for microducts.

[stevesong]

We are still waiting to hear more detail from the stakeholder. Their interest was in knowing what ISO standard duct the fibre was deployed in. The purpose I believe is to understand whether there is capacity for additional fibre but I am not sure.

[duncandewhurst]

Thanks for the clarification! With that use case in mind, we might consider a more general field to indicate whether capacity for additional fibre is available, similar to Span.darkFibre and Node.power. If there is a need for more detail, such a field could be paired with a xDetails field. Anyway, we can wait for more information before making any decisions - just logging thoughts whilst they occur to me.

[lgs85]

Thanks both. Noting here that the thing I think we need to be super clear on is what constitutes a single span vs multiple spans on a similar/the same route. A structural change to the data model can address this explicitly, whereas if we opt for the simpler approach of adding fields we'll need to think carefully about descriptions and definitions.