摘要

  • Peter Hessler 支持建立只整理出处的政策索引，并希望纳入 Database Working Group 的文档。
  • 他要求先单独记录已通过政策之间的定义冲突，再讨论是否修改文本。

政策索引看起来像整理文件。真正的难题是：两份文件对同一件事给出不同定义时，谁来说明它们的关系？

Remco van Mook 在 RIPE 93 Address Policy 工作组介绍了一个“新厨房”构想：按主题整理 RIPE 政策，让读者知道规则散落在哪里。他描述的现状是新旧文件并存、术语不一致，提案又常被两类意见夹住：有人嫌方案复杂，有人指出它漏掉了自己的边缘情形。两种批评都可能成立，提案便在“写全一点”和“简单一点”之间来回打转。

van Mook 提出的第一步很克制：索引只引用现有 RIPE 文档，不搬动政策条文，也不改写规则。它可以按 IPv4、IPv6、ASN、转让和特殊用途资源组织章节，日后再补充历史和运行背景。官方逐字稿记录的是讨论邀请，没有记载正式通过、负责人或交付日期。

Peter Hessler 以 RIPE Database Working Group 联合主席身份发言。他欢迎把数据库文档纳入索引，随后指出两项容易被混为一谈的工作：收集引用很简单；统一相互冲突的定义则会触及政策本身。他要求把冲突整理作为一个更早、单独可见的步骤。稍后他再次强调，归集文件与修正文句应当分开。

两者用途不同。索引回答“规则在哪里”；冲突清单回答“哪些条款对不上、下一步交给哪个工作组”。一旦编辑者决定哪段话优先，索引工作就变成了政策解释。

会场上，Tobias Fiebig 以 IPv6 最小分配规模为例，指出不同文件可能采用不同定义。逐字稿没有给出文件编号或具体条款；对照原文才能确认这究竟是直接冲突，还是需要解释的差异。

现行 RIPE-781 政策制定流程分为提案、讨论、审议和结论四阶段，要求过程开放、透明并以共识作决定；已通过政策写入 RIPE 文件。正式流程可以处理规则修订。准确的索引则让读者在提出修订前先找到正在生效的文本。

这条界线在会场上已经引起争论。van Mook 把索引描述为小步推进。Maynard Koch 提醒，即使后来只是“澄清”，也可能改变现有政策的应用；Gert Döring 则要求确认新措辞仍保留原意。争论的核心不只是文档如何摆放，而是谁能判断两份旧文本表达了同一个规则。

RIPE Database Working Group 的官方页面列出的职责涉及数据库变更、功能、分发和安全。把相关文档纳入索引会让地图更完整；把冲突单列，则让问题有明确去向，不必靠维护者在多份文件间悄悄统一措辞。

逐字稿没有为冲突清单指定负责人或期限。下一份有用的材料应保留原始引用、标出每组冲突的文件和章节，再把解释或修订交给相应流程。Hessler 划出的边界很清楚：索引负责标出地形，如何处理它揭示的问题，应由公开流程决定。

来源