今日共有20篇文稿更新，涉及5个area里的13个WG

ART

cbor

1. draft-ietf-cbor-cddl-more-control-08

  • Title: Concise Data Definition Language (CDDL): Additional Control Operators for the Conversion and Processing of Text
  • Authors: Carsten Bormann(cabo@tzi.org)
  • Summary: 是关于标准化的数据定义语言（CDDL）的一个补充文档。它主要包含以下几部分内容： 1. 引言：介绍了CDDL的发展历史、目标以及当前存在的控制操作符。 2. 文本转换：详细描述了基于CDDL的四种文本转换功能，包括Base16编码（HEX）、Base32编码、Base45编码和Base64编码。 3. 文本处理：阐述了如何使用这些转换功能来构建复杂的文本结构，并对它们进行了详细的说明。 4. 语义考量：讨论了这些控制操作符在实际应用中的适用性和安全性问题。 5. 实施情况：介绍了最新版本的工具支持这些控制操作符的功能。 6. 安全性考虑：强调了安全措施的重要性，特别是针对不同数据类型的安全限制。 7. 参考文献：列举了相关的标准化文件和参考文献。 总的来说，《CDDL: 更多控制操作符》提供了一种统一的数据表示方式，使得开发者可以更加灵活地表达数据结构，提高系统的可扩展性和安全性。
  • Diff: 综上所述，上述新版本的英文标准文稿的主要区别在于： 1. 在控制操作符定义上，增加了更多的支持性控制操作符，如Base16、Base32、Base45、Base64等，以及更通用的打印格式化控制符。 2. 提供了更多灵活的选择来表示整数和字符串数据类型，例如可以使用不同的字符集表示数字或字符串，并允许添加空白字符以进行序列化。 3. 对于JSON对象，提供了默认的转换规则，以便在不增加复杂性的情况下将JSON对象转换为CDDL数据结构。 4. 引入了新的注册表项，用于向IANA申请注册新的控制操作符，便于未来对这些控制操作符进行扩展或修改。 总体而言，这一版更新了现有的一些控制操作符，并引入了一些新的特性，旨在提供更加丰富和灵活的数据模型表达能力。

dmarc

1. draft-ietf-dmarc-failure-reporting-12

  • Title: Domain-based Message Authentication, Reporting, and Conformance (DMARC) Failure Reporting
  • Authors: Steven M Jones(smj@crash.com), Alessandro Vesely(vesely@tana.it)
  • Summary: 这篇文档主要介绍了DMARC失败报告的定义、格式和使用方法。它解释了什么是DMARC失败报告，以及它们在邮件处理中的作用。此外，还讨论了如何验证外部目的地、隐私考虑和安全措施。最后，给出了一个例子来展示DMARC失败报告的具体内容。 总结而言，这篇文稿详细阐述了DMARC失败报告的概念和功能，并提供了详细的指导和建议，以帮助组织更好地利用这项技术来提高邮件安全性。
  • Diff: 新的英文标准文稿（域名基于消息认证、报告和一致性的失败报告）对之前版本做了以下主要修改： 1. 删除了200多条无用的空行。 2. 删除了“must include”这一部分，因为反馈是可选的，并不意味着必须包含任何URI。 3. 将“data exposure considerations”更改为“数据暴露考虑”，以保持一致性。 4. 简化了“report recipients”一节，将其更改为“报告接收者”。 5. 改进了错误的引号使用，例如将`<`替换为 `<` 和 `>`替换为 `>` 6. 在安全考虑中添加了关于组织域的表述。 7. 在反馈报告头字段注册表中更新了“identity alignment”字段的引用。 总的来说，这次更新简化了文档结构，减少了冗余内容，改进了文档的清晰度和格式。这些变化使得新的文本更加易读和简洁，符合最新的标准化要求。

OPS

bmwg

1. draft-ietf-bmwg-containerized-infra-04

  • Title: Considerations for Benchmarking Network Performance in Containerized Infrastructures
  • Authors: Trần Minh Ngọc(mipearlska1307@dcn.ssu.ac.kr), Sridhar Rao(srao@linuxfoundation.org), Jangwon Lee(jangwon.lee@dcn.ssu.ac.kr), Younghan Kim(younghak@ssu.ac.kr)
  • Summary: 本文主要讨论了容器化网络功能(NFV)基础设施中的基准测试方法。文稿首先介绍了容器化的网络架构，如容器化网络接口(CNI)插件和用户空间加速模型等技术。然后，根据不同的网络模型（非加速、用户空间加速、扩展式加速等）对容器化网络性能进行了评估。最后，指出了在容器化网络环境中进行基准测试时需要考虑的一些关键因素，如资源配置、网络模式选择以及安全性和兼容性等问题。总的来说，本文为容器化网络环境下的基准测试提供了全面的指导和建议。
  • Diff: 关于容器化网络性能基准测试考虑因素的新版文档，主要关注了以下方面： 1. 网络模型：相较于传统虚拟机环境中的物理网络功能（PNF），容器化网络函数（CNF）被使用更轻量级的虚拟化方法来实现，例如Host OS虚拟化而非Hypervisor上的硬件虚拟化。这种差异对容器化基础设施的网络配置和部署有重大影响。 2. 资源配置：相比传统VM环境，容器化环境下的资源隔离和网络技术选择对于容器化的网络性能至关重要。新版文档着重于这些差异，并提供了更多的细节建议。 3. 包括加速器和非加速器两种类型的网络模型：在原有的基础上，新版文档增加了用户空间加速模型、eBPF加速模型以及基于DPDK的用户空间加速模型等新的加速模式，以满足不同性能需求。 4. 指南性更强：新版文档通过明确列出不同的网络模型和相应的加速方式，为容器化基础设施的网络性能评估提供了一个指南框架。 综上所述，与旧版本相比，新版文档在参考架构、网络模型分类、资源配置建议、加速器类型等方面有了显著改进和补充，更加全面地覆盖了容器化环境中网络性能优化的相关考虑因素。

