Internet Drafts - IDs for Dec/2024

Index - Month Index of IDs

All IDs - sorted by date)

31/12/2024

	MISP core format
	draft-dulaunoy-misp-core-format-19.txt   Date: 31/12/2024   Authors: Alexandre Dulaunoy, Andras Iklody   Working Group: Individual Submissions (none)	This document describes the MISP core format used to exchange indicators and threat information between MISP (Open Source Threat Intelligence Sharing Platform formerly known as Malware Information Sharing Platform) instances. The JSON format includes the overall structure along with the semantic associated for each respective key. The format is described to support other implementations which reuse the format and ensuring an interoperability with existing MISP [MISP-P] software and other Threat Intelligence Platforms.
	IPv4 Parcels and Advanced Jumbos (AJs)
	draft-templin-intarea-parcels2-15.txt   Date: 31/12/2024   Authors: Fred Templin   Working Group: Individual Submissions (none)	IPv6 Parcels and Advanced Jumbos (AJs) present new data packaging constructs for both existing Internetworking pathways and a new link model for the future. As is often the case, technologies developed in the IPv6 space can also be applied in IPv4 and vice-versa. This document presents the adaptations necessary to support Parcels and AJs in IPv4.
	IPv6 Extended Fragment Header (EFH)
	draft-templin-6man-ipid-ext2-05.txt   Date: 31/12/2024   Authors: Fred Templin, Tom Herbert   Working Group: Individual Submissions (none)	The Internet Protocol, version 4 (IPv4) header includes a 16-bit Identification field in all packets, but this length is too small to ensure reassembly integrity even at moderate data rates in modern networks. Even for Internet Protocol, version 6 (IPv6), the 32-bit Identification field included when a Fragment Header is present may be smaller than desired for some applications. This specification addresses these limitations by defining an IPv6 Extended Fragment Header (EFH) that includes a 64-bit Identification with efficient fragmentation and reassembly procedures.
	IPv6 Extended Fragment Header for IPv4
	draft-templin-intarea-ipid-ext2-05.txt   Date: 31/12/2024   Authors: Fred Templin   Working Group: Individual Submissions (none)	The Internet Protocol, version 4 (IPv4) header includes a 16-bit Identification field in all packets, but this length is too small to ensure reassembly integrity even at moderate data rates in modern networks. Even for Internet Protocol, version 6 (IPv6), the 32-bit Identification field included when a Fragment Header is present may be smaller than desired for some applications. This specification addresses these limitations by adapting the IPv6 Extended Fragment Header for IPv4.

30/12/2024

	MISP taxonomy format
	draft-dulaunoy-misp-taxonomy-format-10.txt   Date: 30/12/2024   Authors: Alexandre Dulaunoy, Andras Iklody   Working Group: Individual Submissions (none)	This document outlines the MISP taxonomy format, a straightforward JSON structure designed to represent machine tags (also known as triple tags) vocabularies. A public directory, referred to as MISP taxonomies, is available and leverages this format. These taxonomies are used to classify cybersecurity events, threats, suspicious activities, and indicators.
	BGP SR Policy Extensions for template
	draft-zhang-idr-sr-policy-template-05.txt   Date: 30/12/2024   Authors: KaZhang, Zhibo Hu, Jie Dong, Qiangzhou Gao   Working Group: Individual Submissions (none)	Segment Routing(SR) Policies can be advertised using BGP. An SR Policy may has lots of attributes, and as the application and features evolve, the SR Policy may need have more and more attribute attributes. To avoid modifying BGP when attributes are added to an SR Policy, we can define a template. The identifier and content of the template are defined by the receiver of the SR Policy. The advertiser of an SR policy only needs to know the ID of the template. When advertising SR policy, the advertiser carries the template ID in the tunnel encapsulation information of the SR policy. After receiving the SR Policy information, the receiver obtains the corresponding template and content according to the template ID, thereby obtaining abundant constraint configuration information.
	CoAP in Space
	draft-gomez-core-coap-space-02.txt   Date: 30/12/2024   Authors: Carles Gomez, Sergio Aguilar   Working Group: Individual Submissions (none)	This document provides guidance on using the Constrained Application Protocol (CoAP) in spatial environments characterized by long delays and intermittent communication opportunities. Such environments include some Low Earth Orbit (LEO) satellite-based scenarios, as well as deep space scenarios. The document focuses on the approach whereby an IP protocol stack is used for end-to-end communication.

29/12/2024

	External References to Values in CBOR Diagnostic Notation (EDN)
	draft-ietf-cbor-edn-e-ref-01.txt   Date: 29/12/2024   Authors: Carsten Bormann   Working Group: Concise Binary Object Representation Maintenance and Extensions (cbor)	The Concise Binary Object Representation (CBOR, RFC 8949) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. CBOR diagnostic notation (EDN) is widely used to represent CBOR data items in a way that is accessible to humans, for instance for examples in a specification. At the time of writing, EDN did not provide mechanisms for composition of such examples from multiple components or sources. This document uses EDN application extensions to provide two such mechanisms, both of which insert an imported data item into the data item being described in EDN: The e'' application extension provides a way to import data items, particularly constant values, from a CDDL model (which itself has ways to provide composition). The ref'' application extension provides a way to import data items that are described in EDN.
	BGP SR Policy Extensions for metric
	draft-ietf-idr-sr-policy-metric-02.txt   Date: 29/12/2024   Authors: KaZhang, Jie Dong, Ketan Talaulikar   Working Group: Inter-Domain Routing (idr)	SR Policy candidate paths can be represented in BGP UPDATE messages. BGP can then be used to propagate the SR Policy candidate paths to the headend nodes in the network. After SR Policy is installed on the ingress node, the packets can be steered into SR Policy through route selection. Therefore, route selection may be performed on the ingress node of the SR Policy. If there are multiple routes to the same destination, the route selection node can select routes based on the local policy. The local policy may use the IGP metric of the selected path, which is the IGP Metric of the SR Policy. Thus the BGP UPDATE message needs to carry the metric of each segment list of the SR Policy Candidate Path, which can be used in path selection of routing.
	Unicast Use of the Formerly Reserved 240/4
	draft-schoen-intarea-unicast-240-08.txt   Date: 29/12/2024   Authors: Seth Schoen, John Gilmore, David Taht   Working Group: Individual Submissions (none)	This document redesignates 240/4, the region of the IPv4 address space historically known as "Experimental," "Future Use," or "Class E" address space, so that this space is no longer reserved. It asks implementers to make addresses in this range fully usable for unicast use on the Internet.
	Unicast Use of the Lowest Address in an IPv4 Subnet
	draft-schoen-intarea-unicast-lowest-address-07.txt   Date: 29/12/2024   Authors: Seth Schoen, John Gilmore, David Taht, Michael Karels   Working Group: Individual Submissions (none)	With ever-increasing pressure to conserve IP address space on the Internet, it makes sense to consider where relatively minor changes can be made to fielded practice to improve numbering efficiency. One such change, proposed by this document, is to increase the number of unicast addresses in each existing subnet, by redefining the use of the lowest-numbered (zeroth) host address in each IPv4 subnet as an ordinary unicast host identifier, instead of as a duplicate segment- directed broadcast address.
	Flow Measurement in IPv6 Network
	draft-wang-ippm-ipv6-flow-measurement-08.txt   Date: 29/12/2024   Authors: Haojie Wang, Yisong Liu, Changwang Lin, Xiao Min, Greg Mirsky, Jinming Li   Working Group: Individual Submissions (none)	This document describes how to deploy in-situ flow performance measurement based on Alternate-Marking method in IPv6 domain.
	Unicast Use of the Formerly Reserved 0/8
	draft-schoen-intarea-unicast-0-07.txt   Date: 29/12/2024   Authors: Seth Schoen, John Gilmore, David Taht   Working Group: Individual Submissions (none)	This document redesignates 0/8, the lowest block in the IPv4 address space, so that this space is no longer reserved. It asks implementers to make addresses in this range fully usable for unicast use on the Internet.
	Unicast Use of the Formerly Special-Cased 127/8
	draft-schoen-intarea-unicast-127-07.txt   Date: 29/12/2024   Authors: Seth Schoen, John Gilmore, David Taht   Working Group: Individual Submissions (none)	This document redefines the IPv4 local loopback network as consisting only of the 65,536 addresses 127.0.0.0 to 127.0.255.255 (127.0.0.0/16). It asks implementers to make addresses in the prior loopback range 127.1.0.0 to 127.255.255.255 fully usable for unicast use on the Internet.
	SRPM Path Consistency over SRv6
	draft-weng-ippm-srpm-path-consistency-over-srv6-08.txt   Date: 29/12/2024   Authors: sijun weng, Weiqiang Cheng, Changwang Lin, Xiao Min, Jinming Li   Working Group: Individual Submissions (none)	TWAMP can be used to measure the performance of end-to-end paths in networks. STAMP [rfc8762] and TWAMP light are more lightweight measurement methods. In the SRv6 network, it is also necessary to measure the performance of SRv6 policy. This document describes a method to measure srv6 policy through stamp and TWAMP light.
	Distributed Flow Measurement in IPv6
	draft-wang-ippm-ipv6-distributed-flow-measurement-06.txt   Date: 29/12/2024   Authors: Haojie Wang, Jinming Li, Changwang Lin, Xiao Min, Greg Mirsky   Working Group: Individual Submissions (none)	In IPv6 networks, performance measurements such as packet loss, delay and jitter of real traffic can be carried out based on the Alternate-Marking method. Usually, the controller needs to collect statistical data on network devices, calculate and present the measurement results. This document proposes a distributed method for on-path flow measurement, which is independent of the controller.
	Intra-domain SAV Support via BGP
	draft-cheng-savnet-intra-domain-sav-bgp-02.txt   Date: 29/12/2024   Authors: Weiqiang Cheng, Changwang Lin, 1211176911910469110103   Working Group: Individual Submissions (none)	This document describes a method for publishing source prefixes via the BGP protocol, iterating through the SAV table entries based on intra-domain next hop SAV rules. The generation of intra-domain next hop SAV rules is implemented by the intra-domain IGP protocol, and the BGP protocol inherits the source interface list from its next hop SAV rules to generate the SAV rule table for source prefixes.
	BGP SR Policy Extensions for Weight Time Range
	draft-yang-idr-sr-policy-weight-timerange-01.txt   Date: 29/12/2024   Authors: Feng Yang, Changwang Lin   Working Group: Individual Submissions (none)	Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is a set of candidate paths, each consisting of one or more segment lists. In the scenario where there are multiple segment list paths, traffic load balancing can be achieved based on the weight value assigned to each path. Typically, the weight value for each path is fixed. This document defines an extension of BGP SR Policy for setting the weight value for each path based on time range.
	Sockets API Extensions for In-kernel QUIC Implementations
	draft-lxin-quic-socket-apis-01.txt   Date: 29/12/2024   Authors: Long Xin, Moritz Buhl, Marcelo Leitner   Working Group: Individual Submissions (none)	This document describes a mapping of In-kernel QUIC Implementations into a sockets API. The benefits of this mapping include compatibility for TCP applications, access to new QUIC features, and a consolidated error and event notification scheme. In-kernel QUIC enables usage for both userspace applications and kernel consumers.
	Public Key Hash for Local Domains
	draft-wing-settle-public-key-hash-00.txt   Date: 29/12/2024   Authors: Dan Wing   Working Group: Individual Submissions (none)	This specification eliminates security warnings when connecting to local domains using TLS. Servers use a unique, long hostname which encodes their public key that the client validates against the public key presented in the TLS handshake.

