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

ART

asdf

1. draft-bormann-asdf-sdftype-link-04

  • Title: An sdfType for Links
  • Authors: Carsten Bormann(cabo@tzi.org)
  • Summary: 本文定义并注册了一个名为“链接”的SDF数据类型，该类型适用于描述互联网事物（SDF）中的数据和交互模型。链接是一种常见的数据类型，在物联网设备模型中经常出现，例如包含目标URI等参数的信息模型。本文还讨论了安全考虑、IANA考虑以及参考文献。 本文是关于定义和注册一个用于描述互联网事物模型的数据类型的文档，主要讨论了如何在SDF中表示链接，并且指出了当前对生态系统特定链接结构映射到字符串语法带来的问题。此外，还提出了使用对象集合模式来解决这个问题的想法。 总的来说，本文提供了一种新的方式来处理链路属性，使得它们可以在定义阶段添加信息，而在运行时将这些链路指向实例转化为数据和交互模型的一部分。它也讨论了如何为不同系统构建不同的链路类型，从而更好地适应各种生态系统的需要。最后，文稿提供了相关的参考文献和支持性资源。
  • Diff: 本文是关于在SDF（Semantic Definition Format）中定义并注册一个新的数据类型“链接”，用于表示物联网设备中的关系信息。与之前的英文标准文稿相比，主要的区别在于： 1. 文档标题：从"An sdfType for Links"更改为"An sdfType for Links for Data and Interactions of Things" 2. 概述部分对SDF、SDF参数和关联对象等概念进行了简要介绍。 3. 针对新的数据类型“链接”给出了详细的定义，并说明了如何使用它来描述对象模型中的属性和行为。 4. 对于安全考虑，没有详细讨论。 5. 在IANA分组中提供了新的数据类型的注册模板。 总的来说，本文是对现有标准的扩展，增加了新的数据类型以支持物联网设备中的关联关系，同时保留了原有的安全性框架。


2. draft-bormann-asdf-sdf-mapping-05

  • Title: Semantic Definition Format (SDF): Mapping files
  • Authors: Carsten Bormann(cabo@tzi.org), Jan Romann(jan.romann@uni-bremen.de)
  • Summary: 本文主要讨论了SDF(Semantic Definition Format)这个格式，它是用来描述物理对象（Things）的数据和交互模型的一种语言。它是由One Data Model Liaison Organization(OlDM)组织创建的通用语言，用于开发数据模型。此外，该文档还提到了如何将特定的生态系统或应用中的信息附加到一个或多个SDF模型上，并提供了一个简单的示例来说明这种映射过程。 本文重点介绍了SDF文件的基本结构，包括信息块、命名空间、默认命名空间以及映射部分。另外，也对IANA媒体类型进行了考虑，并讨论了安全性问题。 总之，本文是关于SDF格式及其在描述物理对象上的应用的一份指南，强调了其作为通用语言的重要性，同时也指出了与不同生态系统的兼容性需求。
  • Diff: 以上新的英文标准文档是关于SDF（Semantic Definition Format）的一个草案。主要内容包括： 1. 引言：介绍了SDF的定义、用途和使用场景。 2. 介绍SDF的基本概念：命名空间、品质、数据模型等。 3. 形式化语法：描述了如何在SDF文件中创建和维护数据和交互模型。 4. 对IANA考虑：提出将SDF映射文件作为媒体类型添加到“媒体类型”注册表中。 5. 安全性考虑：讨论了一些可能的安全问题，并提供了解决方案。 6. 参考文献：列出了一系列相关的标准化工作和研究文稿。 总的来说，与旧版相比，新版增加了对SDF映射文件格式和安全性方面的详细说明，同时也提出了相关标准建议。

INT

6man

