TIC Timor's Dual-AS Government Network Control Surface: RDAP Identity,

Summary

APNIC records bind two active ASN registrations to TIC TIMOR I.P., while the sampled RIPEstat view observed only AS139688 as announced; this is a registry-and-routing control surface, not proof of a dual-live design.
Government-network, data-center, cybersecurity, and municipal integration responsibilities create continuing supervision, maintenance, and exception-handling costs that public capability descriptions do not measure.

Government digital services depend on more than applications. They depend on a chain of operational controls that begins with unique network identities and continues through routing, connectivity, data-center operations, security, support, and recovery. Each link can be correct in isolation while the combined service remains fragile. An autonomous-system record may identify the right organization but point to a role that is no longer monitored. A route may be visible while a continuity plan is untested. A municipality may receive a connection while application ownership, incident authority, or capacity management remains unclear.

Public-sector digitalization therefore has to be evaluated as a maintained operating system, not as a list of technology projects.

TIC TIMOR I.P. offers a useful public case. The BTW directory object is named "TIC TIMOR IP administrator." That phrase is not a separate company. In APNIC's Registration Data Access Protocol records for AS139687 and AS139688, it is the functional group assigned administrative and technical roles. The same records identify TIC TIMOR I.P. as the registrant organization and list a separate incident-response role. This distinction matters. Registry data is a ledger of identifiers and responsibilities, not a complete organization chart and not proof that every operational process works.

The directory object can anchor the article while the prose refers to the public institute that actually holds the registration.

Both APNIC records were active when checked. They use different network names: TICTIMORIP-AS-AP for AS139687 and TICTIMORIP-AS for AS139688. A simultaneous RIPEstat observation reported AS139688 as announced and AS139687 as not announced. That is not evidence of a fault. It is evidence that registered status and observed routing status answer different questions. A registered ASN can be reserved for a planned role, used only in a context that public collectors do not see, temporarily inactive, or no longer originated. Public sources reviewed for this article do not establish which explanation applies to AS139687.

They also do not establish that the two numbers form an active-active design, a failover pair, separate providers, or two independent facilities.

TIC Timor's public mandate is broader than routing. A 2019 Council of Ministers record says the institute manages the Government's IT network and other public entities' infrastructure and information systems. TIC Timor's own 2025 account describes responsibility for government network infrastructure, centralization of government data, electronic-government applications, distribution points, network access, business-continuity solutions, and data-center strategy.

Other first-party reports describe network and data-center services, a cybersecurity unit, municipal awareness and support, and coordination with another public institute over an internet line. These records establish an operating scope and program intent. They do not prove private architecture, measured availability, security effectiveness, cost savings attributable to network design, or a particular agency's production outcome.

The strongest interpretation is therefore operational. TIC Timor sits across several control surfaces that have to agree. APNIC records should match the people and roles authorized to act. Expected routing state should match what independent observers can see. Government-network documentation should match the running topology. Municipal integration should match the support and escalation model. Data-center, cybersecurity, application, and network teams should share change and recovery assumptions. Business-continuity language should be translated into tested dependencies, not treated as proof by itself.

This article analyzes that reality layer. It separates capability, reliability, and customer or citizen outcomes. It examines the supervision, integration, maintenance, and exception-handling costs that public descriptions often compress into words such as "network," "data center," "connectivity," or "digital transformation." It records failure modes without claiming they have occurred at TIC Timor. It also identifies what leaders can verify without demanding disclosure of sensitive infrastructure.

Identity boundary: the directory object is an operating role

The first engineering control is semantic accuracy. APNIC's RDAP responses for both autonomous-system numbers contain several related records. TIC TIMOR I.P. is the registrant organization. "TIC TIMOR IP administrator" is a group with administrative and technical roles. A separate incident-response group carries the abuse role. The autonomous-system objects have their own handles and network names. These are connected records, but they are not interchangeable identities.

