摘要

  • RFC 1503 设想让应用把一段文字交给“上下文解析器”，用户无需逐项指定 SNMPv2 的 party 和 context。
  • 对未配置的地址或主机名，解析器可临时建一对 noAuth/noPriv party、一个 context 和只允许 get、get-next、get-bulk 的 ACL；实际操作还要满足应用提出的安全条件。

如果只是想查一台路由器，为什么要先学会填写一套 SNMPv2 身份表？Keith McCloghrie 与 Marshall Rose 在 1993 年 8 月给出了一个答案：让管理器自己查表、补表。那份备忘录把“上下文解析器”放在管理应用和本地 party 数据库之间。操作员交出字符串，解析器承担选择工作。

它并非一上来就给陌生设备开门。第一步是找管理员预设的精确文本句柄。示例中的 router.xyz.com-public 指向公开查询上下文；只输入 router.xyz.com，则可能同时选中 -public 和 -all 两个上下文。后者在示例里有带认证的 set 权限，前者只允许查询。输入变短，候选反而变多；最终能用哪条 ACL，还要看请求的操作和安全要求。

本地表没有匹配项时，解析器才把字符串当成 IP 地址或可解析的域名。一个地址对应临时的 noAuth/noPriv party 配对、context 和查询 ACL；域名解析出多个地址，就分别建立多套。命名遵循较早 Party MIB 中的 initialPartyId 与 initialContextId 约定。这里生成的是管理器自己的记录，并非远端设备出具的身份凭据。

同一个入口还能识别斜杠：主机名或地址后面的字符成为 SNMPv1 community string。解析器据此再建一个临时查询上下文。所谓方便，不只是替用户找到了主机，还替他解释了输入，并选择了协议路径。

真正发请求时，应用提交上下文句柄和最低安全要求。管理器找允许该操作且满足要求的 ACL，优先选合适的 SNMPv2 项；若要求认证而没有合格项，请求就停下来。主机名只是索引的起点，授权发生在后面的规则选择。

RFC Editor 的记录 将 RFC 1503 列为 Informational。文中是建议算法，没有具名产品的部署结果；安全章节只写了一句，安全问题不在此讨论。它留下的历史价值很具体：界面每删去一个难填的参数，管理器就必须在别处替人作一次选择。那张本地表，才是快捷按钮背后的账本。