摘要

  • RFC 1302 为 NIC 划出四项基本职责：提供信息、直接支持用户、维护其他 NIC 的转介信息、支持 NIC 协作基础设施。
  • NIC 应把询问负责到某种解决状态，但直接回答、转介信息源和协调 NOC 处理连通性问题是三类不同完成记录。
  • 时间戳、修订号和制作该资料的 NIC 让来源与新旧程度可以核查，却不会自动证明内容准确或问题已解决。

一封邮件只解决“从哪里开始”

RFC 1302 建议采用统一的 NIC@domain 地址。用户不必先知道复杂的机构分工，便能找到第一扇门。来信应得到人工回应，或得到一封保持更新、能按问题类别分流的自动回复。

这项安排降低了求助成本，却没有缩短事实链。邮箱可达，只证明入口工作；自动回复，只证明系统做出分类；给出另一个地址，只证明提出了一条路径。对方是否接收、资料是否适用、NOC 是否采取动作、用户目的是否恢复，都要另有记录。

RFC 要求 NIC 以 best effort 回答，并对询问负责，直到它“以某种方式”解决。随后列出的三种方式很重要：回答问题；把用户转到适当信息源；与 NOC 协调解决连通性故障。这里的解决首先是 NIC 对承接义务的完成，不是把三种外部结果压成一个绿色状态。

信息中心不等于运行中心

文档把 NIC 定义为提供信息、行政与程序支持的组织，把 NOC 定义为监督和维护网络日常运行的组织。一个机构可以同时承担两类工作，两者也必须紧密合作，但职能没有因此合并。

NIC 可以收集用户描述、查找文件、解释流程、找到技术联系人。它收到故障报告，并不等于有权修改网络。NOC 可以执行操作，却未必知道用户寻找的应用是否恢复。询问、诊断、授权、动作、网络观测与用户结果各自回答不同问题。

安全部分沿用了这条边界。NIC 应知道哪些团队负责安全事件，准备明确流程，并能联系响应中心、NOC 与用户。知道升级路线，不等于拥有事件指挥权；提出转介，也不证明真实事件已经处置。

不可能全知，所以要保存转介关系

RFC 1302 直言，任何一个 NIC 都不可能掌握互联网全部服务与资料的完整、最新信息。于是每个中心都要知道其他 NIC 及其专长，并通过 nic-profiles 数据库共享这张协作地图。

这不是中央知识库。某个 profile 说明“可能该问谁”，不证明目标仍有能力、愿意接单或拥有操作权。可靠的转介需要成对记录：发送方交出了什么，接收方是否接受。若只有发送方的关闭码，问题就可能在两套统计之间消失。

四项基本职责也保留地方差异：具体服务水平、人员、经费和实现方式由各 NIC 决定。共同最低规范使不同能力的中心能够协作，而不是假装它们规模相同、知识相同、权限相同。

资料放在这里，不代表由这里制作

NIC 可以把别处资料复制到本地供用户取用，可以把用户指向远端，也可以自行创作资料。RFC 只在第三种情形下明确说，制作资料的 NIC 对内容与准确性独自负责。可下载位置与制作主体并非天然一致。

每份资料应标出时间戳、修订号和制作它的 NIC，服务方还应保留源联系人。这些字段使用户能够比较版本、判断年龄、追问原始责任人。它们提供核查入口，却不替代核查：新日期可能附着错误内容，旧规范可能仍然有效，本地副本也可能在上游发布新版后失去时效。

RFC 1290 处理相邻问题：目录中的大多数项目只是通往最终信息的指针。RFC 1309 则说明统一的 X.500 视图可由分布式保管者、副本、链路和转介组成。本篇不重复它们；RFC 1302 的独有问题，是人在这些分布式表面之间求助时，谁负责不让问题失踪。

一年一次更新仍留下时间窗口

对个人资料库，RFC 建议披露收集目的、用途、不提供或撤回的后果、必填与选填字段、哪些内容公开、谁能更新，以及多久主动征求更新。资料涉及的人应知道公开状态，并有修改或撤回机会。

NIC 至少每年主动征求一次更新，并公开最后更新日期。年度动作是维护承诺，不是对其余 364 天的真实性担保。最后更新时间只使不确定性可见，不能把沉默解释为确认。

RFC 1261 提供了鲜明边界：SRI 向 GSI 移交 NIC 服务时，熟悉的联系与信息表面力求延续，但 WHOIS 主库五天不接受修改，所有登记动作暂停。入口可达、服务名称延续、权威写入可用，是三个独立状态。

来源

RFC 1302 描述的是 1992 年的服务模型，不证明今天存在某个 NIC、真实工单、成功转介、NOC 修复、准确数据库、安全事件处置或用户结果。