今日共有19篇文稿更新，涉及6个area里的14个WG

ART

dmarc

1. draft-ietf-dmarc-aggregate-reporting-24

• Title: Domain-based Message Authentication, Reporting, and Conformance (DMARC) Aggregate Reporting
• Authors: Alex Brotman(alex_brotman@comcast.com)
• Summary: 本文主要介绍了DMARC协议中的一种扩展功能——DMARC聚合报告，它允许域主请求接收方提供各种类型的报告。这些报告提供了关于邮件发送者的信息和认证结果，帮助域主更好地理解他们的政策，并据此采取行动。 聚合反馈报告包含两部分：元数据（描述信息）和记录（IP地址相关的数据）。每个报告都应只包含一个政策域的配置。如果在报告期间观察到多个配置，则可以生成多份报告。当一个报告周期结束时，如果需要的话，可以生成一份综合报告。 此外，该文档还讨论了如何验证外部目的地、安全考虑以及隐私保护问题。文稿指出，虽然DMARC聚合报告可能会泄露一些敏感信息，但通过正确使用DMARC协议，可以最大程度地减少这些问题的影响。
• Diff: 摘要： 本文为互联网工程任务组(IETF)发布的一份关于DMARC(Domain-Based Message Authentication, Reporting, and Conformance)聚合报告的新版本标准文档。 与之前的版本相比，本版本的主要区别在于： 1. 更加详细地描述了DMARC聚合反馈报文中可能包含的数据元素和结构； 2. 增加了对于发送方如何处理重复信息以及如何验证外部目的地的相关说明； 3. 提供了一个新的定义，用于描述报告ID格式； 4. 涉及到了更多的扩展字段和子元素，并对这些元素进行了进一步的说明； 5. 对于不同类型的扩展部分提供了具体的例子，以帮助理解； 6. 对于一些错误类型添加了额外的信息，以便更好地理解和识别它们； 7. 引入了对于错误原因的一种方式，即允许接收者提供一个特定的文本来表示为什么该政策与已发布的政策不匹配； 8. 对于DMARC协议记录进行了更新，以反映最新的变化和改进； 9. 确定了如何处理多个不同的政策在同一个时间点下被发送的情况。 总的来说，本版本的文档更全面、详细地介绍了DMARC聚合反馈报文的具体内容和结构，为接收者提供了更多关于如何正确处理这些数据的指导。

satp

1. draft-avrilionis-satp-setup-stage-01

• Title: SATP Setup Stage
• Authors: Denis Avrilionis(denis@compellio.com), Thomas Hardjono(hardjono@mit.edu)
• Summary: 本文讨论了SATP（安全资产交换协议）中的一个阶段——Setup。在该阶段，两个网络之间的资产转移需要经过一系列交互和绑定过程，以确保资产的安全性和一致性。这个阶段包括从客户端应用程序请求创建Transfer Context（TC）到最终执行SATP Core的过程。 其中最重要的步骤是两台网络设备之间建立绑定关系，以便后续可以进行资产的传递。通过这种方式，客户端可以在不直接控制网络行为的情况下，将资产信息发送给另一端，从而实现资产的高效、安全传输。
• Diff: 摘要： 本文定义了SATP核心所定义的三个阶段（Transfer Initiation、Lock-Assertion和Commitment Establishment）中的Setup阶段（Stage-0），它是SATP协议执行前的一个必要步骤。在Setup阶段，两个网络参与者通过创建一个“转移上下文”来交换资产。这个上下文包含关于要交换的资产的信息。 新版本与旧版本的主要区别在于： 1. 增加了"Setup Phase"的概念，即在执行SATP之前需要进行的准备工作。 2. 强调了客户端应用与服务器端应用之间的交互，以及他们如何在Setup阶段相互作用以准备资产交换。 3. 提供了一个具体的例子，展示了如何创建一个转移上下文。 4. 增加了对资产交换上下文的描述，包括转移上下文的标识符、状态等信息。 总的来说，本文是针对特定技术背景下的资产交换场景提供的一种新的文档结构，强调了在进行大规模数据传输时确保资产安全性和一致性的重要性。

2. draft-avrilionis-satp-asset-schema-architecture-05