dnsop

1. draft-ietf-dnsop-generalized-notify-05

  • Title: Generalized DNS Notifications
  • Authors: Johan Stenstam(johan.stenstam@internetstiftelsen.se), Peter Thomassen(peter@desec.io), John R. Levine(ietf@johnlevine.com)
  • Summary: 本文讨论了通用DNS通知的使用，它扩展了传统DNS通知的用途，使DNS基础设施完全避开效率低下和浪费的时间。该协议引入了一种新的资源记录类型（DSYNC），用于发现并发布接收通知的目标地址。当发送者想要知道如何将特定的通知分发给其他方时，可以利用这种机制。此外，本文还提出了一些实用的实施细节，并详细介绍了其安全考虑。 主要结论是，通用DNS通知具有改善DNS维护过程、减少扫描次数以及加速变化更新等优点。然而，需要注意的是，虽然通用DNS通知可能会提高某些情况下的性能，但在其他情况下可能会导致延迟或错误。因此，在使用这种技术之前，需要仔细评估其适用性。
  • Diff: 本文主要介绍了通用DNS通知（Generalized DNS Notifications, GDNOT）的概念及其在DNS运营中的应用。GDNOT是在传统DNS通知的基础上扩展了使用范围，以支持更高效的自动代理维护。它通过引入新的DSYNC记录类型来实现这一点，并允许监听特定子域的通知发送者发布其地址。 相比于旧版的文档，主要区别在于： 1. 新增了DSYNC记录类型的定义，用于发现接收方地址； 2. 在出版目标时，提供了多种方法选择，如子域名指定、动态名称等； 3. 可能出现的其他通知机制由DSYNC记录决定，而不是直接依赖于通知方式； 4. 目标查询和验证是基于DNSSEC进行的，以确保安全性； 5. 安全性考虑增加了对报告错误的支持； 6. 持续检查间隔被调整为默认值； 7. 硬件速率限制在源IP地址和所含区的名字空间上配置； 8. 在无附加声明的情况下，可签发未授权的通知。 总的来说，这个改进增强了DNS通知的效率，特别是在处理大规模变更时提供更快的响应时间。然而，这需要实施适当的网络和硬件策略来有效利用该功能。

netconf

1. draft-wilton-netconf-yp-observability-01

  • Title: YANG-Push Operational Data Observability Enhancements
  • Authors: Robert Wilton(rwilton@cisco.com)
  • Summary: 这篇文稿主要介绍了YANG-Push轻量级订阅观测能力的增强版本，它优化了YANG Push的行为以适应操作数据的监測。此外，还提出了可能需要讨论的问题，比如是否应该扩展到YANG Push或定义一个新的“YANG Push lite”。最后，文档中还包括了一个示例配置好的传输增强（附录A）和一个子集订阅错误示例（附录B）。
  • Diff: 关于本文档的主要区别： 1. 增加了新的编码格式和联合周期性和事件触发的订阅功能。 2. 提供了新的联合周期性、事件触发订阅的概念，允许接收者同时接收周期性和事件触发的更新消息。 3. 在编码方面，考虑使用JSON而不使用复杂的YANG patch格式，以提高可读性和与现有数据模型的一致性。 4. 提出了更多的改进方向，如支持子订阅、过滤器、更简洁的命名空间映射等。

opsawg

1. draft-ietf-opsawg-ntw-attachment-circuit-15

  • Title: A Network YANG Data Model for Attachment Circuits
  • Authors: Mohamed Boucadair(mohamed.boucadair@orange.com), Richard Roberts(rroberts@juniper.net), Oscar Gonzalez de Dios(oscar.gonzalezdedios@telefonica.com), Samier Barguil(samir.barguil@gmail.com), Bo Wu(lana.wubo@huawei.com)
  • Summary: 本文主要介绍了网络模型（YANG）中的一个附加模块，用于管理服务提供商提供的附件电路。该模块扩展了基础网络和业务节点模型，并提供了详细的AC接入电路信息。这些数据可以用来控制服务提供者的网络配置，并且可以支持不同类型的部署，如虚拟化网络、云网络等。 文中还详细讨论了附加模块在服务交付流程中的应用，以及如何使用不同的参数来定义和关联不同的AC。例如，一个附加模块可能需要定义多个AC以支持特定的服务或部署模式。 此外，文稿提到了一些具体的数据节点和属性，如Bearer ID、AC名称、服务引用、网络ID等。这些信息可以方便地从服务层映射到实际的AC中去。 总之，这个附加模块为网络运营商提供了强大的工具来管理和配置他们的附件电路，这对于实现高效的服务交付至关重要。
  • Diff: 新的英文标准文稿是关于网络模型和附加到服务提供商网络中的附件电路（AC）的数据模型的描述。 相较于旧版，主要有以下几个方面的区别： 1. 增加了新的章节“Sample Uses of the Attachment Circuit Data Models”来展示数据模型的实际应用场景，包括终止一个或多个客户边缘（CE）的AC和定位AC网络模型在服务交付过程中的位置。 2. 在模块结构方面，添加了“Overall Structure of the Module”部分来描述整个模型的结构。 3. 对于特定的数据节点进行了定义，例如Bearer、Network Controller、Service Orchestrator等，并对它们的用途和作用做了详细的说明。 4. 提供了具体的例子，如VPLS（虚拟私有线路）、父AC（父AC与子AC之间的关系）等，以帮助读者理解这些概念。 总的来说，新版文稿更详细地介绍了AC模型的细节，增加了实际应用案例，有助于理解和使用这个数据模型。