28/12/2024

	ICMP Extensions for Environmental Information
	draft-pignataro-green-enviro-icmp-01.txt   Date: 28/12/2024   Authors: Carlos Pignataro, Jainam Parikh, Ron Bonica, Michael Welzl   Working Group: Individual Submissions (none)	This document defines a data structure that can be appended to selected ICMP messages. The ICMP extension defined herein can be used to gain visibility on environmental sustainability information on the Internet by providing per-hop (i.e., per topological network node) power metrics and other current or future sustainability metrics. This will contribute to achieving an objective mentioned in the IAB E-Impact workshop. The techniques presented are useful not only in a transactional setting (e.g., a user-issued traceroute or a ping request), but also in a scheduled automated setting where they may be run periodically in a mesh across an administrative domain to map out environmental sustainability metrics.

27/12/2024

	MPLS Network Actions (MNA) Framework
	draft-ietf-mpls-mna-fwk-15.txt   Date: 27/12/2024   Authors: Loa Andersson, Stewart Bryant, Matthew Bocci, Tony Li   Working Group: Multiprotocol Label Switching (mpls)	This document describes an architectural framework for the MPLS Network Actions (MNA) technologies. MNA technologies are used to indicate actions that impact the forwarding or other processing (such as monitoring) of the packet along the Label Switched Path (LSP) of the packet and to transfer any additional data needed for these actions. The document provides the foundation for the development of a common set of network actions and information elements supporting additional operational models and capabilities of MPLS networks.
	DHCPv6 Extension Practices and Considerations
	draft-rhl-dhc-dhcpv6-extensions-02.txt   Date: 27/12/2024   Authors: Ren Gang, Lin He, Ying Liu   Working Group: Individual Submissions (none)	IP addresses assume an increasing number of attributes as communication identifiers to meet different requirements. Privacy protection, accountability, security, and manageability of networks can be supported by extending the DHCPv6 protocol as required. This document provides current extension practices and typical DHCPv6 server software in terms of extensions, defines a general model of DHCPv6, discusses some extension points, and presents extension cases.
	Architectural Considerations for Environmental Sustainability
	draft-pignataro-enviro-sustainability-architecture-01.txt   Date: 27/12/2024   Authors: Carlos Pignataro, Ali Rezaki, Suresh Krishnan, Jari Arkko, Alexander Clemm, Hesham ElBakoury   Working Group: Individual Submissions (none)	This document describes several of the design tradeoffs for trying to optimize for sustainability along with the other common networking metrics such as performance and availability.
	Sustainability Considerations for Networking Protocols and Applications
	draft-pignataro-enviro-sustainability-consid-01.txt   Date: 27/12/2024   Authors: Carlos Pignataro, Ali Rezaki, Jari Arkko, Alexander Clemm, Hesham ElBakoury   Working Group: Individual Submissions (none)	Embedding sustainability considerations at the design of new protocols and extensions is more effective than attempting to do so after-the-fact. Consequently, this document also gives network, protocol, and application designers and implementors sustainability- related advice and guideance. This document recommends to authors and reviewers the inclusion of a Sustainability Considerations section in IETF Internet-Drafts and RFCs.
	Environmental Sustainability Terminology and Concepts
	draft-pignataro-green-enviro-sust-terminology-01.txt   Date: 27/12/2024   Authors: Carlos Pignataro, Ali Rezaki, Hesham ElBakoury   Working Group: Individual Submissions (none)	This document defines a set of sustainability-related terms and concepts to be used while describing and evaluating the negative and positive environmental sustainability impacts and implications of Internet technologies.
	Next Generation browser
	draft-pradeepkumarxplorer-ngenbrowser-00.txt   Date: 27/12/2024   Authors: pradeep xplorer   Working Group: Individual Submissions (none)	Next Generation browser

26/12/2024

	BGP Extensions of SR Policy for Composite Candidate Path
	draft-jiang-idr-sr-policy-composite-path-01.txt   Date: 26/12/2024   Authors: Jiang Wenying, Changwang Lin, Ran Chen   Working Group: Individual Submissions (none)	Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths. A candidate path is either dynamic, explicit or composite. This document defines extensions to BGP to distribute SR policies carrying composite candidate path information. So that composite candidate paths can be installed when the SR policy is applied.

25/12/2024

	Latency Guarantee with Stateless Fair Queuing
	draft-joung-detnet-stateless-fair-queuing-04.txt   Date: 25/12/2024   Authors: Jinoo Joung, Jeong-dong Ryoo, Taesik Cheung, Yizhou Li, Peng Liu   Working Group: Individual Submissions (none)	This document specifies the framework and the operational procedure for deterministic networking with a set of rate based work conserving packet schedulers. The framework guarantees end-to-end (E2E) latency bounds to flows. The schedulers in core nodes do not need to maintain flow states. Instead, the entrance node of a flow marks an ideal service completion time according to a fluid model, called Finish Time (FT), of a packet in the packet header. The subsequent core nodes update FT by adding delay factors, which are functions of the flow and the nodes. The packets in the queue of the scheduler are served in the ascending order of FT. This mechanism is called the stateless fair queuing. The result is that flows are isolated from each other almost perfectly. The latency bound of a flow depends only on the flow's intrinsic parameters such as the maximum burst size and the service rate, except the link capacities and the maximum packet length among other flows sharing each output link with the flow.
	IGP Extensions for Optimized SRv6 SID Advertisement
	draft-cheng-lsr-extension-opt-srv6-sid-adv-01.txt   Date: 25/12/2024   Authors: Weiqiang Cheng, Liyan Gong, Changwang Lin, Louis Chan   Working Group: Individual Submissions (none)	When the IGP runs SRv6 Flex-Algo or performs QoS resource allocation, it needs to assign a large number of END.X SIDs, which can significantly impact IGP LSDB advertisements and overall performance. This document proposes a simplified method for advertising a large number of SRv6 SIDs. This method is particularly useful in scenarios that require generating many END.X SIDs, such as when supporting numerous Flex-Algo algorithms. It helps reduce the size of LSDB advertisements and improves IGP advertisement efficiency and operational performance.

23/12/2024

	Adaptive IPv4 Address Space
	draft-chen-ati-adaptive-ipv4-address-space-17.txt   Date: 23/12/2024   Authors: Abraham Chen, Ramamurthy Ati, Abhay Karandikar, David Crowe   Working Group: Individual Submissions (none)	This document describes a solution to the Internet address depletion issue through the use of an existing Option mechanism that is part of the original IPv4 protocol. This proposal, named EzIP (phonetic for Easy IPv4), outlines the IPv4 public address pool expansion and the Internet system architecture enhancement considerations. EzIP may expand an IPv4 address by a factor of 256M without affecting the existing IPv4 based Internet, or the current private networks. It is in full conformance with the IPv4 protocol, and supports not only both direct and private network connectivity, but also their interoperability. EzIP deployments may coexist with existing Internet traffic and IoTs (Internet of Things) operations without perturbing their setups, while offering end-users the freedom to indepdently choose which service. EzIP may be implemented as a software or firmware enhancement to Internet edge routers or private network routing gateways, wherever needed, or simply installed as an inline adjunct hardware module between the two, enabling a seamless introduction. The 256M case detailed here establishes a complete spherical layer of an overlay of routers for interfacing between the Internet fabic (core plus edge routers) and the end user premises or IoTs. Incorporating caching proxy technology in the gateway, a fairly large geographical region may enjoy address expansion based on as few as one ordinary IPv4 public address utilizing IP packets with degenerated EzIP header. If IPv4 public pool allocations were reorganized, the assignable pool could be multiplied 512M fold or even more. Enabling hierarchical address architecture which facilitates both hierarchical and mesh routing, EzIP can provide nearly the same order of magnitude of address pool resources as IPv6 while streamlining the administrative aspects of it. The basic EzIP will immediately resolve the local IPv4 address shortage, while being transparent to the rest of the Internet as a new parallel facility. Under the Dual-Stack environment, these proposed interim facilities will relieve the IPv4 address shortage issue, while affording IPv6 more time to reach maturity for providing the availability levels required for delivering a long-term general service. The basic EzIP may be deployed in two distinctive phases. First, the CG-NAT operation may be enhanced by enabling the use of 240/4 netblock in addition to the current 100.64/10 netblock of RFC6598. This makes end-to-end connectivity feasible within the service area of each 240/4 netblock. Second, this capability may extend to global coverage with the use of the Option Word mechanism in the IP header.
	IGP Extensions for Deterministic Traffic Engineering
	draft-peng-lsr-deterministic-traffic-engineering-03.txt   Date: 23/12/2024   Authors: Shaofu Peng   Working Group: Individual Submissions (none)	This document describes IGP extensions to support Traffic Engineering (TE) of deterministic routing, by specifying new information that a router can place in the advertisement of neighbors. This information describes additional details regarding the state of the network that are useful for deterministic traffic engineering path computations.
	Research Agenda for a Post-Quantum DNSSEC
	draft-fregly-research-agenda-for-pqc-dnssec-02.txt   Date: 23/12/2024   Authors: Andrew Fregly, Roland van Rijswijk-Deij, Moritz Mueller, Peter Thomassen, Caspar Schutijser, Taejoong Chung   Working Group: Individual Submissions (none)	This document describes a notional research agenda for collaborative multi-stakeholder research related to a future post-quantum DNSSEC ecosystem. It is inspired by the anticipation that adoption of Post- Quantum signature algorithms will have enough operational impact on DNSSEC that either DNS protocol enhancements will be needed, or DNS will move away from UDP as the prevalent DNS transport, or a combination of both will be needed. Some members of the DNS technical community have even suggested evaluating alternatives to DNSSEC and potentially adopting an alternative protocol or practices to assure the integrity of DNS responses. Given the potential impact of such changes on the DNS ecosystem, the authors believe collaborative multi-stakeholder research into the impact of proposed changes should be performed to inform adoption and standardization activities.
	PCRP Webhook Specification
	draft-deepakarumugham-pcrp-spec-00.txt   Date: 23/12/2024   Authors: Deepak Arumugham   Working Group: Individual Submissions (none)	This document defines the PCRP (Ping, Challenge, Resolve, Product) Specification for Webhook events in a standardized way. It is specifically designed to address the challenges faced in current webhook event implementations, which lack consistency and a defined flow. PCRP introduces a new header X-PCRP-Type to indicate the step of the process, and its values include ping, challenge, resolve, and product.

22/12/2024

	Attacks on the Constrained Application Protocol (CoAP)
	draft-ietf-core-attacks-on-coap-05.txt   Date: 22/12/2024   Authors: John Mattsson, John Fornehed, Goeran Selander, Francesca Palombini, Christian Amsuess   Working Group: Constrained RESTful Environments (core)	Being able to securely retrieve information from sensors and control actuators while providing guards against distributed denial-of- service (DDoS) attacks are key requirements for CoAP deployments. To that aim, a security protocol (e.g., DTLS, TLS, or OSCORE) can be enabled to ensure secure CoAP operation, including protection against many attacks. This document identifies a set of known CoAP attacks and shows that simply using CoAP with a security protocol is not always enough for secure operation. Several of the identified attacks can be mitigated with a security protocol providing confidentiality and integrity combined with the solutions specified in RFC 9175.
	A taxonomy of eavesdropping attacks
	draft-richardson-saag-onpath-attacker-04.txt   Date: 22/12/2024   Authors: Michael Richardson, Jonathan Hoyland   Working Group: Individual Submissions (none)	The terms on-path attacker and MITM Attack have been used in a variety of ways, sometimes interchangeably, and sometimes meaning different things. Increasingly people have become uncomfortable with the gendered term "Man" in the middle and have sought alternatives. This document offers an update on terminology for network attacks, retaining some acronyms terms while redefining the expansion, and clarifying the different kinds of attacks. Consistent terminology is important in describing what kinds of attacks a particular protocol defends against, and which kinds the protocol does not.
	WebTransport over WebSocket
	draft-richter-webtransport-websocket-02.txt   Date: 22/12/2024   Authors: Marten Richter   Working Group: Individual Submissions (none)	WebTransport [OVERVIEW], a protocol framework within the Web security model, empowers Web clients to initiate secure multiplexed transport for low-level client-server interactions with remote servers. This document outlines a protocol, based on WebSocket [WEBSOCKET], offering WebTransport capabilities similar to the HTTP/2 variant [WEBTRANSPORT-H2]. It serves as an alternative when UDP-based protocols are inaccessible, and the client environment exclusively supports WebSocket [WEBSOCKET].

