摘要

  • APNIC 与国际电信联盟曾于 2016 年协助东帝汶建立 TLIXP 测试交换点。贸发会议 2024 年评估称 TLIX 当时似乎未在运行，同时明确指出可用运营数据有限；报告另称，当年另一项 IXP 预算已获批、正在招标，并与三家运营商进行测试。
  • APNIC 在 2026 年称 ANC 正在建设 TL-IXP。这是项目状态信息，不是验收证明。接下来应能公开核验的是：部署协助结束后，谁拥有日常运营权、支持责任、经费安排和持续服务记录。

项目完成之后，谁接手？

2016 年 APNIC 执行委员会纪要记载，APNIC 技术援助团队与国际电信联盟曼谷区域办公室合作，帮助东帝汶建立了名为 TLIXP 的 IXP 测试项目。纪要没有说明它后来服务了多少成员、承载多少流量、运行了多久，也没有写明设备、维护或项目退出安排。

贸发会议 2024 年的电子商务准备度评估给出了一项带有边界的回顾：TLIX 于 2016 年在帝力建立；由于运营数据有限，在评估所覆盖的时间点，它似乎没有正常运作。报告还说，2024 年另一项 IXP 预算获批，招标正在进行，并与三家运营商测试。两段资料描述的是不同时间、不同环节。报告没有说明早期项目为何停止，也没有证明新招标是对旧设施的直接延续。

这不是名称上的小差异。一个交换点要持续提供服务，必须有人能维护交换网络、修复故障、管理路由策略，并在设备老化时筹措替换资金。用户还需要看到足够的证据，知道服务是否仍然可用。没有公开记录不能直接证明技术故障，但会让责任归属与运营状态无法被外部读者核实。

设计文件与运营证据不是一回事

APNIC 基金会托管的一份 2025 年项目演示把 ANC 列为拟议的主办方，并提及 Timor Telecom、Telemor 和 Telkomcel 等主要运营商。方案提出共享治理、免费对等互联、路由服务器、IXP Manager、镜像服务与监测。这些内容说明设计想采用什么安排，不说明设计已获批准或投入运行。

ANC 的技术顾问职务说明书则列出了交付任务：部署路由服务器和 IXP Manager，支持 RPKI 验证与监测，编写运营政策和接入手册，培训本地人员，制作可持续运营及移交路线图，并在部署后提供 60 至 90 天支持。招聘公告于 2025 年 8 月截止。已查阅的资料没有确认谁获聘、这些工作何时交付，或后续支持期是否已经开始。

APNIC 于 2026 年 10 月 16 日称 ANC 正在建设 TL-IXP，计划包含路由服务器、DNS 根镜像、监测和 RPKI 验证。APNIC 参与过相关技术工作，因此这是一条有价值的进度信息，但它不是独立验收报告。互联网协会 Pulse 当时没有列出一个符合其标准的东帝汶活跃 IXP；其判断依据是 PeeringDB 中看似活跃且至少列有三个自治系统的条目。这反映目录可见度，不足以证明当地不存在设施或私有互联。

路由服务器也不能单独证明用户流量走过交换点。RFC 7947 说明，路由服务器负责分发路由信息，不直接转发数据包。会话数、已接受路由数反映控制平面上的参与，并不显示实际流量、路径本地性、时延变化或故障时的韧性。

移交记录应回答哪些问题

有用的公开移交文件应说明运营机构是谁，谁负责日常维护、故障处置、软件升级和设备更换；还应列出外部支持期限、故障升级渠道、经费来源，以及每项任务何时交由本地团队承担。如果 ANC、运营商和技术伙伴共同负责，就要把决策边界写清楚。

这不要求公布敏感配置。定期服务报告可以分别列出成员、路由服务器会话、接受的路由、流量及其测量时段，还可以报告可用率、计划维护和故障恢复时间。每项数字都需要方法和分母：路由条目不等于流量，单个会话不等于实际使用，某一天的仪表盘也不能证明服务长期连续。

项目历史同样值得解释。公开记录可以说明 2016 年试点、2024 年有限的运营观察以及新一轮招标之间的关系，而不臆测早期项目为何似乎停止。如果 TL-IXP 是前项目的继任者，可以标明这项决定及其日期；如果是另一个服务，也可以交代哪些经验或资产被沿用。这样的时间线关系到过去的承诺由谁回应、下一次维修由谁决定。

风险仍是条件性的：如果部署支持结束时没有明确的本地维护人、资金和升级渠道，常见故障与软件更新可能再次依靠临时外援。若责任得到正式分配并定期复查，持续运行就更有制度基础，即使此时还不能宣称用户成本下降。

东帝汶不必公开所有网络配置，也不必先承诺一个全国性效益数字。它需要的是一份可核验的验收记录、明确的运营负责人，以及周期性服务证据。出现这些资料之前，“正在建设”是最准确的公开表述。

来源