主要领域
基础设施
在 主要领域 分类下,基础设施 按主要领域组织行业情报,帮助读者聚焦互联网基础设施、治理、连接市场或数字资本等方向。页面汇集了相关文章、公开证据、机构、公司、人物、区域关联、运营依赖和市场环境,这些内容可能分散在多个分类页面中。页面解释了该领域、可能的行为主体类型、市场或治理背景,以及读者比较信号时应使用的参考来源。运营商、分析师和治理领域的读者可以观察同一领域如何在事件、档案、市场变化、公开来源证据、区域依赖和更长周期的基础设施决策中随时间显现。

AFNOG
AfNOG 的提案类型字段列出格式,却未定义各自证据
AfNOG 2007 年征集文件列出三种提案格式,却未公布各格式专属的信息字段。

IETF
QUIC 0-RTT 接受不等于交易提交
延迟仪表盘可以显示早期数据已被接受,但应用仍需判断被重放的请求是否会再次产生副作用。

IETF
所有单元格都写着停止:RFC 9906 完成 ECC-GOST 的 DNSSEC 退役
每一个受影响的 ECC-GOST 注册表单元格现在都写着 **MUST NOT**:与 RFC 9905 为 SHA-1 保留兼容性过渡通道不同,RFC 9906 同时关闭生产和验证两条路径,并把执行要求推进到注册表接纳环节。

AFNOG
AfNOG 的 200 个词摘要上限未说明必要信息
AfNOG 2007 年征集页把摘要限制在 200 个词,却没有说明摘要必须证明什么。

欧洲与中东区域 ISP 趋势
Ray-Svyaz 的 500 Mbit/s 促销仍需核实续约价格
MyCentra 面向舍列格什的方案把“最高 500 Mbit/s”和“五折”放在同一页面。该官方页面同时说明,折扣自接入起仅持续三个月,之后转为签约时约定的主套餐。因此,用户首先要确认的经济事实不是首期价格,而是促销结束后的价格。

互联网历史
当 IPv4 标识不再标识每个数据报
*一个字段仍然存在于每个报头中,并不意味着它对每个数据包都具有相同的语义。*

IETF
停止签名,继续验证:RFC 9905 让 SHA-1 退役呈现非对称路径
RFC 9905 的关键机制很直接:受影响的 DNSSEC 算法行同时禁止新建 SHA-1 材料,却保留验证实现义务。运营者要停止用 RSASHA1 和 RSASHA1-NSEC3-SHA1 生成 DNSKEY、RRSIG 与 DS,同时让递归验证器继续能够验证仍处于安装基础迁移期的旧数据。
IETF
MPLS 线性保护协调倒换,但优先级规则决定哪项请求胜出
运行决策:保护域端点会接收本地与远端请求,按明确的优先级排序,并在预先配置的工作路径与保护路径之间移动选择器。PSC 协调的是既有保护域内的一次倒换;它不会创建路径、分配容量、单凭自身认证消息,也不会授予任一端点不受约束的路由权力。

互联网历史
附件声明了类型,本机决定了命令:RFC 1524
一封邮件可以把正文标成图像,却没有资格替收件人的电脑指定查看程序。RFC 1524 用一层本地 `mailcap` 规则把这两件事隔开:网络负责传递可互认的名称,本机负责决定这个名称是否、以及如何变成可执行动作。

IETF
QUIC 接收上限不是路径 MTU
对端声明的是自己愿意接收的 UDP 负载大小,不是网络路径能够承载的最大值。

IETF
四个单元格,一条信任链:RFC 9904 将 DNSSEC 算法政策移入注册表
RFC 9904 并没有改变 DNSSEC 算法编号本身。它改变的是围绕这些编号组织建议、引用权威信息和处理后续更新的方式。一个 DNSSEC 算法编号对应四个分别管理的建议单元格:验证器实现、签名器实现、验证使用和签名使用。理解这四个维度,而不是把它们压缩成一个笼统的“算法状态”,是读懂 RFC 9904 的起点。

互联网历史
消息完整抵达,阅读顺序却仍有三个责任方:RFC 1556
同一封希伯来语与英语混排的邮件,可以在每一跳都保持字节不变,却在两个收件人的屏幕上变成两种句子。RFC 1556 追问的不是字符有没有到,而是到达之后究竟由谁决定它们被人怎样读。

互联网历史
TCP 为什么同时需要结束标记和无操作
TCP 的可变选项区必须让接收方知道哪里停止解析,也必须允许发送方调整后续选项的位置。EOL 与 NOP 分别承担这两个任务。

互联网历史
中继器先回复,后重置:RFC 1516
“收到”必须先走出设备,“完成”却要等破坏性动作之后才有资格出现。RFC 1516 没有把这两个时刻揉成一个成功状态:SNMP 回复、硬件重置、健康更新与业务恢复,各自需要自己的见证。

互联网历史
选定下一代协议之前,互联网先问谁要与它共处:RFC 1550
电表和无线链路,比任何候选协议的包头更早出现在 RFC 1550 里。1993 年的这份征集没有急着问谁会赢,而是先让未来承担迁移、运营与安全后果的人说明:新协议必须经受什么。

互联网历史
告警必须等五秒,计数器不必:RFC 1515
同一个以太网介质连接单元可以在五秒内两次进入异常状态。管理端也许只收到一次告警,下一次轮询又已经看见正常;但进入异常状态的累计数仍可能增加两次。1993 年的 RFC 1515 把这三种记录并排保留下来,因为“需要注意”“现在怎样”与“发生过几次”本来就不是同一项事实。

互联网历史
功能关掉,标准也得照常工作:RFC 1547
在按流量收费的线路上,一枚只为确认“对端还活着”的报文也会进入账单。RFC 1547 从这类不起眼的冲突出发,提出了一条很硬的规则:一端需要某项功能,另一端选择关闭它,双方仍必须留在同一个协议里。

互联网历史
同一块盘,为什么容量表里不是同一个数字:RFC 1514
机房里只有一套存储硬件,监控端却收到几种不同的“容量”:设备有设备的总量,文件系统有自己的边界,应用真正能申请到的空间又少了一截。RFC 1514 没有把这种差异当作需要抹平的噪声,而是把它写成 Host Resources MIB 的结构:先说明数字属于哪一层,再谈数字有多大。

互联网历史
地址没变,接手的服务器却可以变:RFC 1546
运维记录里,一串多年不变的 IP 地址很容易被写成“那台服务器”。但在 RFC 1546 设想的世界里,这种写法从第一天起就不成立:地址负责把一次请求交给某个能提供服务的成员,却没有承诺下一次仍由它接手。

互联网历史
探针多记了一次资源告急,却不知道漏了多少帧:RFC 1513
计数器从 41 跳到 42,数字干净得像一项确定事实。可若追问“刚才究竟漏掉多少帧”,RFC 1513 的答案是:这个计数器没有回答那道题。它只说明远程监测探针又一次察觉自己资源不足。