1. draft-ietf-6man-eh-limits-17

  • Title: Limits on Sending and Processing IPv6 Extension Headers
  • Authors: Tom Herbert(tom@herbertland.com)
  • Summary: 本文主要讨论了IPv6协议中扩展头部的发送、接收和处理限制。主要包括以下几点： 1. 支持更合理的使用案例，增加部署和使用的可实施性和扩大采用范围。 2. 设定了各种对扩展头部处理的限制，如头部长度、选项长度、头部数量等。这些限制是可选的，根据实际需求调整。 3. 定义了一些关于接收和处理扩展头部的默认极限，作为基本支持标准。 本文提出了接收端在收到含有扩展头部的IPv6包时应该采取的推荐行动，当达到或超过极限时应如何操作。对于路由器，如果达到接收头限制，则需要停止处理头并转发数据；否则将丢弃该包，并可能发送错误消息以提醒源地址。 总结：本文为实现更多IPv6扩展头部的可部署性提供了技术框架，旨在通过设置必要的头部处理限制来减少攻击风险，并鼓励开发更多的实用应用。
  • Diff: 本文是关于IPv6扩展头限制的新版本文档。主要内容包括： 1. 相关工作：讨论了相关领域的研究和工作。 2. 需求语言：定义了新的接收、发送和处理IPv6扩展头部的要求。 3. 基本概念：对相关的术语进行了定义。 4. 概念总结：详细描述了这些要求的具体内容，并说明它们的意义和目标。 5. 主要区别：与旧版相比，本文的主要区别在于增加了更多的选项长度和数量限制，以及对某些类型节点（如路由器）的行为进行规定。 总的来说，本文在保持原有基本需求的基础上，增加了一些限制条件，旨在提高IPv6扩展头部的可实现性和可用性，从而推动其在互联网上的部署和发展。

OPS

netmod

1. draft-ietf-netmod-system-config-10

  • Title: System-defined Configuration
  • Authors: Qiufang Ma(maqiufang1@huawei.com), Qin Wu(bill.wu@huawei.com), Chong Feng(fengchonglly@gmail.com)
  • Summary: 该文档提出了一个新的数据存储概念——系统定义配置数据存储(),以控制系统提供给服务器的数据。该数据存储允许客户端引用、修改和配置系统定义节点的子节点。这个概念对网络管理系统中的系统配置进行了一定程度上的扩展，使得在没有物理资源的情况下也能获取到系统提供的配置信息。同时，也指出了与现有标准如NMDA等之间的兼容性。 该文档还更新了RFC 8342中关于系统的系统配置的定义,将系统配置从运行状态中分离出来，合并到系统定义配置数据存储中。然后，系统定义配置数据存储被重新定义为一个读取只写属性的数据存储，并且它的内容不能被改变。另外，文档还介绍了如何引用、修改和配置系统定义节点的子节点。这些内容对于理解系统的系统配置有着重要的意义。
  • Diff: 本文档更新了(NMDA)定义，在这个架构下定义了一个称为“系统”的配置数据存储，用于持有由设备自身提供的配置。这个系统配置可以被客户端引用（通过leafref），并可以修改系统提供给的值，也可以配置子节点。 与旧版的不同之处在于： 1. 定义了一个新的数据存储资源名称：“系统”（System）。 2. 在旧版中，“conventional”概念被使用来描述其他几种类型的配置数据存储，现在在新版中将“系统”添加到列表中。 3. 将旧版中的术语“立即呈现”和“条件性呈现”分别重新定义为“立即呈现”和“条件性呈现”。 4. 修订了关于如何处理动态变化的规则。 5. 更新了“intended”原生元数据注解标识身份定义，将其从“运行期”更改为“源”，并允许一部分流自系统却未在运行期配置或过写的子节点使用“系统”作为其来源标识。 总的来说，新版的主要区别是引入了一个新的系统数据存储，并对一些基本的概念进行了修订以反映最新的架构需求。

RTG

lisp