2. draft-ietf-opsawg-ac-lxsm-lxnm-glue-13

  • Title: A YANG Data Model for Augmenting VPN Service and Network Models with Attachment Circuits
  • Authors: Mohamed Boucadair(mohamed.boucadair@orange.com), Richard Roberts(rroberts@juniper.net), Samier Barguil(samir.barguil@gmail.com), Oscar Gonzalez de Dios(oscar.gonzalezdedios@telefonica.com)
  • Summary: 是关于在虚拟私有网络(VPN)模型中增加附加电路(Access Circuit)信息，以便为特定的服务和网络配置添加参考。这个模块主要更新了Layer 2(Services)、Layer 3(Networks)和网络访问(Network Access)中的服务和网络模型，使得它们能够绑定到特定的接入电路(Access Circuits)，从而实现更灵活的网络服务部署。 本文总结了该文档的主要贡献：一是更新了现有服务和网络模型以包含与接入电路相关的数据；二是提供了几种使用方式来结合接入电路和具体的服务或网络配置，如通过ACaaS模型创建接入电路，并将这些接入电路与其他服务关联起来。此外，还讨论了安全性和IANA注册的问题。总的来说，这是对现有VPN模型的一种补充，有助于实现更高效的服务管理和网络配置。
  • Diff: 新的文档主要更新了以下内容： 1. 模块定义：增加了对AC服务模型和网络模型的数据补充。 2. 分组结构：在模块树结构中添加了关于AC服务的信息分组，以及关于AC网络信息的分组。 3. 参考文献：在参考部分给出了详细的引用列表，包括正式引用和非正式引用。 4. 新增示例：提供了几个实际的例子来说明如何使用新的数据模型。 总的来说，这个文档主要是针对原有文档进行了扩展和完善，使得原有的数据模型更加完整，并且在实践中可以得到更好的应用。


3. draft-ietf-opsawg-teas-attachment-circuit-19

  • Title: YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS)
  • Authors: Mohamed Boucadair(mohamed.boucadair@orange.com), Richard Roberts(rroberts@juniper.net), Oscar Gonzalez de Dios(oscar.gonzalezdedios@telefonica.com), Samier Barguil(samir.barguil@gmail.com), Bo Wu(lana.wubo@huawei.com)
  • Summary: 本文提出了一个新的数据模型，用于管理网络服务中的连接器和“附件电路”（Attachment Circuits）服务。该模型允许客户订购并管理他们自己的附加电路，并且可以被用来创建、修改或发现这些电路。 文中首先介绍了新的数据模型，然后详细解释了它如何与现有的网络数据模型进行交互，并给出了几个示例来说明如何使用这个模型。最后，讨论了一些安全性和IANA考虑因素。
  • Diff: 该文档是关于数据模型和架构的，详细介绍了ACaaS（Attachment Circuits-as-a-Service）的概念、定义、结构、使用场景以及与现有网络模型的关系等。相较于旧版本的英文标准文稿，它在以下方面有所改进： 1. 更清晰地描述了ACaaS的定位：ACaaS是一种提供服务前或服务后管理附加电路（ACs）的方法，旨在简化对附加电路的服务部署。 2. 提供了新的模块来管理附加电路，如Bearer（承载）、AC（附加电路）和服务提供商网络（ServiceProvider Network）。这些模块提供了更灵活的选择方式，以满足不同的需求。 3. 描述了如何通过创建一个新的承载来创建一个新的AC，并说明了ACs可以通过多个承载进行实例化。这为服务提供商提供了更大的灵活性。 4. 引入了新的模块来管理和协调多个AC之间的关系，比如控制优先级、绑定到多个CE（Customer Edge）等，这使得服务部署更加复杂但可控。 5. 针对不同应用场景提供了相应的例子，例如创建新的承载、请求附加电路参考、创建多条附加电路、控制关联优先级、创建绑定到特定网络切片的服务、连接虚拟化环境、跨运营商互连等。这些示例使文档更加实用且易于理解。 总的来说，该文档的主要区别在于引入了新的模块和机制来支持更复杂的附加电路管理流程，同时保持了文档的整体性并增加了实用性。