• Title: Asset Schema Architecture for Asset Exchange
• Authors: Denis Avrilionis(denis@compellio.com), Thomas Hardjono(hardjono@mit.edu)
• Summary: 本文提出了一个资产管理架构，用于管理资产定义（schema）和配额。主要概念包括： 1. 管理架构的目标是提供在不同网络之间传输基于定义的数字资产的有效性和可验证性。 2. 定义了两个核心概念：资产定义（asset schema），它是所有资产类型的集合；以及资产定义配额（schema profile），它是针对特定行业或垂直细分市场的资产定义配额。 3. 文稿讨论了如何创建、存储和管理这些资产定义配额，以支持资产在网络之间的交换。文中也提到了一些具体的步骤，如获取资产定义配额、验证资产定义配额等。 总的来说，文稿提出了一种新的资产管理框架来处理不同网络中的资产定义和配额，并且提到了一些具体的操作步骤。
• Diff: 摘要：资产定义和资产配置架构是实现不同网络间资产交易的前提条件，尤其是资产定义和资产配置的标准化管理对于资产交换协议至关重要。现有资产定义和资产配置管理机制无法满足当前的资产交换需求，尤其是在跨网资产交易场景下，需要一个统一的管理框架来支持不同行业垂直或细分市场的特定资产类型。 区别： 1. 现有文档讨论了资产定义和资产配置管理的基本概念、目标以及相关组件的架构设计；而新文档探讨了基于资产定义和资产配置管理的管理架构，包括对资产定义和资产配置的相关实体和关联资产的相关数据和艺术作品进行注册、管理和验证的过程。 2. 新文档引入了更多关于资产管理流程中的关键组件，如资产相关网络（Network）、资产门户（Gateway）等，并详细描述了这些组件在资产管理过程中的作用。 3. 新文档还补充了更多的资产相关细节，比如资产记录（Digitized Asset Record, DAR）的概念，它是一个用于存储真实世界资产相关信息的数据结构，可用于验证资产的真实性。此外，还提到了资产凭证（Asset Issuance Authorization, TIAR）的概念，它是证明资产提供商获得了授权的重要文件。 总的来说，新版本文档在原有基础上进行了扩展和完善，更深入地讨论了如何利用资产定义和资产配置构建一套符合实际应用场景的资产交换管理系统。

3. draft-avrilionis-satp-asset-profiles-03

• Title: Asset Profiles for Asset Exchange
• Authors: Denis Avrilionis(denis@compellio.com), Thomas Hardjono(hardjono@mit.edu)
• Summary: 本文主要讨论了资产交换协议（SIP）中的资产定义和资产交易所需要的资产定义架构。资产定义是通过资产类型（profile）来描述的，这些资产类型可以覆盖不同的行业或垂直市场。在资产交换过程中，资产实例与特定资产类型的资产交换关系是在一个Ontology（概念模型）上的，以确保资产之间的互操作性。此外，本文还提到了如何使用JSON-LD语言表示资产定义和资产交易。
• Diff: 该标准文稿定义了资产交换中的资产定义、资产类型（Profile）和资产记录等概念，并提出了资产交换的基本架构。主要区别在于： 1. 引入了抽象的资产定义（Schema）概念，它定义了资产交换的基础协议。 2. 提出了资产类型的层次结构，描述不同行业或领域特定的资产类型。 3. 定义了资产实例与资产类型的关联关系，即通过资产类型定义资产实例在协议执行中的地位。 4. 增加了对资产管理方面的考虑，如非转移性、网络兼容性、法律管辖权等特性。 5. 规定了如何验证Tokenized Asset Record（TR），包括使用JSON-LD验证流程以及附加的验证步骤来检查Registry中存储的信息一致性。 总的来说，新版本更侧重于构建资产交换领域的基础框架，强调了资产类型之间的互操作性和管理要求。

INT

6man

1. draft-templin-6man-parcels2-16

• Title: IPv6 Parcels and Advanced Jumbos (AJs)
• Authors: Fred Templin(fltemplin@acm.org)
• Summary: 本文主要讨论了IPv6中的"包"和"高级超大包"（AJ）概念，以及它们如何支持传输单个大小从非常小到非常大的段。其中，包允许一个IPv6包包含多个段，并且可以使用多种不同的协议选项；而AJ则提供了一种更可靠的服务，当需要传输所有大小的段时。此外，文中还讨论了新的延迟容错网络（DTN）模型，该模型适用于运输单个段的所有大小，特别适合移动应用。 总结：本文提出了一些新的概念，如包和高级超大包（AJ），以及这些概念如何支持在不同场景下传输单个大小从非常小到非常大的数据段。它还提出了一个新的延迟容错网络模型，适用于这种需求。
• Diff: 以上新的英文标准文稿，对IPv6网络中的封装和传输机制进行了更新和完善，提出了“IPv6 Parcel”和“Advanced Jumbo（AJ）”等新的概念和结构，以满足用户在多段链路上传输数据的需求。主要内容包括： 1. 新定义了“IPv6 Parcel”作为承载多个运输层协议数据单元的包装体，可以包含多个连续的运输层协议数据单元。 2. 提出了“Advanced Jumbo（AJ）”，与基本的IPv6 jumbogram有所不同，附加了一种端到端校验码（Cyclic Redundancy Check, CRC）来提供额外的安全性，并允许更小的片段大小。 3. 强调了通过使用新的“Parcel Payload Option”来支持更大的链路带宽需求。 4. 描述了延迟容错网络（DTN）链接模型，用于支持大尺寸的数据包传递，特别是单个大小为65535字节或更大的数据包。 5. 引入了“Controlled Environment”和“Limited Domain”概念，指明所有节点必须遵守该文档中的规定，而开放网络上的节点可能会有不完全遵从的情况。 总的来说，这个新版本的主要区别在于引入了新的封装和传输机制，如IPv6 Parcel、Advanced Jumbo（AJ）、DTN等，以及强调了大尺寸数据包的性能提升，旨在为用户提供更好的服务。

