摘要

  • ARIN-2025-1称，所有Internet Service Provider都是Local Internet Registry，但并非所有LIR都是ISP。它拟议的LIR定义要求Internet Registry职能、RIR成员关系、接收号码资源分配以及面向客户、终端用户和基础设施的再分配。
  • 拟议ISP定义只要求向员工以外的对象提供互联网服务，例子包括连接、Web服务、机房托管、独立服务器、VPS和VPN。这些条件本身推导不出前述包含关系。
  • 可重放的解决办法不是让ARIN审查商业模式，而是为每次分类固定术语版本、资源生命周期、下游委派职能与适用条款，并逐项记录从ISP到LIR的文本和应用迁移。

同一家公司可以拿着两张不同的牌

ISP通常回答“这家公司向谁卖什么服务”。LIR回答的却是另一件事：“这家公司从哪里取得号码资源，又怎样把资源向下分发并登记”。传统接入运营商往往同时符合两种描述，所以两个缩写长期被当成同义词。

边界上的组织不会如此整齐。Web托管商可以完全使用上游供应商的地址；大学可以直接领取资源并在院系或关联用户之间分配，却不经营零售接入；大型企业也可能承担某种下游登记职能，但从不把ISP作为自己的商业身份。

NOG Alliance的独立政策追踪表把ARIN-2025-1列为Draft Policy，并将最近一次变更标为2026年8月13日。提案从一个真实问题出发：LIR已有定义，ISP却没有独立定义。问题陈述随即提出一个集合关系——按照含义和通常商业实践，所有ISP都是LIR，但不是所有LIR都是ISP。

“经常重合”与“必然包含”不是一回事。只要文本说“所有”，每个满足ISP定义的组织就必须同时满足LIR定义。熟悉的电信运营商全部落在交集里，不能替代这个逻辑条件。

社区完全可以选择这种包含结构。若要称为澄清，定义本身就应让陌生读者检验它，而不是要求读者知道ARIN平时如何用词。

LIR定义沿着资源链条展开

一份由独立站点保存的2026年3月PPML提案文本给LIR规定了连续动作：组织首先是Internet Registry，是某个RIR的成员，从该RIR取得互联网号码资源分配，再把这些资源分配给客户、终端用户与自身基础设施。

这些都是号码资源职能。取得分配形成生命周期事件；向下分配说明资源去向；登记分发结果维持可追溯性。草案列出的LIR例子也不限于电信企业，还包括大型企业、大学和ISP。

同一份存档还显示迁移范围：多个标题与规范条款会从ISP改成LIR，术语条款则称ISP是LIR的子集。这不是词汇表边注，而是把角色名称带过allocation、reassignment、利用率和下游客户义务。

存档只能证明当时传播了什么文字，不能赋予文字权威。追踪表也只证明后来出现了一个版本边界和流程状态。发布记录应同时保留两个事实：本文实际分析的文本，以及实施前必须全文复核的更新版本。

ISP定义沿着产品目录展开

拟议ISP定义转向商业活动。凡是向其他组织、客户或员工以外个人提供互联网服务的组织，都可以被称为ISP。非封闭例子包括连接服务、Web服务、colocation、独立服务器、virtual private server和virtual private network。

这句话没有要求组织本身是Internet Registry，没有要求它从RIR直接取得allocation，也没有要求RIR成员身份或面向客户的号码资源委派。只要对外提供清单中的某类服务，就能满足字面条件。

歧义也出现在一份由独立站点保存的PPML申请指南讨论中。一名参与者引述了把LIR简写成ISP的指南，也引述了“LIR通常是ISP”的定义，继而追问两类角色究竟相同、包含，还是直接allocation持有者可以选择。该存档只证明疑问被公开提出，不能替代员工对具体申请的判断。

这种分开原本很有价值。商业描述帮助申请人找到一扇门，资源条件决定申请人能不能通过。卖VPN不会凭空生成直接allocation；运营独立服务器也不自动证明企业登记了下游号码资源分发。

最初提案曾把ISP写成“一种LIR组织”。当前草案只说“一种组织”。删掉的几个词没有改变产品清单，却拿走了ISP集合通向LIR集合的明示桥梁。