1. draft-ietf-lisp-name-encoding-16

  • Title: LISP Distinguished Name Encoding
  • Authors: Dino Farinacci(farinacci@gmail.com), Luigi Iannone(ggx@gigix.net)
  • Summary: 本文主要讨论了在LISP协议中使用地址家族标识符（AFI）来编码LISP控制消息中的标识信息。它定义了一个终止字符，用于表示字符串的长度，以便确定标识符的长度。此外，还提供了几种特定场景下的应用示例，如为设备角色或功能注册分配专属的标识符、驱动XTR上线流程以及自文档化的路由位置等。该标准定义了如何使用AFI编码Distinguished Name（DN），用于标识设备的角色和功能，并提供了一定的安全性和兼容性考虑。最后，文稿总结了其应用经验，并对未来的标准化工作提出了建议。
  • Diff: 这篇新版本的英文标准文档是关于使用地址族标识符（AFI）字段来编码在LISP控制消息中使用的LISP Distinguished Name（DNS）。主要区别在于： 1. 使用了新的术语“Address Family Identifier”（AFI），取代了旧版中的“Address Family”。 2. 引入了一个终止字符，用于确定字符串长度，以避免在处理数据包时出现错误。 3. 提出了一个新的格式，用于表示Distinguished Name字符串，并定义了如何在EID和RLOC记录中使用这个格式。 4. 针对使用例进行了详细说明，包括使用EID、RLOC记录以及自定义命名的方法等。 5. 对名称碰撞考虑做了更新，强调每个应用都应为其特定用途注册自己的Instance-ID，并定义其结构语法。 6. 对安全性考虑做出了调整，将它们纳入到LISP控制平面的一部分，适用范围也扩大到了LISP。 7. 在IANA地址族序列登记表中分配了新的代码点值17，这也是新的一个编码方式。 8. 具体的部署经验示例提供了一些实际例子，帮助理解这些概念的实际应用。 总体来说，这次修订增加了更多细节和具体实施方法，使标准文档更加实用和全面。

SEC

lamps

1. draft-liu-lamps-certification-path-validation-05

  • Title: Technical guidelines of Web server certification path validation for Interent browser
  • Authors: Penghui Liu(liuph@pcl.ac.cn), Xiang Liu(liux15@pcl.ac.cn), Rongwei Yang(yangrw@pcl.ac.cn), Yu Zhang(zhangy08@pcl.ac.cn)
  • Summary: 本文是关于Web PKI中的证书路径验证指南，主要阐述了在SSL/TLS协议通信中为互联网浏览器建立和验证服务器证书的过程。它概述了基本路径验证过程、引用程序以及如何使用验证算法来确定证书的有效性和合法性等步骤。本文还讨论了认证过程中可能遇到的安全性问题，并给出了相关的安全参考文献。 总结而言，本文提供了Web浏览器环境中实施和验证SSL/TLS数字证书的一般指南，旨在提高证书安全性的实现和维护。它强调了跨平台的可扩展性和灵活性的重要性，以满足不同应用程序的需求和兼容性要求。此外，本文也对证书管理流程进行了规范，确保了安全性标准的遵守和透明度。
  • Diff: 该文档为互联网安全协议(Internet Protocol, IP)中的Web服务器证书路径验证指南。主要内容包括： 1. 网络浏览器制造商对Web PKI的安全审查过程是关键的审核步骤。然而，当前有多种网络浏览器供应商在全球范围内存在，随着网络安全实践的变化和技术的发展，验证过程在互联网浏览器行业中相对混乱，涉及到各种私有实施厂商的私人编码实现。 2. 这个文档提出了一种统一的Web服务器证书路径验证方法，结合RFC5280和最新的实践情况，提供给网络浏览器厂商参考。 3. 主要区别在于： - 新版提供了更详细的技术指导来完成SSL/TLS协议通信中的Web服务器证书路径验证，包括基本路径验证流程、参考程序、指导和建议等。 - 新版描述了如何使用特定的认证路径验证算法进行具体实施。 - 新版也介绍了如何通过OCSP查询机制确定证书是否已撤销的方法。 - 新版增加了安全性考虑（如证书生命周期检查）、引用的规范性参考资料（例如BGP工作流）以及针对客户端的配置要求（如OCSP和CT验证）。

Unknown

Unknown