This matters because operational systems often flatten identity. A directory may display a contact group's name as if it were the organization. A ticket may route work to an email address without confirming who can authorize a registry change. An asset inventory may store the autonomous-system number but omit the responsible business unit. A public article may turn a role label into a fictional company. Each mistake reduces accountability.

The correct model has at least four layers. The organizational layer identifies the public institute. The resource layer identifies AS139687 and AS139688. The role layer identifies administrative, technical, and incident responsibilities. The running layer consists of routers, links, services, procedures, and people that use those identifiers. APNIC records connect the first three layers. They do not expose the fourth in full.

Registry accuracy therefore has two dimensions. Syntactic accuracy asks whether a record contains valid names, addresses, and contact methods. Operational accuracy asks whether the named role is monitored, has appropriate authority, can authenticate to the required systems, and can act within the needed time. A shared mailbox can pass a delivery test while failing the operational test because nobody on duty may approve an emergency route change. A former staff member's credential can remain technically valid while organizational authority has ended.

Maintenance should include periodic review of the registrant and all functional roles. Reviews should verify ownership, response expectations, authentication, escalation, and separation of duties. They should also compare registry records with the institute's public contact information and internal asset ownership. A discrepancy is not automatically an incident, but it is an exception that needs an owner and a deadline.

The role distinction helps during recovery. A routing anomaly may need a network operator. A suspected abuse event may need an incident team. A permanent change to a registration may need administrative authority. A public-service outage may require an application or municipal-service owner. Sending all four problems to one undifferentiated contact increases delay and makes post-incident accountability harder.

Public analysis should preserve the same discipline. The RDAP records support the conclusion that the existing directory object represents an administrative and technical role attached to TIC TIMOR I.P. They do not establish staffing numbers, reporting lines, shift coverage, or the identity of every authorized operator. Those unknowns belong in diligence, not in invented narrative.

Two registered ASNs are not proof of a redundant design

An autonomous-system number is a unique routing-policy identifier. Its existence in a registry establishes that the resource has been assigned and provides records about the holder and contacts. It does not say how many routers use it, where those routers are located, which providers connect them, whether routes are currently originated, or what traffic they carry.

APNIC's records identify AS139687 as TICTIMORIP-AS-AP and AS139688 as TICTIMORIP-AS. Both were returned with active status. The organization and functional-role bindings were materially consistent across the two records when observed. This creates a useful inventory baseline: TIC TIMOR I.P. holds two distinct registered autonomous-system identities, and the directory role is associated with both.

The baseline is important because separate ASNs can support several legitimate designs. They can represent different networks, policy domains, environments, organizational units, migrations, or future capacity. They can also remain assigned without being publicly originated. The records alone do not identify the design intent. Treating "two" as synonymous with "redundant" would be a serious analytical error.

Real redundancy depends on failure domains. Two ASNs operated by the same team may share routers, power, fiber, upstream providers, configuration systems, credentials, or change windows. Conversely, one ASN can be operated across several independent facilities and providers. Resource count is not a resilience metric.

The operational value of two resource identities depends on documented purpose. An inventory should state the intended role of each ASN, expected prefixes, permitted origins, upstream or peer relationships at an appropriate level, monitoring scope, change authority, and retirement conditions. That record need not be public. It does need to exist for operators.

Purpose also determines alerting. If AS139687 is not expected to be announced, an alert about its absence is noise. If it is expected to appear only during a planned migration, continuous announcement may be the anomaly. If AS139688 is the expected public origin, loss of visibility may be significant. Monitoring cannot interpret state safely without an expectation model.

Lifecycle controls should cover acquisition, activation, change, suspension, and retirement. Before activation, registry roles, routing policy, filters, security metadata, monitoring, and contacts should be ready. During operation, observed routes should be reconciled with the approved baseline. During a migration, both old and new states may be valid for a limited period. At retirement, routes, credentials, filters, monitoring rules, and public records should be removed or updated in a controlled order.

