今日共有16篇文稿更新，涉及4个area里的12个WG

ART

mimi

1. draft-mahy-mimi-app-components-00

  • Title: Application State Components for More Instant Messaging Interoperability (MIMI)
  • Authors: Rohan Mahy(rohan.ietf@gmail.com)
  • Summary: 本文主要讨论了在即时消息通信领域中，如何实现更多的交互性。文稿提出了一种新的应用状态组件MIMI（More Instant Messaging Interoperability）的概念，并详细介绍了其中的各种功能和特性。例如，它包括了房间元数据、角色授权控制、参与者列表以及预授权参与者等。这些组件的实现将有助于提升即时消息通信系统的可扩展性和灵活性，为用户提供更加丰富和个性化的服务体验。同时，为了保证系统的安全性和可靠性，还对安全性考虑做了详细的阐述。 总的来说，本文提供了一个全面而详尽的视角，旨在推动即时消息通信系统的发展，以满足用户日益增长的需求。

RTG

detnet

1. draft-varga-detnet-srv6-data-plane-01

  • Title: Deterministic Networking SRv6 Data Plane
  • Authors: Balazs Varga(balazs.a.varga@ericsson.com), Ferenc Fejes(ferenc.fejes@ericsson.com)
  • Summary: 这篇英文标准文档主要描述了如何在IPv6/SRv6数据包交换网络上使用DetNet数据平面。DetNet是一种可以提供低丢包率和端到端交付延迟的网络服务，通过使用DetNet特定SID、可选地利用现有的SRv6流量工程机制来支持DetNet数据流。 文稿首先介绍了DetNet的术语，如Flow-ID、SeqNum等，并对它们进行了定义。然后详细讨论了DetNet SRv6数据平面的概述，包括服务层和转发层的功能以及它们之间的关系。接着说明了SRv6下DetNet的数据封装方法，包括SID的作用以及如何配置这些参数以满足不同需求。 最后，文稿探讨了在DetNet SRv6网络中的安全考虑，包括可能的安全威胁以及相应的防护措施。此外，还指出了需要遵循的一些规范性参考文献。 总的来说，本文提供了关于如何使用IPv6/SRv6数据包交换网络上的DetNet数据平面的相关技术细节和建议。它为构建基于DetNet的服务奠定了基础，并提出了必要的技术和设计要求。
  • Diff: 新的英文标准文档在实现SRv6技术的基础上，定义了SRv6数据平面为Determined Networking（DetNet）提供了一个数据层网络服务。与旧版相比，主要有以下主要区别： 1. 使用SRv6作为DetNet的数据传输方式，简化了操作和管理过程。 2. 在接收端确定DetNet服务时使用DetNet服务标识符（Service Identifier），而不是发送方。 3. SRv6隧道用于封装并传递DetNet流，同时通过SRH字段指示所需的队列处理以及转发参数。 4. 利用DetNet服务子层功能进行序列编号的管理和处理，如Packet Replication Function、Packet Elimination Function、Packet Ordering Function等。 5. 提供了服务子层相关处理，如在DetNet SRv6域内创建和删除DetNet服务标识符。 6. 在DetNet SRv6网络中，通过SRv6隧道提供了路由资源和路径分配。 总体而言，该文档扩展了DetNet架构，并将SRv6引入到其数据平面，以支持更高效的流量控制和可靠性要求。

pals