缺的是一条可以验证的蕴含

用五个分析符号就能把问题说清楚。这不是ARIN术语，也不是数据库设计。

令IR(x)表示组织x分发互联网号码资源并登记分发；M(x)表示它拥有规则指定且带版本的RIR成员状态；A(x)表示它从该RIR取得allocation；D(x)表示它向下分配或委派号码资源；S(x)表示它向外部对象提供至少一种列明的互联网服务。

拟议LIR定义可以写成LIR(x) = IR(x) ∧ M(x) ∧ A(x) ∧ D(x)；拟议ISP定义则是ISP(x) = S(x)。

若要保证所有ISP都是LIR，文本还必须给出S(x) → IR(x) ∧ M(x) ∧ A(x) ∧ D(x)。当前定义没有这条蕴含。

这不等于证明ARIN在实际工作中错误分类。申请表、其他资格条款、员工提问与证据审查都可能补充信息。严格结论仅限于：读者无法只靠两份公开定义，推导出问题陈述声称的集合关系。

修复方案不止一种。ISP可以重新明确写成LIR的一种；规范性ISP可以限于实际承担合格下游分发职能的服务商；两个类别可以改为有交集但互不包含；也可以从决定资格的条款中移除ISP，只依据资源用途与委派事实选择路径。

哪一种更好属于社区决定。无论选择哪一种，都应让读者在文本中看见。

一个只用于测试定义的合成案例

假设一家不存在的企业向外部客户出售托管Web服务与VPN接入。它使用的全部地址来自上游供应商，没有任何RIR直接分配，也不作为Internet Registry向客户分配并登记号码资源。

这只是合成逻辑测试，不代表任何真实公司、ARIN申请或员工决定。

按照拟议ISP服务清单，这家企业满足S(x)。按照拟议LIR条件，它至少不满足A(x)与D(x)；取决于member of an RIR的具体含义，它也可能不满足M(x)。

市场把它叫作ISP没有问题。让它先阅读ISP申请指南也可能是最便利的导航，因为它需要判断未来的客户分配计划是否足以申请直接资源。但导航入口不是已经发生的分配事件，上游地址也不会因为商业标签变成RIR直发资源。

边界案例不需要常见。它只要落在定义文字允许的范围内，就足以暴露缺失条件。

资源职能与企业标签是两个坐标轴

RFC 7020把互联网号码注册系统描述成分层结构：registry向客户分配号码资源，LIR通常是ISP。“通常”表达高频关系，并没有把注册角色与所有出售互联网服务的企业定义成同一集合。

资源轴上可以有申请人、直接allocation持有者、下游分发者、end user和使用上游空间的运营者；服务轴上可以有连接、托管、colocation和VPN。分类可以同时查看两个轴，但必须写明哪一种组合触发规范角色。

PPML讨论中一份存档的替代定义把选择写得更直接：LIR与RFC 7020的注册系统相连，ISP的重要特征则是为客户消费并证明号码资源合理性。那只是参与者建议，不是已采用文本。它的诊断价值在于：一旦明确资源职能，缺失的桥梁只需一句话就能表达。

如果member of an RIR仍是LIR必要条件，文本还要说明具体关系和判断时点。商业服务不会凭含义创造该状态，资源关系也不应从市场称谓反推。

管理程序的历史始终区分角色

2000年发布的资料性文件RFC 2901曾根据组织如何取得和使用地址，把它们引向不同申请材料。它属于历史，不能证明ARIN当前要求；但它说明了一个长期分析事实：ISP常被用作申请路径标签，LIR则属于注册体系层级。

日常用词可以趋同，程序仍可能询问不同事实。因此值得固定的公共事实不是企业偏爱的名词，而是在特定版本和时点选择规则的资源职能。

公开讨论已经发现薄弱桥梁

存档讨论并不只是修辞争论。一份2026年3月回复同意拟议LIR句子在语法上不完整，并质疑at a local level，因为一些LIR的运营范围超过单一RIR区域；同一封回复也转载了基于服务清单的ISP定义。