4. draft-ietf-opsawg-teas-common-ac-14

  • Title: A Common YANG Data Model for Attachment Circuits
  • Authors: Mohamed Boucadair(mohamed.boucadair@orange.com), Richard Roberts(rroberts@juniper.net), Oscar Gonzalez de Dios(oscar.gonzalezdedios@telefonica.com), Samier Barguil(samir.barguil@gmail.com), Bo Wu(lana.wubo@huawei.com)
  • Summary: 本文提出了一个通用的附件电路(YANG模型)模块，该模块设计用于与其他模型共享和复用。主要功能包括支持多种类型的附件电路（如以太网、无线连接等），以及实现服务与特定附件电路绑定的功能。此外，还定义了多个可重用组，例如操作指令组、层2封装、层2隧道服务等，这些都便于管理和维护。 总结而言，本文提出了一种通用的YANG模型，旨在帮助其他模型复用和共享附件电路数据，并为提供附加组件和服务提供了基础。
  • Diff: 该文档是关于创建公共附加电路（AC）数据模型的草案，它定义了一个公共附加电路模块，以支持其他模型在管理附加电路时使用。与旧版标准文稿不同的是： 1. 引言部分被删除。 2. 模块名称更改为“ietf-ac-common”。 3. 对于一些关键概念进行了修订，例如Bearer、AC、Layer 2/TCP/IP等。 相比旧版标准文稿，主要区别在于：引入了新的模块名称和模块功能，如“ietf-ac-common”，并且对相关术语进行了更新或重命名，使得文档结构更加清晰和一致。此外，文档还增加了对新的管理和网络配置要求的支持，如服务器生成的身份验证信息以及路由协议支持。这些变化有助于提升文档的实用性和可扩展性。


5. draft-ietf-opsawg-ipfix-gtpu-03

  • Title: Export of GTP-U Information in IP Flow Information Export (IPFIX)
  • Authors: Daniel Voyer(danvoyerwork@gmail.com), Sriram Gopalakrishnan(sriragop@cisco.com), Thomas Graf(thomas.graf@swisscom.com), Vyasraj Satyanarayana(vyasraj@juniper.net)
  • Summary: 是关于在IPFIX协议中添加GTP-U信息元素，以报告GTP-U通用分组无线服务隧道协议用户平面（GTP-U）头中的字段，如隧道端点标识符（TEID），以及其会话扩展头部附加字段的信息。这些信息可用于监控和评估移动终端的数据转发性能。 IPFIX是一种用于交换流量信息的协议，用于传输网络设备之间的流量信息。该文档定义了六个IPFIX信息元素来报告GTP-U头中的字段，包括隧道端点标识符（TEID）、QoS流标识符（QFI）和PDU类型。这些信息可以用来分析和优化网络性能，并有助于运营商管理和配置不同网络功能。同时，这些信息也要求开发者需要考虑数据安全性和存储策略，确保正确使用这些信息。
  • Diff: 摘要 本文档引入了用于报告通用分组无线业务（GPRS）隧道协议用户平面头中的特定字段信息的IPFIX信息元素（IE）。这些IE特别适用于在通用分组无线业务（GTP-U）头中发现Tunnel Endpoint Identifier（TEID）、QoS Flow Identifier（QFI）和PDU类型。 具体来说，这些IE被用来提取GTP-U头部中的Tunnel Endpoint Identifier（TEID）、QoS Flow Identifier（QFI）和PDU类型的值，并将其作为GTP-U相关的信息元素来报告。 使用IPFIX模板记录可以表示这个数据结构： ```plaintext Template Record: ``` 其中，Template ID为256，表示该数据集将作为Data Record的一部分使用。 Data Set: ```plaintext 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ``` 在这两个部分之间填充的是具体的IE值，如：flags、message type、TEID、sequence number、QFI和PDU type等。 主要区别在于： 1. 在旧版标准文中，没有明确定义这些IE以及它们的功能。 2. 在新版标准文中，详细定义了这些IE及其功能，包括版本、消息类型、TEID、序列编号、QFI、PDU类型等。 综上所述，新版标准文稿比旧版更加详细地描述了IPFIX信息元素及其用途，提供了一个更清晰的框架来理解和处理GTP-U头部中的信息。

RTG

cats

1. draft-lbdd-cats-dp-sr-03

  • Title: Computing-Aware Traffic Steering (CATS) Using Segment Routing
  • Authors: Cheng Li(c.l@huawei.com), Mohamed Boucadair(mohamed.boucadair@orange.com), Zongpeng Du(duzongpeng@foxmail.com), John Drake(jdrake@juniper.net)
  • Summary: 本文提出了一个使用任何地址作为CATS服务标识符和在Ingress CATS路由器上使用Segment Routing (SR)作为数据平面来实现计算感知流量导向（CATS）解决方案。本文概述了如何实现在多服务实例中的CATS架构，包括如何实现CATS框架组件、流程以及安全考虑等。 总结：本文提出了一种使用任何地址作为CATS服务标识符，并通过Segment Routing在Ingress CATS路由器上实现的CATS数据平面解决方案，该方案将为网络环境中部署的服务提供更好的流量控制和调度能力。
  • Diff: 新的版本文档详细介绍了如何使用无向广播地址作为CATS服务标识符、段路由（SR）作为数据平面封装来实现计算敏感型交通导向（CATS）。该解决方案基于任何播地址和SR，并且在控制面层面上实现了流量分发和分类处理。同时，它也考虑了安全性和安全性方面的考量。 与旧版相比，最大的不同在于采用了无向广播地址作为CATS服务标识符，以及使用SR作为数据平面封装。此外，该方案还考虑了网络相关安全问题，比如反向代理等，以确保CATS架构的安全性。最后，该文档提出了一个中心化模型或混合模型的概念，其中由集中式控制器收集并发布具有指标的路由，以满足不同服务的需求。 总的来说，这一改进提高了方案的灵活性和实用性，使其能够更好地适应实际应用环境。

