摘要

  • RFC 8808 允许设备支持 factory-reset，却不支持可供程序读取的 factory-default 数据存储；操作能力与事前可见性不是同一个承诺。
  • 默认配置可能取代维持现有管理连接的设置。设备可以保留出厂时植入的身份材料，同时失去运行期间形成的凭证、配置和记录。
  • 规范明确要求所有者不得依靠这一重置来保证数据无法被取证恢复，或据此认定符合某种数据清理标准。恢复配置、恢复控制与证明擦除，需要不同证据。

先问恢复到哪里，再问是否支持恢复

一份设备清单写着“支持恢复出厂设置”，通常会被读成一种安全余地：实在修不好，还能回到原点。但这个原点是谁定义的？它包含哪些地址、管理服务和接入条件？采购时认识的原点，是否仍对应现在这台设备？一句功能支持，并没有同时回答这些问题。

RFC 8808 留下了一处很有分量的选择空间。设备可以提供恢复出厂设置的远程过程调用，却不提供保存默认配置、供程序查询的数据存储。规范直接说明，后者缺失会消除程序化确定默认配置的能力。换言之，控制器可能拿到了按钮，却没有通过同一套管理机制查看按钮目的地的能力。

这不是看到功能不全就能认定的违规。factory-default 数据存储本来就是可选项。反过来，如果设备支持它，就必须把它列入 YANG 库的数据存储清单。支持与不支持是两种可以区分的事实，不能在资产表里都压缩成“重置：是”。

没有可读的数据存储，也不意味着厂商不可能提供其他说明。纸面资料、离线文件或专门的技术说明，都可能补充信息。问题在于是否存在、覆盖多少、是否适用于当前设备，而不在于先假定厂商完全不透明或完全可靠。规范留下的空白，需要具体证据填上。

因此，重置决策的第一步并不是点击确认，而是确定将要接受什么状态。这是一种从协议边界推导出的管理问题，不是针对某个产品的测评结论。标准可以让不同设备接受同一种操作，不能仅凭操作名称让它们拥有相同的恢复条件。

出厂状态不是把一切变成空白

factory-reset 会把所有受支持的常规可读写配置数据存储恢复为默认内容。running 在这个范围内，startup 和 candidate 在得到支持时也在范围内。规范并没有要求设备为了重置而创建本来不存在的数据存储，更没有说这些存储重置后都必须为空。

只读数据存储从其他数据存储取得内容。动态配置数据存储中的数据必须被丢弃。operational 数据存储则必须反映应用默认配置后设备的实际运行状态。这几条要求分别处理配置输入、动态数据和运行结果，不能被一句“全部恢复正常”代替。

尤其是运行结果。一份默认配置文件能够证明预期安装什么，不能单独证明设备已经取得可用地址、管理服务已经响应，或者外部依赖已经恢复。预期状态可以在文档中检查，实际状态仍需要观察。把前者复制进验收表，并不会自动产生后者的证据。

可选的 factory-default 存储包含配置节点，其模式必须与常规配置数据存储相同，或构成后者的子集。默认内容由设备厂商定义，并且必须跨设备重启保留。这里的“保留”很容易被误读成“任何时候都不会变”。

规范实际说的是，服务器以依赖实现的方式设置内容；普通 NETCONF、RESTCONF、命令行等管理操作不能修改它，除非设备提供专门、特定的操作。这个约束不能推出不同产品、不同软件版本或专门修改机制下的内容永远一致。持久性解决的是重启后的延续，不是替所有未来变化背书。

由此产生的核对工作并不华丽，却很关键。某次保存的默认配置，对应哪一套软件、哪些模块和功能？后来替换的设备是否仍处于同样条件？这些不是已被本文观察到的厂商变化，而是判断一份资料还能否支持下一次决策时必须弄清的适用范围。

被删掉的恰好是当前管理入口

设想一台远端设备，当前地址和管理参数保存在它正在使用的配置中。管理员决定放弃这套配置，调用恢复出厂设置。默认值替换了原来的参数，原有管理连接随之失去作用。整个过程并不需要重置功能出错；它可能正是按要求移除了连接所依赖的配置。

这是依据规范构造的说明场景，不是一宗已发生事故的报道。RFC 8808 本身明确提醒：立即重置可读写数据存储后，设备可能不再能够作为网络主机被访问。它要求操作者理解具体厂商设备在操作执行后的行为。失联不是只能在事后调查的意外，也可能是事前就应纳入判断的后果。

“它会重启”不能替代这份判断。规范允许操作触发节点或部分软件进程重启，也建议实现者重启设备并完成配置，或重启自举所需的进程。但允许和建议都不是所有设备都会执行同一种重启流程的无条件保证。

从这些文字中，同样推不出统一的恢复时限、响应与完成之间的普遍顺序，或自动回到旧配置的通用保护机制。某个产品如果另有这样的能力，应当拿出该产品的证据，不能把它当成 RFC 名称自带的附加承诺。

真正被分开的，是“摆脱坏配置”和“重新控制设备”两件事。前者可能清除后者原来依赖的条件。在现场能够轻易接入的设备，与只能远程到达的设备，面对同一操作未必承担同一种代价。本文没有测量任何一种场景的成本，但规范已经足以说明，不能默认这项成本不存在。

默认拒绝，也不是自动提供救援通道

factory-reset 的 YANG 定义带有 nacm:default-deny-all，说明它属于敏感控制。这个名称看起来很绝对，但不能被理解成普通用户永远无法获准执行。具体的授权过程由 RFC 8341 描述。

在 NACM 启用时，匹配的显式访问规则可以允许非恢复会话用户执行操作。默认拒绝是在前面的规则处理没有给出许可时发挥作用。关闭 NACM，或把会话识别为恢复会话，则会改变这条检查路径。忽略这些条件，会把一项默认策略写成不存在例外的绝对封锁。