21/12/2024

	A Task Segmentation Framework for Computing-Aware Traffic Steering
	draft-li-cats-task-segmentation-framework-01.txt   Date: 21/12/2024   Authors: Chuanghuan Li, 89 117, Shicong Zhang, Bo Ma   Working Group: Individual Submissions (none)	This document proposes an extension to the Computing-Aware Traffic Steering (CATS) framework by introducing a task segmentation module. This extension enables the CATS framework to handle divisible computing requests by breaking them down into smaller computational units, referred to as "Task". The document focuses on two primary task segmentation modes: the distributed mode and the stepwise mode, providing detailed workflows for each.

20/12/2024

	BGP Usage for SD-WAN Overlay Networks
	draft-ietf-bess-bgp-sdwan-usage-25.txt   Date: 20/12/2024   Authors: Linda Dunbar, Ali Sajassi, John Drake, Basil Najem, Susan Hares   Working Group: BGP Enabled ServiceS (bess)	This document explores the complexities involved in managing large scale Software Defined WAN (SD-WAN) overlay networks, along with various SD-WAN scenarios. Its objective is to illustrate how the BGP-based control plane can effectively manage large-scale SD-WAN overlay networks with minimal manual intervention.
	DHCPv4-over-DHCPv6 (DHCP 4o6) with Relay Agent Support
	draft-ietf-dhc-dhcpv4-over-dhcpv6-ra-01.txt   Date: 20/12/2024   Authors: Claudio Porfiri, Suresh Krishnan, Jari Arkko, Mirja Kuehlewind   Working Group: Dynamic Host Configuration (dhc)	This document describes a mechanism for networks with legacy IPv4-only clients to use services provided by DHCPv6 using DHCPv4- over-DHCPv6 (DHCP 4o6) in a Relay Agent. RFC7341 specifies use of DHCPv4-over-DHCPv6 in the client only. This document specifies a RFC7341-based approach that allows DHCP 4o6 to be deployed as a Relay Agent (4o6RA) that implements the 4o6 DHCP encapsulation and decapsulation in contexts where it is not possible at the client.
	api-catalog: a well-known URI and link relation to help discovery of APIs
	draft-ietf-httpapi-api-catalog-08.txt   Date: 20/12/2024   Authors: Kevin Smith   Working Group: Building Blocks for HTTP APIs (httpapi)	This document defines the "api-catalog" well-known URI and link relation. It is intended to facilitate automated discovery and usage of published APIs. A request to the api-catalog resource will return a document providing information about, and links to, the publisher's APIs.
	Randomized and Changing MAC Address: Context,Network Impacts,and Use Cases
	draft-ietf-madinas-use-cases-19.txt   Date: 20/12/2024   Authors: Jerome Henry, Yiu Lee   Working Group: MAC Address Device Identification for Network and Application Services (madinas)	To limit the privacy issues created by the association between a device, its traffic, its location, and its user in [IEEE_802] networks, client and client Operating System vendors have started implementing MAC address randomization. This technology is particularly important in Wi-Fi [IEEE_802.11] networks due to the over-the-air medium and device mobility. When such randomization happens, some in-network states may break, which may affect network connectivity and user experience. At the same time, devices may continue using other stable identifiers, defeating the MAC address randomization purposes. This document lists various network environments and a range of network services that may be affected by such randomization. This document then examines settings where the user experience may be affected by in-network state disruption. Last, this document examines two existing frameworks to maintain user privacy while preserving user quality of experience and network operation efficiency.
	OAuth Status Assertions
	draft-demarco-oauth-status-assertions-03.txt   Date: 20/12/2024   Authors: Giuseppe De Marco, Orie Steele, Francesco Marino, Marina Adomeit   Working Group: Individual Submissions (none)	Status Assertion is a signed object that demonstrates the validity status of a Digital Credential. These assertions are periodically provided to Holders, who can present these to Credential Verifier along with the corresponding Digital Credentials. The approach outlined in this document makes the Credential Verifier able to check the status, such as the non-revocation, of a Digital Credential without requiring to query any third-party entities.
	On-path Telemetry YANG Data Model
	draft-fz-ippm-on-path-telemetry-yang-01.txt   Date: 20/12/2024   Authors: Giuseppe Fioccola, Tianran Zhou   Working Group: Individual Submissions (none)	This document proposes a YANG data model for monitoring on-path telemetry information. The Alternate-Marking Method and In-situ Operations, Administration, and Maintenance (IOAM) are the on-path hybrid measurement methods considered in this document.
	Trust is non-negotiable
	draft-jackson-tls-trust-is-nonnegotiable-00.txt   Date: 20/12/2024   Authors: Dennis Jackson   Working Group: Individual Submissions (none)	This document considers proposals to enable the negotiation of trust anchors in TLS. It makes three basic arguments: that trust negotiation is not helpful in addressing the problems it claims to address, that trust negotiation instead comes with material harms to the critical trust infrastructure of the Internet, and that the proposed mechanisms for deploying trust negotiation are unworkable. This draft goes on to discuss simpler and more effective solutions to these problems.

19/12/2024

	BGP Extensions for BIER
	draft-ietf-bier-idr-extensions-19.txt   Date: 19/12/2024   Authors: Xiaohu Xu, Mach Chen, Keyur Patel, IJsbrand Wijnands, Tony Przygienda, Zhaohui Zhang   Working Group: Bit Indexed Explicit Replication (bier)	Bit Index Explicit Replication (BIER) is a multicast forwarding architecture that doesn't require an explicit tree-building protocol and doesn't require intermediate routers to maintain per-tree multicast states. Some BIER-specific information and state, which are only in proportion to the number of BIER routers but not per- tree, do need to be advertised, calculated, and maintained. This document describes BGP extensions for advertising the BIER information and methods for calculating BIER states based on the advertisements.
	OAuth Resource Helper
	draft-vandermeulen-oauth-resource-helper-00.txt   Date: 19/12/2024   Authors: Pieter van der Meulen, Michiel de Jong   Working Group: Individual Submissions (none)	This Internet Draft introduces the concept of a Resource Helper in OAuth 2.0. A Resource Helper is a modular component that assists the Authorization Server in managing fine-grained authorization processes. The Resource Helper, associated with a specific Resource Server, handles scope selection and resource-specific details, providing the user-interface for the Resource Owner to approve or refine access requests. By offloading scope-related user interaction to the Resource Helper, the Authorization Server remains generic and stable while the Resource Helper evolves alongside the Resource Server's requirements. This specification defines the protocol, interfaces, and flow between the Authorization Server and the Resource Helper. Introducing a Resource Helper does not affect the OAuth client or the interaction between the OAuth client and the Resource Server.
	Configuring UDP Sockets for ECN for Common Platforms
	draft-ietf-tsvwg-udp-ecn-00.txt   Date: 19/12/2024   Authors: Martin Duke   Working Group: Transport and Services Working Group (tsvwg)	Explicit Congestion Notification (ECN) applies to all transport protocols in principle. However, it had limited deployment for UDP until QUIC became widely adopted. As a result, documentation of UDP socket APIs for ECN on various platforms is sparse. This document records the results of experimenting with these APIs in order to get ECN working on UDP for Chromium on Apple, Linux, and Windows platforms.

18/12/2024

	Constrained Application Protocol (CoAP): Corrections and Clarifications
	draft-ietf-core-corr-clar-01.txt   Date: 18/12/2024   Authors: Carsten Bormann   Working Group: Constrained RESTful Environments (core)	RFC 7252 defines the Constrained Application Protocol (CoAP), along with a number of additional specifications, including RFC 7641, RFC 7959, RFC 8132, and RFC 8323. RFC 6690 defines the link format that is used in CoAP self-description documents. Some parts of the specification may be unclear or even contain errors that may lead to misinterpretations that may impair interoperability between different implementations. The present document provides corrections, additions, and clarifications to the RFCs cited; this document thus updates these RFCs. In addition, other clarifications related to the use of CoAP in other specifications, including RFC 7390 and RFC 8075, are also provided.
	Something Better Than Errata
	draft-farrell-errata-02.txt   Date: 18/12/2024   Authors: Stephen Farrell   Working Group: Individual Submissions (none)	This document outlines some ideas for a new errata handling policy that would (in the author's view) be better than current errata handling. This is for discussion and is not expected to become an RFC.
	An Update on Milestones
	draft-schinazi-update-on-milestones-03.txt   Date: 18/12/2024   Authors: David Schinazi   Working Group: Individual Submissions (none)	As mandated in RFC 2418, working group charters currently contain milestones. However, these milestones are often sufficiently out of date that they no longer provide value. This document makes milestones optional and allows more discretion on their dates. It updates RFC 2418.
	Deterministic Networking SRv6 Data Plane
	draft-varga-detnet-srv6-data-plane-01.txt   Date: 18/12/2024   Authors: Balazs Varga, Ferenc Fejes   Working Group: Individual Submissions (none)	This document specifies the Deterministic Networking (DetNet) data plane when operating over an IPv6/SRv6 Packet Switched Network. It leverages existing IPv6 encapsulations using DetNet specific SIDs and optionaly the Traffic Engineering mechanisms provided by SRv6. This document builds on the DetNet architecture and data plane framework.
	Deterministic Networking specific SID
	draft-varga-spring-preof-sid-01.txt   Date: 18/12/2024   Authors: Balazs Varga, Ferenc Fejes   Working Group: Individual Submissions (none)	Replication, Elimination and Ordering functions of the DetNet Architecture require packet sequence information (i.e., sequence number) to provide service protection by the DetNet service sub- layer. This document extends SRv6 Network Programming [RFC8986] with new SR endpoint and transit behaviors to be performed on packets of DetNet flows to support the specific service protection treatment.
	TLS Trust Anchor Identifiers
	draft-beck-tls-trust-anchor-ids-03.txt   Date: 18/12/2024   Authors: Bob Beck, David Benjamin, Devon O'Brien, Kyle Nekritz   Working Group: Individual Submissions (none)	This document defines the TLS Trust Anchors extension, a mechanism for relying parties to convey trusted certification authorities. It describes individual certification authorities more succinctly than the TLS Certificate Authorities extension. Additionally, to support TLS clients with many trusted certification authorities, it supports a mode where servers describe their available certification paths and the client selects from them. Servers may describe this during connection setup, or in DNS for lower latency.
	What is TCP?
	draft-bormann-what-is-tcp-00.txt   Date: 18/12/2024   Authors: Carsten Bormann   Working Group: Individual Submissions (none)	This document references STD 7.

17/12/2024

	Interconnecting domains with IBGP
	draft-smn-idr-inter-domain-ibgp-06.txt   Date: 17/12/2024   Authors: Krzysztof Szarkowicz, Moshiko Nayman, Israel Means   Working Group: Individual Submissions (none)	This document relaxes the recommendations specified in BGP/MPLS IP Virtual Private Networks (VPNs) and BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) allowing the building of Inter-domain L3VPN architecture with internal BGP.
	Fast Congestion Notification Packet (CNP) in RoCEv2 Networks
	draft-xiao-rtgwg-rocev2-fast-cnp-02.txt   Date: 17/12/2024   Authors: Xiao Min, lihesong   Working Group: Individual Submissions (none)	This document describes a Remote Direct Memory Access (RDMA) over Converged Ethernet version 2 (RoCEv2) congestion control mechanism, which is inspired by Really Explicit Congestion Notification (RECN) described in RFC 7514, also known as Fast Congestion Notification Packet (Fast CNP). By extending the RoCEv2 CNP, Fast CNP can be sent by the switch directly to the sender, advising the sender to reduce the transmission rate at which it sends the flow of RoCEv2 data traffic.
	Unsigned X.509 Certificates
	draft-davidben-x509-alg-none-01.txt   Date: 17/12/2024   Authors: David Benjamin   Working Group: Individual Submissions (none)	This document defines a placeholder X.509 signature algorithm that may be used in contexts where the consumer of the certificate does not intend to verify the signature.
	Secure Asset Transfer (SAT) Interoperability Architecture
	draft-ietf-satp-architecture-06.txt   Date: 17/12/2024   Authors: Thomas Hardjono, Martin Hargreaves, Ned Smith, Venkatraman Ramakrishna   Working Group: Secure Asset Transfer Protocol (satp)	This document proposes an interoperability architecture for the secure transfer of assets between two networks or systems based on the gateway model.