1. draft-moskowitz-hip-fast-mobility-09

  • Title: Fast HIP Host Mobility
  • Authors: Robert Moskowitz(rgm@labs.htt-consult.com), Stuart W. Card(stu.card@critical.com), Adam Wiethuechter(adam.wiethuechter@axenterprize.com)
  • Summary: 本文主要讨论了如何通过加速基本的HIP移动更新来解决移动过程中可能存在的问题。首先，文稿介绍了移动的时间延迟以及改进这一延迟的方法，例如使用新的地址进行验证、利用Next Header的方式在传输窗口较小的情况下发送多包等。然后，文稿探讨了高速移动的情况，包括单次移动和双跳等情况，并给出了相应的优化建议。此外，还提出了对IANA考虑的问题，以及提出了一些安全方面的考量。总的来说，本文提供了有关如何提高HIP移动速度的建议，以满足用户的需求。 总结：本文提供了一种解决方案，即加速基本的HIP移动更新过程，以减少移动过程中出现的问题，如数据丢失或错误接收等问题。同时，它也提出了对一些相关标准和规范的考虑，为未来的研究和应用奠定了基础。
  • Diff: 摘要 本文描述了移动场景和如何在HIP中积极支持它们的方法。目标是减少移动事件中的延迟。两个原因被用来解释这种做法：中间件阻止返回可达性，并且恶意同伴提供虚假地址更新以向目标洪水。 文档的主要区别在于： 1. 使用新的地址直到验证时。最坏的情况是几包丢失或发送到错误的目标。这些是接受的风险，以便获得快速、有效的地址更新，在大多数情况下有效。 2. 增加了VIA_RVS参数的可用性。首先，当I1通过RVS路由给Initiator时，Responder应始终在其R1中提供VIA_RVS信息。其次，Initiator应始终在其I2中提供VIA_RVS信息。这样，主机将能够拥有对方的RVS地址来“射击”更新并因此加速移动。 3. 提供了一个单个移动移动方案。数据流量可能使用ESP与HIP或任何其他隧道协议传输。在这种情况下，关系到隧道SA与HIP SA之间的信任度对快慢移动提供了高度的信任。 4. 在双跳动移动中，即使没有使用RVS也必须这样做。这是因为只有RVS才能找到其同伴。如果知道RVS，则可以在Direct Connection失败之前先访问Peer的RVS。 5. 扩展了VIA_RVS的可用性，即在R1中总是包含Responder的VIA_RVS信息，以及在I2中总是包含Initiator的VIA_RVS信息。这两个扩展增加了VIA_RVS的可用性，使主机确信可以拥有对方的RVS地址来“射击”更新并因此加速移动。 6. 由于不需要使用RVS，所以没有提供IANA要求。 7. 安全考虑方面，与先前版本相同，但没有提及新的安全特性。 8. 感谢部分提到的术语“枪支”，该术语来自InfraHIP项目。HIP UPDATE长度由Jeff Ahrenholz提供。Sue Hares从华为和Tempered Networks贡献了清晰度。


2. draft-boucadair-veloce-yang-01

  • Title: YANG deVELpment PrOCEss & maintenance (VELOCE)
  • Authors: Mohamed Boucadair(mohamed.boucadair@orange.com)
  • Summary: 本文主要讨论了如何为网络工程文档提供参考模型和稳定模型。该方法适用于IETF模块，但不适用于IANA管理的模块。此外，还讨论了安全性、IANA考虑等内容。最后，给出了引用的相关文档。
  • Diff: 本文提出了一种新的文档编写方法，用于在互联网工程任务组（IETF）内部创建和维护YANG模块。与传统的RFC格式不同，这种新方法更适用于YANG模块的开发。具体来说，它定义了一个基于VELOCE的流程，包括创建一个新仓库、分配参与者角色以及遵守特定的安全性和IANA考虑等。此外，本文还讨论了安全、编码规范和IANA管理等内容，并给出了详细的参考文献列表。总的来说，相较于旧版，本版增加了更多关于如何使用YANG模块的新指导原则，更加符合实际应用需求。 由于这是新版本的英语标准文稿，我无法直接提供中文摘要，但可以尝试概括一下其核心要点： 1. 新文稿描述了一种适合在IETF内部创建和维护YANG模块的方法。 2. 定义了一个基于VELOCE的流程来管理和维护YANG模块。 3. 强调了安全性、编码规范和IANA管理的重要性。 4. 提供了详细的参考文献列表以支持论述。