该回复不能决定政策，也没有给出实施结论。它只能证明，在8月13日版本边界之前，参与者已经检查这些谓词及其范围。本文发现的不是隐藏不当行为，而是一道可复核、可由后续版本回答的文本问题。

术语是分布式状态。定义会进入标题、指南、员工指引、培训与申请字段。更新版本必须作为新对象重新审查，不能默认为3月存档文字的无声延续。

最小角色谓词对照与迁移记录

可重放的分类不需要企业交出所有产品、客户或拓扑。它只需要把决定性职能、规则版本和资源事件固定下来。十六个字段足以构成初始记录。

  1. 组织与Org ID身份。 固定用于本次分类的法律和注册局身份，并注明有效时间范围。
  2. 申请或决定身份。 赋予稳定ID、提交时间，并明确链接每次修订与替代申请。
  3. 术语版本。 记录实际采用的NRPM、draft或实施配置版本、生效日期，以及ISP、LIR、IR与end user定义。
  4. 分类目的。 说明哪个具体政策决定需要该角色，禁止一个通用商业标签决定所有不同行为。
  5. 商业服务谓词。 记录与决定相关的外部服务类别，而不把完整私人产品目录写入公共规则。
  6. Internet Registry谓词。 说明组织是否分发号码资源并登记分发，用受保护证据引用支撑。
  7. 直接allocation状态。 区分无、已申请、已批准、已签发、已归还、已撤销或已替换，并绑定具体资源事件。
  8. 下游委派职能。 区分reallocation与reassignment，记录接收者类别和控制条款。
  9. 内部基础设施使用。 把组织自用的有限数量与客户分发分开。
  10. 成员状态。 按版本记录非成员申请人、Service、General、General in Good Standing或Trustee，不从资源角色推断投票权。
  11. 协议与授权状态。 把RSA/LRSA覆盖和有权代表组织的角色绑定到受保护证据，不公开私人授权文件。
  12. 适用政策路径。 列出经验证资源职能选择的具体章节、资格测试与排除项。
  13. 术语出现位置对照。 为每个有后果的替换保存旧词、新词、章节、表面类型和受限语义影响码。
  14. 实施绑定。 把同一含义连接到公共指南、员工指引、培训、应用字段和测试向量版本。
  15. 结果、解释与纠正。 保留决定性谓词、分类结果、复核路径、后续角色变化与纠正历史。
  16. 保护隐私的聚合投影。 公布不同路径数量、分类变化、表单版本错配与纠正次数，不披露申请人或商业秘密。

这不是指定数据库schema，而是规定另一个审查者重放“为什么走这条政策路径”所需的最小信息。

公共层记录职能，不设计公司

Minimum Initial Specification给出一条建设性边界：公共协调层应只严格规定维持唯一性、互操作、控制证明、共同安全与状态转换所需的确定事实；商业安排、制度偏好与自由裁量不应默认进入其中。

本问题中的公共事实包括组织身份、术语版本、资源生命周期、下游委派职能、适用条款和已记录的状态变化。协议与授权证据可以受保护。公开聚合只需显示路径变化、版本错配与纠正。

商业结构保持本地。ARIN不必判断Web托管占企业收入多少、VPN怎样包装、VPS使用哪种hypervisor、机房选择什么路由器。只有当某个明确资源谓词需要相应事实时，问题才进入协调记录。

“最小”不是“模糊”。公共规则对企业主张得越少，就越能对真正需要协调的资源职能写得准确。

Sources

证据没有证明什么

本证据包没有指出任何真实组织因ISP/LIR用词被ARIN错误分类，也没有统计额外ticket、延误、拒绝、地址规模变化或分析员差异。当前内部申请字段、培训材料与完整决策逻辑同样不在公开证据中。

因此，证据足以支撑文本逻辑判断和版本化记录建议，不足以支撑不当行为指控或发生率估计。

它也不能预测PDP结果。独立追踪表把ARIN-2025-1列为Draft Policy。新版本可以恢复明确包含关系、删除subset陈述、只保留LIR或重新设计两个定义；针对新对象的评估将是新事实。