1. draft-ietf-pals-ple-14

  • Title: Private Line Emulation over Packet Switched Networks
  • Authors: Steven Gringeri(steven.gringeri@verizon.com), Jeremy Whittaker(jeremy.whittaker@verizon.com), Nicolai Leymann(n.leymann@telekom.de), Christian Schmutzer(cschmutz@cisco.com), Chris Brown(cbrown@ciena.com)
  • Summary: 这篇文档扩展了虚拟私有电报服务(Virtual Private Wire Service, VPWS)信号的可传输范围，不仅限于时间分隔多路复用(TDM)信号。它使用新的封装技术Private Line Emulation (PLE)来承载不同速率、多种协议和拓扑结构的信号，如Ethernet、Fibre Channel、OTN等。该文档描述了一个基于Pseudo Wire Emulation Edge-to-Edge (PWE3)的封装机制，使得信号可以跨多个不同的网络拓扑进行传输。文中讨论了PLE的实现原理、数据流格式、操作流程、QoS控制以及安全考虑等关键方面。 总结而言，PLE提供了一种灵活且可靠的解决方案，允许在各种网络环境下将复杂的数据流通过PWE3封装成虚拟线路服务，从而跨越不同类型的物理和逻辑网络边界。它的设计旨在满足业务需求，同时保证信号透明性和服务质量，是未来网络架构中的一种重要趋势。
  • Diff: 以上新版本的英文标准文稿详细描述了如何在包交换网络（PSN）上封装高速比特流作为虚拟私有线服务（VPWS），提供完整的信号透明传输。与旧版相比，主要有以下区别： 1. 支持更广泛的设备类型：不仅限于PDH技术，还包括Ethernet、Fibre Channel和OTN等其他协议。 2. 包括多种类型的比特流服务：包括基于TDM的PDH信号以及基于Structured Bit Stream的PDH信号。 3. 网络模型更加灵活：可以处理各种通信协议，无需进行额外的操作或改变。 4. 适应性强：允许跨越不同的底层技术栈，从TDM到OTN等。 5. 提供端到端的服务质量控制：支持QoS和流量管理机制。 总的来说，该文档扩展了现有方法，并提供了适用于更多协议和数据结构的方法来实现VPWS的传输。它为不同层间的通信和信号的透明传输提供了新的可能性。

pce

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

  • 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: 本文定义了PCEP数据模型，为路径计算元素（PCE）之间的通信协议（PCEP）提供管理。该文档包含基础PCEP YANG模块和高级PCE功能的详细描述。其中： - 基础模块定义了基本的PCEP数据模型。 - 高级模块定义了诸如能力、范围等状态化PCE的功能。 总结如下：本文提供了关于路径计算元素通信协议（PCEP）的数据模型以及其配置和操作的基础知识，包括但不限于PCEP的基本概念、设计思想、属性设置、管理和通信等功能。同时，还讨论了PCEP对网络管理系统数据存储架构的支持，强调了统一的数据模型对于不同参与者之间有效交互的重要性。
  • Diff: 该文档定义了用于管理路径计算元素通信协议（PCEP）的Yang数据模型。与旧版本相比，主要区别在于： 1. 更详细地描述了YANG数据模型，包括PCEP实体、PCEP邻居列表、状态数据等。 2. 添加了对高级PCE功能的说明，如状态化PCE的LSDB以及附加属性等。 3. 对一些概念进行了更详细的解释，例如“主动状态化PCE”、“被动状态化PCE”等。 4. 指出了使用TLS来提供安全传输的消息格式和操作符。 5. 增加了对配置数据、状态数据和统计信息等方面的讨论。 总的来说，新版本更加详细和完整，为理解PCEP提供了更全面的数据模型。

spring