This is where software lifecycle and lock-in become relevant even though the primary assets are network identifiers. The operational policy is encoded across router configurations, monitoring rules, asset databases, provider portals, registry interfaces, and runbooks. If only one vendor tool or one engineer can reconstruct the intended relationship between the two ASNs, the organization has a continuity dependency. Portability requires current records and repeatable procedures, not just ownership of the numbers.

Registration state and observed routing state answer different questions

RIPEstat's autonomous-system overview reported different announced states for the two numbers at the time of observation: AS139688 was announced, while AS139687 was not. The result is a timestamped external observation, not a permanent description. Public routing collectors do not see every private or restricted context, and routing can change after the query.

The difference illustrates why network assurance needs more than one data source. RDAP answers who the registry associates with a resource and which roles are recorded. Routing observation answers whether collectors currently see the resource participating in public BGP. Neither source is sufficient alone.

A registered record without an observed route may be entirely correct. The resource may be unused, reserved, private to a limited environment, or temporarily absent. An observed route without an accurate registration creates a different concern: traffic can flow while responders lack reliable responsibility records. The trustworthy state is alignment between organizational intent, registry data, routing policy, and observation.

An operator baseline should define expected state for each ASN. It should identify which prefixes, if any, are expected to originate; which changes are planned; how quickly collector visibility is expected; and who decides whether a variance is acceptable. The baseline should be versioned so that an investigation can distinguish an old expectation from an unauthorized change.

Monitoring should compare several dimensions. Origin monitoring asks whether expected prefixes appear under the intended ASN. Visibility monitoring asks whether multiple observation points see them. Path monitoring asks whether upstream or peer changes require explanation. Registry monitoring asks whether organization and role records remain consistent. Configuration monitoring asks whether running devices match approved policy. No single dashboard can infer all of these dimensions reliably without maintained inputs.

Exception handling is critical because routing observations are ambiguous. A missing route can reflect maintenance, an upstream problem, a local configuration error, a collector gap, or deliberate withdrawal. An unexpected route can be a planned test, a migration, a leak, or an unauthorized action. Automation should identify the deviation and preserve evidence; a responsible operator should classify it against the change record and service context.

The public evidence supports only a limited conclusion: two active APNIC registrations exist, and one of them was publicly announced in the sampled RIPEstat overview while the other was not. It does not support a claim about uptime, route volume, neighbour diversity, traffic engineering, or a failure. Preserving that boundary makes the observation useful rather than sensational.

The government-network mandate creates a multi-owner control surface

The 2019 Council of Ministers record describes TIC Timor as a public institute responsible for implementing ICT policy and strategy and managing the IT network of the Government and other public entities, including ICT infrastructure and information systems. The record also describes objectives around national and international connection, equipment and software compatibility, interoperability, and data security.

TIC Timor's 2025 seminar account presents a similarly broad scope. It says the institute is entrusted with ICT and electronic-government programs, manages government network infrastructure, centralizes government data, and develops applications. It describes robust digital infrastructure, a government digital data center, distribution points, network access, business continuity, and integration with national ICT infrastructure.

That breadth creates coordination costs. Network infrastructure, data-center facilities, cloud platforms, cybersecurity, applications, identity systems, municipal connections, and policy are different disciplines. They may have different budgets, vendors, release cycles, and incident thresholds. A change that is locally correct can still cause a cross-system failure.

Consider a new municipal service. The application team can deploy a functioning system while the network path lacks capacity or stable name resolution. The network team can provide connectivity while identity and access controls remain incomplete. The data-center team can host the service while backup ownership is unclear. The cybersecurity team can impose a control that blocks a legitimate workflow. The local institution can receive access without a trained support contact. None of these failures requires negligence; they arise naturally at ownership boundaries.