16/12/2024

	Non-source-routed Multicast in SR Networks
	draft-zzhang-mboned-non-source-routed-sr-mcast-01.txt   Date: 16/12/2024   Authors: Zhaohui Zhang, IJsbrand Wijnands, Hooman Bidgoli, Yisong Liu   Working Group: MBONE Deployment (mboned)	With Segment Routing (SR) architecture, a unicast flow can be source- routed through an SR network following an explicit path specified in the packet, w/o the need for per-flow state in the network. As a result, the otherwise needed protocols to signal the per-flow unicast state can also be removed from the network. In the case of multicast, traffic can be either source-routed or non-source-routed, and this document discusses non-sourced-routed options for multicast in an SR network with either MPLS or IPv6/SRv6 data plane.
	ICANN Registry Interfaces
	draft-lozano-icann-registry-interfaces-23.txt   Date: 16/12/2024   Authors: Gustavo Ibarra, Eduardo Alvarez   Working Group: Individual Submissions (none)	This document describes the technical details of the interfaces provided by the Internet Corporation for Assigned Names and Numbers (ICANN) to its contracted parties to fulfill reporting requirements. The interfaces provided by ICANN to Data Escrow Agents and Registry Operators to fulfill the requirements of Specifications 2 and 3 of the gTLD Base Registry Agreement are described in this document. Additionally, interfaces for retrieving the IP addresses of the probe nodes used in the SLA Monitoring System (SLAM) and interfaces for supporting maintenance window objects are described in this document.
	Problems and Requirements of Addressing in Integrated Space-Terrestrial Network
	draft-li-istn-addressing-requirement-05.txt   Date: 16/12/2024   Authors: Yuanjie Li, Hewu Li, Lixin Liu, Qian Wu, Jun Liu   Working Group: Individual Submissions (none)	This document presents a detailed analysis of the problems and requirements of network addressing in "Internet in space" for terrestrial users. It introduces the basics of satellite mega- constellations, terrestrial terminals/ground stations, and their inter-networking. Then it explicitly analyzes how space-terrestrial mobility yeilds challenges for the logical topology, addressing, and their impact on routing. The requirements of addressing in the space-terrestrial network are discussed in detail, including uniqueness, stability, locality, scalability, efficiency and backward compatibility with terrestrial Internet. The problems and requirements of network addressing in space-terrestrial networks are finally outlined.
	SID as source address in SRv6
	draft-yang-spring-sid-as-source-address-05.txt   Date: 16/12/2024   Authors: Feng Yang, Changwang Lin   Working Group: Individual Submissions (none)	In SRv6 network, the SRv6 packets usually use loopback address as source address. However, when there is symmetric traffic requirement for bidirectional flow, or there is requirement for traffic source validation, using loopback address as source address is not sufficient. This document proposes using SID as source address for SRv6 traffic, also identifies solution for several use cases.
	Agreements To Fix Forwarding
	draft-vesely-fix-forwarding-02.txt   Date: 16/12/2024   Authors: Alessandro Vesely   Working Group: Individual Submissions (none)	The widespread adoption of Domain-based Message Authentication, Reporting, and Conformance (DMARC) causes problems to indirect mail flows. This document proposes a protocol to establish forwarding agreements whereby a mailbox provider can whitelist indirect mail flows directed toward its users by maintaining per-user lists of agreements.
	RDAP Extension for DNS Time-To-Live (TTL Values)
	draft-brown-rdap-ttl-extension-02.txt   Date: 16/12/2024   Authors: Gavin Brown   Working Group: Individual Submissions (none)	This document describes an extension to the Registration Data Access Protocol ([RFC9083]) which allows the Time-To-Live (TTL) values for relevant DNS record types to be included in RDAP responses. About this draft This note is to be removed before publishing as an RFC. The source for this draft, and an issue tracker, may can be found at https://github.com/gbxyz/rdap-ttl-extension.
	STAMP Extensions for DetNet
	draft-xp-ippm-detnet-stamp-01.txt   Date: 16/12/2024   Authors: Xiao Min, Shaofu Peng, Xiaoming He   Working Group: Individual Submissions (none)	Deterministic Networking (DetNet) provides a capability for the delivery of data flows with extremely low packet loss rates and bounded end-to-end delivery latency. The enabler to DetNet is a proper queue scheduling mechanism, such as timeslot based queueing and forwarding mechanism, which requires every router along the DetNet path to collect the basic timeslot mapping relationship between itself and its adjacent router. This document defines two Simple Two-Way Active Measurement Protocol (STAMP) TLVs, to acquire the basic timeslot mapping relationship between the local router and its adjacent router.
	Discovery of Network Rate-Limit Policies (NRLPs)
	draft-brw-scone-rate-policy-discovery-02.txt   Date: 16/12/2024   Authors: Mohamed Boucadair, Dan Wing, Tirumaleswar Reddy.K, Sridharan Rajagopalan, Gyan Mishra, Markus Amend, Luis Contreras   Working Group: Individual Submissions (none)	This document specifies mechanims for hosts to dynamically discover Network Rate-Limit Policies (NRLPs). This information is then passed to applications that might adjust their behaviors accordingly. Networks already support mechanisms to advertize a set of network properties to hosts (e.g., link MTU (RFC 4861) and PREFIX64 (RFC 8781)). This document complements these tools and specifies a Neighbor Discovery option to be used in Router Advertisements (RAs) to communicate NRLPs to hosts. For address family parity, a new DHCP option is also defined. The document also discusses how Provisioning Domains (PvD) can be used to notify hosts with NRLPs.
	Security and Privacy Considerations for Deep Space Network
	draft-xu-deepspace-security-privacy-considerations-00.txt   Date: 16/12/2024   Authors: Lei Xu, Cuicui Wang, Yu Fu, Yunshi Wang   Working Group: Individual Submissions (none)	Deep Space Network (DSN) inherits potential security vulnerabilities as well as privacy issues. This document describes various threats and security concerns related to Deep Space Networks and existing approaches to solve these threats.

15/12/2024

	Matroska Media Container Codec Specifications
	draft-ietf-cellar-codec-14.txt   Date: 15/12/2024   Authors: Steve Lhomme, Moritz Bunkus, Dave Rice   Working Group: Codec Encoding for LossLess Archiving and Realtime transmission (cellar)	This document defines the Matroska codec mappings, including the codec ID, layout of data in a Block element and in an optional CodecPrivate element.
	Resource Allocation Model for Hybrid Switching Networks
	draft-sun-nmrg-hybrid-switching-11.txt   Date: 15/12/2024   Authors: Weiqiang Sun, Junyi Shao, Weisheng Hu   Working Group: Individual Submissions (none)	The fast increase in traffic volumn within and outside Datacenters is placing an unprecendented challenge on the underline network, in both the capacity it can provide, and the way it delivers traffic. When a large portion of network traffic is contributed by large flows, providing high capacity and slow to change optical circuit switching along side fine-granular packet services may potentially improve network utility and reduce both CAPEX and OpEX. This gives rise to the concept of hybrid switching - a paradigm that seeks to make the best of packet and circuit switching. However, the full potential of hybrid switching networks (HSNs) can only be realized when such a network is optimally designed and operated, in the sense that "an appropriate amount of resource is used to handle an appropriate amount of traffic in both switching planes." The resource allocation problem in HSNs is in fact complex ineractions between three components: resource allocation between the two switching planes, traffic partitioning between the two switching planes, and the overall cost or performance constraints. In this memo, we explore the challenges of planning and operating hybrid switching networks, with a particular focus on the resource allocation problem, and provide a high-level model that may guide resource allocation in future hybrid switching networks.
	Transient Hiding of Hop-by-Hop Options
	draft-eastlake-6man-hide-options-08.txt   Date: 15/12/2024   Authors: Donald Eastlake, Jie Dong   Working Group: Individual Submissions (none)	There are an increasing number of IPv6 hop-by-hop options specified but such IPv6 options are poorly handled, particularly by high-speed routers in the core Internet where packets having options may be discarded. This document proposes a simple method of transiently hiding such options for part of a packet's path to protect the packet from discard or mishandling.
	Post-Quantum Guidance for TLS.
	draft-farrell-tls-pqg-00.txt   Date: 15/12/2024   Authors: Stephen Farrell   Working Group: Individual Submissions (none)	We provide guidance on the use of post-quantum algorithms for those deploying applications using TLS.

14/12/2024

	Support of Observation Timestamp in YANG-Push Notifications
	draft-tgraf-netconf-yang-push-observation-time-03.txt   Date: 14/12/2024   Authors: Thomas Graf, Benoit Claise, Alex Feng   Working Group: Individual Submissions (none)	This document extends YANG-Push Notifications with the YANG objects observation timestamp and point-in-time for streaming update YANG- Push notifications.
	Signed Prefix List (SPL) Based Route Origin Verification and Operational Considerations
	draft-ietf-sidrops-spl-verification-01.txt   Date: 14/12/2024   Authors: Kotikalapudi Sriram, Job Snijders, Doug Montgomery   Working Group: SIDR Operations (sidrops)	The Signed Prefix List (SPL) is an RPKI object that attests to the complete list of prefixes which an Autonomous System (AS) may originate in the Border Gateway Protocol (BGP). This document specifies an SPL-based Route Origin Verification (SPL-ROV) methodology and combines it with the ROA-based ROV (ROA-ROV) to facilitate an integrated mitigation strategy for prefix hijacks and AS forgery. The document also explains the various BGP security threats that SPL can help address and provides operational considerations associated with SPL-ROV deployment.
	The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
	draft-ietf-tls-rfc9147bis-00.txt   Date: 14/12/2024   Authors: Eric Rescorla, Hannes Tschofenig, Nagendra Modadugu   Working Group: Transport Layer Security (tls)	This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347.