1. draft-varga-spring-preof-sid-01

  • Title: Deterministic Networking specific SID
  • Authors: Balazs Varga(balazs.a.varga@ericsson.com), Ferenc Fejes(ferenc.fejes@ericsson.com)
  • Summary: 本文是关于Determined Networking（DetNet）网络架构的一部分，描述了如何使用SRv6数据平面和特定SID（Segment Identifier）来支持DetNet服务层的功能。DetNet服务层需要序列信息（即序列号）来提供服务保护。本文提出了一种新的特定SID，并在SRv6端点行为中定义了一些新的处理规则。 首先，DetNet特定SID代表一个包含三个部分的SID：位置（LOC）、功能（FUNCT）和参数（ARG）。对于PreOf功能，需要两个参数：流ID（用于确定要为哪个DetNet流使用哪一个PreOf实例）和序列编号（由DetNet边缘节点创建并用于PEF/POF功能）。DetNet特定SID的格式基于SRv6技术，不需要额外的隧道或实施其他协议栈（例如MPLS）。 然后，本文讨论了DetNet特定SID的相关包处理规则：End.DPREOF、H.Encaps.PREOF、H.Encaps.PREOF.Red、H.Encaps.PREOF.L2和H.Encaps.PREOF.L2.Red。 这些规则涉及对IPv6数据包进行分段、去除外部IPv6头部以及将剩余部分传递给DetNet服务层。此外，提出了相关计数器的概念，以跟踪每条DetNet流的预处理流量。 最后，本文还讨论了安全性考虑，如DetNet和SRv6网络编程中的安全考虑。尽管没有提到具体的密钥词，但文稿展示了如何根据DetNet特定SID和上述操作实现相应的流量计数和安全措施。
  • Diff: 本文是关于扩展SRv6网络编程（Network Programming）以支持DetNet（确定性网络）中的特定SID（segment identifier）的功能。DetNet是一种分布式数据流处理技术，用于在多条路径上复制相同的数据包，并使用序列信息来消除重复。 主要内容有： 1. 描述了DetNet和SRv6架构之间的关系。 2. 提出了一个新的SID格式——DetNet SID，用于承载流ID和序列号信息，供服务子层功能（如PREOF）使用。 3. 定义了端点行为，包括End.DPREOF、H.Encaps.PREOF等，这些行为允许节点执行特定的DetNet流相关操作。 4. 阐述了与DetNet相关的计数器和安全性考虑。 5. 讨论了该标准化工作的意义和未来工作方向。 相较于旧版标准文档，本新版本的主要区别在于增加了对DetNet特定SID的相关描述，以及对安全性和计数器等相关特性的详细说明。此外，引入了最新的SRv6标准框架和特定SID格式，进一步丰富了标准文档的内容。总的来说，这是对现有DetNet和SRv6协议的一个重要补充和完善。

SEC

cose

1. draft-ietf-cose-dilithium-05

  • Title: ML-DSA for JOSE and COSE
  • Authors: Michael Prorock(mprorock@mesur.io), Orie Steele(orie@transmute.industries), Rafael Misoczki(rafaelmisoczki@google.com), Michael Osborne(osb@zurich.ibm.com), Christine Cloostermans(christine.cloostermans@nxp.com)
  • Summary: Failed to summarize the draft
  • Diff: 上述新版本的英文标准文稿主要对JSON Object Signing和Encryption (JOSE)和CBOR Object Signing和Encryption (COSE)进行了介绍，详细描述了它们与模块化代数学（ML-DSA）的安全接口、算法参数类型等。相比于旧版本，主要区别在于： 1. 简化了文档结构和格式，使其更易于理解和操作。 2. 提供了更多的示例数据，便于理解其原理和应用。 3. 更详细的算法分析文档和建议，指导如何正确使用这些算法。 综上所述，新版本简化了文档结构，提供了更多示例数据，并提供更详细的算法分析文档，以指导正确使用这些算法。

jose