The operating model therefore needs service maps rather than isolated asset lists. A service map connects the public function to applications, data, identity, DNS, network paths, hosting, monitoring, vendors, support roles, and recovery objectives. It distinguishes authoritative records from observed state. It records who may approve a change and who may accept residual risk.

Interoperability adds another layer. The Council of Ministers' description refers to standards for equipment and software compatibility. Standards reduce ambiguity only when they are translated into tested interfaces. A written protocol requirement does not guarantee that versions, certificate chains, data formats, time synchronization, or error handling agree in production. Integration testing and change control remain necessary.

Centralization can simplify governance and improve consistency, but it can also concentrate dependency. Central data, identity, network, or support services may become common failure points. The correct conclusion is not that centralization is good or bad. It is that shared services need explicit capacity, redundancy, access, maintenance, and recovery controls proportionate to the number of public functions that depend on them.

TIC Timor's public mandate establishes why the institute is a network-control-surface company object for this research. It does not prove that every component is centralized, that every ministry uses the same architecture, or that all government services depend on the two observed ASNs. Those relationships are not disclosed and should not be inferred.

Distribution points, municipalities, and the cost of edge integration

TIC Timor's public material refers to distribution points, enhanced network access, municipal activity, and local government services. Reports from Oé-Cusse, Manatuto, and Díli describe electronic-government awareness, local-network access, network infrastructure, data-center and cybersecurity topics, and technical support. An INDMO report describes coordination over installation of an internet line to support that institute's digital systems.

These records show organizational reach and integration activity. They do not prove that every municipality had a completed production connection, that every service met a target, or that a specific user outcome followed. Awareness events are evidence of engagement and training, not performance benchmarks. A planning meeting is evidence of coordination, not proof of completed delivery.

Edge integration has several technical stages. The parties must define the service boundary, select a connection method, identify required addresses and names, configure security policy, test applications, establish monitoring, document support, and agree on acceptance evidence. Each stage may involve TIC Timor, the receiving institution, carriers, facilities, application owners, and security teams.

The handoff between national and local systems is especially important. A central team may monitor backbone reachability while a municipality owns local switching, power, devices, or user support. A central link can be healthy while the public service remains unavailable. Conversely, a local application problem can be misclassified as a network outage. Shared diagnostics should show where the service boundary lies and what evidence each team can collect.

Geography changes maintenance assumptions. Travel time, equipment availability, power quality, carrier repair processes, and local staffing can affect restoration. Remote management can reduce travel but increases dependence on secure access and out-of-band paths. Spare equipment can reduce repair time but creates inventory and lifecycle costs. Standardized configurations can simplify support but may not fit every site.

Capacity planning is also end to end. A higher-capacity national link does not automatically improve a municipal service if the local access, application, server, or user device remains constrained. Usage growth can appear in one layer before another. Monitoring should distinguish physical errors, congestion, packet loss, name-resolution failures, authentication delays, application response, and user-reported symptoms.

Acceptance should therefore be service-specific. A connectivity test can confirm reachability. It cannot confirm that an application workflow is usable, that backups complete, or that support can resolve an incident. A stronger acceptance package records link state, path and DNS checks, application transactions, monitoring enrollment, support ownership, rollback conditions, and the date of the next review.

Public descriptions of municipal expansion express a policy objective. Operational continuity depends on the quality of those repeated integration and support practices. That is the hidden work behind phrases such as "expand connectivity" or "local network."

Data-center centralization and cloud plans require boundary discipline

TIC Timor's public reports describe a government data center, centralization of government data, data-center services, cybersecurity responsibilities, and future hybrid-cloud governance. These are capabilities and plans. They should not be converted into claims about a particular architecture, cloud provider, certification, redundancy level, or workload placement.

Data-center centralization changes the dependency graph. Applications may depend on shared compute, storage, identity, DNS, network, logging, backup, and physical facilities. Shared services can reduce duplication and improve consistent control. They can also widen the impact of a common failure or maintenance error.

