【每日文稿】2025-01-21
今日共有25篇文稿更新，涉及7个area里的21个WG
ART
cbor
- Title: CBOR: On Deterministic Encoding and Representation
- Authors: Carsten Bormann(cabo@tzi.org)
- Summary: 本文主要对CBOR数据格式中的“确定性编码”这一概念进行了阐述和介绍。主要内容包括： 1. 基本概念：解释了什么是确定性编码，以及其与常规编码的区别。 2. 使用场景：讨论了几种可能的应用场景，如诊断、缓存和安全签名等。 3. 支持方式：介绍了通用编码器和解码器如何支持确定性编码，并给出了具体的选择建议。 4. 指标考虑：详细说明了媒体类型定义、需要使用映射的关键点等方面的支持要求。 5. 实施考虑：讨论了如何在编码器和解码器中实现确定性编码，以及应用层规则的重要性。 6. 应用规则：提出了基于数据模型的特定转换规则，以便于通用编码器支持确定性表示。 7. 定义和规范：简要介绍了相关标准（例如ISO 10646）和工作流程指南（例如RFC 8259）。 8. 与JSON的关系：探讨了将确定性编码应用于JSON的可能性及其潜在优势。 9. 安全考虑：强调了确保确定性编码过程的安全性的必要性。 10. 后记：总结了起草该文档的过程及注意事项。
- Diff: 该文档主要提供了一个关于决定性编码和表示（Deterministic Encoding and Representation）的详细解释，包括其定义、应用场景、支持方式以及实施考虑等。与之前的版本相比，本文增加了更多的实用信息，如对应用层处理的描述，以及在通用编码器和解码器中的建议。此外，还提供了使用基于特定应用要求的转换过程的示例，以满足不同的需求。 总的来说，本文是对之前版本的一个补充和完善，旨在为实现CBOR数据的有效性和可扩展性提供更多指导和支持。它不仅丰富了现有知识库，也增强了对未来技术发展的理解。
- Title: CBOR Common Deterministic Encoding (CDE)
- Authors: Carsten Bormann(cabo@tzi.org)
- Summary: 本文主要探讨了标准通用报文格式（Standard Generalized Binary Object Representation）中的“确定性编码”概念。文稿详细介绍了CBOR数据结构和标准化，以及如何在通用编码器中使用它作为可选择的功能。它还讨论了如何定义应用程序特定的、不兼容的变异版本的CDE，并提出了一种称为“基础序列化规则”的限制形式，用于增加与有限（例如受限）CBOR解码器实现的互操作性。最后，文稿总结了本文对CBOR标准贡献的重要性和适用性。 总的来说，这篇文稿提供了有关CBOR确定性编码的基础知识，并强调了其对应用程序和平台之间的互操作性的潜在益处。它为开发者提供了一个可以共享的应用程序级定量化表示规则的方法，以处理某些情况下难以完全确定的数据类型。这些规则允许应用开发者决定在特定上下文中使用的编码策略，从而增加了系统的稳定性并减少了开发工作量。
- Diff: （简称CDE）是针对CBOR（标准94）的一种新的编码规范，提供了更灵活的选择空间来满足特定应用的需求。它的核心思想是强制使用一些预定义的编码方式，比如默认使用零值的定长编码和指定特定格式的特殊零值的处理等。 此外，它还支持多种数据定义语言，如CDDL，用来指示应用层是否需要进行CDE编码。同时，它也强调了对于不同平台之间的兼容性问题，以及如何在不同的应用程序之间共享数据结构以实现共同编码的目标。 总的来说，CDE相比于旧版标准化文档，增加了更多的灵活性和可选择性，使得各种应用可以根据自己的需求对CBOR数据进行定制化编码。这对于促进跨应用的数据交换和互操作性是非常有帮助的。
mlcodec
- Title: Extension Formatting for the Opus Codec
- Authors: Timothy B. Terriberry(tterribe@xiph.org), Jean-Marc Valin(jeanmarcv@google.com)
- Summary: 本文更新了RFC6716文档，以扩展Opus编码器和解码器的功能。新增功能包括允许在Opus编码器中插入额外的填充数据（padding），以及对长度信息的支持。此外，还定义了一个新的“Opus”组，该组将包含所有未来的Opus扩展ID，并为这些ID分配了唯一的编号。本文还讨论了与媒体类型注册相关的扩展参数，以及如何在客户端和服务器之间传递这些参数。 总的来说，本文更新了Opus编码器和解码器，以支持更多可选功能，并且为未来的新扩展ID分配了唯一编号。它还定义了新组，用于管理未来Opus扩展ID，从而提供了更好的兼容性和标准化。
- Diff: 是关于扩展Opus编码器（RFC6716）的一种方式，以保持互操作性，同时添加可选功能。在新的版本中，将ID 0定义为原始填充，它与原定义相同。另外，对ID 1到ID 119定义了未分配的扩展，由IANA负责分配，并对长度标志进行了更新。此外，新增了实验性的ID和一个扩展类型ID 127。 最重要的是，该文档更新了Opus媒体类型注册文件（[RFC7587]），增加了两个参数：extension:接收者支持的扩展ID列表；sprop-extensions:发送方支持的扩展ID列表。所有这些扩展都必须被标记为“standards action”来避免可能的兼容性问题。 总的来说，新版本的主要区别在于增加了一些实验性的扩展ID、改进了长度信号处理以及对Opus媒体类型注册文件做了修改。
GEN
gendispatch
- Title: IETF Experiments
- Authors: Ron Bonica(rbonica@juniper.net), Adrian Farrel(adrian@olddog.co.uk)
- Summary: 本文主要讨论了在互联网标准文档中描述实验性RFC（Research or Development Effort）的规定，以及如何编写实验性RFC。文稿强调了实验RFC必须清楚地表明其为实验性质而非标准发布，并详细介绍了实验RFC的要求和特征，包括代码点分配、安全性和隐私考虑等。此外，还提出了如何报告实验结果和建议的下一步行动等内容。总的来说，该文提供了关于实验性RFC的详细指导和指南，旨在确保实验RFC的安全性和有效性，并促进其向标准发布的过渡。
- Diff: 以上新版本的英文标准文稿描述了我太网组织对实验性RFC（即在研究或开发阶段的工作）的一些要求和指南。主要内容包括： 1. 对于实验性的RFC，必须明确说明其为实验性质而非标准发布，并概述其目的和范围。 2. 实验性的RFC应该详细描述实验，使其可以被复制并识别在部署中，以及如何保证实验不会危害网络或干扰其运作。 3. 必须列出实验所需的配置参数，结束日期，收集到的指标和观察结果等信息。 4. 实验性RFC应讨论风险管理和安全性考虑，如需要的资源、可能的影响、成本等。 5. 应提供成功或失败的信息报告方式，建议模板，以及后续行动建议等。 与旧版相比，新版本增加了关于代码点使用的指导，规定不能使用从管理这些代码点的注册机构处获取的代码点，以避免影响实验的安全性。此外，还引入了新的需求级别语言和关键词来帮助描述实验性和部署性。
INT
dtn
- Title: Bundle Protocol Endpoint ID Patterns
- Authors: Brian Sipos(brian.sipos+ietf@gmail.com)
- Summary: 本文主要讨论了EID(Package Protocol Endpoint ID)和IPN(EID Pattern)的定义与实现。文稿提出了一种新的包协议端点ID（EID）模式，用于描述多个端点ID，并使用文本形式进行编码。这种模式可以在不增加网络开销的情况下实现端点ID的统一处理。 文中还详细介绍了PKIX (Public Key Infrastructure Using X.509)等公共密钥基础设施中的其他名称（Other Name）表，以及如何将EID模式嵌入到这些表中，以支持在证书中包含端点ID或端点ID模式作为身份验证信息的功能。文稿对EID模式的安全性进行了讨论，并提供了相应的建议。 总的来说，本文为EID模式及其应用提供了一个基础框架，有助于实现更高效、灵活的端点ID管理。
- Diff: 该文档扩展了包协议（BP）的端点标识符（EID）概念，并将其扩展为端点标识符模式（EID模式），用于分类任何端点ID。相比旧版标准文稿，其主要区别在于： 1. 使用了新的文本和二进制编码形式。 2. 定义了一个公共密钥基础设施使用X.509（PKIX）其他名称模式来包含EID模式和处理规则来匹配EID。 总的来说，本文档通过定义一个逻辑模型来表示端点标识符模式和它们在不同体系结构中的应用，例如与公共密钥证书、包协议以及网络层相关标准如TCP CL等的整合。
OPS
anima
- Title: BRSKI Cloud Registrar
- Authors: Owen Friel(ofriel@cisco.com), Rifaat Shekh-Yusef(rifaat.s.ietf@gmail.com), Michael Richardson(mcr+ietf@sandelman.ca)
- Summary: 本文主要介绍了BRSKI云注册器的使用方法，以及在没有本地域控制器的情况下如何使Pledge发现和信任其运营商管理的基础设施。它还讨论了如何将Pledge重新定向到运营商的域控制器或云注册器提供的EST服务。 该文档定义了一个新的机制来通知运营商的云注册器，并提供了一种将Pledge引导至运营商域控制器的方法。此外，文档还定义了一个新的Voucher类型的属性来指示EST服务器。 总体来说，该文稿为未接入本地网络的设备提供了跨域通信所需的注册信息，从而帮助它们访问运营商管理的基础设施。它为Pledge的网络连接提供了灵活性，使其能够从一个区域直接转向另一个区域。
- Diff: 该文档提供了关于在无本地网络基础设施的情况下使用Cloud Registrar进行远程密钥基础设施在线板载的方法。具体来说： 1. 在无本地网络基础设施的情况下，设备通过云注册器（Cloud Registrar）找到其运营商维护的基础设施。 2. 如果云注册器不支持BRSKI机制，则可以向设备发放Voucher，其中包含运营者的EST服务器域名。 对比旧版的英文标准文稿： 1. 稍微增加了对Pledge和Owner Registrar之间的交互细节的说明，例如如何将Pledge与Owner Registrar关联起来以及如何处理Voucher请求等。 2. 引入了YANG扩展以允许使用Voucher发起的重定向，并且详细描述了如何操作。 3. 增加了关于安全更新、信任锚、HTTP重定向考虑点等内容的讨论。 总的来说，这个新版标准文稿更加详细地规定了如何实现远程密钥基础设施在线板载的过程，包括云注册器的功能和工作原理，以及如何与运营商维护的基础设施进行交互等关键信息。相较于旧版，增加了更多的细节和实用性建议，更有利于实际应用。
dnsop
- Title: Deprecate usage of ECC-GOST within DNSSEC
- Authors: Wes Hardaker(wjhns1@hardakers.net), Warren "Ace" Kumari(warren@kumari.net)
- Summary: 本文主要讨论了在DNS安全扩展(DNSSEC)中废弃使用GOST R 34.10-2001和GOST R 34.11-94算法的问题。这两个算法由于俄罗斯联邦技术监督和计量局（Rosstandart）的公告而被废止，且已经被取代为GOST 34.10-2012和GOST 34.11-2012。此外，该文档还详细介绍了如何处理不再推荐使用的ECC-GOST算法。 该文档特别指出，为了增加DNSSEC生态系统的安全性，需要删除与已废弃使用的算法相关的支持和验证。例如，在创建DS记录时必须避免使用ECC-GOST算法，并在使用这些算法进行签名、验证或部署时应该谨慎对待。同时，对于已经发布或上传的旧版本DS记录，应该立即采取行动来替换它们以符合最新的安全要求。 最后，该文档提出了一些对IANA管理机构的具体建议，包括更改相关注册表中的字段值，以确保新的安全标准得到实施和遵守。
- Diff: 上述新版本的英文标准文稿主要区别如下： 1. 删除了使用GOST R 34.10-2001和GOST R 34.11-94算法在DNSSEC中的相关描述。 2. 提出了使用GOST R 34.11-94、GOST 34.10-2012和GOST 34.11-2012作为替代选项来实现DNSSEC。 3. 针对不同类型的资源记录（如DS、DNSKEY和RRSIG）提供了不同的安全要求和处理方式，以确保其安全性。 4. 强调了对于部署这些算法的区间的警告，建议立即切换到更安全的加密技术。 5. 提出了IANA组织需要更新相关算法列表的状态，并且要求停止支持这些算法。 总的来说，新的文档主要侧重于删除已过时的算法，强调了安全性的重要性，并提供了一套更加推荐的安全策略。与旧版相比，新版更加注重实用性和指导性，为当前的DNSSEC环境做出了必要的调整。
- Title: Deprecating the use of SHA-1 in DNSSEC signature algorithms
- Authors: Wes Hardaker(wjhns1@hardakers.net), Warren "Ace" Kumari(warren@kumari.net)
- Summary: 摘要 随着各种攻击对SHA-1算法的削弱，其安全性的不断减弱。由于存在更强大的验证算法，如RSA SHA-256、ECDSAP256SHA256、ED25519和ED448等，因此不再适合用于DNSSEC。本文进一步规定了在创建DNSKEY和RRSIG记录时不能使用RSASHA1和RSASHA1-NSEC3-SHA1算法。 安全性考虑 此文档通过指导签名者选择更兼容的验证算法来减少由于缺少SHA-1支持而导致的无法验证的风险。 操作考虑 当前使用SHA-1验证器的用户应立即切换到有更强加密强度的验证算法，例如RSA SHA-256、ECDSAP256SHA256、ED25519和ED448等。 IANA考虑 IA内设应将“用于DNSSEC Delegation”字段设置为必须不使用SHA-1（1），并将“用于DNSSEC Signing”列中的RSASHA1（5）和RSASHA1-NSEC3-SHA1（7）算法设置为必须不使用SHA-1。 引用 [DNSKEY-IANA] IANA, "Domain Name System Security (DNSSEC) Algorithm Numbers", n.d.,
- Diff: 本文档是关于删除使用 SHA-1 在 DNSSEC 标签中的应用。主要区别在于： 1. 删除了对 SHA-1 的支持。 2. 提示用户选择更兼容的签名算法。 此外，还更新了参考文献、引用和相关链接。总体而言，文档的重点是提醒用户考虑安全性和性能因素来选择合适的签名算法。
green
- Title: Requirements for Energy Efficiency Management
- Authors: Emile Stephan(emile.stephan@orange.com), Marisol Palmero(mpalmero@cisco.com), Benoît Claise(benoit@claise.be), Qin Wu(bill.wu@huawei.com), Luis M. Contreras(luismiguel.contrerasmurillo@telefonica.com)
- Summary: 是基于RFC6988和绿色工作组（GREEN）讨论会的相关成果，重新评估并更新了对网络设备节能管理的需求。文稿强调了在能源效率管理方面需要关注以下几个核心目标： 1. 收集和更新节能网络管理系统需求。 2. 定义不同场景下的节能网络管理使用案例。 文稿从能源管理框架、能耗报告、实时能源计量等方面总结了相关的能源效率管理需求，并将这些需求整合到绿色工作组的文档中，以确保标准规范能够反映当前需求。同时，它也列出了收集到的初始要求，旨在为后续制定更具体的节能网络管理标准提供基础。
- Diff: 上述新版本的英文标准文稿主要分为以下几个部分： 1. 引言：概述了能源效率管理的要求以及对RFC6988和最近绿营讨论的需求的整合。 2. 使用案例：列举了一些典型的应用场景，如逐步迁移至绿色网络设备、选择性减少网络中的能量消耗等。 3. 要求提取自拥护者文档：回顾了之前BoF期间提出的能源效率管理需求。 4. 绿色能源效率管理要求从RFC6988bis中提取：这些要求仍然需要进一步细化并以表格形式排列。 5. 海外工作坊讨论框架：概述了讨论过程中关于能源效率管理的分层功能（发现、监控和控制）。 6. 安全考虑：包括安全的能源管理、隔离不足的安全实体、可选的功能限制等问题。 7. 标签和参考文献：详细列出了所有引用的标准规范。 8. 开放问题：明确列出了一些有待讨论或收集的开放问题。 总的来说，相较于之前的版本，该新版着重强调了能源效率管理和现有绿色网络技术的融合，并更详细地分层化了要求，便于后续制定具体的技术实现指南。此外，也更加注重安全性和生命周期管理方面的细节。
iotops
- Title: Comparison of CoAP Security Protocols
- Authors: John Preuß Mattsson(john.mattsson@gmail.com), Francesca Palombini(francesca.palombini@ericsson.com), Mališa Vučinić(malisa.vucinic@inria.fr)
- Summary: 本文分析了不同安全协议在CoAP上的安全性对比，包括验证交换、保护数据和处理应用程序数据。针对CoAP的安全性，本文研究了以下方面： 1. 对比了验证交换的大小，包括密钥交换航班的大小以及每帧的过载。 2. 分析了加密和认证应用层数据时使用的记录层（例如DTLS、TLS、cTLS和OSCORE）的大小。这些记录层不考虑分组拆分、如何组合记录层消息到记录、以及底层协议对选择应用程序层数据大小的影响。 3. 比较了使用不同算法和选项时的总过载。例如，对于DTLS 1.3，它可能依赖于不同的分组拆分方式，如动态上下文压缩或静态DH X.509/ECDSAPSK等；而对于OSCORE，则可能依赖于包含的应用程序选项的数量以及ID Context长度。 4. 研究了不同的部署情况下的关键点，比如网络类型（低功耗个人区域网）、传输速率和通信量限制等。在多跳网络中，过大的负载可能会导致不可接受的时间完成时间，因为将大量帧碎片化并等待发送每个帧之间的时间。 总的来说，本文旨在提供一个比较性的视角，帮助开发人员在有限的资源下做出更明智的选择，以确保CoAP的安全性和性能。
- Diff: 根据上面的分析和总结，新版本的英文标准文稿对CoAP安全协议进行了比较，详细分析了它们在大小和过负荷方面的差异。 主要区别在于： 1. 基于不同的参数和假设，计算了不同协议下关键交换航班和每包消息大小过载的估计值。 2. 对比了DTLS、EDHOC、cTLS、OSCORE等协议的安全保护层的大小和过负载。 3. 比较了基于连接ID的不同选项（例如，是否使用Connection ID）对关键交换航班大小的影响。 4. 提供了更有效的编码方法（如x25519、ed25519），以减少关键交换航班的大小和过载。 总的来说，新版本文稿通过详细的算法和配置选择，提供了对CoAP安全协议性能的关键见解。这些信息对于设计优化CoAP网络架构至关重要。
netconf
- Title: NETCONF Private Candidates
- Authors: James Cumming(james@cumming.org), Robert Wills(rowills@cisco.com)
- Summary: 本文主要探讨了如何在Netconf协议和Restconf协议中使用私有候选者来支持多客户端同时修改配置并确保只对定义的变更进行提交。它描述了两种不同类型的私有候选者，即共享候选配置数据集和私有候选配置数据集，并讨论了它们之间的差异。 文档更新了两个RFC：RFC6241（Netconf）和RFC8526（Restconf）。其中，RFC6241新增了与私有候选者相关的特性；RFC8526扩展了与网络管理数据存储架构相关的特性。此外，还提出了一个新的操作“update”以实现两步更新过程。 最后，文档提到了对IANA、安全性和参考文献的考虑，并建议将新添加的NETCONF能力注册到RFC列表中。
- Diff: 新的英文标准文稿种机制来扩展网络配置协议（NETCONF）和RESTCONF协议，以支持多个客户端在同时进行配置更改并确保他们只提交那些定义的更改。主要内容包括： 1. 描述了使用私有候选者的限制、缓解策略和解决方案。 2. 修改了现有的两个RFC文档：RFC6241和RFC8526。 3. 对RFC9144进行了修改，以描述如何与私有候选者交互。 主要区别在于： 1. 提供了私有候选者的概念和实现方法，解决了NETCONF和RESTCONF同时操作时导致的冲突问题。 2. 更多地关注了私有候选者对性能提升和用户友好性的影响，而不是简单地阻止其他用户编辑配置。 3. 增加了系统级冲突解决规则，使得在某些情况下可以自动或手动处理冲突。 总的来说，新的标准文稿提供了更全面、更灵活的私有候选者方案，能够有效管理和优化网络配置过程中的协作和冲突处理。
netmod
- Title: YANG Semantic Versioning
- Authors: Joe Clarke(jclarke@cisco.com), Robert Wilton(rwilton@cisco.com), Reshad Rahman(reshad@yahoo.com), Balázs Lengyel(balazs.lengyel@ericsson.com), Jason Sterne(jason.sterne@nokia.com), Benoît Claise(benoit@claise.be)
- Summary: 本文主要讲述了网络管理协议Netconf和Restconf使用Yang版本进行版本化。Yang是用于描述数据结构的XML语法标准，而版本化是为了管理不同版本的文件和依赖关系。 Yang版本可以用来表示不同版本的数据结构，并且这些版本可以互相比较和转换。Yang版本化的优点在于它提供了一种更简单、更容易理解的方式来管理复杂的文件系统，同时也可以避免因为版本升级导致的问题。 然而，版本化的缺点是可能会引入更多的依赖关系和版本控制问题，例如需要维护多个版本的文件。此外，版本化还可能会影响应用程序的兼容性和可测试性。 总之，Yang版本化是一种有用的工具，但同时也有一些挑战需要克服。
- Diff: 本文档定义了新的Yang扩展，该扩展可以为Yang文档（如模块、子模块和包）添加一个版本标识符，用于表示与前一个版本不同的更改，并提供了控制如何使用这些变更的规则。这个新版本也允许更新到更早版本的Yang文档，以修复bug或进行增强。 相比于旧版本，主要有以下区别： 1. 新版文档增加了对Yang Semver的详细解释。 2. 新版文档规定了Yang Semver的格式和语法，以及如何在Yang文档中使用它。 3. 新版文档还描述了分支限制，包括不支持某些分支策略。 4. 新版文档指出了不同修改类型的可能影响，并提供了处理这些影响的方法。 5. 新版文档提供了关于如何使用Yang Semver在模块开发期间的应用指南。 总的来说，新版文档提供了更加灵活和强大的Yang Semver版本管理机制，使Yang文档开发者能够更好地管理和维护他们的Yang文档。
nmop
- Title: Some Key Terms for Network Fault and Problem Management
- Authors: Nigel Davis(ndavis@ciena.com), Adrian Farrel(adrian@olddog.co.uk), Thomas Graf(thomas.graf@swisscom.com), Qin Wu(bill.wu@huawei.com), Chaode Yu(yuchaode@huawei.com)
- Summary: 本文主要介绍了网络故障和问题管理的相关概念和技术。首先，文稿定义了网络层以下的重要概念，包括网络监控、网络观测能力等，并解释了这些概念之间的关系。接着，讨论了网络故障和问题的概念及其分类。此外，还提到了事件、状态、症状以及其与原因之间的关系。最后，文稿对网络安全和隐私保护进行了简要探讨。 总结而言，该文旨在提供一个关于网络故障和问题管理的基础框架，帮助实现更好的网络管理和服务质量。它强调了理解和处理网络故障和问题的重要性，同时也指出了在实现这一目标时可能遇到的一些挑战和限制。
- Diff: 新版本的英文标准文稿主要围绕网络故障管理和问题管理这一主题，提供了有关术语、定义、工作流程等核心概念的详细说明。与旧版相比，新文档引入了以下几方面的变化： 1. 更加清晰地划分了上下文性词汇，帮助读者理解不同层级网络管理的概念和关联。 2. 集成了更多基于RFC的前导信息，如RFC3877和RFC8632中的定义，使后续文件在描述这些元素时可以保持一致性。 3. 提供了一些有用的辅助性词汇，比如“症状”、“原因”，可能对理解和使用网络监控工具有所帮助。 4. 深入讨论了事件（Event）、状态(State)、条件(Condition)以及变更(Change)等基本概念，强调了这些概念之间的关系及其在事件处理过程中的作用。 5. 强调了阈值驱动的重要性，特别是在评估或通知资源的数值时。 总的来说，新版本通过提供详尽的定义和解释，帮助读者建立了一个关于网络故障管理和问题管理的完整框架，并为后续相关工作提供了基础性的知识积累。
RTG
lsr
- Title: An Algorithm for Computing Dynamic Flooding Topologies
- Authors: Sarah Chen(sarahchen@arista.com), Tony Li(tony.li@tony.li)
- Summary: 本文讨论了一种算法，用于计算动态泛洪拓扑。传统的链路状态路由协议在密集网络结构下会过量泛洪。动态泛洪通过解耦洪水拓扑与物理拓扑来缓解这个问题。链路状态更新只在网络中少量区域泛洪，而数据流量则继续沿用物理拓扑。 本文描述了一个从稠密图中获取稀疏子图的方法。该子图具有某些理想属性，可以作为动态泛洪的洪水拓扑使用。本文并未声称算法是优化的，而是提出一种实用且易于实施的方法，并希望未来的研究和改进能提高结果。 本文还介绍了实现类似算法所需的算法细节。本文没有提出将此算法标准化或工作组是否应该将其作为标准工作进行进一步标准化的工作，但是工作组无反对意见。本文也不主张将此算法标准化。
- Diff: 上述新版本的英文标准文稿详细介绍了动态网络中如何通过算法计算并构建一个更有效的动态拓扑结构来减少网络流量。与旧版本相比，有以下几个显著区别： 1. 算法更为简单实用：旧版提出了复杂的迭代算法，而新版使用了更简单的循环和路径选择方法。 2. 计算目标更加明确：旧版旨在找出最理想的收敛拓扑结构，而新版则直接为目标减小链路状态协议数据包的传播延迟。 3. 比较关注实际应用需求：旧版更多是理论探索，而新版设计是为了实现具体的实时应用需求。 总的来说，新的标准文稿更注重实际应用，减少了不必要的复杂性，并简化了算法以更好地满足动态网络环境的需求。
mpls
- Title: Deterministic Networking specific MNA
- Authors: Greg Mirsky(gregimirsky@gmail.com), Balazs Varga(balazs.a.varga@ericsson.com)
- Summary: 本文是关于使用MPLS数据平面实现确定网络(Deterministic Networking)中的流(MNA)的技术。MNA允许在MPLS标签栈中放置特定的参数，如流标识符（Flow-ID）、序列编号（SeqNum）和延迟信息（LatencyInfo）。这些参数可以用于流分发、延迟限制以及服务保护。为了确保延迟要求，并且可以通过PW技术实现多段路由（S-Labels），这些参数需要通过d-CW技术进行编码。 MNA允许将流参数封装在一个单一的MNA数据结构中，并且可以在整个网络中使用相同的格式来传输这些参数。此外，还可以使用附加NASes（比如流量标识符NAS和延迟NAS）来携带其他相关信息。该标准定义了如何使用特定的NASes来传递流参数，以实现跨网络转发时的服务层功能。同时，还考虑了安全性、IANA代码分配等问题。
- Diff: 这篇新的英文标准文档讨论了在IPv6网络中使用MPLS数据平面实现分布式网络功能（DetNet）的相关技术细节。主要内容包括： 1. 引言：概述了DetNet工作组定义的Packet Replication Function和Packet Elimination Function（PRF/PEF），以及这些功能如何导致帧丢失等问题。 2. 术语解释：详细介绍了使用的术语，如DetNet、MNA、NAS等，并描述了它们之间的关系。 3. DetNet特定的MNA：讨论了用于在IPv6网络中转发的三种信息元素，包括流标识符（Flow-ID）、序列号（SeqNum）和延迟信息（LatencyInfo）。MNA可以用来更好地处理DetNet包中的延迟约束，而不需要额外的后栈数据。 4. DetNet在网络适配层的信息传递：详细说明了在DetNet网络适配层中是如何传递这些信息元素的。例如，通过MNA将流标识符和序列号一起封装在标签堆栈中。 5. 安全性考虑：讨论了在IPv6网络中实施DetNet时的安全问题，并提出了解决方案。 6. IANA考虑：建议分配新的操作码值给MNA。 7. 作者地址：列出相关作者的联系方式。 与旧版文档相比，新版本的主要区别在于它更具体地阐述了在IPv6网络中使用MPLS数据平面实现DetNet的功能细节，特别是在处理帧丢包方面进行了深入探讨。此外，它还提供了关于如何安全地部署DetNet的指导原则。
- Title: MPLS Network Actions for Network Resource Partition Selector
- Authors: Tony Li(tony.li@tony.li), John Drake(jdrake@juniper.net), Vishnu Pavan Beeram(vbeeram@juniper.net), Tarek Saad(tsaad.net@gmail.com), Israel Meilik(israel@broadcom.com)
- Summary: 本文主要讨论了在多协议标签交换（MPLS）网络中使用MPLS网络动作（MNA）技术来携带网络资源分配选择器（NRPS）。本文提出了几种编码方案，这些编码方案能够将特定的标识符用于携带NRPS，并且符合MNA头编码格式。这些编码方案可以有效地避免碰撞和混淆，在确保安全性的同时，也为网络服务提供了灵活性。 此外，本文还探讨了对一些与安全相关的考虑，如：如何在MPLS网络中实施有效的安全措施，以及如何防止恶意节点影响网络转发的行为等。最后，本文总结了使用MPLS网络动作技术时的安全性和效率优势，并指出了未来的研究方向。
- Diff: 上述新版本的英文标准文稿讨论了如何使用多协议标签交换(MPLS)网络动作技术来在MPLS标签堆栈中携带网络资源分区选择器(NRP Selector)信息。与旧版本不同的是，该文档引入了一个新的编码格式，用于承载NRP Selector，并且讨论了一些关于如何实现这一目标的技术细节。此外，该文档还提供了有关IANA代码点分配的信息，以及相关的安全考虑和贡献者列表。总的来说，新版本为使用MPLS网络动作技术携带特定信息提供了一种新的方法，并详细介绍了相关技术规范。
pim
- Title: Multicast-only Fast Reroute Based on Topology Independent Loop-free Alternate Fast Reroute
- Authors: Yisong Liu(liuyisong@chinamobile.com), Mike McBride(mmcbride7@gmail.com), Zheng Zhang(zhang.zheng@zte.com.cn), Jingrong Xie(xiejingrong@huawei.com), Changwang Lin(linchangwang.04414@h3c.com)
- Summary: 是互联网工程任务组发布的一份关于快速重新路由协议和多播保护的研究报告。该报告讨论了在使用传统的链路状态内环网协议（IGP）时，如何利用拓扑独立回流备份路径（TI-LFA）来实现快速重路由，并且如何与多播快速重路由机制（MoFRR）结合使用以增强多播网络的冗余性和减少包丢失。 该报告提出了一种基于拓扑独立回流备份路径的解决方案，即通过TI-LFA预置一个备用转发条目来防止在具有特定网络拓扑环境中的未故障节点之间建立单播树。然而，在多播环境中，例如在使用标准链路状态内环网协议（IGP）和段路由（SR）场景下，由于存在限制性问题，这种机制仅适用于某些网络拓扑环境。为此，报告提出了一个新的基于拓扑独立回流备份路径的多播快速重路由方法，可以为多播服务提供全面的多播保护。 此外，报告还提供了示例图来展示不同网络拓扑环境下Ti-LFA和MoFRR如何协同工作。最终，报告概述了实施TI-LFA和MoFRR相结合的PIM所需的所有必要的协议扩展和操作考虑因素，确保在遇到故障时能够迅速重路由多播流量。 总之，本文提出的基于拓扑独立回流备份路径的多播快速重路由方案是一种有效的多播服务保护措施，它可以有效提高多播网络的可靠性并降低多播包丢失率。
- Diff: 新的标准文档提出了使用Topology Independent Loop-Free Alternate（TI-LFA）机制与Multicast Only Fast ReRoute（MoFRR）相结合来支持协议独立多播（PIM）。相较于旧版本，主要内容有： 1. 解决了传统MoFRR仅依赖于标准链路状态（Link State）内环网路径和分段路由（SR）场景下的限制，扩展到PIM网络中的多种部署情况。 2. 提出了基于TI-LFA的解决方案，通过在IP地址前增加节点标识符（Node SID）和邻接侧边索引（Adjacency SIDs）组成的Segment List来代替传统的递归冗余检测（RPF）矢量，以保护未到达目的地的节点或链接。 3. 在PIM过程中，利用TI-LFA计算出来的Segment List作为备用上游多播跳点（UMH），以便发送PIM二次加入消息逐跳转发，创建快速备份路径。 4. 完全兼容现有协议实现，并不需对中间节点的协议或转发功能进行更改，如果存在双向从源节点到接收器的节点选择冲突，则优先考虑无RPF矢量的加入。没有改变PIM会话冲突处理规则。 5. 为备份路径提供了一个附加的方法，旨在扩展现有多播系统保护范围。它与当前协议实施兼容，无需对协议或中间节点的转发功能进行修改。在有选择的情况下，非向量加好友可能被优先考虑，这意味着保护路径不会活跃起来。本文不改变与其他会话冲突相关的处理方式。对于会话属性冲突的指导，请参考RFC5384第3.3.3节。
rtgwg
- Title: Applicability of Bidirectional Forwarding Detection (BFD) for Multi-point Networks in Virtual Router Redundancy Protocol (VRRP)
- Authors: Greg Mirsky(gregimirsky@gmail.com), Jeff Tantsura(jefftant.ietf@gmail.com), Gyan Mishra(gyan.s.mishra@verizon.com)
- Summary: 这篇文档探讨了在多点网络中使用双向检测（bfd）来加快虚拟路由器冗余协议（vrrp）中确定活跃路由器失败的能力。它定义了如何将bfd扩展到使用ipv4和ipv6的vrrp广告消息进行多点bfd会话，从而更新rfc 9568。 该文档提出了一种方法，可以在不改变任何协议功能的情况下实现加速检测故障以影响vrrp功能的设备。它讨论了这个过程的安全性考虑，并提供了相应的参考文献。
- Diff: 该文档主要探讨了在多点网络中应用双向检测（BFD）以实现虚拟路由器冗余协议（VRRP）中的快速收敛问题，并定义了一个扩展的IPv4/IPv6 VRRP告警消息来启用点对多点（p2mp）BFD会话。这个扩展使得Backup Router可以在VRRP冗余组中使用p2mp BFD检测Active Router故障并最小化服务中断的能力。此外，还讨论了如何通过使用IPv4/IPv6 VRRP告警消息来支持p2mp BFD会话。 与旧版相比，主要的区别在于： 1. 引入了新的字段：BFD标志、Active Router Discriminator和IPvX地址。 2. 新增了IPvX地址作为源IP地址的功能。 3. 使用IPv4/IPv6 VRRP告警消息代替传统的动态路由选择。 4. 提供了一种方法来加速检测VRRP功能失败的影响，从而加快恢复速度。 这些改进旨在提供一个更高效、可扩展且能有效应对VRRP冗余场景的方法。
teas
- Title: A YANG Data Model for the RFC 9543 Network Slice Service
- Authors: Bo Wu(lana.wubo@huawei.com), Dhruv Dhody(dd@dhruvdhody.com), Reza Rokui(reza.rokui@gmail.com), Tarek Saad(tsaad.net@gmail.com), John Mullooly(jmullool@cisco.com)
- Summary: 本文定义了一个YANG数据模型来描述RFC9543网络切片服务。该模型可用于客户和提供者的网络切片服务接口之间，用于管理（例如订阅、删除或更改）网络切片服务。它还定义了网络切片服务模型（NSSM）的使用场景以及相关的属性。 NSSM提供了SLO和SLE模板，用于共享已有的SLO/SLE政策。此外，还定义了网络切片服务模型（NSSM），用于抽象化网络切片服务，并为客户提供一个通用的数据结构。在实现时，网络切片服务可以被映射到不同的连接构造上，这些连接构造是可分组的，并且可以共享相同的SLO/SLE配置。 总结而言，本文定义了一个统一的数据模型，用于描述网络切片服务的特性，使得客户和服务提供商能够方便地管理和操作网络切片服务。
- Diff: 本文档定义了用于RFC 9543网络切片服务（Network Slice Service）的数据模型。该数据模型可以被用来在运营商之间的网络切片接口中使用，提供网络切片服务到客户的服务请求。相较于旧版文档，新的文档引入了一些新的概念和细节： 1. 模型更加丰富：新增了对SLO、SLE模板以及网络切片服务组件的详细描述。 2. 提供更详细的SLO与SLE政策：提供了SLO和SLE的更多属性定义，如SDP位置信息、节点ID等。 3. 增加了对网络切片性能监控的描述：提供了关于如何实现和监控网络切片服务的方法。 4. 引入了附加考虑因素：例如ACL等安全措施的定义。 5. 管理服务标签：对于多个实际客户共享同一网络切片服务的情况，增加了管理服务标签的概念。 总的来说，新的文档为网络切片服务的设计与实现提供了更为详尽和细致的规定，有助于确保网络切片服务的安全性、稳定性与可扩展性。
SEC
cose
- Title: Ascon-AEAD128 for JOSE and COSE
- Authors: Dmytro Ochkas(dmytro.ochkas@imt-atlantique.fr), Hélène Le Bouder(helene.le-bouder@imt-atlantique.fr), Alexander Pelov(alexander.pelov@imt-atlantique.fr)
- Summary: 本文主要描述了Ascon-AEAD128在JSON Object Signing和Encryption（JOSE）和Cryptographic Object Signage and Encryption（COSE）中的序列化。Ascon是轻量级加密标准之一，它提供了轻量级认证加密服务。Ascon-AEAD128算法是一个用于加密和解密的数据包，并且在作为Ascon的一部分时被使用。该文档还讨论了Ascon-AEAD128的安全性分析和对IANA注册表的影响。总的来说，本文提供了一个关于如何将Ascon-AEAD128应用到JOSE和COSE结构上的建议。
- Diff: 本文档概述了JSON Object Signing和Encryption（JOSE）和CBOR Object Signing和加密（COSE）序列化方式与Ascon算法之间的关系。这些算法在轻量级密码学领域获得了一定的关注。 Ascon算法主要分为两部分：认证加密Ascon（Ascon-AEAD128）、以及两种扩展输出函数（XOF），分别是Ascon-AEAD128和Ascon-AEAD128a。Ascon是唯一允许用于认证加密的部分。 在使用COSE或JOSE结构时，需要确保密钥类型、长度和算法正确匹配。此外，在进行加密或解密操作时，应检查密钥是否满足相应的要求。 对于IV头参数，目前[IANA.cose]只定义了完整的初始化向量头部参数（IV，名称为5），而[IANA.jose]则同时支持非零值和初始化向量头部参数（Partial IV，名称为6）。因此，当指定多个这些头参数时，非零值头部参数必须优先于初始化向量头部参数。 总体而言，相较于旧版，本文更详细地介绍了Ascon算法和其应用，同时也提供了几个具体的例子来说明如何使用这些算法。此外，还增加了对新COSE和JOSE算法的注册请求，包括新增的Ascon-AEAD128算法。
lake
- Title: EDHOC PSK authentication
- Authors: Elsa Lopez-Perez(elsa.lopez-perez@inria.fr), Göran Selander(goran.selander@ericsson.com), John Preuß Mattsson(john.mattsson@gmail.com), Rafael Marin-Lopez(rafa@um.es)
- Summary: 本文主要讨论了Ephemerel Diffie-Hellman Over COSE (EDHOC)中的预共享密钥（PSK）认证方法。该方法使用预先生成的随机数来确保加密和解密过程的安全性，并且在发起者和接收者之间建立了身份保护，从而防止被动攻击。 本文提出了两种可能的验证方式：一种是直接从发送方发送PSK ID到接收方，另一种是在每次EDHOC通信过程中都必须发送一个额外的消息以确认接收方是否拥有正确的PSK。此外，本文还指出了PSK认证方法可能会遇到一些潜在的主动攻击风险。 总结来说，PSK认证方法提供了安全性和效率之间的平衡，特别适用于需要频繁交换密钥的应用场景。但是，它也可能受到某些攻击的影响，因此开发者需要注意如何正确管理和维护这些密钥。
- Title: EDHOC PSK authentication
- Authors: Elsa Lopez-Perez(elsa.lopez-perez@inria.fr), Göran Selander(goran.selander@ericsson.com), John Preuß Mattsson(john.mattsson@gmail.com), Rafael Marin-Lopez(rafa@um.es)
- Summary: 本文主要介绍了关于预共享密钥（PSK）认证方法在Ephemerel Diffie-Hellman Over COSE（EDHOC）协议中的应用。该认证方法允许节点通过预先共享的密钥进行差分哈希运算，从而实现完美前向保密性，并防止被动攻击者对通信进行监听和篡改。此外，它还支持会话重置功能，即先前连接的双方可以快速重建立安全通信，减少公钥操作的开销。总的来说，EDHOC-PSK认证方法提供了有效的隐私保护、性能优化以及高效的安全性。
- Diff: 该文档详细描述了在EDHOC协议中使用的Pre-Shared Key（预共享密钥）认证方法，包括认证流程、消息流和安全考虑等。相较于旧版的[RFC9528]，主要区别在于： 1. 新增了PSK身份保护措施：当前的EDHOC方法仅保护了发起方的身份，而新增的PSK认证方法还保护了响应方的身份。 2. 增加了PSK重命名机制：为了防止长期隐私风险，定期更新CRED_PSK和ID_CRED_PSK有助于避免静态密钥标识带来的潜在威胁。 3. 引入了外部授权数据：可以同时发送额外的信息如EAD_3和EAD_4或通过OSCORE消息与message_3和message_4同步进行，以保持协议效率。 4. 取消了OSCORE消息中的EDHOC message_4，改为基于原协议的约定：Initiator不会在验证message_4后立即存储应用密钥，从而增强隐私性。
lamps
- Title: Use of Password-Based Message Authentication Code 1 (PBMAC1) in PKCS #12 Syntax
- Authors: Alicja Kario(hkario@redhat.com)
- Summary: 本文是关于对PKCS#12格式进行修改，以支持使用PBMAC1（密码基于消息认证码1）在其中插入PBKDF2密钥生成函数。PBMAC1比PBES1更适合在PKCS#12中使用，因为它提供了更高级别的安全性，并且可以满足未来扩展性需求。本文定义了如何将PBMAC1和PBKDF2组合在一起使用，同时保留了PKCS#12的原有特性。本文还提供了一个新的对象标识符来表示PBMAC1算法。 总的来说，本文旨在通过引入PBMAC1并支持PBKDF2，使得PKCS#12能够更好地适应现代安全需求，并为未来的加密协议提供更多的灵活性。
- Diff: 新版本的英文标准文稿与旧版的主要区别在于： 1. 简化了密码编码的处理方式：不再使用BMP字符串，而是声明为UTF-8字符串。 2. 提供了更多的可选参数，如PBKDF2、SHA-256和SHA-512算法的选择，以及迭代次数和盐大小的可配置性等。 3. 支持不同的密钥生成函数（KDF），允许使用PBKDF2或scrypt PBKDF进行更高级别的安全性保护。 4. 引入了新的对象标识符(id-pkcs12-pbmac1-2023)，以定义PBMAC1在PKCS#12中的使用格式。 5. 新增了测试数据文件，用于验证支持PBMAC1的实现是否正确解析和处理不同类型的PKCS#12文件。 总的来说，新版本简化了密码处理过程，增加了更多选择，提高了灵活性，并且引入了新的属性来支持更加复杂的安全性要求。这使得该规范更加适用于现代密码学需求。
radext
- Title: Operational Considerations for RADIUS and TLS-PSK
- Authors: Alan DeKok(aland@freeradius.org)
- Summary: 是一篇关于如何在使用TLS-PSK时进行安全操作的文稿。文稿主要讨论了以下几方面： 1. 基于PSK的安全要求，避免使用相同的PSK在不同版本的TLS之间复用。 2. 提供了PSK管理的一般指导原则，包括长度、格式等建议。 3. 管理PSK和共享秘密之间的关系，并提出了一些建议来保护用户的隐私。 4. 对RADIUS客户端提供了有关如何使用PSK的信息。 5. 推荐服务器实施IP地址过滤，以进一步限制暴露给攻击者的风险。 6. 讨论了如何在支持RADIUS/TLS的同时处理动态源IP地址问题。 7. 关注了系统的隐私性和安全性考虑，如防止PSK被泄露以及如何管理和保护这些信息。 总的来说，该文档提供了一个指南，帮助系统管理员和开发者在转换到使用TLS-PSK时顺利过渡，同时确保网络的安全性。
- Diff: 本文提供了关于使用TLS-PSK(RADIUS/TLS和RADIUS/DTLS)的相关建议。 与旧版本不同的是： 1. 文档开始部分将旧版文档中的“工作在UDP上的共享秘密”替换为“工作在TLS上的预共享密钥”，以便清晰区分两种协议类型。 2. 强调了当前使用的证书对于升级到支持证书的RADIUS/TLS和RADIUS/DTLS环境的重要性，并指出这些升级可能涉及到实施新的通知API和更复杂的配置变更，以支持证书。 3. 描述了使用PSK的优势，即它提供了一种简单的方法来过渡从RADIUS/UDP到RADIUS/TLS或RADIUS/DTLS，同时避免了在升级过程中出现的复杂性和不便。 4. 提出了一个简化更新过程的概念，其中用户不需要手动创建PSK，而是在某些情况下可以通过生成伪随机数来轻松管理它们。 5. 指出在部署环境中，静态发现服务器可能导致动态识别服务器变得困难，因此引入了可以自动交换连接证书的机制，如[RFC7585]动态发现。 总体而言，新版文档更加侧重于提供一种过渡到RADIUS/TLS的简单方法，同时强调了在安全性和性能之间找到平衡的必要性。
WIT
ccwg
- Title: SEARCH -- a New Slow Start Algorithm for TCP and QUIC
- Authors: Jae Won Chung(jaewon.chung@viasat.com), Maryam Ataei Kachooei(mataeikachooei@wpi.edu), Feng Li(funglee@gmail.com), Mark Claypool(claypool@cs.wpi.edu)
- Summary: 本文提出了一种新的慢启动算法Search，用于改善TCP和QUIC协议在无线网络中的性能。该算法通过计算已发送数据量与期望发送数据量之差，以及使用窗口大小、阈值等参数来确定是否应退出慢启动阶段。实验结果表明，在无线网络中，Search能可靠地退出慢启动阶段，同时避免不必要的丢包。 主要总结如下： 1. 提出了基于搜索原理的新慢启动算法。 2. 分析了当前慢启动算法的局限性，并提出了改进方案。 3. 实验验证了新算法的有效性和稳定性。 4. 介绍了实施和部署情况，包括开源实现和商用实现。
- Diff: 摘要 TCP慢启动机制在快速增加到网络拥堵点的同时，每往返一次时间（RTT）大约加倍流量窗口（cwnd）。然而，默认Linux TCP慢启动实现——如TCP Cubic与HyStart [HYSTART] ——可能导致过早从慢启动阶段退出，特别是在无线连接上，降低了链接利用率。相比之下，如果没有HyStart，则会导致过度发送数据导致不必要的包丢失。为改进TCP慢启动性能，本文提出使用搜索快进(CHokepoint)算法，该算法基于TCP服务器监测已确认交付的字节，并将其与预期交付字节进行比较。当当前交付字节数比预期交付字节数低时，应该结束慢启动阶段。 算法概述 在本文中详细描述了search算法，它运行于TCP服务器端。在初始化和接收到ACK后，主搜索算法开始执行。通过计算当前和之前RTT期间的交付字节数，对比当前字节数和先前的字节数，可以确定是否已经达到网络拥堵点。如果这个差值超过阈值，就应该结束慢启动。 参数设置 这些参数包括窗口大小、门槛、数字位数等，它们是搜索引擎的关键参数。 安全性考虑 虽然没有安全措施被讨论，但是由于这是标准文档，因此不需要专门的安全性考虑。 IANA考虑 无需要特别关注IANA考虑部分。 结论 总的来说，search算法是一个实用的工具，它可以用于改善TCP的性能。随着技术的发展，这个算法将继续得到改进。