lsvr

1. draft-ietf-lsvr-bgp-spf-45

  • Title: BGP Link-State Shortest Path First (SPF) Routing
  • Authors: Keyur Patel(keyur@arrcus.com), Acee Lindem(acee.ietf@gmail.com), Shawn Zandi(szandi@linkedin.com), Wim Henderickx(wim.henderickx@gmail.com)
  • Summary: 本文主要讨论了BGP与BGP Link-State Shortest Path First（BGP-LS SPF）之间的关系，以及这两种协议在MSDC中的应用。文稿首先介绍了两种协议的特点和优势，然后讨论了它们的关系，并定义了BGP-LS SPF的安全性要求。接着，它描述了BGP SPF协议的基本概念，包括如何使用BGP-LS来支持计算最短路径算法。最后，它概述了BGP SPF协议可能遇到的问题，并给出了相应的解决方法。总的来说，该文提供了BGP SPF协议的详细描述和实施指南，有助于网络工程师更好地理解和利用这两种协议。
  • Diff: 这篇新的标准文档描述了一个基于BGP和BGP Link-State Distribution的解决方案，用于简化大规模数据中心的数据中心互联（DCI）网络中的三层路由。主要区别在于： 1. 基于BGP的协议关系：本文与旧版不同，它没有改变BGP协议的基本框架。 2. 基于BGP的决策过程：在BGP SPF计算过程中，修改了选择最佳路径的方法，并将阶段2替换为Dijkstra算法。 3. 基于BGP的NSF信息交换：引入了新的BGP-LS-SPF SAFI来交换NSF信息。 4. 路由计算方法：定义了基于BGP SPF的算法，包括NSF属性、更新策略等。 5. 安全性考虑：增加了对错误处理的安全措施，如通知码等。 总体来说，新的方案提供了更多的灵活性，支持更多类型的网络拓扑，并通过NSF属性的改进提高了效率。

spring

1. draft-zhao-spring-srh-extended-srv6-policy-key-01

  • Title: The Correspondence between Packets and SRv6 Tunnels
  • Authors: Jing Zhao(zhaoj501@chinaunicom.cn), Wenxiang Lve(lvwx28@chinaunicom.cn)
  • Summary: 本文提出了一种新的扩展头，即SRv6政策密钥（Policy Key），它解决了控制器在SRv6网络中的路径管理中的及时性和准确性的问题。通过添加到消息头部的独特路径标识符，这种方案允许网络节点向控制器报告路径信息。这确保了控制器能够实时和准确地保持SR路径状态，即使SID在传输过程中丢失或控制器不能即时、准确地监控它们。 本文还讨论了此方案的优势，例如增强网络可用性和操作效率，特别是在涉及多路径隧道配置和负载均衡等场景。此外，该策略还可以改进对单隧道多路径的需求，从而提高带宽利用效率并最大化网络性能。最后，本文介绍了使用SRv6 Policy Key进行实时路径识别的功能，并讨论了其安全性考虑和IANA考虑。
  • Diff: 以上新版本的英文标准文稿，主要在以下几个方面做了改进： 1. 对于SRv6协议定义了一个新的扩展头部SRH Policy Key，用于标识SRv6隧道。 2. 提供了SRH Policy Key的格式定义，包括类型、长度、标志位等信息。 3. 引入了SRH Policy Key TLV（TLV），包含了路径偏好和政策颜色等信息。 4. 描述了功能描述，包括路径一致性验证、服务流量分析等功能。 5. 针对安全性和IANA考虑进行了修改。 6. 调整了文档标题和目录结构。 总的来说，新版本增加了对SRH Policy Key的详细定义和使用场景说明，并对安全性、IANA考虑等方面进行了优化，使其更加符合当前网络设计的需求。与旧版相比，其在定义性内容上有了较大的提升。

SEC

lamps