Boundary discipline starts with ownership. Facilities teams own power, cooling, physical access, and hardware environments within their scope. Platform teams own virtualization, storage, operating systems, or cloud control planes. Network teams own connectivity and routing. Application teams own business logic and data use. Security teams define and monitor controls. Service owners decide recovery priorities. A reliable operating model makes those boundaries visible while preserving a single accountable service outcome.

Hybrid-cloud governance adds portability and lifecycle questions. Workloads may depend on provider-specific identity, networking, storage, monitoring, or deployment interfaces. Portability is not achieved by calling a design "hybrid." It requires tested data export, configuration reconstruction, credential recovery, network reattachment, and application validation. The organization must know which components can move, how long movement takes, and what functionality is lost during the transition.

Backup is another common ambiguity. A successful backup job proves that data was written somewhere. It does not prove that the data is complete, readable, protected, or restorable within the service objective. Restore tests should include application consistency, identity, network configuration, dependencies, and operator access. A data center can remain physically available while a critical service cannot be reconstructed.

Change coordination becomes more difficult as shared-platform use grows. A certificate renewal, DNS change, firewall rule, storage upgrade, or identity-policy change can affect many applications. The change process should identify downstream services, maintenance overlap, rollback limits, and validation owners. High-risk changes may need staged rollout and independent recovery access.

Public transparency must also be balanced with security. Citizens and agencies benefit from knowing responsibilities, service scope, and incident channels. Detailed rack layouts, addresses, credentials, or defensive configurations should remain protected. Assurance can be demonstrated through control evidence and tested procedures without publishing sensitive topology.

The public sources support the conclusion that data-center and cloud governance are part of TIC Timor's declared operating scope. They do not establish whether a specific design is resilient or whether a particular service has met its recovery objective. Those questions require dated, workload-level evidence.

Cybersecurity is an operating dependency, not a descriptive label

TIC Timor's site and reports identify cybersecurity as one of the institute's responsibilities. One 2024 account describes a Cybersecurity Unit associated with protecting important data centralized in the electronic-government data center. Another public account lists security threats, privacy, skills, budget, and limited resources among the challenges of digital transformation.

This is useful because it acknowledges constraints rather than presenting technology as frictionless. Security controls consume staff time, integration effort, maintenance windows, and exception capacity. They can reduce risk and still create service failure when poorly coordinated.

Network security depends on current identity and routing records. Incident teams need accurate contacts for autonomous-system resources. Monitoring needs an expected route and service baseline. Access control needs timely joiner, mover, and leaver updates. Logging needs synchronized time and retention. Vulnerability management needs asset ownership. Recovery needs credentials that remain available when the primary identity system is degraded.

Security tooling also has lifecycle cost. Sensors, firewalls, endpoint controls, certificate services, and log platforms require updates, tuning, storage, and trained interpretation. A control that generates too many false positives can be ignored. A rule that is never reviewed can block a legitimate change. A dashboard that has no response owner records risk without reducing it.

Exception handling should be designed in advance. A public institution may need to restore a service while an upstream record is stale, a certificate is near expiry, or a security control blocks an emergency workflow. The response should be a scoped and time-limited exception with an approver, compensating monitoring, and a required permanent repair. Disabling a broad control without those boundaries can turn an availability problem into a security problem.

Security and continuity can conflict if teams optimize them separately. Strict network filtering may protect the normal state but prevent a failover path. A backup account may aid recovery but create privilege risk. Centralized identity may improve governance but become a recovery dependency. Design reviews should evaluate both the ordinary and degraded modes.

Claims discipline is essential here. The existence of a cybersecurity unit is capability evidence. Public discussion of threats is risk awareness. Neither proves that incidents have or have not occurred, that a control is effective, or that a system is secure. The right questions concern asset coverage, detection ownership, response authority, recovery testing, and the age of the evidence.

