摘要

  • AFRINIC 仍公开的《服务水平承诺》标注为 2015 年 11 月第一版，承诺运营团队在两个工作日内，对所有已提交给它的询问作出有效响应；紧随其后的表格列出十二个具名队列。
  • 另一张支持邮件表列出十六类专业入口，而主要联系页把选择压缩为 Registry Queries、Technical Support、Media & Press 三类邮箱，并链接到没有可见服务类别选项的通用表单。
  • 这组页面不能证明邮件曾经丢失、路由错误或超期。它能证明的是：公开材料没有逐项说明每个入口进入哪个承诺队列、何时开始计时，以及转交时是否保留第一次收件时间。
  • 合理的修补不是删掉专业邮箱或复杂化表单，而是增加一张有版本和生效日期的入口对照表，把事项、地址、队列、计时事件、转交规则、备用渠道与升级路径连起来。

三张网页，一件普通小事

设想一名会员要修改反向 DNS。他没有遭遇故障，也没有准备投诉，只想把材料送到 AFRINIC 承诺处理的正确位置。

第一张页面说，这类事项属于 Service support。第二张页面使用 Account Info & Services，并给出专门邮箱；同一页还另列 DNS and DNSSEC、DB-help。第三张页面只让访问者在 Registry Queries 与 Technical Support 之间判断，或者填写一张通用联系表。

任何一张单独看都说得通。合在一起，问题便从“邮箱该写哪个”变成“两个工作日从哪一步开始”。

AFRINIC 的服务水平承诺把时间写得很明确。页面自称“Version 1 | November 2015”，第 3.2 节说，运营团队承诺在两个工作日内，对所有已提交给它的询问作出有效响应。附录又把响应时间与解决时间分开：前者是 AFRINIC 对问题作出回应有多快，后者则从问题登记持续到完全解决。

这种区分值得保留。新增地址资源的申请可能需要补件，账单争议可能需要核账，路由安全事项也未必能在两天内收尾。首次响应的意义，是确认收件、说明归属、列出下一步；它不该被包装成问题已经解决。

可是，只要请求要从宽入口转进专门队列，两个定义之间就多出一段没有公开说明的路程。是邮件到达公开邮箱时起算，还是工单建立时？是通用表单提交时，还是专业团队接手时？如果分类改了，原始时间是否随工单一起移动？

服务承诺里的十二个队列

承诺页提供的不是一句孤立口号。两日响应的下面有一张 Queue 表，包含十二个非空类别：如何成为会员、会员申请评估、Hostmaster、Billing、Service support、服务基础设施维护、RPKI 支持、DNS 与 DNSSEC 支持、Routing Registry、网站信息、投诉报告和投诉升级。

部分边界写得相当具体。Hostmaster 接受额外资源请求及 IP 资源管理的一般问题。Service support 覆盖反向 DNS、BPKI 证书、MyAFRINIC、Whois 数据库以及相关对象的创建和修改错误。RPKI、DNS、路由注册各有一行。

因此，这十二个名称不只是旧通讯录的栏目。它们位于响应承诺的结构内部，构成读者理解承诺范围的公开分类。一个人自然会认为，自己的请求需要落到其中某一格，才知道应以什么方式观察两日时钟。

投诉部分更清楚。页面说，以电话或邮件收到投诉后，AFRINIC 管理层将在两个工作日内响应，毛里求斯公共假日不计。如果投诉没有得到令来信者满意的解决，可以发送升级邮件，说明希望升级，并提供包括服务工单号在内的有用信息。升级后的投诉也有两个工作日内响应的表述。

这不等于承诺支持投诉人的主张，也不等于两天内结案。它至少勾勒了一条连续链路：服务请求产生工单，工单可进入投诉，投诉可以升级。要让这条链路真正可审计，当前入口、工单号和最初收件时间就不能在页面之间断开。

支持目录里的十六种专业分工

AFRINIC 的支持邮件与邮件列表页面提供第二套分类。它先解释为何要分设邮箱：不同请求需要不同专业知识，区分入口是为了保证询问不被忽略。这套理由很扎实。

页面列出十六类：Hostmaster/IP Resources、Billing、Account Info & Services、Routing Registry、DB-help、Prospective Members、Training、Outage、Fellowship、Fellowship Alumni、General、Escalation、RPKI、DNS and DNSSEC、Data Protection，以及 IT security/Responsible disclosure。

有些对应关系一眼可见。Hostmaster/IP Resources 大概对应 Hostmaster；Account Info & Services 与 Service support 的范围相近；Outage 与 Service Infrastructure Maintenance 可能前后相接；RPKI、DNS 和 Routing Registry 的名称也很接近。

但“很像”不能替代正式映射。承诺表把“如何成为会员”与“会员申请评估”分为两队，支持目录只有 Prospective Members 这一名称。承诺表列 Complaint report 和 Complaint escalation，目录列 Escalation，却没有同名的初次投诉行。网站信息只出现在前者；培训、奖学金、数据保护和负责任披露则只在后者成为显式类别。

这些差异完全可能有合理原因。一个邮箱可以是别名；两个页面标签可以进入同一后台队列；工作人员可以重新分类，又不改变原始到达时间。本文没有证据说明它们是不同系统，更没有证据说明其中一个地址失效。