1. draft-housley-lamps-private-key-attest-attr-01

  • Title: An Attribute for Statement of Possession of a Private Key
  • Authors: Russ Housley(housley@vigilsec.com)
  • Summary: 本文详细描述了在X.509证书认证过程中，一个声明持有私钥凭证的属性。这个属性用于证明一个证书主体对公钥拥有合法的所有权。当需要两个证书时，如一个用于签名、另一个用于密钥建立，一个签名证书可以验证由该主体生成的私钥签发的签名。 本文讨论了如何使用私钥声明属性来证明一个主体持有特定私钥的资格，并提供了几个示例来说明如何实现。同时，它还考虑了私钥声明的有效性、完整性以及与X.509标准和CRMF的兼容性等问题。 总的来说，本文主要介绍了私钥声明属性的定义、使用方法及其安全性问题，为构建安全的数字身份认证系统提供了指导。
  • Diff: 摘要：本文档详细描述了在X.509证书申请中一个用于证明拥有私钥属性的声明语句。作为X.509证书注册流程的一部分，认证机构通常要求申请人提供关于他们拥有的私钥的证明。如果情况允许，某些认证机构接受来自申请人的签名声明来验证之前的签名证书。例如，在需要两个证书（一个用于签名，另一个用于密钥建立）的情况下，一份可以验证的声明可能会比之前颁发的签名证书更可靠。 本文的主要区别在于： 1. 定义了一个新的声明语句标识符，并与现有的一些相关特性进行了关联，如私钥和证书。 2. 使用ASN.1语法定义了这个新声明的结构和部分元素，提供了编码规范和示例使用说明。 3. 提供了相关的安全考虑、IANA命名空间和参考文献信息。 总的来说，该文档扩展了当前的X.509标准，引入了一个新的声明机制来增强证书注册过程的安全性和可追溯性。


2. draft-ietf-lamps-rfc4210bis-16

  • Title: Internet X.509 Public Key Infrastructure -- Certificate Management Protocol (CMP)
  • Authors: Hendrik Brockhaus(hendrik.brockhaus@siemens.com), David von Oheimb(david.von.oheimb@siemens.com), Mike Ounsworth(mike.ounsworth@entrust.com), John Gray(john.gray@entrust.com)
  • Summary: 是一个关于公钥基础设施(CPKI)证书管理协议(CMP)的标准文档。它定义了如何在互联网上处理证书和密钥，包括创建、更新、撤销和发布证书以及管理密钥。文稿还讨论了管理和保护证书的方式，并提供了相关的定义和缩略语。 主要变化有： 1. 分割成两个附录：一个用于描述基本配置要求（如验证根CA证书），另一个用于描述可选的功能要求（如自动签发根CA证书）。 2. 新增了一种确认机制，减少了协议消息的数量，例如引入了隐含确认方法。 3. 改进了对证书透明度的描述，增加了对不同保护方式的支持。 4. 添加了新的通用消息类型来请求CA证书、更新根CA证书等。 5. 更新了根CA初始化部分，新增了RootCaKeyUpdateContent消息类型。 6. 提供了支持KEM密钥传递到证明持有权的多个方法。 7. 删除了与版本cmp1999无关的消息确认功能，将其移入附加C.2中的认证算法使用规则。 8. 增加了安全考虑的部分，包括证明持有权的重要性。 9. 重新组织了文档结构，使其更易于理解和访问。 总的来说，CMP规范为公钥基础设施的证书管理提供了统一的接口，简化了相关操作，使用户可以更容易地管理和维护他们的数字证书。
  • Diff: 摘要 本文描述了互联网X.509公共密钥基础设施（PKI）证书管理协议（CMP）。定义了用于X.509v3证书创建和管理的协议消息，以及客户端系统与PKI组件之间的交互，如注册授权（RA）和认证机构（CA）。本文引入了支持关键实体管理和使用EnvelopedData的KEM密钥，并更新了关于PKI管理模型、要求、数据结构等部分内容。 主要区别： 1. 新增了对Root CA证书更新的支持。 2. 引入了EnvelopedData作为替代EncryptedValue的消息保护方式。 3. 增加了根CA初始化的功能。 4. 定义了请求CA证书、根CA更新、证书请求模板或证书撤销列表（CRL）更新等通用消息类型。 5. 支持使用KEM密钥进行证明拥有权的证明方法。 6. 更改了根CA初始化的方法。 7. 保留了消息确认机制，但增加了新的强制性消息确认方法。 8. 更新了消息格式以适应新的要求。 9. 指出了加密算法字段在证书状态中的用途。 以上这些更改保持了与之前版本的兼容性，同时为新的功能提供了基础。


3. draft-ietf-lamps-rfc6712bis-10

  • Title: Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP)
  • Authors: Hendrik Brockhaus(hendrik.brockhaus@siemens.com), David von Oheimb(david.von.oheimb@siemens.com), Mike Ounsworth(mike.ounsworth@entrust.com), John Gray(john.gray@entrust.com)
  • Summary: 本文讨论了在HTTP协议上如何层叠证书管理协议（CMP）。主要更新包括引入了以"/.well-known/cmp"路径开头的HTTP URI，并添加了新的协议组和选项来扩展URI结构。此外，文稿还删除了支持HTTP/1.0的条件，强调了HTTP是用于传递CMP消息的理想方式，因为其易于实现、能够跨越网络边界并广泛使用。同时，还对并发请求进行了考虑，确保它们能够正确处理延迟等异常情况。 总结：本文介绍了如何在HTTP协议上提供可靠的传输机制，以便传递CMP消息。它还指出了HTTP作为最佳实践的重要地位，并提供了有关如何利用HTTP进行可靠通信的详细说明。最后，文稿指出了相关的标准化组织和参考文献。
  • Diff: 新的英文标准文档描述了如何在HTTP协议的基础上，为证书管理协议（CMP）提供可靠的消息传输机制。主要变化包括： 1. 在RFC9480中引入了"/.well-known/cmp"前缀来标识CMP URI，并定义了一个新的协议组。 2. 实施了当HTTP请求失败时应响应错误的状态码规则。 3. 删除了RFC6712中的关于HTTP/1.0的支持要求。 4. 在RFC6712中增加了对HTTP/1.1支持的要求。 5. 删除了关于3.8节冗余信息的段落。 6. 引入了需要HTTP响应消息内容给应用的信息要求。 7. 简化了3.8节与当前HTTP/1.1版本之间的冗余性。 这些更新旨在改进HTTP层下传递CMP消息的方法，以增强其在可靠和高效方面的表现。