1. draft-ietf-jose-hpke-encrypt-04

  • Title: Use of Hybrid Public Key Encryption (HPKE) with JSON Object Signing and Encryption (JOSE)
  • Authors: Tirumaleswar Reddy.K(kondtir@gmail.com), Hannes Tschofenig(Hannes.Tschofenig@gmx.net), Aritra Banerjee(aritra.banerjee@nokia.com), Orie Steele(orie@transmute.industries), Michael B. Jones(michael_b_jones@hotmail.com)
  • Summary: 本文是关于使用混合公钥加密（HPKE）在JSON对象签名和加密（JWE）中的应用。HPKE是一种允许使用任意大小的明文进行公钥加密的方法，适用于接收方的公共密钥。HPKE支持多种组合的KEM、KDF和AEAD，并且可以与不同的JOSE版本兼容。 HPKE用于JWE时有以下两种模式： 1. HPKE-JWE Integrated Encryption：将HPKE用于加密明文。 2. HPKE-JWE Key Encryption：将HPKE用于加密内容加密密钥（CEK），并随后使用CEK来加密明文。 这两种模式都可以通过调用JWE中的保护头参数来选择，例如设置“alg”为“HPKE”，并且“enc”值应为“dir”。 此外，还可以使用多个接收者模式。在该模式下，HPKE用于加密一个内容加密密钥（CEK），然后使用该CEK来加密明文。在使用Compact JWE序列化的情况下，还需要包含额外的认证数据（AAD）字段。 安全性方面，本文提到HPKE依赖于随机数生成器以提供足够大的熵，以防被攻击者利用。实施者应该确保随机数生成器遵循[RFC8937]的安全指南。对于其他类型的密钥，也需要考虑其足够的熵。最后，应该使用适当的算法，特别是当使用Key Encryption模式时，需要保证强度符合标准要求。
  • Diff: 这篇新版本的英文标准文稿详细介绍了Hybrid Public Key Encryption (HPKE)在JSON Object Signing and Encryption (JOSE)中的应用，提供了关于HPKE和JOSE的详细定义、模式描述等信息，并讨论了其安全性考虑。与旧版相比，主要区别在于： 1. 更多的定义：增加了关于辅助认证信息、加密套件注册等内容的定义。 2. 模式更新：增加了新的HPKE模式，如"Auth_Psk"、"Auth"和"Auth_Psk"，并更新了一些模式参数的描述。 3. 兼容性：支持不同的JSON序列化格式（如Compact和General）以及特定序列化的限制。 4. 安全性考虑：新增了对随机数生成指南的要求，确保使用合适的算法强度。 5. 许可证：修订了版权声明，强调了该文档的许可信息。 总的来说，这篇新版标准文稿为开发者提供了一个更加全面且兼容性强的框架，有助于实现Hybrid Public Key Encryption在JOSE中的安全集成。

oauth

1. draft-ietf-oauth-browser-based-apps-20

  • Title: OAuth 2.0 for Browser-Based Applications
  • Authors: Aaron Parecki(aaron@parecki.com), David Waite(david@alkaline-solutions.com), Philippe De Ryck(philippe@pragmaticwebsecurity.com)
  • Summary: 这篇文稿主要讨论了浏览器基础应用中的威胁、攻击后果、安全考虑和最佳实践。文稿分析了恶意JavaScript对浏览器基础应用的安全性的影响，并探讨了如何通过不同的架构模式来应对这些挑战。 首先，文稿指出恶意JavaScript可以窃取访问令牌和刷新令牌，或者直接控制应用程序，导致严重的安全问题。为了防止这种威胁，提出了减少权限、发送约束和授权服务器混杂等策略。 然后，文稿总结了三种主要的架构模式：前端后端模式（前端依赖后端处理）、前端后端模式（前端同时运行在客户端）以及前端模式（仅由浏览器提供服务）。每种模式都有其优缺点和潜在风险。 最后，文稿强调了应使用OAuth 2.0的授权码流式并配置PKCE保护，以防止资源服务器重放攻击。此外，还建议使用DPoP保护访问令牌免受恶意代码泄露。 总的来说，这篇文稿提供了有关如何设计和实施浏览器基础应用的最佳实践指南，以提高安全性。
  • Diff: 新的文档（draft-ietf-oauth-browser-based-apps-20）详细介绍了在浏览器环境中实施OAuth 2.0客户端时面临的威胁、攻击后果和安全考虑，并分析了不同架构模式如何解决这些挑战。 与旧版相比，新增加的内容有： 1. 描述了恶意JavaScript对浏览器环境中的应用的影响，以及针对这种影响的安全策略。 2. 提出了不同类型的架构模式（BFF, Token-Mediating Backend 和 Browser-based OAuth Client），每种模式都有其优势和劣势。 3. 分析了每个架构模式的优缺点及其适用场景。 总结来说，新版文档扩展并限制了前两版中提到的具体建议，更加关注于浏览器环境下的安全问题，并为开发者提供了一个基于OAuth的应用框架设计指南。