恢复会话本身也是可选机制。它如何配置、如何被识别，取决于具体实现，超出 RFC 8341 的定义范围。规范里有这个概念，不证明购买的设备一定提供它，更不证明负责人员已经掌握访问它所需的条件。

即便确有恢复角色，仍需一条能到达它的路径。权限不会凭空修复消失的地址，不会建立物理连接，也不会保证凭证在重置后仍能使用。能获准操作、知道下一状态、能够到达下一状态，是三份不同的能力证明。

安全传输也不能把三者合并。加密管理连接保护的是通信过程，不会自动授予重置权限；授予权限又不会保住承载连接的配置。明确每项控制的边界，是避免虚假保证，而不是贬低安全控制的价值。

离线文件可以补上视野，不能替代验收

RFC 9195 提供了一种不依赖在线服务器的资料形式：使用 XML 或 JSON 表达 YANG 实例数据。它明确把记录出厂默认配置列为用途之一，并引用 RFC 8808。设备不可达时，相关说明未必只能随设备一起消失。

这给买方和供应方一个更具体的讨论对象。与其只问是否支持“标准恢复”，不如确定一份数据集描述什么、适用于哪些模块修订、支持功能和偏离项。RFC 9195 的内容模式概念包括这些维度。它们把“同样的设备”拆成可核对的条件。

不过，该文件同样强调时间边界。实例数据集是在某个时点形成的。如果底层数据变化而文件没有更新，文件便不再代表当前数据。妥善归档能够保住过去的一份陈述，不能让它自然升级成今天的正确答案。

格式还允许部分数据集。在这种情况下，一些原本适用的约束可以不满足；配置和运行状态数据也可以混合出现。因此，文件能被解析，不等于它是完整、可直接部署的配置，更不等于它已被某台设备实际采用。

局部说明仍然有用。它可能准确回答一个管理参数的问题，同时把其他行为留在范围之外。只要边界清楚，这比笼统保证更有价值。风险出现在把一份有限说明升级成完整恢复方案，却没有补上相应证据的时候。

还要保留规范措辞的强度。关于内容模式、描述和变化方式的若干元数据要求属于建议，并非所有资料都必须内嵌全部细节。RFC 9195 也没有强制每家厂商向每位买方交付完整默认配置档案。采购合同可以提出更高要求，但那是新的商业承诺，不是文件格式已经替买方取得的权利。

设备记得自己是谁，不代表保住了运营历史

RFC 8808 还要求把非易失性存储恢复到出厂状态。根据系统不同，这可能涉及删除动态生成的文件，包括运行期间形成的密钥、证书、日志和临时文件。出厂镜像中已有的密码学材料会保留，规范以初始设备身份 IDevID 为例。

这会形成一种不对称。设备仍可携带出厂身份，运行期间积累的管理资料和证据却可能不再可用。确认“还是这台设备”，并不证明旧的管理凭证还在、原有服务配置还在，或故障之前的日志还能调取。

在事故调查中，这个差别尤其重要。重新取得管理入口不会自动重建没有提前保留的日志。资产身份跨越了重置，事件证据不一定跟着跨过去。用同一个资产编号串起前后记录，也不能填补中间缺失的事实。

反过来，从普通管理接口中看不到某份数据，不证明它已经无法被恢复。RFC 8808 建议尽可能彻底删除安全敏感材料，但同时明确要求所有者不得依赖出厂重置来保证抵御取证恢复，或符合某种数据清理标准。

这不是宣称所有产品都留下可恢复秘密，而是限定什么证据能够支持什么结论。设备退役若要求特定的擦除保证，就需要与该保证对应的证据；不能因为维护记录写着“已重置”，便借用它完成另一种验收。

维修与处置因此可以用到同一操作，却有不同的终点。维修可能关心服务和控制权是否恢复；处置可能关心敏感材料的归宿。操作对两者都有关系，不代表它独自完成了任何一项工作的全部要求。

新近勘误不等于新近能力

RFC 8808 的勘误记录 中，9033 是 2026 年 7 月 23 日报告并验证的编辑性勘误，补上的是该文件更新 RFC 8342 的标记。它改变文档关系的说明，不是新增重置功能，也不是加强数据擦除保证。

时间靠近今天，不代表技术能力刚刚出现。报告者关于实现者认知的评论，也不能被当作独立测得的部署普及率。对标准新闻的判断，要把报告日期、修正类别和实际修改内容分开。

配套检查同样需要区分状态。RFC 8341 的技术勘误 8302 涉及 RESTCONF 事件流映射，状态仍为已报告；6493 涉及标识符前缀，已经被拒绝。两者都不能当成本篇授权结论的已接受修改。RFC 9195 的查询 在本次研究时没有返回匹配勘误，这只是查询时点的结果。

Lu Heng 在讨论互联网治理代理问题的文章中，把控制与后果之间的关系置于核心。本文借用的是分析视角：谁决定默认值、谁允许重置、谁承担恢复工作的代价。它不是 Lu Heng 专门评述这份协议的证据。

他在说明 BTW 存在理由的文章中强调描述结构，而不是替某一方倡议。这里的结构，是一种可能移除自身管理条件的操作，以及由不同参与者掌握的知识、权限和恢复资源。没有必要虚构恶意，问题也足够清楚。

这些来源不提供当代产品实测、恢复成功率、重启耗时、攻击发生率或具体事故。本研究没有执行任何设备重置或网络探测。能够成立的结论更窄：出厂状态是一套预设配置，不是自动交还控制权的承诺，更不是设备已经忘记过去的证明。