intarea

1. draft-templin-intarea-parcels2-14

• Title: IPv4 Parcels and Advanced Jumbos (AJs)
• Authors: Fred Templin(fltemplin@acm.org)
• Summary: 本文是关于IPv6 Parcels和Advanced Jumbos（AJs）的标准化工作。主要内容包括： 1. 引言：介绍了IPv6 Parcels和AJs的概念，它们是在IPv4网络上使用的新数据包装构建。 2. 需求：文稿概述了IPv4Parcel和AJs在IPv4中的应用需求，强调了与IPv6的相关性以及IPv4协议版本与IPv6的区别。 3. IPv4Parcel和Advanced Jumbos（AJs） - 介绍IPv4Parcel和AJs的基本概念和差异； - 描述了IPv4总长度、时间到活值（TTL）、IP parcel/jumbo数据长度等基本特性； - 提供了IPv4 Compatible IPv6地址编码方式； - 讨论了IPv4 parcel和AJ的包化和恢复过程； - 对于parcel probing，描述了如何处理探针消息以支持IPv4 parcel/AJ头校验计算； - 对于parcel/jumbo replys，描述了如何准备ICMPv4消息，并将封装在IP parcel/AJ中的数据复制到ICMPv4消息体中； - 讨论了对于advanced jumbos（aj），所有的方面都遵循IPv4高级jumbos的处理方式。 4. 实施状态：介绍了早期IPv4 parcel和AJs的实现情况。 5. IANA考虑：建议为新的type TBD1创建一个新表并指定其名称、参考信息。 6. 安全考虑：讨论了IPv4 parcel/AJ的安全要求与IPv6一致。 7. 参考文献：列出了一些相关的标准和文档引用。
• Diff: 该文档是关于IPv4中的Parcels和Advanced Jumbos（AJ）的新版本。主要内容包括： 1. IPv4 Parcels和Advanced Jumbos（AJ）在IPv6中引入了新的数据包装构造，并在IPv4中也有应用。 2. 与IPv6不同，IPv4中的Parcels和AJ遵循不同的封装规范。例如，IPv4中的Parcels是基于GSO和GRO，而AJ则使用Jumbo-In-Jumbo（JIN）技术。 3. 对于网络层，需要考虑如何处理这些差异。对于节点来说，需要正确处理IPv4协议字段为0时的情况，以支持Parcels和AJ的使用。 4. 本文档没有提供具体的实现细节或安全性考虑，但提到了一些通用要求和可能的变更点。对于IPv4而言，将有一些适应性变化。 总的来说，这是对IPv4中Parcels和AJ的一些新规定和改进。由于涉及到复杂的网络架构和协议设计，实际实现可能会有很大的灵活性。

OPS

ippm

1. draft-xp-ippm-detnet-stamp-01

• Title: STAMP Extensions for DetNet
• Authors: Xiao Min(xiao.min2@zte.com.cn), Shaofu Peng(peng.shaofu@zte.com.cn), hexiaoming(hexm4@chinatelecom.cn)
• Summary: 本文主要讨论了Deterministic Networking（DetNet）中的一个扩展协议，名为Stamp，用于检测网络中各种性能指标。Stamp使用Type-Length-Value（TLV）编码，并定义了两个新的TLV类型：Timeslot Mapping TLV和Orchestration Period Mapping TLV，用于获取网络节点间的时钟映射关系。这些TLV可以用来收集关于网络拓扑结构的信息，从而为网络提供更好的服务。 文稿还指出了Stamp在安全性方面的考虑，如检查源地址以防止来自非邻接节点的攻击。此外，还提到了IANA对Stamp协议TLV类型的申请，以支持两种新类型的TLV：Timeslot Mapping TLV和Orchestration Period Mapping TLV。最后，作者总结了Stamp协议的优点和未来的研究方向。
• Diff: 上述新版本的英文标准文稿定义了两个新的简单两向活测量协议（STAMP）标签类型：一个用于从本地路由器到其相邻路由器之间的时钟映射关系，另一个用于从本地路由器到其相邻路由器的时钟映射关系。这两个标签允许网络管理员在单个管理域内的两个节点之间检查源地址，并在网络拓扑发生变化时阻止包含扩展信息的测试包。 相比于旧版本的英文标准文稿，主要的区别在于： 1. 增加了对扩展信息的支持，允许网络管理员在单个管理域内的两个节点之间检查源地址。 2. 改进了安全考虑，包括验证以减小潜在攻击的风险。 3. 简化了文档结构和格式，使内容更易于阅读和理解。 4. 增加了参考文献，提供了更多的背景知识和相关引用。

mboned

1. draft-zzhang-mboned-non-source-routed-sr-mcast-01