tls

1. draft-beck-tls-trust-anchor-ids-03

  • Title: TLS Trust Anchor Identifiers
  • Authors: Bob Beck(bbe@google.com), David Benjamin(davidben@google.com), Devon O'Brien(asymmetric@google.com), Kyle Nekritz(knekritz@fb.com)
  • Summary: 这篇文档定义了TLS信任标识扩展，一种机制让依赖方能够通过短小精悍的标识符来传达可信认证权威。它还定义了用于支持多个受信任认证路径的模式，以及可以用来描述可用认证路径的服务参数。同时，该文档也讨论了信任标识扩展的安全性考虑。 本文主要介绍了以下几点： 1. 定义了信任标识扩展（Trust Anchor Identifiers）的概念。 2. 描述了如何在连接时使用信任标识扩展以减少证书选择的大小成本。 3. 讨论了DNS服务参数的用途，使得客户端可以请求更准确的信任标识扩展，并避免重新连接的成本。 4. 分析了可能的问题和应用场景，如如何处理新加入的可信认证权威、已知的不安全证书等。
  • Diff: 该文档定义了TLS Trust Anchor Identifiers（TAIDs），这是一种简化认证依赖方信任的机制。它允许依赖方通过提供可信的证书权威来表示他们的信任来源，并且提供了两种方式：一种是发送一个可能为空列表或包含多个候选信任锚标识的TAID列表给客户端；另一种是在接收到客户端的信任锚标识列表后，向客户端发送空的TAID列表作为首选信任路径。此外，它还定义了一个ACME扩展，用于提供更多的个性化信任路径。这些改进旨在减少跨依赖方的信道开销，支持灵活和健壮的PKI架构，使更多应用受益。

uta

1. draft-reddy-uta-pqc-app-04

  • Title: Post-Quantum Cryptography Recommendations for Applications
  • Authors: Tirumaleswar Reddy.K(kondtir@gmail.com)
  • Summary: 本文是关于推荐量子安全应用协议的文档。主要讨论了在数据保密性和认证方面的问题，包括如何应对量子计算机带来的挑战以及如何实施量子安全策略。其中还提到了加密DNS、混合公钥加密（HPKE）和WebRTC等技术。文稿强调了量子安全的重要性，并提出了相应的解决方案。
  • Diff: 该文档是关于量子密码推荐给应用的通知性文档，包括以下主要内容： 1. 引言：介绍了量子密码对应用、用户和系统管理员带来的挑战。 2. 框架时间表：讨论了量子密钥交换和认证的不同时间框架，分别适用于数据保密性和认证。 3. 数据保密性：讨论了如何在传统算法与量子加密技术之间进行过渡，以及使用混合密钥交换机制的好处。 4. 认证：解释了在证书基于认证的应用程序中如何利用量子安全属性。 5. 应用协议：详细说明了对于使用TLS的客户端和服务器应用程序而言，应如何实施量子安全特性。 6. 提醒用户：当服务器检测到客户端不支持量子或混秘键交换时，如何通知用户。 7. 分析：讨论了在实际部署过程中可能遇到的挑战和策略。 8. 安全考虑：概述了实现量子安全性的关键考虑因素。 与旧版相比，新版的主要区别在于： 1. 更详尽地讨论了量子密码的优缺点，并提供了详细的对比分析。 2. 对于认证方面的描述更为深入，包括了认证体系中的多个方面。 3. 对于应用协议部分进行了更详细的阐述，特别是针对SSL/TLS的应用场景。 4. 在提醒用户部分提供了一种更加具体且实用的方法来告知用户可能存在的问题。 综上所述，新版不仅详细列出了各种实施量子密码的新方法，还通过引入更多的案例研究和实践经验，为开发者提供了更好的指导和支持。

WIT

core

