Summary

  • RIPE’s public records identify AS210417 with the as-name Datatokni and expose separate organisation, contact and maintainer references. Those fields describe the registry object and its administration; they do not by themselves establish legal ownership or current operational control.
  • The evidence package preserves public source endpoints for the ASN, its FT-NET contact reference and routing-monitor services, but it does not contain a trustworthy timestamped routing response. Current announcements, prefix counts, neighbours and continuity therefore remain open questions rather than publishable facts.

The most important distinction in this case is also the easiest to lose: an autonomous system can be present in a registry while its live routing status is changing, absent from a particular collector, or not independently established by the evidence at hand. The name Datatokni is therefore a useful starting point for investigation, not a conclusion about who operates a network or how much traffic it carries.

The registry identity

The canonical RIPE RDAP record is keyed to autonomous system number 210417 and publishes Datatokni as the ASN name. The RIPE Database aut-num object likewise records AS210417 with the as-name Datatokni and exposes the object’s organisation reference, administrative and technical contacts, maintainers, registry status, creation time and modification time. The object’s status is ASSIGNED. These are strong facts about the public registry record. They are not interchangeable with facts about routing.

The distinction matters because registry databases and routing collectors answer different questions. A registry records the allocation or assignment state of a number resource and the metadata needed to administer it. A routing monitor records what its collectors observed in BGP at a particular time and from a particular measurement position. An assigned object can coexist with no route visible to one collector. A route can be visible while the registry’s descriptive fields remain unchanged. Neither observation, standing alone, resolves the legal or operational identity of the network.

The RIPE materials also associate AS210417 with FT-NET or FT-NET-MNT administrative metadata. The related FT-NET object is a role or contact record associated with Føroya Tele or Faroese Telecom network contact details. That is useful evidence about where administrative or technical communication is directed. It is not proof that Føroya Tele currently owns AS210417, operates it, depends on it, or originates routes through it. Contact, registrant and maintainer roles can be related without being equivalent.

Why the contact record is not an operating-company certificate

The previous public coverage of Datatokni ForoyaTele focused on the intelligence value of registry contact entities: a named contact can connect an Internet number-resource record to an organisation or administrative function, and changes in that record may warrant monitoring. That is a valid commissioning context, but it leaves a more difficult question unanswered: what can the record establish about the network itself?

The answer is narrower than a profile article might imply. A contact relationship can show how the registry expects a query, maintenance action or operational issue to be routed. It can help investigators compare changes across the aut-num object, role object, organisation references and maintainer fields. It can also identify a continuity surface: if a number resource is important to a service, changes in its administrative metadata may deserve review. But the contact record does not turn an administrative association into a verified ownership chain.

That boundary is particularly important where names differ across fields. RIPE may display Datatokni as the as-name while another public service displays ForoyaTele or Føroya Tele in a descriptive, holder or contact field. Those labels can refer to different object attributes rather than presenting a direct contradiction. The proper interpretation is to preserve the field meanings and state which source publishes which label.

The routing question remains time-sensitive

RIPEstat provides endpoints for AS Overview, Routing Status and Announced Prefixes. The routing-status endpoint is designed to report RIPE RIS-observed visibility, including first-seen or last-seen information when available. The announced-prefixes endpoint can list prefixes associated with AS210417 during the applicable observation interval. BGP.Tools and Hurricane Electric’s BGP Toolkit provide additional collector-backed views that can be used for cross-checking.

But a routing claim requires more than the existence of an endpoint. It requires the actual response, its query parameters where relevant, and a trustworthy retrieval time. The preserved research package contains the public URLs for those services, yet the available search output did not provide a reliable timestamped response from which to state that AS210417 was announced, unannounced, originating a particular prefix, or connected to a particular neighbour at a defined moment.

That is not a minor technical footnote. Routing data changes. Collector coverage differs. Caches age at different rates. A route may be visible from one vantage point and absent from another because of propagation, filtering or measurement position. Even a confirmed observation would describe visibility during an interval, not legal ownership, exclusive dependency or future continuity.

The same caution applies to the RIPE NCC delegated-statistics file. The source endpoint is https://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest. A matching entry could help verify that ASN 210417 remains present in delegation data, along with fields such as status, country code and allocation date. It would still establish registry delegation rather than live route origination. Registry persistence and routing visibility are related signals, not substitutes.

What can be said with confidence

The evidence supports four bounded conclusions.

First, AS210417 is a publicly documented RIPE autonomous-system object whose published as-name is Datatokni. The RIPE records are the appropriate primary evidence for that statement: RDAP autnum record and RIPE Database aut-num object.

Second, the object exposes distinct organisation, administrative, technical and maintainer references. The FT-NET role record is relevant to that administrative surface, but it should be described as a contact or role object, not as independent proof of ownership or operation: FT-NET role object.

Third, RIPEstat and third-party BGP services provide the right public measurement surfaces for testing current visibility, but the evidence preserved for this article does not justify a current announcement, prefix, peer or upstream claim. The relevant endpoints are RIPEstat AS Overview, RIPEstat Routing Status, RIPEstat Announced Prefixes, BGP.Tools and Hurricane Electric’s BGP Toolkit.

Fourth, the registry and routing layers can legitimately disagree without either one being defective. The ASN may remain assigned while no route is observed by a given collector. A route may be observed while the registry’s contact metadata still reflects an older administrative arrangement. The correct next step is time-stamped comparison, not extrapolation.

The operating question for infrastructure readers

For operators, investors and public-interest infrastructure readers, the practical issue is not whether Datatokni is a meaningful registry label. It is how much continuity or leverage can be inferred from the record.

At present, the answer is limited. The record identifies an object that can be monitored across registry and routing layers. It does not show the traffic volume, customer dependence, upstream concentration, geographic reach, redundancy or failure impact of any service associated with AS210417. Nor does it establish that Føroya Tele is the current operator merely because FT-NET appears in administrative metadata.

That leaves a concrete monitoring plan. Capture the RIPE aut-num and role objects at regular intervals. Record changes to status, organisation references, admin-c, tech-c and mnt-by fields. At the same times, preserve timestamped RIPEstat, BGP.Tools and Hurricane Electric observations, including whether any prefixes and adjacencies were visible. Compare those snapshots rather than treating any single field as decisive. If a material change appears in one layer but not the others, report the discrepancy and investigate its semantics.

The plan also creates a useful negative discipline. A missing route observation should not be rewritten as proof of shutdown. An unchanged contact should not be rewritten as proof of operational continuity. A named contact should not be rewritten as a corporate ownership finding. In network-resource research, the gaps between those propositions are where the most consequential errors occur.

A bounded conclusion

AS210417 is best understood as a registry object with a published Datatokni label and a visible administrative surface that includes FT-NET references. That is enough to justify continued monitoring. It is not enough to claim current routing activity, a specific prefix set, a confirmed neighbour, or operational control by a named organisation from the evidence preserved here.

The open question is therefore precise: when captured with a trustworthy timestamp, what do RIPE RIS and independent BGP services actually observe for AS210417, and do those observations change over time alongside the registry metadata? Until that comparison is made, the responsible description is not that the ASN is active or inactive, controlled or abandoned. It is that registry identity is established, while live network behaviour remains to be measured.

For the delegated registry evidence, see the RIPE NCC delegated-statistics file. For the canonical directory context, see the Datatokni ForoyaTele directory record.