13/12/2024

	EAT profile for Intel(r) Trust Domain Extensions (TDX) attestation result
	draft-kdyxy-rats-tdx-eat-profile-02.txt   Date: 13/12/2024   Authors: Greg Kostal, Sindhuri Dittakavi, Raghuram Yeluri, Haidong Xia, Jerry Yu   Working Group: Individual Submissions (none)	Intel® Trust Domain Extensions (TDX) introduce architectural elements designed for the deployment of hardware-isolated virtual machines (VMs) known as trust domains (TDs). TDX is designed to provide a secure and isolated environment for running sensitive workloads or applications. This Entity Attestation Token (EAT) profile outlines claims for an Intel TDX attestation result which facilitate the establishment of trust between a relying party and the environment.
	Responsive Use of the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2
	draft-dearlove-manet-olsrv2-responsive-01.txt   Date: 13/12/2024   Authors: Christopher Dearlove   Working Group: Individual Submissions (none)	This specification describes an optional Topology Control (TC) message that can be sent by an OLSRv2 router. This is permitted, but not suggested, by the existing protocol, but is here recommended for use in some networks. The original motivation for this message came from the circumstances of a mostly stable network, in the most extreme case updated only by messages responding to the arrival and departure of routers, in which case the additional TC message is not just recommended but required. However, the additional message could be useful in reducing the routing convergence time in any network in which messages are sent at lengthy intervals. This specification updates RFC 7181 "The Optimized Link State Routing Protocol version 2 (OLSRv2)".
	Throughput Advice Object for SCONE
	draft-brw-scone-throughput-advice-blob-02.txt   Date: 13/12/2024   Authors: Mohamed Boucadair, Dan Wing, Tirumaleswar Reddy.K, Sridharan Rajagopalan, Luis Contreras   Working Group: Individual Submissions (none)	Traffic exchanged over a network may be subject to rate-limit policies for various operational reasons. This document specifies a generic object (called, Throughput Advice) that can be used by mechanisms for hosts to dynamically discover these network rate-limit policies. This information is then passed to applications that might adjust their behaviors accordingly. The design of the throughput advice object is independent of the discovery channel (protocol, API, etc.).

12/12/2024

	IPv6 Query for Enabled In-situ OAM Capabilities
	draft-ietf-6man-icmpv6-ioam-conf-state-07.txt   Date: 12/12/2024   Authors: Xiao Min, Greg Mirsky   Working Group: IPv6 Maintenance (6man)	This document describes the application of the mechanism of discovering In-situ OAM (IOAM) capabilities, described in RFC 9359 "Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities", in IPv6 networks. IPv6 Node IOAM Request uses the IPv6 Node Information messages, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node. This document updates RFCs 4620 and 4884.
	CDNI Capacity Capability Advertisement Extensions
	draft-ietf-cdni-capacity-insights-extensions-12.txt   Date: 12/12/2024   Authors: Andrew Ryan, Ben Rosenblum, Nir Sopher   Working Group: Content Delivery Networks Interconnection (cdni)	The Content Delivery Networks Interconnection (CDNI) Capacity Capability Advertisement Extensions define a set of additional Capability Objects that provide information about current downstream CDN (dCDN) utilization and specified usage limits to the delegating upstream CDN (uCDN) in order to inform traffic delegation decisions. This document supplements the CDNI Capability Objects, defined in RFC 8008 as part of the Footprints & Capabilities Advertisement Interface (FCI), with two additional Capability Objects: FCI.CapacityLimits and FCI.Telemetry.
	Use of the HSS and XMSS Hash-Based Signature Algorithms in Internet X.509 Public Key Infrastructure
	draft-ietf-lamps-x509-shbs-13.txt   Date: 12/12/2024   Authors: Daniel Van Geest, Kaveh Bashiri, Scott Fluhrer, Stefan-Lukas Gazdag, Stavros Kousidis   Working Group: Limited Additional Mechanisms for PKIX and SMIME (lamps)	This document specifies algorithm identifiers and ASN.1 encoding formats for the stateful hash-based signature (HBS) schemes Hierarchical Signature System (HSS), eXtended Merkle Signature Scheme (XMSS), and XMSS^MT, a multi-tree variant of XMSS. This specification applies to the Internet X.509 Public Key infrastructure (PKI) when those digital signatures are used in Internet X.509 certificates and certificate revocation lists.
	Intelligent Routing Method of SR Policy
	draft-yang-spring-sr-policy-intelligent-routing-03.txt   Date: 12/12/2024   Authors: Feng Yang, Changwang Lin, Yuanxiang Qiu   Working Group: Individual Submissions (none)	Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths, and each candidate path is either dynamic, explicit or composite. This document describes an intelligent routing method for SR Policy based on network quality in MPLS and IPv6 environments.
	Advanced Professional Video
	draft-lim-apv-03.txt   Date: 12/12/2024   Authors: Youngkwon Lim, Minwoo Park, Madhukar Budagavi, Rajan Joshi, Kwang Choi   Working Group: Individual Submissions (none)	This document describes bitstream format of Advanced Professional Video and decoding process of it.
	YANG Data Model for SR Policy Group
	draft-gong-spring-sr-policy-group-yang-01.txt   Date: 12/12/2024   Authors: Liyan Gong, Changwang Lin, Ran Chen, Yuanxiang Qiu   Working Group: Individual Submissions (none)	This document defines YANG data models for Segment Routing (SR) Policy group that can be used for configuring, instantiating, and managing SR Policy groups. The model is generic and apply equally to the MPLS and SRv6 instantiations of SR policy groups.
	Segment Routing based Solution for Hierarchical IETF Network Slices
	draft-gong-spring-hierarchical-slice-solution-01.txt   Date: 12/12/2024   Authors: Liyan Gong, Weiqiang Cheng, Changwang Lin, Mengxiao Chen, Jie Dong, Ran Chen, Yanrong Liang   Working Group: Individual Submissions (none)	This document describes a Segment Routing based solution for two- level hierarchical IETF network slices. Level-1 network slice is realized by associating Flex-Algo with dedicated sub-interfaces, and level-2 network slice is realized by using SR Policy with additional NRP-ID on data plane.
	A Safe Application Interface to Messaging Layer Security
	draft-barnes-mls-appsync-01.txt   Date: 12/12/2024   Authors: Joel, Richard Barnes, Rohan Mahy, Marta Mularczyk   Working Group: Individual Submissions (none)	The Messaging Layer Security protocol enables a group of participants to negotiate a common cryptographic state. While the primary function of MLS is to establish shared secret state for the group, an MLS group also captures authentication information for group participants and information on which the group has confirmed agreement. This document defines an interface interface by which multiple uncoordinated application functions may safely reuse the cryptographic state of an MLS group for application purposes.

11/12/2024

	Clarification of IPv6 Address Assignment Policy
	draft-ietf-6man-addr-assign-02.txt   Date: 11/12/2024   Authors: Brian Carpenter, Suresh Krishnan, David Farmer   Working Group: IPv6 Maintenance (6man)	This document specifies the approval process for changes to the IPv6 Address Space registry. It also updates RFC 7249. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-6man-addr-assign/. Discussion of this document takes place on the 6MAN Working Group mailing list (mailto:ipv6@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ipv6/. Subscribe at https://www.ietf.org/mailman/listinfo/ipv6/.
	Information Distribution over GRASP
	draft-ietf-anima-grasp-distribution-12.txt   Date: 11/12/2024   Authors: Sheng Jiang, Bing Liu, Xun Xiao, Artur Hecker, Xiuli Zheng   Working Group: Autonomic Networking Integrated Model and Approach (anima)	This document specifies experimental extensions to the GRASP protocol to enable information distribution capabilities. The extension has two aspects: 1) new GRASP messages and options; 2) processing behaviors on the nodes. With these extensions, the GRASP would have following new capabilities which make it a sufficient tool for general information distribution: 1) Pub-Sub model of information processing; 2) one node can actively sending data to another, without GRASP negotiation procedures; 3) selective flooding mechanism to allow the ASAs control the flooding scope. This document updates RFC8990, the GeneRic Autonomic Signaling Protocol (GRASP)[RFC8990].
	remoteStorage
	draft-dejong-remotestorage-24.txt   Date: 11/12/2024   Authors: Michiel de Jong, F. Kooman, Sebastian Kippe   Working Group: Individual Submissions (none)	This draft describes a protocol by which client-side applications, running inside a web browser, can communicate with a data storage server that is hosted on a different domain name. This way, the provider of a web application need not also play the role of data storage provider. The protocol supports storing, retrieving, and removing individual documents, as well as listing the contents of an individual folder, and access control is based on bearer tokens.
	Cisco's CoAP Simple Management Protocol
	draft-duffy-csmp-08.txt   Date: 11/12/2024   Authors: Paul Duffy   Working Group: Individual Submissions (none)	CoAP Simple Management Protocol (CSMP) is purpose-built to provide lifecycle management for resource constrained IoT devices deployed within large-scale, bandwidth constrained IoT networks. CSMP offers an efficient transport and message encoding supporting classic NMS functions such as device on-boarding, device configuration, device status reporting, securing the network, etc. This document describes the design and operation of CSMP. This document does not represent an IETF consensus.
	The SDN-based MPTCP-aware and MPQUIC-aware Transmission Control Model using ALTO
	draft-xing-nmop-sdn-controller-aware-mptcp-mpquic-02.txt   Date: 11/12/2024   Authors: Ziyang Xing, Xiaoqiang Di, Hui Qi   Working Group: Individual Submissions (none)	This document aims to study and implement Multipath Transmission Control Protocol (MPTCP) and Multipath QUIC (MPQUIC) using application layer traffic optimization (ALTO) in software defined network (SDN). In a software-defined network, ALTO server collects network cost indicators (including link delay, number of paths, availability, network traffic, bandwidth and packet loss rate etc.), and the controller extracts MPTCP or MPQUIC packet header to allocate MPTCP or MPQUIC packet to suitable transmission path according to the network cost indicators by ALTO, which can reduce the probability of transmission path congestion and improving path utilization in a multipath transmission network.
	Considerations For Using Unique Local Addresses
	draft-ietf-v6ops-ula-usage-considerations-05.txt   Date: 11/12/2024   Authors: Sheng Jiang, Bing Liu, Nick Buraglio   Working Group: IPv6 Operations (v6ops)	This document provides considerations for using IPv6 Unique Local Addresses (ULAs). Based on an analysis of different ULA usage scenarios, this document identifies use cases where ULA addresses are helpful as well as potential problems caused by using them.