1. draft-ietf-core-cf-reg-update-00

  • Title: Update to the IANA CoAP Content-Formats Registration Procedures
  • Authors: Thomas Fossati(thomas.fossati@linaro.org), Esko Dijk(esko.dijk@iotconsultancy.nl)
  • Summary: 本文更新了CoAP Content-Format注册流程，其中涉及CoRE Parameters组中的"CoAP Content-Formats"部分。主要变化在于对FCFS部分的规定：在确保安全性的前提下，增加了对媒体类型和参数的有效性检查。文稿还提供了一些示例以说明如何正确使用该规则来防止恶意注册。总的来说，本文提高了CoAP Content-Format注册的安全性和可靠性。


2. draft-ietf-core-corr-clar-01

  • Title: Constrained Application Protocol (CoAP): Corrections and Clarifications
  • Authors: Carsten Bormann(cabo@tzi.org)
  • Summary: 本文是关于CoAP协议的一个修正和澄清文档。它主要对已发布的RFC文件进行了修订，纠正了一些语法错误、模糊定义以及不清晰的描述，并提出了其他澄清。这些修订主要是为了提高CoAP协议在实际使用中的兼容性和稳定性。 文稿的主要内容包括： 1. 对RFC7252的修改，如增加内容格式代码（ct）的定义、完善Max-Age值的含义等。 2. 对RFC7252-5.10.5中的max-age值进行更新，使其更符合现实情况。 3. 对RFC7252-6.4中分段构建URI为选项部分的部分进行修改，使其更加准确。 4. 将RFC7252-7.2.1中的“ct”属性限制到一个URI路径上一次出现。 5. 对RFC7252-9.1.1/9.1.2中的匹配箱处理规则进行改进，以适应新的需求。 6. 对RFC7252-12.3中的内容格式注册表进行更新，使之更准确地反映当前的实际状况。 7. 提出了对一些特殊应用领域的需求，如需要对特定OSCORE安全上下文进行隔离的情况。 总之，本文提供了对CoAP协议的进一步解释和修正，旨在改善其与不同设备之间的交互性，使协议更容易被接受和实现。
  • Diff: 该文档更新了部分关于CoAP协议的错误和不明确之处，并提供了相关修正、补充和澄清。主要包括： 1. 对RFC7252中的术语进行了更详细的定义。 2. 解释了如何在CoAP中使用DTLS连接（[RFC7252]）。 3. 提供了对匹配框的理解和改进。 4. 对组对象安全扩展（Group OSCORE）的位置进行了说明。 与旧版本不同的是，文档增加了更多的修正和补充内容，并且强调了这些修订的目的：为了提高CoAP协议的兼容性和可互操作性。另外，引入了一个新的过程来管理修订和更新，这将使这个文档成为长期维护的一个动态文档。

httpbis

1. draft-ietf-httpbis-safe-method-w-body-07

  • Title: The HTTP QUERY Method
  • Authors: Julian Reschke(julian.reschke@gmx.de), Ashok Malhotra(malhotrasahib@gmail.com), James M. Snell(jasnell@gmail.com), Mike Bishop(mbishop@evequefou.be)
  • Summary: 本文主要讨论了HTTP协议中的新方法——查询方法。它定义了一种新的安全、可重试请求方法，可以携带请求内容。本文介绍了查询方法的基本概念和特性，并强调了其安全性、不可变性以及对资源的影响。 总结：本文详细解释了HTTP协议中的查询方法（QUERY），探讨了它的基本功能、应用场景、使用限制等。本文还指出了查询方法的安全性和不可变性，并且提出了如何处理敏感信息的方法。最后，本文还提到了该方法与其他HTTP方法的关系，如GET、POST等。
  • Diff: 该新版本的英文标准文稿定义了一个新的HTTP方法——查询（QUERY），作为安全、可重试且包含请求内容的IDEMPOTENT请求方式。与GET和POST相比，它更适合于处理大量数据的查询操作。 主要区别在于： 1. 使用“QUERY”代替“GET”或“POST”，使得其更具通用性； 2. 将请求体字段由“undefined “text/query” ”更改为“application/x-www-form-urlencoded”等表示编码格式的媒体类型； 3. 增加了“Content-Location”和“Location”头部字段，用于指示资源位置； 4. 提供了支持条件查询的功能； 5. 支持缓存，并提供了关于如何使用Cache Key的指导。 总的来说，相比之前的版本，这个新版本增加了更多的功能特性，使QUERY成为更加强大的查询工具。