Supervision, integration, maintenance, and exception costs

The operating cost of TIC Timor's public mandate is not captured by hardware or bandwidth alone. It includes the labor required to keep records, systems, teams, and institutions aligned.

Supervision starts with expected state. For the two autonomous-system resources, the expectation should state whether public routing is intended, which prefixes belong to each policy domain, and what changes are authorized. For government services, the expectation should state required dependencies, monitoring, recovery objectives, and support boundaries. Alerts without that context create work but not assurance.

Integration work connects layers. Registry contacts must align with network authority. Routing policy must align with address plans and security metadata. DNS and identity must align with applications. Municipal links must align with local equipment and support. Data-center capacity must align with workload demand. Cybersecurity controls must align with change and recovery procedures.

Maintenance preserves that alignment over time. Contacts change, certificates expire, software reaches end of support, carriers alter services, equipment ages, and applications add dependencies. Documentation can become inaccurate even when every original statement was true. A maintenance program should assign review intervals based on risk, not treat all records alike.

Exception handling absorbs uncertainty. A route observation may not match the baseline. A municipality may have a failing link during a planned central change. A security control may block a valid service. A data-center dependency may degrade without fully failing. The response requires evidence collection, classification, authority, communication, and follow-up.

The cost model should include at least six categories. First is people: on-call coverage, training, peer review, and exercises. Second is tooling: monitoring, configuration management, logging, ticketing, and secure access. Third is integration: testing across network, identity, application, and institutional boundaries. Fourth is maintenance: upgrades, renewals, records, spares, and decommissioning. Fifth is exceptions: incident response, temporary controls, and root-cause repair. Sixth is assurance: audits, restore tests, route reviews, and service acceptance.

These costs do not indicate failure. They are the price of operating a shared control surface responsibly. A larger capability set creates more interfaces to maintain. A central public institute also carries coordination cost that might otherwise be duplicated across agencies.

Efficiency should therefore be measured against outcomes and risk, not by minimizing control activity. Automating a registry comparison can save review time, but someone still has to interpret a mismatch. Standardizing municipal configurations can reduce variation, but exceptions still need governance. Centralizing monitoring can improve visibility, but local teams still need a usable escalation path.

The most effective controls produce evidence that can be reused. A service map supports change review, incident response, and audit. A versioned expected-route list supports monitoring and recovery. A tested restore procedure supports continuity and staff training. A current authority matrix supports both security and operations. Reusable evidence lowers the marginal cost of assurance.

Failure modes supported as testable hypotheses

The public evidence supports the following failure hypotheses. It does not show that any of them has occurred at TIC Timor.

1. Registry-role drift

The administrative, technical, registrant, or incident role can become stale after a staffing or organizational change. Testing should verify authority and response, not just contact delivery.

2. Registered-versus-expected-state confusion

An active ASN registration can be mistaken for an expectation that the ASN must be publicly announced. The control is a versioned purpose and routing baseline for each resource.

3. Unexpected route appearance

An ASN not expected in public routing can appear. Operators need planned-change context, origin and prefix evidence, and an escalation owner before classifying the event.

4. Expected route disappearance

An expected public route can vanish because of maintenance, configuration, upstream failure, or observation gaps. Multiple evidence sources and a documented service impact test reduce misclassification.

5. False redundancy inference

Two ASNs can be described as resilient even when they share critical dependencies or do not form a failover design. Continuity reviews should map actual failure domains.

6. Configuration-to-registry drift

Routers, monitoring, and filters can use an old organization, contact, or policy record. Periodic reconciliation should connect the authoritative record to every downstream consumer.

7. Municipal handoff gap

A central link can be installed without clear ownership for local power, switching, applications, or user support. Acceptance should record the demarcation and escalation path.

8. Capacity bottleneck migration

Increasing backbone or internet capacity can move the bottleneck to local access, applications, identity, or storage. End-to-end measurements should distinguish layers.