10/12/2024

	Key Transparency Protocol
	draft-ietf-keytrans-protocol-00.txt   Date: 10/12/2024   Authors: Brendan McMillion, Felix Linker   Working Group: Key Transparency (keytrans)	While there are several established protocols for end-to-end encryption, relatively little attention has been given to securely distributing the end-user public keys for such encryption. As a result, these protocols are often still vulnerable to eavesdropping by active attackers. Key Transparency is a protocol for distributing sensitive cryptographic information, such as public keys, in a way that reliably either prevents interference or detects that it occurred in a timely manner.
	Related Certificates for Use in Multiple Authentications within a Protocol
	draft-ietf-lamps-cert-binding-for-multi-auth-06.txt   Date: 10/12/2024   Authors: Alison Becker, Rebecca Guthrie, Michael Jenkins   Working Group: Limited Additional Mechanisms for PKIX and SMIME (lamps)	This document defines a new CSR attribute, relatedCertRequest, and a new X.509 certificate extension, RelatedCertificate. The use of the relatedCertRequest attribute in a CSR and the inclusion of the RelatedCertificate extension in the resulting certificate together provide additional assurance that two certificates each belong to the same end entity. This mechanism is particularly useful in the context of non-composite hybrid authentication, which enables users to employ the same certificates in hybrid authentication as in authentication done with only traditional or post-quantum algorithms.
	Parent-side authoritative DNS records for enhanced delegation
	draft-peetterr-dnsop-parent-side-auth-types-01.txt   Date: 10/12/2024   Authors: Peter van Dijk, Petr Spacek   Working Group: Individual Submissions (none)	DNS RR types with numbers in the range 0xFA00-0xFDFF are now included in special treatment like DS RR type specified in [RFC4035]. Authoritative servers, DNSSEC signers, and recursive resolvers need to extend the conditions for DS special handling to also include this range. This means: being authoritative on the parent side of a delegation; being signed by the parent; being provided along with delegations by the parent. DNSSEC validators also need to implement downgrade protection described in Section 5.3.
	Paired MLS - PCS in Limited Modes
	draft-fondevik-mls-pairedmls-02.txt   Date: 10/12/2024   Authors: Elsie Fondevik, Britta Hale, Xisen Tian   Working Group: Individual Submissions (none)	This document describes the Paired Messaging Layer Security (MLS) extension that improves Post Compromise Security for devices that are unable to self-update using a trusted paired device.
	CoRIM profile for AMD SEV-SNP attestation report
	draft-deeglaze-amd-sev-snp-corim-profile-02.txt   Date: 10/12/2024   Authors: Dionna Glaze   Working Group: Individual Submissions (none)	AMD Secure Encrypted Virtualization with Secure Nested Pages (SEV- SNP) attestation reports comprise of reference values and cryptographic key material that a Verifier needs in order to appraise Attestation Evidence produced by an AMD SEV-SNP virtual machine. This document specifies the information elements for representing SEV-SNP Reference Values in CoRIM format. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/deeglaze/draft-deeglaze-amd-sev-snp-corim-profile.
	Absolute Capture Timestamp RTP header extension
	draft-alvestrand-avtcore-abs-capture-time-01.txt   Date: 10/12/2024   Authors: Harald Alvestrand   Working Group: Individual Submissions (none)	This document describes an RTP header extension that can be used to carry information about the capture time of a video frame / audio sample, and include information that allows the capture time to be estimated by the receiver when the frame may have passed over multiple hops before reaching the receiver.
	COSE Receipts with CCF
	draft-birkholz-cose-receipts-ccf-profile-03.txt   Date: 10/12/2024   Authors: Henk Birkholz, Antoine Delignat-Lavaud, Cedric Fournet, Amaury Chamayou   Working Group: Individual Submissions (none)	This document defines a new verifiable data structure type for COSE Signed Merkle Tree Proofs specifically designed for transaction ledgers produced by Trusted Execution Environments (TEEs), such as the Confidential Consortium Framework ([CCF]) to provide stronger tamper-evidence guarantees.
	Simple Two-Way Active Measurement Protocol (STAMP) Extension for DSCP and ECN Traversal Measurement
	draft-white-ippm-stamp-ecn-00.txt   Date: 10/12/2024   Authors: Greg White   Working Group: Individual Submissions (none)	The Simple Two-Way Active Measurement Protocol (STAMP) enables one- way and round-trip measurement of network metrics between IP hosts, and has a facility for defining optional extensions. This document defines a STAMP extension to enable the measurement of manipulation of the value of the explicit congestion notification (ECN) field of the IP header by middleboxes between two STAMP hosts, and to enable discovery and measurement of paths that provide differential treatment of packets depending on the value of their ECN field.
	Chunked Oblivious HTTP Messages
	draft-ietf-ohai-chunked-ohttp-03.txt   Date: 10/12/2024   Authors: Tommy Pauly, Martin Thomson   Working Group: Oblivious HTTP Application Intermediation (ohai)	This document defines a variant of the Oblivious HTTP message format that allows chunks of requests and responses to be encrypted and decrypted before the entire request or response is processed. This allows incremental processing of Oblivious HTTP messages, which is particularly useful for handling large messages or systems that process messages slowly.

09/12/2024

	EVPN Virtual Ethernet Segment
	draft-ietf-bess-evpn-virtual-eth-segment-19.txt   Date: 09/12/2024   Authors: Ali Sajassi, Patrice Brissette, Rick Schell, John Drake, Jorge Rabadan   Working Group: BGP Enabled ServiceS (bess)	Ethernet VPN (EVPN) and Provider Backbone EVPN (PBB-EVPN) introduce a comprehensive suite of solutions for delivering Ethernet services over MPLS/IP networks. These solutions offer advanced multi-homing capabilities. Specifically, they support Single-Active and All- Active redundancy modes for an Ethernet Segment (ES), which is defined as a collection of physical links connecting a multi-homed device or network to a set of Provider Edge (PE) devices. This document extends the concept of an Ethernet Segment by allowing an ES to be associated with a set of Ethernet Virtual Circuits (EVCs, such as VLANs) or other entities, including MPLS Label Switched Paths (LSPs) or Pseudowires (PWs). This extended concept is referred to as virtual Ethernet Segments (vES). This draft list the requirements and specifies the necessary extensions to support vES in both EVPN and PBB-EVPN.
	BGP Dissemination of Flow Specification Rules for Tunneled Traffic
	draft-ietf-idr-flowspec-nvo3-21.txt   Date: 09/12/2024   Authors: Donald Eastlake, Hao Weiguo, Shunwan Zhuang, Zhenbin Li, Rong Gu   Working Group: Inter-Domain Routing (idr)	This draft specifies a Border Gateway Protocol (BGP) Network Layer Reachability Information (NLRI) encoding format for flow specifications (RFC 8955) that can match on a variety of tunneled traffic. In addition, flow specification components are specified for certain tunneling header fields.
	A YANG Network Data Model of Network Inventory Software Extensions
	draft-ietf-ivy-network-inventory-software-00.txt   Date: 09/12/2024   Authors: Bo Wu, Cheng Zhou, Qin WU, Mohamed Boucadair   Working Group: Network Inventory YANG (ivy)	The base Network Inventory YANG model defines the physical network elements (NEs) and hardware components of NEs. This document extends the base Network Inventory model for non-physical NEs (e.g., controllers, virtual routers, virtual firewalls) and software components (e.g., platform operating system (OS), software-patch).
	Advertising Unreachable Links in OSPF
	draft-ietf-lsr-ospf-ls-link-infinity-02.txt   Date: 09/12/2024   Authors: Liyan Gong, Weiqiang Cheng, Changwang Lin, Acee Lindem, Ran Chen   Working Group: Link State Routing (lsr)	In certain scenarios, it is necessary to advertise unreachable links in OSPF, which should be explicitly excluded from the related SPF calculation. This document specifies using LSLinkInfinity(0xffff) to advertise an OSPF link as unreachable. Stub Router Advertisement (RFC 6987) defines MaxLinkMetric (0xffff) to indicate a router-LSA link should not be used for transit traffic. This document updates RFC 6987 and RFC 8770. When an OSPFv2 router supports the Unreachable Link support capability defined in this document, the OSPFv2 stub router MaxLinkMetric(0xffff) MUST be updated to MaxReachableLinkMetric(0xfffe).
	Secure Shell (SSH) Key Exchange Method Using Hybrid Streamlined NTRU Prime sntrup761 and X25519 with SHA-512: sntrup761x25519-sha512
	draft-ietf-sshm-ntruprime-ssh-01.txt   Date: 09/12/2024   Authors: Markus Friedl, Jan Mojzis, Simon Josefsson   Working Group: Secure Shell Maintenance (sshm)	This document describe a widely deployed hybrid key exchange method in the Secure Shell (SSH) protocol that is based on Streamlined NTRU Prime sntrup761 and X25519 with SHA-512.

08/12/2024

	OSPF-GT (Generalized Transport)
	draft-ietf-lsr-ospf-transport-instance-08.txt   Date: 08/12/2024   Authors: Acee Lindem, Yingzhen Qu, Abhay Roy, Sina Mirtorabi   Working Group: Link State Routing (lsr)	OSPFv2 and OSPFv3 include a reliable flooding mechanism to disseminate routing topology and Traffic Engineering (TE) information within a routing domain. Given the effectiveness of these mechanisms, it is advantageous to use the same mechanism for dissemination of other types of information within the domain. However, burdening OSPF with this additional information will impact intra-domain routing convergence and possibly jeopardize the stability of the OSPF routing domain. This document presents mechanisms to advertise this non-routing information in separate OSPF Generalized Transport (OSPF-GT) instances. OSPF-GT is not constrained to the semantics as traditional OSPF. OSPF-GT neighbors are not required to be directly attached since they are never used to compute hop-by-hop routing. Consequently, independent sparse topologies can be defined to dissemenate non- routing information only to those OSPF-GT routers requiring it.
	MAC Address for Layer 3 Link Local Discovery Protocol (LLDP)
	draft-eastlake-lldp-mac-03.txt   Date: 08/12/2024   Authors: Donald Eastlake   Working Group: Individual Submissions (none)	IEEE 802 has defined a number of protocols which can operate between adjacent Ethernet stations at Layer 2, including bridges, and may be useful between Layer 3 aware stations such as IP routers and hosts. An example is the Link Layer Discover Protocol (IEEE Std 802.1AB, LLDP). This document specifies a MAC address that can be used for this purpose for interoperability despite intervening bridges.
	lispers.net LISP NAT-Traversal Implementation Report
	draft-farinacci-lisp-lispers-net-nat-09.txt   Date: 08/12/2024   Authors: Dino Farinacci   Working Group: Individual Submissions (none)	This memo documents the lispers.net implementation of LISP NAT traversal functionality. The document describes message formats and protocol semantics necessary to interoperate with the implementation. This memo is not a standard and does not reflect IETF consensus.
	Use of Reliable Transport in the Internet Key Exchange Protocol Version 2 (IKEv2)
	draft-smyslov-ipsecme-ikev2-reliable-transport-03.txt   Date: 08/12/2024   Authors: Valery Smyslov   Working Group: Individual Submissions (none)	The Internet Key Exchange protocol version 2 (IKE2) can operate either over unreliable (UDP) transport or over reliable (TCP) transport. If TCP is used, then IPsec tunnels created by IKEv2 also use TCP. This document specifies how to decouple IKEv2 and IPsec transports, so that IKEv2 can operate over TCP, while IPsec tunnels use unreliable transport. This feature allows IKEv2 to effectively exchange large blobs of data (e.g. when post-quantum algorithms are employed) while avoiding performance problems which arise when TCP is used for IPsec.
	Amplification Attacks Using the Constrained Application Protocol (CoAP)
	draft-irtf-t2trg-amplification-attacks-04.txt   Date: 08/12/2024   Authors: John Mattsson, Goeran Selander, Christian Amsuess   Working Group: Thing-to-Thing (t2trg)	Protecting Internet of Things (IoT) devices against attacks is not enough. IoT deployments need to make sure that they are not used for Distributed Denial-of-Service (DDoS) attacks. DDoS attacks are typically done with compromised devices or with amplification attacks using a spoofed source address. This document gives examples of different theoretical amplification attacks using the Constrained Application Protocol (CoAP). The goal with this document is to raise awareness and to motivate generic and protocol-specific recommendations on the usage of CoAP. Some of the discussed attacks can be mitigated by not using NoSec or by using the Echo option.

07/12/2024

	Recommendation to avoid use of BGP Extended Communities at Internet Exchange Route Servers
	draft-ietf-grow-ixp-ext-comms-01.txt   Date: 07/12/2024   Authors: Job Snijders, Stavros Konstantaras, Mo Shivji   Working Group: Global Routing Operations (grow)	This document outlines a recommendation to the Internet operational community to avoid the use of BGP Extended Communities at Internet Exchange Point (IXP) Route Servers. It includes guidance for both the Internet Service Provider side peering with Route Servers and IXPs operating Route Servers. This recommendation aims to help the global Internet routing system's performance and help protect Route Server participants against misconfigurations.
	Peering API
	draft-ietf-grow-peering-api-00.txt   Date: 07/12/2024   Authors: Carlos Aguado, Matt Griswold, Jenny Ramseyer, Arturo Servin, Tom Strickx   Working Group: Global Routing Operations (grow)	We propose an API standard for BGP Peering, also known as interdomain interconnection through global Internet Routing. This API offers a standard way to request public (settlement-free) peering, verify the status of a request or BGP session, and list potential connection locations. The API is backed by PeeringDB OIDC, the industry standard for peering authentication. We also propose future work to cover private peering, and alternative authentication methods.
	Integration of Speech Codec Enhancement Methods into the Opus Codec
	draft-ietf-mlcodec-opus-speech-coding-enhancement-00.txt   Date: 07/12/2024   Authors: Jan Buethe, Jean-Marc Valin   Working Group: Machine Learning for Audio Coding (mlcodec)	This document proposes a set of requirements for integrating a speech codec enhancement method into the Opus codec [RFC6716]