4. draft-ietf-lamps-cms-kyber-08

  • Title: Use of ML-KEM in the Cryptographic Message Syntax (CMS)
  • Authors: PRAT Julien(julien.prat@cryptonext-security.com), Mike Ounsworth(mike.ounsworth@entrust.com), Daniel Van Geest(daniel.vangeest@cryptonext-security.com)
  • Summary: 本文主要介绍了模块学习错误(Make Learning with Errors,简称MLE)在加密消息语法(Cryptographic Message Syntax, CMS)中的使用。它详细描述了如何将ML-KEM算法应用于CMS，以及其内部结构和参数设置。 总结如下： 1. 引言部分解释了ML-KEM的定义、特性、三个安全级别以及它们之间的关系。 2. 文稿详细讨论了使用ML-KEM算法在CMS中的直接应用，并给出了详细的处理流程。 3. 提出了证书和SMIME能力属性等概念，并对它们进行了简要说明。 4. 定义了相关标识符，包括NIST算法对象标识符(nistAlgorithms)，KEM算法对象标识符(kems)等。 5. 简要概述了安全性考虑，包括密钥管理和随机数生成等方面。 6. 对于IANA进行了规定，即分配了一个新的对象标识符（TBD1）以支持模块化的CMS。 7. 最后提供了几个参考文献和一个结论，强调了文档是草案状态并可能进行修改。
  • Diff: 新版本的英文标准文稿详细介绍了模块学习错误（Module Learning with Errors, ML-KEM）作为一种基于模块的量子安全密钥封装机制（KEM）。它由美国国家信息技术局（NIST）PQC项目标准化，并在密文消息语法（CMS）中被用于使用三个参数集：MK-KEM-512、ML-KEM-768和ML-KEM-1024。 关键点如下： 1. 新版本文档定义了ML-KEM算法的三个安全级别，并且这些级别的选择必须与期望的安全水平相匹配。 2. 在使用ML-KEM时，对于每个安全性级别，应确保内部组件的安全性配置一致。 3. 新版本文档提供了不同的哈希函数（如SHA-256）、摘要算法（如HKDF-Extract和HKDF-Expand）、以及支持不同密钥长度的密钥交换算法。 4. 每个安全性级别的ML-KEM都需要具有至少128比特预图像强度和一个密钥长度为128比特或更长的关键分发函数（KDF）。 5. 为了实现ML-KEM算法的正确工作，需要保护ML-KEM私有密钥、密钥加密密钥、内容加密密钥、消息认证密钥和内容验证密钥。 总的来说，新的标准文档提供了一个详细的ML-KEM算法的说明，并包括了其如何与密文消息语法（CMS）一起工作的具体步骤。这个文档将帮助开发者更好地理解并应用这种新的量子安全密钥封装机制。

pquip

1. draft-ietf-pquip-hybrid-signature-spectrums-06

  • Title: Hybrid signature spectrums
  • Authors: Nina Bindel(nina.bindel@sandboxaq.com), Britta Hale(britta.hale@nps.edu), Deirdre Connolly(durumcrustulum@gmail.com), Florence D(florence.d@ncsc.gov.uk)
  • Summary: 本文主要讨论了使用混合数字签名方案的重要性，以及它们在安全性和过渡到量子计算技术方面所面临的挑战。文中还详细介绍了不同类型的混合签名方案及其可能的安全目标和实现要求。 主要目标包括： 1. 混合认证：确保至少一个组件签名是安全的。 2. 纠错验证：通过组合多个签名来实现冗余检查以防止混淆或篡改。 3. 双重签名：确保每个组件签名都是有效的。 4. 合法性：通过正确验证消息和签名来提供身份证明。 5. 整体性能：保证签名操作尽可能高效。 关键概念如下： 1. 混合签名（hybrid signature）：由两个或更多种不同的签名算法组成。 2. 高度非分离（high non-separability）：指攻击者不能仅仅删除其中一个组件签名而不会留下任何痕迹。 3. 弱非分离（weak non-separability）：攻击者可以删除一个组件签名而不影响其他签名。 4. 强非分离（strong non-separability）：攻击者不能仅凭一个组件签名就删除整个签名。 5. 同时验证（simultaneous verification）：确保所有组件签名同时被验证。 6. 后向兼容性（backward compatibility）：允许接受旧版本系统的签名。 总结来说，文稿提供了关于如何设计和实现混合签名方案的一些建议，并强调了这些策略对过渡到量子计算机时代的影响。它还讨论了一些可能的安全威胁，如时间、复杂性等，并给出了应对这些威胁的方法。总的来说，文稿为混合签名方案的设计和发展提供建议。
  • Diff: 该文档提出了关于混合签名方案设计目标和安全考虑的一些分类和属性，包括证明可携性、组件签名不分离、双向/单向兼容性、混合通用性、同时验证等。讨论了这些安全属性之间的冲突，并提出了一些建议。与旧版不同的是，它更加详细地描述了各个安全属性的具体含义，以及它们如何在设计中相互作用。此外，文档还提到了一些未来可能的发展趋势和技术挑战，如量子计算机的安全性和使用场景的变化等。总的来说，该文档为混合签名方案的设计提供了更全面的信息，有助于设计师和实现者更好地理解和选择合适的混合签名方案。