• Title: Non-source-routed Multicast in SR Networks
• Authors: Zhaohui (Jeffrey) Zhang(zzhang@juniper.net), IJsbrand Wijnands(ice@braindump.be), Hooman Bidgoli(hooman.bidgoli@nokia.com), Yisong Liu(liuyisong@chinamobile.com)
• Summary: 本文总结了在Segment Routing（SR）网络中的非源路由多播技术。传统多播技术如点到点（P2P）模式的点对点（PIM）、点对点（P2P）模式下的点到多点（RSVP-TE）和点对点（P2P）模式下的点对点（LDP）需要节点之间的树状状态，这些协议需要在网络中保留这种状态信息。然而，在SR架构下，通过直接将包路由到SR网络中的特定路径来实现源路由可以减少所需的各种协议。此外，传统的多播技术需要在每个分发点上建立树状状态，而SR可以在不依赖于任何协议的情况下简化控制平面。 文稿还讨论了一些非源路由的多播技术，包括Bit Index Explicit Replication（BIER），这是一种新的多播技术，它能够有效地进行多播复制而不需要在转发节点上建立树状状态。然而，BIER的技术栈无法被大多数部署的路由器所支持，但它的进入点障碍正在降低，BIER正变得越来越现实。运营商和供应商可以根据他们的具体需求选择适合的方法：使用Ingress Replication（IR）与SR无流隧道、使用SR-P2MP（不使用现有的树信号协议，仍然需要每棵树木上的转发状态）或使用喷洒（一个点到点（PIM）隧道加上SRv6头域）。
• Diff: 该文档是关于在分段路由（SR）网络中实现非源路由多播的最新版标准文档。与之前的版本相比，主要区别在于： 1. 简化了网络中的流量控制：新的技术允许通过直接指定包路径来源路由单个流，而无需维护额外的流状态。 2. 提供了一种非源路由方法：Bit Index Explicit Replication（BIER）是一种新的多播技术，可以使用传统的IP/MPLS隧道或SR策略（如SR政策），也可以作为SRv6的数据平面。 3. 多播树的其他设置方式：传统的方法要求每个节点都维持一个树的状态，但可以通过其他的网络配置方式，比如静态配置或者基于控制器的计算和信号来实现。 4. IPv6支持：IPv6网络可以在不使用MPLS的情况下运行，但必须采用SRv6数据平面来提供IPv6地址的转换功能。 5. 针对运营商和供应商的新方案：提出了多种解决方案，包括BIER、SR-P2MP、喷洒等，以适应不同需求。 6. 在IPv6环境中使用的考虑因素：需要更多的讨论和研究，特别是在IPv6环境下如何处理不同的部署场景。 总的来说，该文档提供了多播在网络中的实施策略和选择指南，适合那些想要简化网络管理并保持流状态减少的运营商和供应商参考。

opsawg

1. draft-ietf-opsawg-secure-tacacs-yang-03

• Title: A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+)
• Authors: Mohamed Boucadair(mohamed.boucadair@orange.com), Bo Wu(lana.wubo@huawei.com), Guangying Zheng(zhengguangying@huawei.com), Zitao Wang(wangzitao@huawei.com)
• Summary: 本文是关于终端访问控制器访问控制系统加样（TACACS+）客户端的数据模型，包括针对TLS 1.3版本的TACACS+客户端模块。它定义了用于管理TACACS+客户端的结构和数据节点，并在安全性方面提供了详细的考虑。 本文主要分为以下几个部分： 1. 引言：概述了RFC 9105和本文的主要变化，以及对之前的文档进行了一些修改。 2. 文献回顾：列出了一些相关的文献，以提供背景知识。 3. 设计：描述了TACACS+数据模型的设计原则，包括数据存储、加密机制等。 4. 安全性：详细讨论了如何保护数据安全，如使用默认的拒绝写操作。 5. IANA考虑：介绍了IANA将需要更新的URI及其相关信息。 6. 参考文献：列举了相关标准和规范的引用。 总的来说，本文提供了一个完整的TACACS+客户端数据模型的定义，包括数据结构、加密方式等内容，同时也为后续的安全性设计奠定了基础。
• Diff: 本文档定义了一个基于TLS 1.3的终端访问控制器访问控制系统加样（TACACS+）客户端模块，该模块与 RFC 7317 中定义的系统管理数据模型相结合，允许设备使用TACACS+服务器进行集中认证、授权和会计（AAA）。相比旧版文档，新增了以下主要特点： 1. 支持TLS 1.3，不再支持之前的TLS版本。 2. 新增了TLS作为新的安全选择。 3. 对于包含多个接口的TACACS+客户端或服务器，需要指定发送出去的TACACS+报文的目的地址，或者通过接口IP地址设置或从本地Forwarding Information Base(FIB)中导出的出口接口来获取目的地址。 4. 增加了支持共享密钥的选项，可以提供外部预共享密钥(PSK)建立或配置功能。 5. 增加了证书验证选项，支持证书引用和证书引用下的明确认证类型。 6. 加入了断续时间统计信息。 7. 安全性方面新增了证书错误和RPK错误统计数据。 总的来说，这些新增特性为终端访问控制器访问控制系统提供了更多的灵活性和扩展性，使其能够满足更复杂的网络部署需求。

