SINFI 4.0 and network nodes: one boolean for cyber vulnerability, one for early warning

Until now Italy’s national network cadastre wanted to know where the cable runs and what it is threaded through. With version 4.0 it starts asking which amplifier sits in the node, how it is powered, and whether anything is watching it. That changes the nature of the datum, not its detail. And it comes with a caveat almost nobody will quote.

Adopted does not mean settled

Version 4.0 was adopted by AgID determination no. 129/2026 of 14 July, published on the transparency portal on the 15th and announced on the 20th. For line segments the changes are presented as changes, full stop: we went through them yesterday.

For nodes, not so. In the “Report on the changes in specification v.4.0”, the preamble to class ND_COM — node of the telecommunications and cabling network, 070702 — closes with one sentence: “Before proceeding with the integrations, the proposals described must be agreed with the stakeholders” (our translation).

So everything that follows is a proposal. Reading it as an obligation is a mistake. Ignoring it because “it is not mandatory yet” is a bigger one: the moment when a proposal can still be changed is now.

The node, and the node that does not exist

Three integrations are proposed for ND_COM: vertical position (the same domain as line segments, underwater included), type, and specific characteristics expressed as data types.

The type domain — which already lists chambers, joints, telephone exchanges, radio base stations, cross-connection cabinets, FTTCab/CNO, building optical distributors and satellite land stations — gains 15 landing node (between submarine and terrestrial segments) and 16 subsea branching unit. The first is the point where a submarine backbone becomes a terrestrial network, and the most concentrated point of risk on the whole route.

Then there is 89 fictitious, a “node serving the graph connection of nodes (used for amplifiers and monitoring or surveillance systems, detailed as data types)”. Translated: an amplifier is not a node in the topological sense, but it needs one to sit in the cadastre’s graph, so the model invents it. It is a modeller’s detail, and it tells designers something: the cadastre’s representation does not match yours, and the conversion must be designed, not improvised at submission time.

“Cyber vulnerability”: yes or no

Data type ND_COM_AMP describes the amplifier with three attributes. Type: EDFA, Raman, SOA, other — the vocabulary of ITU-T G.662 on optical amplifiers. Power supply: direct current, alternating current, power over Ethernet, remote powering, solar panels or batteries, other. And then AMP_VUL, “cyber vulnerability”, cardinality [0..1], type Boolean.

A boolean. True or false.

Three questions to bring to the consultation. Who answers: the network operator, whoever commissioned the equipment, the manufacturer? Against what: a published security advisory, a firmware version, an internal assessment? As at what date: because equipment that is “not vulnerable” in July stops being so the day an advisory lands, with nothing touched on site.

A binary field on a property that changes over time is a photograph that ages. If the field stays — and it can, provided it is useful — it needs a written rule for completing it: reference, assessment date, the party who signs it. Without those three things the column fills up with “false” out of caution and informs nobody. With them it becomes a datum. That difference is decided now, not at the first submission.

Monitoring is not preventing

The second data type is ND_COM_SOR, monitoring or surveillance systems. The capabilities that can be declared, cardinality [0..*]: fault detection, intrusion or tampering detection, environmental monitoring, signal quality analysis, other. The second matters to anyone with unattended closures and cabinets along the route.

Then SOR_EW, early warning: another boolean, defined by the document as a “preventive alerting function that flags anomalies or potential faults before a service interruption occurs”.

Declaring it costs a tick. Demonstrating it is another matter. An alarm fires once the threshold has been crossed: the service is already down. A pre-alarm means seeing the drift while the service is running — so a measurement that does not stop the traffic but runs alongside it, on another wavelength — and a history to compare it against. Anyone ticking “true” without either is declaring an intention.

Electricity networks are not a separate chapter

On the electricity side the document carries no such caveat. In class TR_ELE (line segment, 070301) a single attribute changes: TR_ELE_TY moves from a hierarchical to a simple enumeration. In the printed domain, however, two different entries carry the same code 04 — “segment serving public lighting” and “segment serving traffic signals and similar” — and in the same list two mnemonics appear twice with different meanings (TR_ELE_STA for status and for housing infrastructure, TR_ELE_PRO for depth and for type of marking). They look like typos: they need clearing up before anyone builds a record layout on them.

In class ND_ELE (node of the electricity network, 070302) the attribute “type of connected user” becomes mandatory and the domain opens into a tree: domestic, industrial by size class, agricultural — with an entry for “precision agriculture” — mixed, firefighting, public buildings, and urban services. The last branch shows the direction of travel: public lighting, traffic signals, electric vehicle charging points, video surveillance, sensors and IoT devices — with the stated aim of supporting integration with the other urban service management systems.

Two honest caveats here too: next to the attribute the printed cardinality is still [0..*], which does not square with the mandatory status announced in the text; and the duplicated “light point” and “traffic signal” entries in the type attribute are items “whose removal is proposed” — so that too is a proposal.

Why it matters to anyone laying fibre: a cadastre that records loads and services, not just conduits, is the map you consult before digging in a shared duct or coordinating works with the electricity distributor.

What to do now

Take part in the consultation instead of inheriting its result. For nodes we are still at proposal stage: a written comment today costs an hour, an imposed change tomorrow costs a survey campaign.
Start collecting the data on active equipment now: amplifier type, power supply, presence and capabilities of the monitoring system. These are the data nobody holds in exportable form — they sit in test records, emails, and the memory of whoever commissioned the equipment.
Write the rule for completing the booleans before completing them: against which reference, as at what date, signed by whom.
Design the conversion towards node 89: decide how your equipment becomes graph nodes, and keep the identifier tying the two representations together.
On the electricity side, survey the connected user node by node: it is a datum you collect once and update, not one you reconstruct afterwards.

The point.

The cadastre is ceasing to be a map and becoming an inventory of state. It is only fed if the datum is born structured where it is born: in the chamber, the cabinet, the test record. Documenting a network is not an end-of-works formality: it is a collection designed beforehand. That is how we work — measurement, certification and as-built documentation set up so that submission is an export.

Do you need to decide which fields to add to your as-built before the data model closes? Talk to an engineer.