scim

1. draft-sehgal-scim-delta-query-02

  • Title: SCIM Delta Query
  • Authors: Anjali Sehgal(anjalisg@amazon.com), Danny Zollner(zollnerd@microsoft.com)
  • Summary: 这篇文稿是关于扩展标准跨域标识管理(SCIM)协议的功能，以允许客户端请求服务提供商更新的更改。这些更改仅包括那些在客户端上最近观察到的资源。这是SCIM 2.0中的一个新功能，旨在提高效率并降低资源消耗。它通过添加新的路径扩展点、改变查询结构和修改响应格式来实现这一目标。该文档还定义了相关术语，并提供了详细的示例。 总的来说，这篇文稿主要讨论了如何使用SCIM 2.0协议扩展其功能，以便客户端可以请求服务提供商提供更新的更改，这些更改仅包括那些在客户端上最近观察到的资源。这个新功能旨在提高效率并降低资源消耗。它通过添加新的路径扩展点、改变查询结构和修改响应格式来实现这一目标。此外，该文档还定义了相关术语，并提供了详细的示例。
  • Diff: 是2024年发布的一份关于扩展SCIM协议功能的文档。相较于之前的版本，《SCIM Delta Query》的主要区别在于： 1. 增加了新的路径扩展点，包括一个用于查询特定资源类型的新路径。 2. 增加了新的“Delta Tokens”部分，定义了获取和管理Delta Token的方法。 3. 新增了一个名为“ServiceProviderConfig”的复杂属性，用于指示服务提供者支持的Delta查询配置选项。 4. 修订了“Delta Query Requests”部分，增加了对请求参数的解释，并更新了搜索请求的schema定义。 5. 为Delta Query响应新增了两个子属性：“ResourceType”和“ChangeType”，并调整了数据结构以适应这些变化。 总的来说，新版文档更注重于添加新的API扩展点，使Delta Query在实际使用中的灵活性更高。

WIT

quic

1. draft-gage-quic-pathmgmt-01

  • Title: QUIC Path Management for Multi-Path Configurations
  • Authors: Bill Gage(billgage.ietf@gmail.com)
  • Summary: 该文档主要讨论了基于多路径配置的QUIC协议。它定义了一个新的操作模型，即在不改变连接管理操作的情况下允许多个路径同时用于传输非探测帧。此外，它还提供了路径管理的相关参数和机制。 文稿总结： 1. 简介：描述了基于多路径配置的QUIC协议，允许多个路径同时用于传输非探测帧。 2. 多路径管理：支持同时使用不同的路径来交换QUIC帧，与传统的单路径概念不同。 3. 高级概述：介绍了一种高效率的多路径配置方法，通过重用现有机制实现。 4. 路径标识：为每个路径分配一个唯一的标识符以区分它们，从而实现了对路径管理的独立性。 5. 路径激活和删除：提供新路径激活、迁移和放弃功能，确保多路径工作正常进行。 6. 路径维护：定义了一些重要的状态值和规则，例如路径状态、优先级等。 7. 包分发：定义了包发送的策略，确保包正确地从可用路径传递。 8. 数据丢失检测：利用ACK确认和超时时间来检测数据丢失，并提供恢复措施。 9. 连接管理错误处理：扩展了QUIC的错误代码表，添加了针对多路径设置的新错误码。 总之，该文档详细介绍了如何在不更改传统连接管理的基础上实施多路径QUIC，以及相关的路径管理和连接管理流程。
  • Diff: Quic工作小组 互联网草案 建议状态：实验性 到期日期：2025年7月13日 文档格式：实验性 Quic多路径管理 draft-gage-quic-pathmgmt-01 此文档定义了Quic在没有连接管理流程的情况下独立于RFC9000中的连接管理流程。它允许多个路径之间的配置，通过任何已建立的端点间路径来传输QUIC分组。由于连接标识符与路径无关，因此收到任何路径上的任何分组都将按照单个路径构建处理。尽管如此，Quic路径特定过程仍然遵循RFC9000，包括重用该协议中的机制、使用相同的数据包头格式以及不修改其帧格式。但是，Quic对[RFC9002]进行了更改，以应对路径依赖特性，如最大数据限、RTT和拥挤控制。 相比于旧版，主要区别在于： 1. 支持同时在多个路径之间传输非探测帧； 2. 尽管只定义了一个路径，但可以同时使用多个路径进行通信； 3. 可以明确地管理使用的路径； 4. 允许接收方拒绝使用新的路径，并且可以改变指定路径的优先级； 5. 采用不同的路径参数来调整最大UDP分组大小等。