真正欠缺的，是一张公开说明上述合理关系的表。没有它，使用者无法分辨：名称变化是同义改写、前端合并、队列拆分，还是不同年代页面留下的分类。

联系首页只留下三条宽路

多数访问者首先遇到的，可能是Contact Us 页面。其中 Support Emails 卡片只列出三个具名去向：Registry Queries、Technical Support 和 Media & Press。

把十六个专业名词收成三类，并不必然是倒退。刚开始申请会员的人未必知道自己的材料是在“如何加入”还是“申请评估”阶段。处理 BGP 路由注册的工程师也可能需要先判断问题属于 IRR、Whois 还是其他支持。宽入口让人先把问题说清楚，而不是先猜组织内部语言。

联系页还链接到 AFRINIC 的通用联系表单。表单要求填写姓名、电子邮箱、主题和正文，另有同意及反垃圾检查。页面上没有服务类型下拉框，也没有把表单对应到十二个承诺队列中的某一项。

主题字段可能已经足够。熟练的工作人员可以读完标题后正确分派；服务器也可能附加来信者看不到的路由数据。本文没有发送测试消息，没有登录会员账户，也没有接触 AFRINIC 的工单系统，所以不能评判实际分流效果。

能够确认的边界是：来信者在提交时看不到一个公开规则，说明这张表进入哪个计时队列。如果后来从 Technical Support 转往 Billing，也看不到第一次提交时间是否被沿用。页面说团队会“shortly”回复，但这个词不是服务承诺中的正式时间单位。

真正容易产生分歧的，是交接

如果来信者从一开始就选中专业邮箱，三个页面的差别也许不会暴露。交接才是控制问题的中心。

假设一封账单邮件先发到 Technical Support。通用支持很快确认，随后交给 Billing。技术支持可以从首次到达统计响应；账单团队也可以从内部接手统计工作。会员则从点击发送开始计算。三方都可能忠实记录，却记录了三个不同事件。

投诉链路更敏感。服务承诺要求升级时带上工单号，但联系首页没有“投诉报告”这一入口。来信者先用通用表单，再使用支持目录中的 Escalation 地址时，两个动作是否自动关联？新工单号是否引用旧号？升级时钟从投诉收件还是从升级邮件开始？页面没有给出统一说明。

不能因为没有说明，就断言系统把时钟归零。严谨的说法是：外部无法验证时钟是否延续。这既限制会员举证，也限制 AFRINIC 证明自己达标。

一张入口对照表就够了

修补这处空白不需要新建门户。AFRINIC 可以发布一张短小、可下载、有版本的表。

每行先用来信者的语言描述事项：成为会员、追加 IPv4 或 IPv6 资源、查询账单、更新账户、修改 Whois、维护反向 DNS、使用 IRR、处理 RPKI、报告服务中断、提出投诉、升级投诉、行使数据权利、披露安全漏洞。旁边列出当前公开邮箱或表单，以及承诺页采用的队列名称。

时间字段需要最明确：哪一个事件算正式收件；自动回执是否确认这个事件；适用哪一个工作日历；转交或重新分类是否保留首次时间；首次响应目标是什么；解决状态用哪个独立指标。这样，快速回复与彻底解决就不会被混成一个成绩。

表中还应有备用路线。如果专业邮箱拒收，等价入口是哪一个？表单不可用时，可否转发至宽口径邮箱并保留时间？服务请求何时变为投诉，投诉怎样升级，工单号如何贯穿？

最后写明负责角色、生效日期、版本号和变更记录。负责角色可以是部门或职能，不必公开个人姓名。地址调整也不必冻结；只要每次调整留下“旧入口—新入口—生效日—时钟处理”的收据。

这张表不需要暴露来信正文、会员资源、内部邮件规则、值班表或安全处置细节。它公开的是制度接口：公众完成发送动作后，AFRINIC 从哪一步承担可计时的响应责任。

公开统计可以很克制

有了稳定分类，还可以发布按月汇总：每类收到多少请求，多少发生转交，多少在目标内首次响应，仍未解决的存量有多少，分别落在哪些时长区间。投诉与升级只需报告数量和分布。

低量、安全或隐私事项应合并或省略，避免通过数字识别个案。无需公开 IP 资源、账单金额、漏洞内容或人员身份。统计的作用只是检验：公开入口与被计量队列是否是同一个服务对象。

也不要只给一个平均数。大多数请求很快回复，少数老工单仍可长期等待；如果转交会重开计时，达标率也可能很好看。先固定首次收件时间和转交规则，再讨论均值与比例，才有意义。

这类数据同样帮助 AFRINIC。转交率高，可能说明页面标签让人困惑；某一类老工单集中，说明资源配置问题；投诉常在交接后发生，说明缺口可能是沟通，而非技术能力。

证据没有说什么

四张一手页面没有展示任何丢失、忽略、错分或超期的请求。本文没有测试邮箱或表单，没有访问内部系统，也没有找到实际受影响会员。宽口径邮箱可能始终准确分流，通用表单也可能稳定地产生工单和回执。

“2015 年第一版”也不能自动等同于失效。页面在取证时仍公开可访问。服务器显示的修改时间可能只是网站部署，不是实质审查日期。可确认的问题只是：公开分类之间没有一张带版本的对应关系。

最后，两日承诺说的是响应，不是解决。本文建议确定计时起点、保留交接时间，绝不是把所有复杂事项改写成两日内必须结案。

来源