9. Central dependency concentration

Centralized DNS, identity, network, or data-center services can widen the impact of one change or failure. Service maps and staged changes should identify shared dependencies.

10. Backup without recoverability

Backup jobs can succeed while application restoration fails because identity, network, configuration, or credentials are missing. Workload-level restore tests are required.

11. Security-control recovery conflict

A control that is correct during ordinary operation can block a failover or emergency workflow. Degraded-mode testing should include security and continuity owners.

12. Maintenance overlap

Carriers, facilities, platform teams, and application teams can schedule individually safe work at the same time. A shared calendar and risk-acceptance authority can prevent compound loss.

13. Documentation-to-running-state drift

Public or internal descriptions of distribution points, services, contacts, or architecture can lag actual changes. Named ownership and review timestamps make drift visible.

14. Helpdesk without action authority

A local or central support contact can receive a case but lack access or approval to resolve it. Escalation tests should verify both reachability and authority.

15. Capability reported as a citizen outcome

Data-center services, government networks, cybersecurity units, municipal programs, and two registered ASNs are capabilities or activities. They do not by themselves prove faster services, lower cost, better availability, or improved citizen experience.

Capability, reliability, and production outcomes are separate evidence classes

Capability evidence answers what an organization is assigned, equipped, or designed to do. TIC Timor's public mandate covers government ICT networks, infrastructure, information systems, electronic government, data-center services, and related support. APNIC records establish two registered autonomous-system identities. First-party reports describe municipal engagement, network integration, and cybersecurity responsibilities.

Reliability evidence answers whether a capability is operating as intended over time. The sampled RIPEstat overview provides a narrow external routing observation. Public reports provide dates and named activities. These are useful signals, but they do not establish service levels, incident rates, recovery performance, or internal test results.

Production-outcome evidence answers what happened for a particular public institution, service, user group, or citizen workflow. A coordination report can show that teams met. It cannot prove the final connection met a capacity target. An awareness event can show participation. It cannot prove an application became more reliable. A public statement about efficiency can describe an objective or reported saving. It does not isolate the network's causal contribution.

Keeping the classes separate improves decisions. Leaders can use capability evidence to define the operating scope. They can use reliability evidence to ask for current controls and tests. They can use production evidence to evaluate whether a service delivered the intended public value. Mixing the classes creates either unjustified confidence or unfair dismissal.

The same discipline should guide public reporting. Describe APNIC identity as registry identity. Describe RIPEstat results as timestamped observations. Describe institute reports as first-party accounts. Describe government records as mandate evidence. Reserve performance conclusions for dated measurements with a clear method and scope.

What the public evidence establishes and leaves unknown

The evidence establishes that TIC TIMOR I.P. is a public institute with a government ICT and electronic-government mandate. It establishes that APNIC associates the institute and the existing administrator role with AS139687 and AS139688. It establishes that both registrations were active when observed. It establishes that RIPEstat reported AS139688 announced and AS139687 not announced at the sampled time. It establishes that TIC Timor publicly discusses government network infrastructure, data-center services, distribution points, cybersecurity, business continuity, municipal activity, and integration with other public institutions.

The evidence does not disclose private topology, address inventory, providers, peering policy, facilities, configuration, route filters, security design, staffing, on-call coverage, maintenance history, incident history, availability, latency, throughput, or recovery results. It does not show that the two ASNs are redundant, independent, or both in production. It does not prove that a municipal connection or digital service achieved a specific outcome.

Those unknowns are not defects in the evidence. Some should remain private. The practical task is to request control evidence proportionate to the decision: current role reviews, expected routing baselines, service maps, change records, restore tests, acceptance evidence, and dated outcome measurements. That approach respects security while still testing operational continuity.

TIC Timor's Dual-AS Government Network Control Surface: RDAP Identity, Routing Continuity, and Public-Service Integration Costs

Why it matters