Unknown

Unknown

1. draft-schinazi-update-on-milestones-03

  • Title: An Update on Milestones
  • Authors: David Schinazi(dschinazi.ietf@gmail.com)
  • Summary: 本文主要更新了关于里程碑的规定。在当前的情况下，作为工作小组章程的一部分，列出特定工作的具体任务列表变得不再必要，因为这些任务通常会随着时间的推移而变动。同时，日期和时间的设定对于工作小组的进度和状态是一个重要的工具，但随着时间的流逝，一些里程碑可能已经过时且无法提供价值。因此，允许工作小组选择是否启用里程碑，并可以指定不同的日期格式（例如月、季度或会议）。此外，如果某个工作组决定不使用里程碑，那么这个决策应由其负责的工作组的区域主任做出，并且这些决定应该被发布到相应的工作组邮件列表上。 另外，在处理任何与日期相关的变更时，区域主任有责任讨论并同意这些决策，而不是完全依赖于社区对里程碑状态的看法。对于需要改进的地方，如提高工具以自动更新根据文档状态来更新里程碑，或者修改RFC 2418以反映现实情况，这些都有待进一步讨论和考虑。
  • Diff: 这篇新版本的英文标准文稿更新了关于工作组里程碑的规定。相比之前的版本，它取消了强制要求工作组在章程中列出里程碑和时间表，并允许工作组根据需要选择是否使用里程碑。此外，对于已存在的里程碑，它们可以是日期相关的或者不带日期。这些变化使工作小组可以在保持灵活性的同时保留或删除里程碑，以适应当前的工作环境。 另外，新的里程碑规定也强调了定期审查和更新工作的里程碑的重要性。此外，这个版本还更新了对一些关键概念的定义，如“miles”（里程碑），“milestone”（里程碑任务），以及“mileage”（进度）。这些修改有助于更准确地理解文档的内容和意图。


2. draft-farrell-errata-02

  • Title: Something Better Than Errata
  • Authors: Stephen Farrell(stephen.farrell@cs.tcd.ie)
  • Summary: 这篇文稿主要讨论了网络工程小组提出的关于错误纠正的新政策。它将允许用户在发布RFC后通过评论系统提交错误和建议修改。每个RFC都有一个单独的邮件列表，其中包含相关的专家和委员会成员。一旦有足够的人投票支持，错误就会被带到相关团队进行审批。此外，还可以手动应用这些更改。该系统旨在提高RFC的可用性和改进其处理方式，而不需要引入新的版本控制机制或改变现有的工作流程。
  • Diff: 本文提出了一种新的错误处理政策，旨在改进当前的错误处理系统。主要区别在于： 1. 使用评论和讨论替代现有的错误报告：在RFC发布后，读者可以通过一个“评论/讨论”按钮提交评论或问题，而不再需要手动创建错误报告。 2. 采用分组管理讨论：每个RFC组都有自己的权限体系来管理和控制讨论，而不是由RPC统一管理。 3. 改进投票机制：投票权根据用户级别变化，以反映他们的贡献和影响力。 4. 提供自动应用更改的功能：错误修正应该能够在获得批准前立即生效。 5. 留下历史记录：尽管存在可能存在的错误修正，但应保留它们以便后续的审查和修订。 总的来说，这个新系统的目的是提高错误处理的有效性，并通过改进现有系统的方法来达到这一目标。


3. draft-bormann-what-is-tcp-00

  • Title: What is TCP?
  • Authors: Carsten Bormann(cabo@tzi.org)
  • Summary: 这篇文档是关于传输控制协议（TCP）的介绍性文档，引用了标准7。它概述了TCP的基本概念和用途，并提供了对规范性的参考链接。该文档没有明确指定任何版本或发布日期，但表示将从2025年6月21日到期。