RTG

bess

1. draft-ietf-bess-evpn-redundant-mcast-source-13

• Title: Multicast Source Redundancy in EVPN Networks
• Authors: Jorge Rabadan(jorge.rabadan@nokia.com), Jayant Kotalwar(jayant.kotalwar@alcatel-lucent.com), Senthil Sathappan(senthil.sathappan@alcatel-lucent.com), Zhaohui (Jeffrey) Zhang(zzhang@juniper.net), Wen Lin(wlin@juniper.net)
• Summary: 在本文中，作者详细介绍了EVPN网络中多源IP分组流冗余的问题。主要讨论了两种解决方案：热备份（Standby）和冷备份（Warm）。热备份方案适用于需要快速恢复的情况，而冷备份方案则更适合要求更长恢复时间的场景。文稿还描述了这两种方案的具体实现细节，并给出了相应的示例。 总的来说，这篇文稿提供了关于如何处理IP分组流冗余问题的方法论建议，对运营商来说非常重要。它强调了在EVPN网络中正确配置多源IP分组流的重要性，并提出了具体的操作步骤来实现这一点。此外，文稿也提到了在不同网络环境中应用这些策略时可能遇到的一些挑战和限制。
• Diff: 在上述新版本的英文标准文稿中，主要内容包括： 1. 引言：定义了IP多播冗余的概念和背景。 2. 解释：详细介绍了IP多播的原理、特点以及与传统多播技术的比较。 3. 内容结构：文档分为三个部分，分别介绍解决方案、扩展和安全考虑等。 4. 文档格式：采用了规范化的格式，如使用术语缩写、表格等方式来提高可读性。 相比于旧版本，该新版本的主要区别在于： 1. 简化了IP多播冗余机制的描述，使其更加清晰明了。 2. 增加了关于热备份（HS）和冷备份（WS）解决方案的详细说明，以满足不同场景的需求。 3. 提供了更具体的例子和示例，使读者更容易理解并应用这些解决方案。 4. 强调了网络拓扑对解决方案选择的影响，并给出了相应的指导建议。

pce

1. draft-ietf-pce-pcep-yang-27

• Title: A YANG Data Model for Path Computation Element Communications Protocol (PCEP)
• Authors: Dhruv Dhody(dd@dhruvdhody.com), Vishnu Pavan Beeram(vbeeram@juniper.net), Jonathan Hardwick(jonathan.e.hardwick@gmail.com), Jeff Tantsura(jefftant.ietf@gmail.com)
• Summary: 本文主要定义了一个YANG数据模型，用于管理路径计算元素通信协议（PCEP）的PCEP对等体的配置、监控和监测。包括Peer列表、Session列表、通知消息、RPC、统计信息以及一些高级特性如状态机PCE的LSP数据库、全局并发优化(GCO)等等。本文还讨论了PCEP的安全性考虑、与TCP认证选项的兼容性、IPv6流量工程、网络配置访问控制模型、标签交换路径状态同步规程、段路由在MPLS/IPv6的数据平面支持、路径计算元素通讯协议（PCEP）扩展性的TLS保护等。最后，文稿指出了相关的参考文献。 总的来说，本文详细地描述了PCEP协议的数据模型及其相关特性，为PCEP的管理和维护提供了基础框架。
• Diff: 以上文档是关于Path Computation Element (PCE)通信协议(PCEP)数据模型的最新版。主要内容包括： 1. 定义了PCEP数据模型，用于管理和配置PCEP发言者。 2. 提供了PCEP数据模型中的基本元素和属性，如实体、角色、状态等。 3. 概述了PCEP通信协议及其扩展，例如支持多层标签交换路径计算（LSP）、段路由在MPLS和IPv6上的使用、以及与IS-IS和OSPF协议的交互。 4. 描述了PCEP通信协议的数据模型，并提供了相关模块的描述。 对比于旧版本，主要区别在于引入了更多的协议细节，如Stateful PCE、LSP-DB管理等，同时也包含了更多新的扩展信息。此外，还增加了对TLS（安全传输）的支持，以及基于对象标识符的索引机制。总的来说，这个新版数据模型更加完整，能更好地满足PCEP的需求。

spring

1. draft-yang-spring-sid-as-source-address-05