06/12/2024

	Fast HIP Host Mobility
	draft-moskowitz-hip-fast-mobility-09.txt   Date: 06/12/2024   Authors: Robert Moskowitz, Stuart Card, Adam Wiethuechter   Working Group: Individual Submissions (none)	This document describes mobility scenarios and how to aggressively support them in HIP. The goal is minimum lag in the mobility event.
	Semantic Definition Format (SDF): Mapping files
	draft-bormann-asdf-sdf-mapping-05.txt   Date: 06/12/2024   Authors: Carsten Bormann, Jan Romann   Working Group: Individual Submissions (none)	The Semantic Definition Format (SDF) is a format for domain experts to use in the creation and maintenance of data and interaction models that describe Things, i.e., physical objects that are available for interaction over a network. It was created as a common language for use in the development of the One Data Model liaison organization (OneDM) models. Tools convert this format to database formats and other serializations as needed. An SDF specification often needs to be augmented by additional information that is specific to its use in a particular ecosystem or application. SDF mapping files provide a mechanism to represent this augmentation.
	An sdfType for Links
	draft-bormann-asdf-sdftype-link-04.txt   Date: 06/12/2024   Authors: Carsten Bormann   Working Group: Individual Submissions (none)	This document defines and registers an sdfType "link" for the Semantic Definition Format (SDF) for Data and Interactions of Things (draft-ietf-asdf-sdf).

05/12/2024

	EVPN Port-Active Redundancy Mode
	draft-ietf-bess-evpn-mh-pa-13.txt   Date: 05/12/2024   Authors: Patrice Brissette, Luc Burdet, Bin Wen, Eddie Leyton, Jorge Rabadan   Working Group: BGP Enabled ServiceS (bess)	The Multi-Chassis Link Aggregation Group (MC-LAG) technology enables establishing a logical link-aggregation connection with a redundant group of independent nodes. The objective of MC-LAG is to enhance both network availability and bandwidth utilization through various modes of traffic load-balancing. RFC7432 defines EVPN-based MC-LAG with Single-active and All-active multi-homing redundancy modes. This document builds on the existing redundancy mechanisms supported by EVPN and introduces a new active/standby redundancy mode, called 'Port-Active'.
	IANA Registry and Processing Recommendations for the First Nibble Following a Label Stack
	draft-ietf-mpls-1stnibble-13.txt   Date: 05/12/2024   Authors: Kireeti Kompella, Stewart Bryant, Matthew Bocci, Greg Mirsky, Loa Andersson, Jie Dong   Working Group: Multiprotocol Label Switching (mpls)	This document creates a new IANA registry (called the Post-stack First Nibble registry) for the first nibble (4-bit field) immediately following an MPLS label stack. Furthermore, this document sets out some documentation requirements for registering new values, and requirements that make processing MPLS packets easier and more robust. The relationship between the IANA IP Version Numbers (RFC 2780) and the Post-stack First Nibble registry is described in this document. This document updates RFC 4928 by deprecating the heuristic method for identifying the type of packet encapsulated in MPLS.
	OpenPGP Web Key Directory
	draft-koch-openpgp-webkey-service-19.txt   Date: 05/12/2024   Authors: Werner Koch   Working Group: Individual Submissions (none)	This specification describes a service to locate OpenPGP keys by mail address using a Web service and the HTTPS protocol. It also provides a method for secure communication between the key owner and the mail provider to publish and revoke the public key.
	Service Affinity Solution for TCP based Application
	draft-wang-tcpm-tcp-service-affinity-option-06.txt   Date: 05/12/2024   Authors: Wei Wang, Aijun Wang   Working Group: Individual Submissions (none)	This draft proposes a service affinity solution between client and server based on the newly defined TCP Options. This solution can avoid the waste of resources caused by saving a large amount of customer status data in the network equipment, and realize the optimized scheduling of resources based on network conditions and computing resources in the computing-aware traffic steering scenario, so as to realize the reasonable operation of network resources, cloud resources and computing resources.
	Certificate Status Information Mechanism Description Updates to RFC 5280
	draft-liu-lamps-mechanism-updates-to-rfc-5280-06.txt   Date: 05/12/2024   Authors: Penghui Liu, Xiang Liu, Rongwei Yang, Yu Zhang   Working Group: Individual Submissions (none)	The updates to RFC 5280 described in this document provide alignment with the 2013 specification for the X.509 Internet Public Key Infrastructure Online Certificate Status Protocol-OCSP [RFC6960].
	Maximum Prefix Outbound Route Filter for BGP
	draft-abraitis-idr-maximum-prefix-orf-00.txt   Date: 05/12/2024   Authors: Donatas Abraitis   Working Group: Individual Submissions (none)	This document introduces a Maximum Prefix ORF (Outbound Route Filtering) type for BGP. It aims to provide a mechanism whereby the sender of route information is informed of the maximum number of prefixes that the receiver is willing to accept. This facilitates improved resource management by limiting the number of routes exchanged, avoiding unnecessary or excessive route propagation, and reducing memory and CPU load.
	Cookies: HTTP State Management Mechanism
	draft-annevk-johannhof-httpbis-cookies-00.txt   Date: 05/12/2024   Authors: Anne van Kesteren, Johann Hofmann   Working Group: Individual Submissions (none)	This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 6265 and 6265bis.
	Update to Automatic Bandwidth Adjustment procedure of Stateful PCE
	draft-ietf-pce-stateful-pce-autobw-update-01.txt   Date: 05/12/2024   Authors: Shuping Peng, Dhruv Dhody, Rakesh Gandhi   Working Group: Path Computation Element (pce)	Extensions to the Path Computation Element Communication Protocol (PCEP) for MPLS-TE Label Switched Path (LSP) Automatic Bandwidth Adjustments with Stateful PCE are defined in RFC 8733. It defines the AUTO-BANDWIDTH-ATTRIBUTES TLV and a set of sub-TLVs for each of the attributes. The sub-TLVs are included if there is a change since the last information sent in the PCEP message. However, it lacks a mechanism to explicitly remove an attribute identified by the sub- TLV. This document updates RFC 8733 by defining the behaviour to explicitly remove an attribute.

04/12/2024

	SNAC Router Flag in ICMPv6 Router Advertisement Messages
	draft-ietf-6man-snac-router-ra-flag-03.txt   Date: 04/12/2024   Authors: Jonathan Hui   Working Group: IPv6 Maintenance (6man)	This document defines a new flag, the SNAC Router flag, in the Router Advertisement message that can be used to distinguish configuration information sent by SNAC routers from information sent by infrastructure routers. This flag is used only by SNAC routers and is ignored by all other devices.
	Extended Mobility Procedures for EVPN-IRB
	draft-ietf-bess-evpn-irb-extended-mobility-21.txt   Date: 04/12/2024   Authors: Neeraj Malhotra, Ali Sajassi, Aparna Pattekar, Jorge Rabadan, Avinash Lingala, John Drake   Working Group: BGP Enabled ServiceS (bess)	This document specifies extensions to Ethernet VPN (EVPN) Integrated Routing and Bridging (IRB) procedures specified in RFC7432 and RFC9135 to enhance the mobility mechanisms for EVPN-IRB based networks. The proposed extensions improve the handling of host mobility and duplicate address detection in EVPN-IRB networks to cover a broader set of scenarios where a host's unicast IP address to MAC address bindings may change across moves. These enhancements address limitations in the existing EVPN-IRB mobility procedures by providing more efficient and scalable solutions. The extensions are backward compatible with existing EVPN-IRB implementations and aim to optimize network performance in scenarios involving frequent IP address mobility. NOTE TO IESG (TO BE DELETED BEFORE PUBLISHING): This draft lists six authors which is above the required limit of five. Given significant and active contributions to the draft from all six authors over the course of six years, we would like to request IESG to allow publication with six authors. Specifically, the three Cisco authors are the original inventors of these procedures and contributed heavily to rev 0 draft, most of which is still intact. AT&T is also a key contributor towards defining the use cases that this document addresses as well as the proposed solution. Authors from Nokia and Juniper have further contributed to revisions and discussions steadily over last six years to enable respective implementations and a wider adoption.
	BIER Penultimate Hop Popping
	draft-ietf-bier-php-16.txt   Date: 04/12/2024   Authors: Zhaohui Zhang   Working Group: Bit Indexed Explicit Replication (bier)	This document specifies a mechanism for Penultimate Hop Popping (PHP) in the Bit Index Explicit Replication (BIER) architecture. PHP enables the removal of the BIER header by the penultimate router, thereby reducing the processing burden on the final router in the delivery path. This extension to BIER enhances operational efficiency by optimizing packet forwarding in scenarios where the final hop's capabilities or requirements necessitate such handling. The document details the necessary extensions to the BIER encapsulation and forwarding processes to support PHP, providing guidance for implementation and deployment within BIER-enabled networks.
	Use Cases for In-Network Computing
	draft-irtf-coinrg-use-cases-07.txt   Date: 04/12/2024   Authors: Ike Kunze, Klaus Wehrle, Dirk Trossen, Marie-Jose Montpetit, Xavier de Foy, David Griffin, Miguel Rio   Working Group: Computing in the Network Research Group (coinrg)	Computing in the Network (COIN) comes with the prospect of deploying processing functionality on networking devices, such as switches and network interface cards. While such functionality can be beneficial, it has to be carefully placed into the context of the general Internet communication and it needs to be clearly identified where and how those benefits apply. This document presents some use cases to demonstrate how a number of salient COIN-related applications can benefit from COIN. Furthermore, to guide research on COIN, it identifies essential research questions and outlines desirable capabilities that COIN systems addressing the use cases may need to support. Finally, the document provides a preliminary categorization of the described research questions to source future work in this domain. It is a product of the Computing in the Network Research Group (COINRG). It is not an IETF product and it is not a standard.
	Use Case Analysis for Computing in the Network
	draft-irtf-coinrg-use-case-analysis-02.txt   Date: 04/12/2024   Authors: Ike Kunze, Jungha Hong, Klaus Wehrle, Dirk Trossen, Marie-Jose Montpetit, Xavier de Foy, David Griffin, Miguel Rio   Working Group: Computing in the Network Research Group (coinrg)	Computing in the Network (COIN) has the potential to enable a wide variety of use cases. The diversity in use cases makes challenges in defining general considerations. This document analyzes the use cases described in a COINRG companion document and potentially explores additional settings, to identify general aspects of interest across all use cases. The insights gained from this analysis will guide future COIN discussions.
	Encapsulation of Simple Two-Way Active Measurement Protocol for Pseudowires and LSPs in MPLS Networks
	draft-ietf-mpls-stamp-pw-00.txt   Date: 04/12/2024   Authors: Rakesh Gandhi, Patrice Brissette, Eddie Leyton, Xiao Min   Working Group: Multiprotocol Label Switching (mpls)	Pseudowires (PWs) and Label Switched Paths (LSPs) are used in MPLS networks for various services including carrying layer 2 and layer 3 data packets. This document describes the procedure for encapsulation of the Simple Two-Way Active Measurement Protocol (STAMP) defined in RFC 8762 and its optional extensions defined in RFC 8972 for PWs and LSPs in MPLS networks. The procedure uses Generic Associated Channel (G-ACh) to encapsulate the STAMP test packets with or without adding an IP/UDP header.
	Client Conformance Signal for SCONE
	draft-rjt-scone-conformance-signal-00.txt   Date: 04/12/2024   Authors: Renjie Tang   Working Group: Individual Submissions (none)	This document proposes conformance signals to be sent by QUIC clients to indicate whether they are able to adapt to the bitrate indicated by the SCONE signal, so that communication service providers MAY stop policing.

