摘要

  • RFC 9900 是 IETF Proposed Standard，只撤销已识别的端口号码绑定：TCP 和 UDP 831 用于 NETCONF over BEEP，832 和 833 用于 NETCONF over SOAP 变体。
  • 服务名 netconf-beep、netconfsoaphttp 和 netconfsoapbeep 仍保留；被撤销的号码在 RFC 6335 的程序下标为 Reserved，并不是立即可以任意使用的号码。
  • RFC 4743 与 RFC 4744 已为 Historic。RFC 9900 的证据边界是：这些分配所支持的协议没有已知实现或生产部署；它没有声称所有 NETCONF 都已过时。

RFC 9900 是一次注册表维护动作，不是新协议，也不提出新的运行、可管理性或安全要求。它移除的是号码与旧传输之间的分配关系。具体而言，原来与 NETCONF over BEEP 相关的 TCP/UDP 831，以及与 NETCONF over SOAP 变体相关的 TCP/UDP 832、833，被从有效的端口分配中撤下。RFC 4743《Using NETCONF over SOAP》和 RFC 4744《Using the NETCONF Protocol over BEEP》的状态是 Historic，这为重新审视这些历史绑定提供了背景，但不能扩展成“NETCONF 整体过时”的结论。

RFC 6335 把端口号码视为注册表中更稀缺的资源，而服务名的耗尽风险低得多。因此，撤销端口分配后，服务名可以继续存在。这样，名称仍能表达历史上的服务语义，旧文档、服务数据库和名称驱动的发现逻辑也不会因为号码归还而失去语义连续性。RFC 9900 还在 831、832、833 的注册表条目上保留注记，说明这些号码过去曾分配给相关 NETCONF 传输，并由 RFC 9900 释放。

“释放”也不等于“立即空闲”。RFC 6335 要求被撤销的端口标记为 Reserved，并规定在相关范围内其他可用端口都已分配之前，不应重新分配该号码。RFC 9900 没有宣布这三个号码何时会分配给新服务，也没有给出资源节省的数量化测量。运营者不应把注册表动作解读为任意改用、抢先复用或既定的重新分配计划。

RFC 9900 对运营者的要求很窄：如果配置仍把已释放的号码与 netconf-beep 或 netconfsoaphttp 联系起来，应重新评估这些配置。它没有规定全网审计周期，也没有新增其他运维或可管理性要求。RFC 9900 同样没有撤销 NETCONF over SSH 的 830、NETCONF Call Home 的 4334，或 NETCONF over TLS 的 6513；这些不在本次撤销范围内。

核验夹具

  1. 对注册表快照核对 831、832、833：号码应显示历史说明和 Reserved 语义，而不应被记录为本次 RFC 重新分配给某个新服务。
  2. 在服务文件、配置管理库、访问控制列表、监控规则和旧架构图中逐字搜索 831、832、833，同时搜索 netconf-beep、netconfsoaphttp、netconfsoapbeep。
  3. 分别确认 830、4334、6513 的 NETCONF 条目没有被这次动作误删；这只是范围核验，不代表这些传输应被改变。
  4. 将 RFC 9900 的原文与 RFC 6335 第 8.2 节、RFC 4743 和 RFC 4744 的状态记录并列保存，避免把号码撤销误写成服务名删除。

运营者决策路径

先确认发现的是字面号码还是服务名；再确定该引用是否仍被实际配置、过滤器或文档依赖。若只是历史资料，保留上下文并标记其历史性质；若仍有配置关联，则由配置所有者评估移除或改正引用，但不要把 Reserved 号码改作任意新用途。最后核对注册表注记、服务名和仍在范围外的 NETCONF 端口，并记录生命周期负责人。这里的“字面号码盘点”“名称优先发现”“配置漂移”和“生命周期归属”是 Theo March 的分析，不是 RFC 9900 规定的额外义务。

来源