摘要

  • IESG于10月8日批准DNS-SD Extensions工作组章程修订版02，将宽泛目标拆成具体的协议与文档任务。
  • 章程授权工作组研究单链路和多链路服务发现，但不包括通用DNS协议修改，也不包括整合其他零配置命名协议。

DNS-SD新章程把工作场景扩展到单链路和多链路，同时更清楚地列出工作组可以承担的任务。互联网工程指导组（IESG）于10月8日批准修订版02。这项决定授权的是一组标准制定和技术说明工作；它既没有批准新协议，也不能证明设备已经能够在不同网络之间可靠发现服务。

对照两版已批准章程，可以看出措辞发生了变化。旧版把目标描述为开发“扩展且可扩展的DNS-SD解决方案”，并要求记录本地零配置命名与全球DNS共存时遇到的问题，但不负责解决这些问题。新版则列出更具体的事项：把通过服务注册协议（SRP）注册的名称发布到多播DNS（mDNS）；改进DNS-SD或mDNS的效率、可用性或效果；以及定义如何解决或避免同一名称的竞争性更新。

技术背景解释了为何要拆开这些事项。DNS-Based Service Discovery和mDNS广泛用于家庭或办公室等单一链路，但mDNS不能发现远端链路上的服务。SRP允许服务器通过单播DNS注册所提供的服务；发现代理可以将从mDNS获知的服务加入单播DNS命名空间。这些组件为扩大服务发现范围提供了条件，也带来名称、更新、可达性与可见性问题。

章程还区分了不同的成果类型。标准轨道文档可以规定如何将SRP注册名称发布到mDNS、如何改进发现机制，以及如何处理名称冲突。信息性或最佳实践文档可以说明如何组合协议组件，使mDNS客户端和SRP客户端都能访问同一个DNS-SD服务。章程要求工作组考虑RFC 8882所述的隐私与安全要求，并在需要时与SNAC、其他DNS工作组和外部机构协调。

排除项与任务清单同样重要。工作组无权负责DNS-SD与其他零配置服务或命名协议的整合，例如Universal Plug and Play或Link-Local Multicast Name Resolution；通用DNS协议更新也不在范围内。章程通过说明哪些问题归该组、哪些问题需要其他决策场所，让工作计划可以被检查，但章程本身不会解决技术问题。

对网络运营商和设备厂商而言，这是治理层面的早期信号，而不是部署里程碑。章程把兼容现有DNS-SD和mDNS部署称为“高度期望”，并未作出保证。接下来需要观察的是草案、审查记录，以及最终标准能否对应到获批任务。新授权并不证明跨链路互操作已完成、通用DNS已改变，或某项具体部署已作出安全决定。

来源