03/12/2024

	Tethering A BIER Router To A BIER Incapable Router
	draft-ietf-bier-tether-08.txt   Date: 03/12/2024   Authors: Zhaohui Zhang, Nils Warnke, IJsbrand Wijnands, Daniel Awduche   Working Group: Bit Indexed Explicit Replication (bier)	This document specifies optional enhancements to optimize the support of Bit Index Explicit Replication (BIER) incapable routers in a BIER domain by attaching (tethering) a BIER router to a BIER incapable router, including procedures and ISIS/OSPF/BGP signaling extensions.
	A YANG Data Model for Optical Transport Network (OTN) Tunnels and Label Switched Paths
	draft-ietf-ccamp-otn-tunnel-model-22.txt   Date: 03/12/2024   Authors: Haomian Zheng, Italo Busi, Sergio Belotti, Victor Lopez, Yunbin Xu   Working Group: Common Control and Measurement Plane (ccamp)	This document describes the YANG data model for tunnels in OTN TE networks. The model can be used to do the configuration in order to establish the tunnel in OTN network. This work is independent with the control plane protocols.
	Tactical Traffic Engineering (TTE)
	draft-li-rtgwg-tte-02.txt   Date: 03/12/2024   Authors: Colby Barth, Tony Li, Andy Smith, Bin Wen, Luay Jalil   Working Group: Individual Submissions (none)	Conventional traffic engineering approaches for resource management used by RSVP-TE and SR-TE often leverage estimates of the ingress traffic demands, during path placement. Unforeseen and/or dynamic events, can skew these estimates by significant enough margins to result in unexpected network congestion. Recomputed paths that address the new demands may take a considerable amount of time, leaving the network in a sub-optimal state for far too long. This document proposes one mechanism that can avert congestion on a real-time basis.
	An Intent-Based Management Framework for Software-Defined Vehicles in Intelligent Transportation Systems
	draft-jeong-opsawg-intent-based-sdv-framework-03.txt   Date: 03/12/2024   Authors: Jaehoon Jeong, Yiwen Shen, Yoseop Ahn, Mose Gu   Working Group: Individual Submissions (none)	Software-Defined Vehicle (SDV) is a new player towards autonomous vehicles in Intelligent Transportation Systems (ITS). An SDV is constructed by a software platform like a cloud-native system (e.g., Kubernetes) and has its internal network. To facilitate the easy and efficient configuration of networks in the SDV, an intent-based management is an appropriate direction. This document proposes a framework of intent-based management for networks, security, and applications in SDVs so that they can communicate with other SDVs and infrastructure nodes for safe driving and infotainment services in the road networks.
	Use Cases and Requirements for Implementing Lossless Techniques in Wide Area Networks
	draft-hs-rtgwg-wan-lossless-uc-00.txt   Date: 03/12/2024   Authors: Han Zhengxin, Tao He, Hang Shi, Tianran Zhou   Working Group: Individual Submissions (none)	This document outlines the use cases and requirements for implementing lossless data transmission techniques in Wide Area Networks (WANs), motivated by the increasing demand for high- bandwidth and reliable data transport in applications such as high- performance computing (HPC), genetic sequencing, multimedia content production and distributed training. The challenges associated with existing data transport protocols in WAN environments are discussed, along with the proposal of requirements for enhancing lossless transmission capabilities to support emerging data-intensive applications.
	CORECONF: Managing IoT Devices with YANG Models
	draft-bormann-nemops-coreconf-00.txt   Date: 03/12/2024   Authors: Carsten Bormann   Working Group: Individual Submissions (none)	This short paper provides an overview over the CORECONF architecture for employing YANG models in managing IoT devices. CORECONF is based on CoAP as a transfer protocol and YANG-CBOR as its data representation format, analogous to the way the original RESTCONF was defined to use HTTP and YANG-XML or YANG-JSON, and the way NETCONF uses SSH and YANG-XML.
	hardware divvying
	draft-rfcxml-general-template-standard-00.txt   Date: 03/12/2024   Authors: William Gardner   Working Group: Individual Submissions (none)	a proposal for hardware divvying (specifically in the case of RAM)
	SD-JWT-based Verifiable Credentials (SD-JWT VC)
	draft-ietf-oauth-sd-jwt-vc-08.txt   Date: 03/12/2024   Authors: Oliver Terbu, Daniel Fett, Brian Campbell   Working Group: Web Authorization Protocol (oauth)	This specification describes data formats as well as validation and processing rules to express Verifiable Credentials with JSON payloads with and without selective disclosure based on the SD-JWT [I-D.ietf-oauth-selective-disclosure-jwt] format.

02/12/2024

	Extensions to Salted Challenge Response (SCRAM) for 2 factor authentication
	draft-ietf-kitten-scram-2fa-05.txt   Date: 02/12/2024   Authors: Alexey Melnikov   Working Group: Common Authentication Technology Next Generation (kitten)	This specification describes an extension to family of Simple Authentication and Security Layer (SASL; RFC 4422) authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which provides support for 2 factor authentication. It also includes a separate extension for quick reauthentication. This specification also gives 2 examples of second factors: TOTP (RFC 6238) and FIDO CTAP1/U2F (Passkey).
	SCRAM-SHA-512 and SCRAM-SHA-512-PLUS Simple Authentication and Security Layer (SASL) Mechanisms
	draft-melnikov-scram-sha-512-05.txt   Date: 02/12/2024   Authors: Alexey Melnikov   Working Group: Individual Submissions (none)	This document registers the Simple Authentication and Security Layer (SASL) mechanisms SCRAM-SHA-512 and SCRAM-SHA-512-PLUS.
	SCRAM-SHA3-512 and SCRAM-SHA3-512-PLUS Simple Authentication and Security Layer (SASL) Mechanisms
	draft-melnikov-scram-sha3-512-05.txt   Date: 02/12/2024   Authors: Alexey Melnikov   Working Group: Individual Submissions (none)	This document registers the Simple Authentication and Security Layer (SASL) mechanisms SCRAM-SHA3-512 and SCRAM-SHA3-512-PLUS.
	MSYNC
	draft-bichot-msync-17.txt   Date: 02/12/2024   Authors: Sophie Bale, Remy Brebion, Guillaume Bichot   Working Group: Individual Submissions (none)	This document specifies the Multicast Synchronization (MSYNC) Protocol. MSYNC is intended to transfer video media objects over IP multicast. Although generic, MSYNC has been primarily designed for transporting HTTP adaptive streaming (HAS) objects including manifests/playlists and media segments (e.g., CMAF) according to a HAS protocol such as Apple HLS or MPEG DASH between a multicast sender and a multicast receiver.
	Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms
	draft-melnikov-scram-bis-05.txt   Date: 02/12/2024   Authors: Alexey Melnikov   Working Group: Individual Submissions (none)	This document updates requirements on implementations of various Salted Challenge Response Authentication Mechanism (SCRAM) Simple Authentication and Security Layer (SASL) mechanisms based on more modern security practices.
	Extensible Simple Authentication and Security Layer (SASL)
	draft-melnikov-sasl2-02.txt   Date: 02/12/2024   Authors: Dave Cridland, Thilo Molitor, Matthew Wild, Alexey Melnikov   Working Group: Individual Submissions (none)	The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer. This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. This document also defines how servers can request fulfillment of extra authentication related tasks, such as two factor authentication and/or password change.
	BGP Next-next Hop Nodes
	draft-wang-idr-next-next-hop-nodes-02.txt   Date: 02/12/2024   Authors: Kevin Wang, Jeffrey Haas, Changwang Lin, Jeff Tantsura   Working Group: Individual Submissions (none)	BGP speakers learn their next hop addresses for NLRI in RFC-4271 in the NEXT_HOP field and in RFC-4760 in the "Network Address of Next Hop" field. Under certain circumstances, it might be desirable for a BGP speaker to know both the next hops and the next-next hops of NLRI to make optimal forwarding decisions. One such example is global load balancing (GLB) in a Clos network. Draft-ietf-idr-entropy-label defines the "Next Hop Dependent Characteristics Attribute" (NHC) which allows a BGP speaker to signal the forwarding characteristics associated with a given next hop. This document defines a new NHC characteristic, the Next-next Hop Nodes (NNHN) characteristic, which can be used to advertise the next- next hop nodes associated with a given next hop.
	SCONE Solution Analysis
	draft-brw-scone-analysis-00.txt   Date: 02/12/2024   Authors: Mohamed Boucadair, Dan Wing, Tirumaleswar Reddy.K, Sridharan Rajagopalan, Luis Contreras   Working Group: Individual Submissions (none)	This document provides an analysis of various SCONE solutions to share the throughput advice. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/boucadair/draft-xxx-ac-rate-policy-discovery.
	SCIM Profile for Security Event Tokens
	draft-ietf-scim-events-07.txt   Date: 02/12/2024   Authors: Phillip Hunt, Nancy Cam-Winget, Mike Kiser, Jen Schreiber   Working Group: System for Cross-domain Identity Management (scim)	This specification defines a set of SCIM Security Events using the Security Event Token Specification RFC8417 to enable the asynchronous exchange of messages between SCIM Service Providers and receivers. SCIM Security Events are typically used for: asynchronous request completion, resource replication, and provisioning co-ordination.

01/12/2024

	iTip using PARTICIPANT only
	draft-ietf-calext-itip-participants-00.txt   Date: 01/12/2024   Authors: Michael Douglass   Working Group: Calendaring Extensions (calext)	This specification defines updates to RFC5546 iTip which allow scheduling using the "PARTICIPANT" calendar components specified in RFC9073. New properties are also defined for use within the "PARTICIPANT" calendar component.
	YANG Data Model for MPLS mLDP
	draft-ietf-mpls-mldp-yang-12.txt   Date: 01/12/2024   Authors: Syed Raza, Xufeng Liu, Santosh Esale, Loa Andersson, Jeff Tantsura   Working Group: Multiprotocol Label Switching (mpls)	This document describes a YANG data model for the Multiprotocol Label Switching (MPLS) Multipoint Label Distribution Protocol (mLDP). The mLDP YANG data model augments the MPLS LDP YANG data model. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA).
	AEGIS-based Cipher Suites for TLS 1.3,DTLS 1.3 and QUIC
	draft-denis-tls-aegis-03.txt   Date: 01/12/2024   Authors: Frank Denis, Samuel Lucas   Working Group: Individual Submissions (none)	This document proposes new cipher suites based on the AEGIS family of authenticated encryption algorithms for integration into the TLS 1.3, DTLS 1.3, and QUIC protocols. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-denis-tls-aegis/. Source for this draft and an issue tracker can be found at https://github.com/jedisct1/draft-denis-tls-aegis.
	RSVP Cryptographic Authentication,Version 2
	draft-atkinson-teas-rsvp-auth-v2-01.txt   Date: 01/12/2024   Authors: Ran Atkinson, Tony Li   Working Group: Individual Submissions (none)	This document provides an algorithm-independent description of the format and use of RSVP's INTEGRITY object. The RSVP INTEGRITY object is widely used to provide hop-by-hop integrity and authentication of RSVP messages, particularly in MPLS deployments using RSVP-TE. This document obsoletes both RFC2747 and RFC3097.

---