• Title: SID as source address in SRv6
• Authors: Feng Yang(yangfeng@chinamobile.com), Changwang Lin(linchangwang.04414@h3c.com)
• Summary: 本文讨论了在SRv6网络中使用SID作为源地址的问题。首先，本文分析了使用loopback地址作为源地址的情况，并指出这种做法不够充分。然后，提出了一种解决方案，即使用SRv6 SID作为源地址。 具体来说： 1. 使用SRv6 SID作为源地址可以防止SRv6隧道源地址欺骗。 2. 在SRv6承载网络中的最后一个节点（例如CE节点）可以通过学习来自控制器或IGP协议的流量服务地址来创建一个动态源地址验证表。当从PE节点接收到这些包时，它可以根据来源地址检查流包以确定其合法性。否则，应丢弃它们。 总结：本文介绍了在SRv6网络中使用SID作为源地址的方法，并提出了相关解决方案。
• Diff: 摘要： 在SRv6网络中，通常使用loopback地址作为源地址。然而，在双向流量需求或者需要验证流量来源的情况下，仅使用loopback地址作为源地址是不够的。本文提出将SID作为SRv6流量的源地址，并识别了几个应用场景。 主要内容如下： 1. 引言：详细描述了在SRv6网络中的源地址可以用来代替loopback地址的情况。 2. 使用SRv6 SID作为源地址： - 用户流量：存在几种情况需要使用SID来替代loopback地址作为源地址。 - 控制流量和OAM流量：这两种类型的流量不会被vpn所终止，因此不受到影响。 - 管理流量：这种流量不会被vpn所终止，因此也不受影。 3. 对于验证源地址的应用场景：在SRv6网络中，可以通过以下两种方式验证源地址： - 在SRv6隧道的第二个节点上进行验证，以防止源地址欺诈。 - 在SRv6隧道尾部进行验证，以防止源地址欺诈。 4. 用途案例： - SRv6网络与SR-aware状态防火墙结合：在SRv6网络中，当有人操纵SRH时，他可以从任何VPN访问，从而改善了VPN隔离的需求。 - 增强的流量隔离：通过对SRv6包最后进入的端口进行验证，以避免双向流量中出现混淆的流量。 5. IANA考虑：无此部分内容。 6. 安全考虑：无此部分内容。 7. 参考文献：参考引用了7个规范性文档和6个信息性文档。

SEC

ipsecme

1. draft-ietf-ipsecme-ikev2-rename-esn-01

• Title: Renaming Extended Sequence Number (ESN) Transform Type in the Internet Key Exchange Protocol Version 2 (IKEv2)
• Authors: Valery Smyslov(valery@smyslov.net)
• Summary: 本文主要讨论了如何将IKEv2中的序列编号（Extended Sequence Numbers，ESN）定义为序列编号属性（Sequence Numbers Properties，SNP）。这个修改旨在更好地描述这些序列编号在网络中的行为，同时考虑到了一些可能的例外情况。新的定义更符合实际情况，并且可以提供给未来的协议使用。 总结起来，本文主要更新了IKEv2中的序列编号定义，使其更加符合实际应用场景，同时也为未来的协议提供了足够的灵活性和可扩展性。
• Diff: 该文档更新了关于IPsec安全协议中的抗重播保护的定义和实现方式。具体来说： 1. 定义了IPSec安全协同时进入网络的序列数的特性，并扩展了这一定义。 2. 对于一些现有协议（如[RFC8750]中的Implicit IV在ESP）依赖的属性进行了澄清，这些属性对于当前定义的transform类型是足够的。 3. 将“Extended Sequence Numbers”定义为“32-bit Sequential Numbers”，并保留其对AH和ESP的安全性影响。 总体而言，这个修订增加了对抗重播保护的详细描述，而无需改变协议的安全性。新的命名方式也使后续的ID定义更加明确。

lamps

1. draft-ietf-lamps-automation-keyusages-01

• Title: X.509 Certificate Extended Key Usage (EKU) for Automation
• Authors: Hendrik Brockhaus(hendrik.brockhaus@siemens.com), Dr. David Goltzsche(david.goltzsche@siemens.com)
• Summary: 这篇标准文档主要讨论了如何在X.509证书中添加自动化扩展密钥使用（Extended Key Usage）信息，以支持工业自动化和安全通信。文档定义了五个关键目的（id-kp-configSigning、id-kp-trustanchorSigning、id-kp-updateSigning、id-kp-safetyCommunication）用于验证文件签名、信任锚配置文件、软件或更新包的签名以及对安全通信的认证。这些目的可以防止跨协议攻击，并提供给观察者识别证书用途的能力。同时，还提供了安全性和隐私方面的考虑。 总的来说，该文档为工业自动化领域的加密系统提供了新的工具，增强了系统的安全性并增加了透明度。
• Diff: 以上新版本的英文标准文稿定义了用于工业自动化和欧盟铁路系统支柱（EURJU）的X.509证书扩展使用目的（Extended Key Usage，简称Eku），这些Eku定义了可以用来验证特定文件、软件更新包或安全通信的公共密钥签名的目的。 与旧版本相比，新的Eku文档对以下方面进行了改进： 1. 更广的使用场景：将自动化硬件和软件产品的扩展用途从欧洲联盟国家的网络安全法规中引入到更广泛的领域中。 2. 安全性考虑：增加对安全性攻击的减少措施，例如限制可使用的公钥操作，并且确保已明确指定的安全责任主体。 3. 隐私保护：增加了在可能的情况下限制某些组合使用扩展密钥使用的目的点。 4. 在认证机构中的应用：强调了确保正确插入Eku值对于每个由认证机构签发的证书的重要性。 总的来说，新版本的Eku文档旨在增强工业自动化系统的安全性并提高互操作性，同时加强隐私保护和合规性要求。

