摘要

  • SNMPv2 party 的配置位置由传输域和地址组成，但 party 还拥有独立身份、认证、隐私协议与操作边界，地址不是主体本身。
  • 发起新请求时，实体查询本地数据库中的目标位置；生成响应时，却使用对应请求实际到达的域与地址，即使它们和记录不一致。
  • 这条例外维持一次会话的回程，不自动更新名录，也不替代身份验证、上下文、访问决策或结果观察。

配置记录负责打开第一扇门

RFC 1445 把 party 定义成受行政限制的虚拟执行环境。它有唯一身份、逻辑网络位置、认证协议、隐私协议，以及可执行操作的范围。逻辑位置又拆成 partyTDomain 与 partyTAddress。

每个实体维护三类本地事实：已知 party、已知管理资源和访问策略。发起请求时，它先写明源 party、目标 party、上下文和操作，再读取双方的认证与隐私参数，最后把序列化消息发往目标的配置位置。

在没有新观测之前，配置表给系统一个起点。它不能证明对方此刻仍在那里，也不能证明那个地址上的进程会接受这次身份、上下文和操作。

RFC 1445 档案页 如今把它列为 Historic。party 模型不应被包装成当前部署建议；这里要保存的是它对证据边界的处理。

请求到达后还要经过多道判断

接收方首先检查外层编码和本地目标 party。内外目标必须一致，消息声明的源 party 也必须存在于本地数据库。随后才按配置协议判断认证，查找上下文，并把目标、主体、资源与操作类别放进 ACL。

只有全部通过，实体才会操作本地 MIB view，或者经代理关系访问远端资源。历史配置 noAuth 会按当时模型把消息视为真实，但它没有让网络源地址获得密码学身份。

因此，请求来自哪里、消息自称是谁、认证是否成立、该身份能否访问此上下文，是四条相连但不可互换的记录。

响应选择了刚刚发生的路径

生成响应时，规范交换原请求的源与目标 party，保留上下文，并把操作结果装入 PDU。然后它修改普通发送流程的最后一步：使用对应请求实际来源的传输域和地址，即使它们不同于本地 party 数据库。

这不是把“现场数据”普遍置于配置之上，而是让一次响应属于引发它的那次请求。系统不用重新猜测管理站位置，也不会因为目录滞后把回复发往另一个出口。

运行事实胜出的范围非常窄：只控制这次回复的目的坐标。

来路没有被自动写成新地址

RFC 1445 的响应步骤没有包含“更新 party 数据库”。观测到的来源可以说明配置过期、另一接口、代理边界或其他情况；规范并未替真实网络挑选唯一原因。

如果软件看到一次成功回程就覆盖配置，它会把数据面观察升级成管理决策。那既抹掉了分歧，也绕过了谁有权改变持久记录的问题。

回信发出不等于对方收到；对方收到不等于配置已经修正；Set 返回成功也不等于重启后仍然存在，更不等于外部网络效果已经发生。每一步都需要自己的证据。

可写表格拥有根级影响

RFC 1447 的 Party MIB 暴露 party、上下文、ACL 和 view 表。文档明确警告：同时掌握四者的完整访问权，等同于 root，因为管理器可以配置具有任意能力的 party。

所以，修改 party 地址绝非无害的“同步”。位置与密钥、隐私、上下文、权限共同定义管理关系。一个权限较低的管理器可以维护自己的 party，却不一定能够扩大或缩小其能力。

协议允许回程临时适应实际路径，同时把永久配置变更留在受控表面。这正是运行连续性与治理权限的分界。

后来的架构继续保留请求状态

RFC 3411 后来把分发、消息处理、安全、访问控制、应用与传输分成不同子系统。RFC 3412 则让入站请求产生 stateReference，供潜在响应使用。

响应准备从这份状态得到目标传输域和地址，再由 dispatcher 发回请求发起者。SNMPv3 缓存的响应状态包含传输坐标，并限制普通响应逻辑随意覆盖。

这不能证明所有实现都合规，也不能把后来的设计倒写成 1993 年的意图。它只显示一条延续的架构边界：通用目的地目录和某次请求的会话状态不是同一个对象。

来源