WIT

core

1. draft-ietf-core-coap-dtls-alpn-01

• Title: ALPN ID Specification for CoAP over DTLS
• Authors: Martine Sophie Lenders(martine.lenders@tu-dresden.de), Christian Amsüss(christian@amsuess.com), Thomas C. Schmidt(t.schmidt@ieee.org), Matthias Wählisch(waehlisch@ieee.org)
• Summary: 本文主要讨论了CoAP协议在DTLS安全环境下使用的ALPN ID。它将使用“co”作为ALPN ID值，以避免由于链路层分片而导致的客户端Hello和服务器Hello消息长度过长的问题。此外，还讨论了ALPN ID的安全性考虑以及IANA注册的相关事宜。
• Diff: 新版本的英文标准文稿对CoAP服务的安全性进行了补充和细化，并且为CoAP在DTLS上的应用定义了新的ALPN ID，名为“co”或“coaps”。同时，文中还提到了ALPN ID值具有可变长度的特点，对于需要安全保护的服务，可以使用这两个ID中的任一个进行发现。此外，该文档针对ALPN和SVCB资源记录的适用范围进行了扩展。 与旧版的英文标准文稿不同之处在于： 1. 新版中添加了对CoAP在DTLS下的安全性的说明，包括安全措施以及IANA注册信息。 2. 提供了一个新的ALPN ID名称“co”，并指出了其含义及使用场景。 3. 在参考文献部分新增了一些资料，如RFC 7252、RFC 7301、RFC 9460等。 4. 文档中加入了关于ALPN ID值长度可变性的描述，以避免在受限网络中因链路层分组而导致的传输问题。 5. 文档更新了计划状态，从标准文档转为了推荐文档（Standards Track变为Recommended），表明该草案已被通过审查，但没有被正式发布。 总的来说，新版本提供了更详细的安全性和规范指导，同时也增加了更多的细节和参考资料，使其成为开发者和研究人员更全面了解CoAP在DTLS下应用的最佳实践指南。

scone

1. draft-brw-scone-rate-policy-discovery-02

• Title: Discovery of Network Rate-Limit Policies (NRLPs)
• Authors: Mohamed Boucadair(mohamed.boucadair@orange.com), Dan Wing(danwing@gmail.com), Tirumaleswar Reddy.K(kondtir@gmail.com), Sridharan Rajagopalan(sridharan.girish@gmail.com), Gyan Mishra(gyan.s.mishra@verizon.com), Markus Amend(markus.amend@telekom.de), Luis M. Contreras(luismiguel.contrerasmurillo@telefonica.com)
• Summary: 本文主要讨论了网络速率限制策略（NRLP）在动态发现和应用于网络连接上的机制。本文提出了两种机制：一种是通过邻居发现（ND）机制将这些策略发布到网络上，另一种是在配置文件中直接指定。文中还介绍了如何使用Podful（PvD）来通知网络端点相关的速率限制策略。 本文主要结论包括： 1. 邻居发现机制用于发布网络速率限制策略给网络节点。 2. 在Podful（PvD）机制下，可以通过DNS查询获取有关网络速率限制的信息，并根据需要调整策略以适应特定的流量类型和业务需求。 3. 本文为网络开发者提供了新的工具和技术，以满足不同应用场景的需求。 总的来说，本文为网络速率限制策略的动态发现和应用提供了一种灵活且可扩展的方法，有助于提高网络性能并保护用户免受网络攻击。
• Diff: 由于文档没有提供原文，我无法准确地概括其内容和区别。请提供原文以便进行比较分析。

Unknown

Unknown

1. draft-vesely-fix-forwarding-02

• Title: Agreements To Fix Forwarding
• Authors: Alessandro Vesely(vesely@tana.it)
• Summary: 本文主要讨论了如何解决间接邮件流问题。作者提出了一个协议，允许用户通过维护一对一的授权列表来为他们的邮箱服务提供商（Mailbox Provider）提供前缀，从而防止其订阅者的电子邮件被直接发送到其他地址。该协议使用了一种称为“Transistor” 的比喻，以帮助理解这个过程。 在文中，作者还探讨了可能需要改变消息发件人地址的情况，例如传统的分组扩展可能会将消息重新插入邮件系统中，并且一些邮件服务器在早期阶段拒绝 SPF 校验失败后仍然处理这些消息。此外，如果接收者从未拒绝过未签名的消息，则可以考虑将原始退信地址保持不变。 作者建议在与接收方建立协议时，应确保对方具备相应的身份验证方法和权限。此外，协议规定了一个名为 _fixforwarding 的 DNS 记录，用于发布条件和请求地址；以及一个包含预定义字段的 HTML 表单，供用户填写并提交确认或否认请求。当接收方收到新的协议请求时，应该认为先前的协议已过期，应将其视为无效。 最后，作者强调了隐私保护的重要性，并提出了一些具体的措施，如使用非公开的发送地址、避免暴露用户的名单成员关系等。
• Diff: 该文档提出的协议解决了域邮件认证、报告和一致性（DMARC）导致的间接邮件流问题。它为邮箱提供商提供了向其用户发布明示同意或拒绝订阅特定列表或发件人的能力。这是通过在发送邮件时要求接收方提供许可来实现的。 主要区别： 1. 旧版文档没有提到任何关于修改发件人地址的做法，新版文档明确提出了使用“从”字段进行重写以避免冒充的做法。 2. 旧版文档没有提及任何关于设置DNSWL白名单的方法，新版文档详细介绍了如何利用DNSWL白名单来进行传统扩展。 3. 旧版文档仅涉及SMTP阶段的处理，而新版文档考虑了更多基于DNS的安全措施，如DNSWL白名单和DNSSLF等。 4. 旧版文档建议采用签名方法来确认发件人的身份，而新版文档还提到了使用授权和认证机制（例如OAuth）作为替代方案。 5. 新版文档增加了对隐私保护的关注，并强调了对于有滥用行为的邮箱提供商，应对其进行限制。

2. draft-lozano-icann-registry-interfaces-23

• Title: ICANN Registry Interfaces
• Authors: Gustavo Lozano Ibarra(gustavo.lozano@icann.org), Eduardo Alvarez(eduardo.alvarez@icann.org)
• Summary: 本文是关于互联网域名注册机构(Internet Corporation for Assigned Names and Numbers, ICANN)提供的针对注册商和数据保管代理的数据报服务接口的技术细节。主要介绍了两个关键接口：数据托管存款报告（Registry Operator Reporting）和数据托管代理通知报告（Data Escrow Agent Reporting）。这两个接口分别满足了ICANN对注册商提交的托管存款及数据托管代理发送给ICANN的数据托管报告的相关要求。 此外，还描述了数据托管窗口管理接口、数据托管窗口列表获取接口以及SLA探针节点列表查询接口。这些接口支持定期收集和存储维护信息，为ICANN提供定期监控和分析数据托管活动的能力。 总结而言，本文详细解释了ICANN提供的数据报服务接口技术细节，并概述了其在实现数据托管报告、窗口管理和维护信息收集方面的功能。
• Diff: 该文档描述了互联网公司管理组织（ICANN）为合同方提供的接口，用于满足关于报告要求的技术细节。这些接口包括数据寄存器代理（Data Escrow Agent）、注册机构（Registry Operator）和ICANN之间的交互，以提供关于特定项目或对象的详细信息。此外，还提供了从SLA监控系统（SLAM）获取探针节点列表、支持维护窗口操作等接口。与旧版标准文稿相比，主要区别在于： 1. 更详细的接口定义：文档包含了更具体的接口描述，如RRI结果、通知对象、报告摘要对象、通知对象、报告对象、维护窗口和SLAM探针节点列表。 2. 新增的接口支持：新增了从SLA监控系统（SLAM）获取探针节点列表和支持维护窗口操作的接口。 3. 报告状态监测：引入了对报告状态的监测功能，以便于用户了解报告状态。 4. 增加了国际化的考虑：文档强调了国际化方面的考虑，例如使用统一的日期格式和字符表示法。 5. 修订后的版权条款：文档中的版权条款进行了修订，说明了新的授权方式。

3. draft-brown-rdap-ttl-extension-02

• Title: RDAP Extension for DNS Time-To-Live (TTL Values)
• Authors: Gavin Brown(gavin.brown@icann.org)
• Summary: 本文主要讨论了在RDAP协议中添加DNS时间戳(TTL)值信息的扩展，允许服务器提供与特定域名或主机对象相关的DNS记录类型的超时值。该文档详细描述了如何通过添加数组元素来实现这一功能，并提供了相应的规范、参考文献和作者地址。此外，还指出了此扩展与其他现有技术之间的互补性。本文旨在为注册数据访问协议(RDAP)增加一种新的特性，以增强其功能性和灵活性。
• Diff: 该文档是关于在注册数据访问协议（RDAP）响应中包含DNS时间戳（TTL）值扩展的一种描述。主要区别在于： 1. 更改了扩展名称：从draft-brown-rdap-ttl-extension-01到draft-brown-rdap-ttl-extension-02。 2. 增加了对DNS记录类型和TTL值命名空间的规范性要求。 3. 在响应结构中添加了新的属性“remarks”和“events”，允许将TTL值映射到多个DNS记录类型。 4. 改变了RDAP响应中的标识符，从ttl改为ttl。 5. 对所使用的符号进行了更严格的定义。 总的来说，该文档增加了对DNS时间戳值的详细支持，并提供了统一的响应格式，使得不同类型的DNS记录能够被有效地包括在RDAP响应中。