RFC Abstracts
RFC8754 - IPv6 Segment Routing Header (SRH)
Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable.
RFC8753 - Internationalized Domain Names for Applications (IDNA) Review for New Unicode Versions
The standards for Internationalized Domain Names in Applications (IDNA) require a review of each new version of Unicode to determine whether incompatibilities with prior versions or other issues exist and, where appropriate, to allow the IETF to decide on the trade-offs between compatibility with prior IDNA versions and compatibility with Unicode going forward. That requirement, and its relationship to tables maintained by IANA, has caused significant confusion in the past. This document makes adjustments to the review procedure based on experience and updates IDNA, specifically RFC 5892, to reflect those changes and to clarify the various relationships involved. It also makes other minor adjustments to align that document with experience.
RFC8752 - Report from the IAB Workshop on Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE)
The Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE) Workshop was convened by the Internet Architecture Board (IAB) in July 2019. This report summarizes its significant points of discussion and identifies topics that may warrant further consideration.
RFC8751 - Hierarchical Stateful Path Computation Element (PCE)
A stateful Path Computation Element (PCE) maintains information on the current network state received from the Path Computation Clients (PCCs), including computed Label Switched Paths (LSPs), reserved resources within the network, and pending path computation requests. This information may then be considered when computing the path for a new traffic-engineered LSP or for any associated/dependent LSPs. The path-computation response from a PCE helps the PCC to gracefully establish the computed LSP.
RFC8750 - Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP)
Encapsulating Security Payload (ESP) sends an initialization vector (IV) in each packet. The size of the IV depends on the applied transform and is usually 8 or 16 octets for the transforms defined at the time this document was written. When used with IPsec, some algorithms, such as AES-GCM, AES-CCM, and ChaCha20-Poly1305, take the IV to generate a nonce that is used as an input parameter for encrypting and decrypting. This IV must be unique but can be predictable. As a result, the value provided in the ESP Sequence Number (SN) can be used instead to generate the nonce. This avoids sending the IV itself and saves 8 octets per packet in the case of AES-GCM, AES-CCM, and ChaCha20-Poly1305. This document describes how to do this.
RFC8749 - Moving DNSSEC Lookaside Validation (DLV) to Historic Status
This document retires DNSSEC Lookaside Validation (DLV) and reclassifies RFCs 4431 and 5074 as Historic. Furthermore, this document updates RFC 6698 by excluding the DLV resource record from certificates and updates RFC 6840 by excluding the DLV registries from the trust anchor selection.
RFC8748 - Registry Fee Extension for the Extensible Provisioning Protocol (EPP)
Given the expansion of the DNS namespace and the proliferation of novel business models, it is desirable to provide a method for Extensible Provisioning Protocol (EPP) clients to query EPP servers for the fees and credits associated with various billable transactions and provide expected fees and credits for certain commands and objects. This document describes an EPP extension mapping for registry fees.
RFC8747 - Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)
This specification describes how to declare in a CBOR Web Token (CWT) (which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs).
RFC8746 - Concise Binary Object Representation (CBOR) Tags for Typed Arrays
The Concise Binary Object Representation (CBOR), as defined in RFC 7049, 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.
RFC8745 - Path Computation Element Communication Protocol (PCEP) Extensions for Associating Working and Protection Label Switched Paths (LSPs) with Stateful PCE
An active stateful Path Computation Element (PCE) is capable of computing as well as controlling via Path Computation Element Communication Protocol (PCEP) Multiprotocol Label Switching Traffic Engineering (MPLS-TE) Label Switched Paths (LSPs). Furthermore, it is also possible for an active stateful PCE to create, maintain, and delete LSPs. This document defines the PCEP extension to associate two or more LSPs to provide end-to-end path protection.
RFC8744 - Issues and Requirements for Server Name Identification (SNI) Encryption in TLS
This document describes the general problem of encrypting the Server Name Identification (SNI) TLS parameter. The proposed solutions hide a hidden service behind a fronting service, only disclosing the SNI of the fronting service to external observers. This document lists known attacks against SNI encryption, discusses the current "HTTP co-tenancy" solution, and presents requirements for future TLS-layer solutions.
RFC8743 - Multiple Access Management Services Multi-Access Management Services (MAMS)
In multiconnectivity scenarios, the clients can simultaneously connect to multiple networks based on different access technologies and network architectures like Wi-Fi, LTE, and DSL. Both the quality of experience of the users and the overall network utilization and efficiency may be improved through the smart selection and combination of access and core network paths that can dynamically adapt to changing network conditions.
RFC8742 - Concise Binary Object Representation (CBOR) Sequences
This document describes the Concise Binary Object Representation (CBOR) Sequence format and associated media type "application/cbor-seq". A CBOR Sequence consists of any number of encoded CBOR data items, simply concatenated in sequence.
RFC8741 - Ability for a Stateful Path Computation Element (PCE) to Request and Obtain Control of a Label Switched Path (LSP)
A stateful Path Computation Element (PCE) retains information about the placement of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs). When a PCE has stateful control over LSPs, it may send indications to LSP head-ends to modify the attributes (especially the paths) of the LSPs. A Path Computation Client (PCC) that has set up LSPs under local configuration may delegate control of those LSPs to a stateful PCE.
RFC8740 - Using TLS 1.3 with HTTP/2
This document updates RFC 7540 by forbidding TLS 1.3 post-handshake authentication, as an analog to the existing TLS 1.2 renegotiation restriction.
RFC8739 - Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME)
Public key certificates need to be revoked when they are compromised, that is, when the associated private key is exposed to an unauthorized entity. However, the revocation process is often unreliable. An alternative to revocation is issuing a sequence of certificates, each with a short validity period, and terminating the sequence upon compromise. This memo proposes an Automated Certificate Management Environment (ACME) extension to enable the issuance of Short-Term, Automatically Renewed (STAR) X.509 certificates.
RFC8738 - Automated Certificate Management Environment (ACME) IP Identifier Validation Extension
This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for IP addresses.
RFC8737 - Automated Certificate Management Environment (ACME) TLS Application-Layer Protocol Negotiation (ALPN) Challenge Extension
This document specifies a new challenge for the Automated Certificate Management Environment (ACME) protocol that allows for domain control validation using TLS.
RFC8736 - PIM Message Type Space Extension and Reserved Bits
The PIM version 2 messages share a common message header format. The common header definition contains eight reserved bits. This document specifies how these bits may be used by individual message types and creates a registry containing the per-message-type usage. This document also extends the PIM type space by defining three new message types. For each of the new types, four of the previously reserved bits are used to form an extended type range.
RFC8735 - Scenarios and Simulation Results of PCE in a Native IP Network
Requirements for providing the End-to-End (E2E) performance assurance are emerging within the service provider networks. While there are various technology solutions, there is no single solution that can fulfill these requirements for a native IP network. In particular, there is a need for a universal E2E solution that can cover both intra- and inter-domain scenarios.
RFC8734 - Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS) Version 1.3
Elliptic Curve Cryptography (ECC) Brainpool curves were an option for authentication and key exchange in the Transport Layer Security (TLS) protocol version 1.2 but were deprecated by the IETF for use with TLS version 1.3 because they had little usage. However, these curves have not been shown to have significant cryptographical weaknesses, and there is some interest in using several of these curves in TLS 1.3.
RFC8733 - Path Computation Element Communication Protocol (PCEP) Extensions for MPLS-TE Label Switched Path (LSP) Auto-Bandwidth Adjustment with Stateful PCE
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. Stateful PCE extensions allow stateful control of MPLS-TE Label Switched Paths (LSPs) using PCEP.
RFC8732 - Generic Security Service Application Program Interface (GSS-API) Key Exchange with SHA-2
This document specifies additions and amendments to RFC 4462. It defines a new key exchange method that uses SHA-2 for integrity and deprecates weak Diffie-Hellman (DH) groups. The purpose of this specification is to modernize the cryptographic primitives used by Generic Security Service (GSS) key exchanges.
RFC8731 - Secure Shell (SSH) Key Exchange Method Using Curve25519 and Curve448
This document describes the specification for using Curve25519 and Curve448 key exchange methods in the Secure Shell (SSH) protocol.
RFC8730 - Independent Submission Editor Model
This document describes the function and responsibilities of the RFC Independent Submission Editor (ISE). The Independent Submission stream is one of the stream producers that create draft RFCs, with the ISE as its stream approver. The ISE is overall responsible for activities within the Independent Submission stream, working with draft editors and reviewers, and interacts with the RFC Production Center and Publisher, and the RFC Series Editor (RSE). The ISE is appointed by the IAB, and also interacts with the IETF Administration Limited Liability Company (LLC).
RFC8729 - The RFC Series and RFC Editor
This document describes the framework for an RFC Series and an RFC Editor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFC Series to continue to fulfill its mandate. This document obsoletes RFC 4844.
RFC8728 - RFC Editor Model (Version 2)
The RFC Editor model described in this document divides the responsibilities for the RFC Series into three functions: the RFC Series Editor, the RFC Production Center, and the RFC Publisher. Internet Architecture Board (IAB) oversight via the RFC Series Oversight Committee (RSOC) is described, as is the relationship between the IETF Administration Limited Liability Company and the RSOC. This document reflects the experience gained with "RFC Editor Model (Version 1)", documented in RFC 5620; and obsoletes RFC 6635 to replace all references to the IETF Administrative Support Activity (IASA) and related structures with those defined by the IASA 2.0 Model.
RFC8727 - JSON Binding of the Incident Object Description Exchange Format
The Incident Object Description Exchange Format (IODEF) defined in RFC 7970 provides an information model and a corresponding XML data model for exchanging incident and indicator information. This document gives implementers and operators an alternative format to exchange the same information by defining an alternative data model implementation in JSON and its encoding in Concise Binary Object Representation (CBOR).
RFC8726 - How Requests for IANA Action Will Be Handled on the Independent Stream
The Internet Assigned Numbers Authority (IANA) maintains registries to track code points used by protocols such as those defined by the IETF and documented in RFCs developed on the IETF Stream.
RFC8725 - JSON Web Token Best Current Practices
JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs.
RFC8724 - SCHC: Generic Framework for Static Context Header Compression and Fragmentation
This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind.
RFC8723 - Double Encryption Procedures for the Secure Real-Time Transport Protocol (SRTP)
In some conferencing scenarios, it is desirable for an intermediary to be able to manipulate some parameters in Real-time Transport Protocol (RTP) packets, while still providing strong end-to-end security guarantees. This document defines a cryptographic transform for the Secure Real-time Transport Protocol (SRTP) that uses two separate but related cryptographic operations to provide hop-by-hop and end-to-end security guarantees. Both the end-to-end and hop-by-hop cryptographic algorithms can utilize an authenticated encryption with associated data (AEAD) algorithm or take advantage of future SRTP transforms with different properties.
RFC8722 - Defining the Role and Function of IETF Protocol Parameter Registry Operators
Many Internet Engineering Task Force (IETF) protocols make use of commonly defined values that are passed in messages or packets. To ensure consistent interpretation of these values between independent implementations, there is a need to ensure that the values and associated semantic intent are uniquely defined. The IETF uses registry functions to record assigned protocol parameter values and their associated semantic intentions. For each IETF protocol parameter, it is current practice for the IETF to delegate the role of Protocol Parameter Registry Operator to a nominated entity. This document provides a description of, and the requirements for, these delegated functions. This document obsoletes RFC 6220 to replace all references to the IETF Administrative Support Activity (IASA) and related structures with those defined by the IASA 2.0 Model.
RFC8721 - Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents
Contributors grant intellectual property rights to the IETF. The IETF Trust holds and manages those rights on behalf of the IETF. The Trustees of the IETF Trust are responsible for that management. This management includes granting the licenses to copy, implement, and otherwise use IETF Contributions, among them Internet-Drafts and RFCs. The Trustees of the IETF Trust accept direction from the IETF regarding the rights to be granted. This document describes the desires of the IETF regarding outbound rights to be granted in IETF Contributions. This document obsoletes RFC 5377 solely for the purpose of removing references to the IETF Administrative Oversight Committee (IAOC), which was part of the IETF Administrative Support Activity (IASA).
RFC8720 - Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries
This document provides principles for the operation of Internet Assigned Numbers Authority (IANA) registries.
RFC8719 - High-Level Guidance for the Meeting Policy of the IETF
This document describes a meeting location policy for the IETF and the various stakeholders required to realize this policy.
RFC8718 - IETF Plenary Meeting Venue Selection Process
The IETF Administration Support Activity (IASA) is responsible for arranging the selection and operation of the IETF plenary meeting venue. This memo specifies IETF community requirements for meeting venues, including hotels and meeting space. It also directs the IASA to make available additional process documents that describe the current meeting selection process.
RFC8717 - IETF Administrative Support Activity 2.0: Consolidated Updates to IETF Administrative Terminology
In 2018, the IETF began the transition to a new administrative structure and updated its IETF Administrative Support Activity (IASA) to a new "IASA 2.0" structure. In addition to more substantive changes that are described in other documents, the transition to the 2018 IETF Administrative Support structure changes several position titles and organizational relationships that are referenced elsewhere. Rather than reissue those referencing documents individually, this specification provides updates to them and deprecates some now-obsolete documents to ensure that there is no confusion due to these changes.
RFC8716 - Update to the IETF Anti-Harassment Procedures for the Replacement of the IETF Administrative Oversight Committee (IAOC) with the IETF Administration LLC
The IETF Anti-Harassment Procedures are described in RFC 7776.
RFC8715 - IETF Administrative Support Activity 2.0: Update to the Process for Selection of Trustees for the IETF Trust
This document captures the rationale for the changes introduced in RFC 8714, "Update to the Process for Selection of Trustees for the IETF Trust".
RFC8714 - Update to the Process for Selection of Trustees for the IETF Trust
This memo updates the process for selection of Trustees for the IETF Trust. Previously, the IETF Administrative Oversight Committee (IAOC) members also acted as Trustees, but the IAOC has been eliminated as part of an update to the structure of the IETF Administrative Support Activity (IASA). This memo specifies that the Trustees shall be selected separately.
RFC8713 - IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees
The process by which the members of the IAB and IESG, some Trustees of the IETF Trust, and some Directors of the IETF Administration LLC (IETF LLC) are selected, confirmed, and recalled is specified in this document. This document is based on RFC 7437. Only those updates required to reflect the changes introduced by IETF Administrative Support Activity (IASA) 2.0 have been included. Any other changes will be addressed in future documents.
RFC8712 - The IETF-ISOC Relationship
This document summarizes the Internet Engineering Task Force (IETF) - Internet Society (ISOC) relationship, following a major revision to the structure of the IETF Administrative Support Activity (IASA) in 2018. The IASA was revised under a new "IASA 2.0" structure by the IASA2 Working Group, which changed the IETF's administrative, legal, and financial structure. As a result, it also changed the relationship between the IETF and ISOC, which made it necessary to revise RFC 2031.
RFC8711 - Structure of the IETF Administrative Support Activity, Version 2.0
The IETF Administrative Support Activity (IASA) was originally established in 2005. In the years since then, the needs of the IETF evolved in ways that required changes to its administrative structure. The purpose of this RFC is to document and describe the IETF Administrative Support Activity, version 2.0 (IASA 2.0). It defines the roles and responsibilities of the IETF Administration LLC Board (IETF LLC Board), the IETF Executive Director, and the Internet Society in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IETF LLC Board.
RFC8710 - Multipart Content-Format for the Constrained Application Protocol (CoAP)
This memo defines application/multipart-core, an application-independent media type that can be used to combine representations of zero or more different media types (each with a Constrained Application Protocol (CoAP) Content-Format identifier) into a single representation, with minimal framing overhead.
RFC8709 - Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH) Protocol
This document describes the use of the Ed25519 and Ed448 digital signature algorithms in the Secure Shell (SSH) protocol. Accordingly, this RFC updates RFC 4253.
RFC8708 - Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS)
This document specifies the conventions for using the Hierarchical Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554.
RFC8707 - Resource Indicators for OAuth 2.0
This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access.
RFC8706 - Restart Signaling for IS-IS
This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the DOWN state while still correctly initiating database synchronization.
RFC8705 - OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token.
Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable.
RFC8753 - Internationalized Domain Names for Applications (IDNA) Review for New Unicode Versions
The standards for Internationalized Domain Names in Applications (IDNA) require a review of each new version of Unicode to determine whether incompatibilities with prior versions or other issues exist and, where appropriate, to allow the IETF to decide on the trade-offs between compatibility with prior IDNA versions and compatibility with Unicode going forward. That requirement, and its relationship to tables maintained by IANA, has caused significant confusion in the past. This document makes adjustments to the review procedure based on experience and updates IDNA, specifically RFC 5892, to reflect those changes and to clarify the various relationships involved. It also makes other minor adjustments to align that document with experience.
RFC8752 - Report from the IAB Workshop on Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE)
The Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE) Workshop was convened by the Internet Architecture Board (IAB) in July 2019. This report summarizes its significant points of discussion and identifies topics that may warrant further consideration.
RFC8751 - Hierarchical Stateful Path Computation Element (PCE)
A stateful Path Computation Element (PCE) maintains information on the current network state received from the Path Computation Clients (PCCs), including computed Label Switched Paths (LSPs), reserved resources within the network, and pending path computation requests. This information may then be considered when computing the path for a new traffic-engineered LSP or for any associated/dependent LSPs. The path-computation response from a PCE helps the PCC to gracefully establish the computed LSP.
RFC8750 - Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP)
Encapsulating Security Payload (ESP) sends an initialization vector (IV) in each packet. The size of the IV depends on the applied transform and is usually 8 or 16 octets for the transforms defined at the time this document was written. When used with IPsec, some algorithms, such as AES-GCM, AES-CCM, and ChaCha20-Poly1305, take the IV to generate a nonce that is used as an input parameter for encrypting and decrypting. This IV must be unique but can be predictable. As a result, the value provided in the ESP Sequence Number (SN) can be used instead to generate the nonce. This avoids sending the IV itself and saves 8 octets per packet in the case of AES-GCM, AES-CCM, and ChaCha20-Poly1305. This document describes how to do this.
RFC8749 - Moving DNSSEC Lookaside Validation (DLV) to Historic Status
This document retires DNSSEC Lookaside Validation (DLV) and reclassifies RFCs 4431 and 5074 as Historic. Furthermore, this document updates RFC 6698 by excluding the DLV resource record from certificates and updates RFC 6840 by excluding the DLV registries from the trust anchor selection.
RFC8748 - Registry Fee Extension for the Extensible Provisioning Protocol (EPP)
Given the expansion of the DNS namespace and the proliferation of novel business models, it is desirable to provide a method for Extensible Provisioning Protocol (EPP) clients to query EPP servers for the fees and credits associated with various billable transactions and provide expected fees and credits for certain commands and objects. This document describes an EPP extension mapping for registry fees.
RFC8747 - Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)
This specification describes how to declare in a CBOR Web Token (CWT) (which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs).
RFC8746 - Concise Binary Object Representation (CBOR) Tags for Typed Arrays
The Concise Binary Object Representation (CBOR), as defined in RFC 7049, 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.
RFC8745 - Path Computation Element Communication Protocol (PCEP) Extensions for Associating Working and Protection Label Switched Paths (LSPs) with Stateful PCE
An active stateful Path Computation Element (PCE) is capable of computing as well as controlling via Path Computation Element Communication Protocol (PCEP) Multiprotocol Label Switching Traffic Engineering (MPLS-TE) Label Switched Paths (LSPs). Furthermore, it is also possible for an active stateful PCE to create, maintain, and delete LSPs. This document defines the PCEP extension to associate two or more LSPs to provide end-to-end path protection.
RFC8744 - Issues and Requirements for Server Name Identification (SNI) Encryption in TLS
This document describes the general problem of encrypting the Server Name Identification (SNI) TLS parameter. The proposed solutions hide a hidden service behind a fronting service, only disclosing the SNI of the fronting service to external observers. This document lists known attacks against SNI encryption, discusses the current "HTTP co-tenancy" solution, and presents requirements for future TLS-layer solutions.
RFC8743 - Multiple Access Management Services Multi-Access Management Services (MAMS)
In multiconnectivity scenarios, the clients can simultaneously connect to multiple networks based on different access technologies and network architectures like Wi-Fi, LTE, and DSL. Both the quality of experience of the users and the overall network utilization and efficiency may be improved through the smart selection and combination of access and core network paths that can dynamically adapt to changing network conditions.
RFC8742 - Concise Binary Object Representation (CBOR) Sequences
This document describes the Concise Binary Object Representation (CBOR) Sequence format and associated media type "application/cbor-seq". A CBOR Sequence consists of any number of encoded CBOR data items, simply concatenated in sequence.
RFC8741 - Ability for a Stateful Path Computation Element (PCE) to Request and Obtain Control of a Label Switched Path (LSP)
A stateful Path Computation Element (PCE) retains information about the placement of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs). When a PCE has stateful control over LSPs, it may send indications to LSP head-ends to modify the attributes (especially the paths) of the LSPs. A Path Computation Client (PCC) that has set up LSPs under local configuration may delegate control of those LSPs to a stateful PCE.
RFC8740 - Using TLS 1.3 with HTTP/2
This document updates RFC 7540 by forbidding TLS 1.3 post-handshake authentication, as an analog to the existing TLS 1.2 renegotiation restriction.
RFC8739 - Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME)
Public key certificates need to be revoked when they are compromised, that is, when the associated private key is exposed to an unauthorized entity. However, the revocation process is often unreliable. An alternative to revocation is issuing a sequence of certificates, each with a short validity period, and terminating the sequence upon compromise. This memo proposes an Automated Certificate Management Environment (ACME) extension to enable the issuance of Short-Term, Automatically Renewed (STAR) X.509 certificates.
RFC8738 - Automated Certificate Management Environment (ACME) IP Identifier Validation Extension
This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for IP addresses.
RFC8737 - Automated Certificate Management Environment (ACME) TLS Application-Layer Protocol Negotiation (ALPN) Challenge Extension
This document specifies a new challenge for the Automated Certificate Management Environment (ACME) protocol that allows for domain control validation using TLS.
RFC8736 - PIM Message Type Space Extension and Reserved Bits
The PIM version 2 messages share a common message header format. The common header definition contains eight reserved bits. This document specifies how these bits may be used by individual message types and creates a registry containing the per-message-type usage. This document also extends the PIM type space by defining three new message types. For each of the new types, four of the previously reserved bits are used to form an extended type range.
RFC8735 - Scenarios and Simulation Results of PCE in a Native IP Network
Requirements for providing the End-to-End (E2E) performance assurance are emerging within the service provider networks. While there are various technology solutions, there is no single solution that can fulfill these requirements for a native IP network. In particular, there is a need for a universal E2E solution that can cover both intra- and inter-domain scenarios.
RFC8734 - Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS) Version 1.3
Elliptic Curve Cryptography (ECC) Brainpool curves were an option for authentication and key exchange in the Transport Layer Security (TLS) protocol version 1.2 but were deprecated by the IETF for use with TLS version 1.3 because they had little usage. However, these curves have not been shown to have significant cryptographical weaknesses, and there is some interest in using several of these curves in TLS 1.3.
RFC8733 - Path Computation Element Communication Protocol (PCEP) Extensions for MPLS-TE Label Switched Path (LSP) Auto-Bandwidth Adjustment with Stateful PCE
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. Stateful PCE extensions allow stateful control of MPLS-TE Label Switched Paths (LSPs) using PCEP.
RFC8732 - Generic Security Service Application Program Interface (GSS-API) Key Exchange with SHA-2
This document specifies additions and amendments to RFC 4462. It defines a new key exchange method that uses SHA-2 for integrity and deprecates weak Diffie-Hellman (DH) groups. The purpose of this specification is to modernize the cryptographic primitives used by Generic Security Service (GSS) key exchanges.
RFC8731 - Secure Shell (SSH) Key Exchange Method Using Curve25519 and Curve448
This document describes the specification for using Curve25519 and Curve448 key exchange methods in the Secure Shell (SSH) protocol.
RFC8730 - Independent Submission Editor Model
This document describes the function and responsibilities of the RFC Independent Submission Editor (ISE). The Independent Submission stream is one of the stream producers that create draft RFCs, with the ISE as its stream approver. The ISE is overall responsible for activities within the Independent Submission stream, working with draft editors and reviewers, and interacts with the RFC Production Center and Publisher, and the RFC Series Editor (RSE). The ISE is appointed by the IAB, and also interacts with the IETF Administration Limited Liability Company (LLC).
RFC8729 - The RFC Series and RFC Editor
This document describes the framework for an RFC Series and an RFC Editor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFC Series to continue to fulfill its mandate. This document obsoletes RFC 4844.
RFC8728 - RFC Editor Model (Version 2)
The RFC Editor model described in this document divides the responsibilities for the RFC Series into three functions: the RFC Series Editor, the RFC Production Center, and the RFC Publisher. Internet Architecture Board (IAB) oversight via the RFC Series Oversight Committee (RSOC) is described, as is the relationship between the IETF Administration Limited Liability Company and the RSOC. This document reflects the experience gained with "RFC Editor Model (Version 1)", documented in RFC 5620; and obsoletes RFC 6635 to replace all references to the IETF Administrative Support Activity (IASA) and related structures with those defined by the IASA 2.0 Model.
RFC8727 - JSON Binding of the Incident Object Description Exchange Format
The Incident Object Description Exchange Format (IODEF) defined in RFC 7970 provides an information model and a corresponding XML data model for exchanging incident and indicator information. This document gives implementers and operators an alternative format to exchange the same information by defining an alternative data model implementation in JSON and its encoding in Concise Binary Object Representation (CBOR).
RFC8726 - How Requests for IANA Action Will Be Handled on the Independent Stream
The Internet Assigned Numbers Authority (IANA) maintains registries to track code points used by protocols such as those defined by the IETF and documented in RFCs developed on the IETF Stream.
RFC8725 - JSON Web Token Best Current Practices
JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs.
RFC8724 - SCHC: Generic Framework for Static Context Header Compression and Fragmentation
This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind.
RFC8723 - Double Encryption Procedures for the Secure Real-Time Transport Protocol (SRTP)
In some conferencing scenarios, it is desirable for an intermediary to be able to manipulate some parameters in Real-time Transport Protocol (RTP) packets, while still providing strong end-to-end security guarantees. This document defines a cryptographic transform for the Secure Real-time Transport Protocol (SRTP) that uses two separate but related cryptographic operations to provide hop-by-hop and end-to-end security guarantees. Both the end-to-end and hop-by-hop cryptographic algorithms can utilize an authenticated encryption with associated data (AEAD) algorithm or take advantage of future SRTP transforms with different properties.
RFC8722 - Defining the Role and Function of IETF Protocol Parameter Registry Operators
Many Internet Engineering Task Force (IETF) protocols make use of commonly defined values that are passed in messages or packets. To ensure consistent interpretation of these values between independent implementations, there is a need to ensure that the values and associated semantic intent are uniquely defined. The IETF uses registry functions to record assigned protocol parameter values and their associated semantic intentions. For each IETF protocol parameter, it is current practice for the IETF to delegate the role of Protocol Parameter Registry Operator to a nominated entity. This document provides a description of, and the requirements for, these delegated functions. This document obsoletes RFC 6220 to replace all references to the IETF Administrative Support Activity (IASA) and related structures with those defined by the IASA 2.0 Model.
RFC8721 - Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents
Contributors grant intellectual property rights to the IETF. The IETF Trust holds and manages those rights on behalf of the IETF. The Trustees of the IETF Trust are responsible for that management. This management includes granting the licenses to copy, implement, and otherwise use IETF Contributions, among them Internet-Drafts and RFCs. The Trustees of the IETF Trust accept direction from the IETF regarding the rights to be granted. This document describes the desires of the IETF regarding outbound rights to be granted in IETF Contributions. This document obsoletes RFC 5377 solely for the purpose of removing references to the IETF Administrative Oversight Committee (IAOC), which was part of the IETF Administrative Support Activity (IASA).
RFC8720 - Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries
This document provides principles for the operation of Internet Assigned Numbers Authority (IANA) registries.
RFC8719 - High-Level Guidance for the Meeting Policy of the IETF
This document describes a meeting location policy for the IETF and the various stakeholders required to realize this policy.
RFC8718 - IETF Plenary Meeting Venue Selection Process
The IETF Administration Support Activity (IASA) is responsible for arranging the selection and operation of the IETF plenary meeting venue. This memo specifies IETF community requirements for meeting venues, including hotels and meeting space. It also directs the IASA to make available additional process documents that describe the current meeting selection process.
RFC8717 - IETF Administrative Support Activity 2.0: Consolidated Updates to IETF Administrative Terminology
In 2018, the IETF began the transition to a new administrative structure and updated its IETF Administrative Support Activity (IASA) to a new "IASA 2.0" structure. In addition to more substantive changes that are described in other documents, the transition to the 2018 IETF Administrative Support structure changes several position titles and organizational relationships that are referenced elsewhere. Rather than reissue those referencing documents individually, this specification provides updates to them and deprecates some now-obsolete documents to ensure that there is no confusion due to these changes.
RFC8716 - Update to the IETF Anti-Harassment Procedures for the Replacement of the IETF Administrative Oversight Committee (IAOC) with the IETF Administration LLC
The IETF Anti-Harassment Procedures are described in RFC 7776.
RFC8715 - IETF Administrative Support Activity 2.0: Update to the Process for Selection of Trustees for the IETF Trust
This document captures the rationale for the changes introduced in RFC 8714, "Update to the Process for Selection of Trustees for the IETF Trust".
RFC8714 - Update to the Process for Selection of Trustees for the IETF Trust
This memo updates the process for selection of Trustees for the IETF Trust. Previously, the IETF Administrative Oversight Committee (IAOC) members also acted as Trustees, but the IAOC has been eliminated as part of an update to the structure of the IETF Administrative Support Activity (IASA). This memo specifies that the Trustees shall be selected separately.
RFC8713 - IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees
The process by which the members of the IAB and IESG, some Trustees of the IETF Trust, and some Directors of the IETF Administration LLC (IETF LLC) are selected, confirmed, and recalled is specified in this document. This document is based on RFC 7437. Only those updates required to reflect the changes introduced by IETF Administrative Support Activity (IASA) 2.0 have been included. Any other changes will be addressed in future documents.
RFC8712 - The IETF-ISOC Relationship
This document summarizes the Internet Engineering Task Force (IETF) - Internet Society (ISOC) relationship, following a major revision to the structure of the IETF Administrative Support Activity (IASA) in 2018. The IASA was revised under a new "IASA 2.0" structure by the IASA2 Working Group, which changed the IETF's administrative, legal, and financial structure. As a result, it also changed the relationship between the IETF and ISOC, which made it necessary to revise RFC 2031.
RFC8711 - Structure of the IETF Administrative Support Activity, Version 2.0
The IETF Administrative Support Activity (IASA) was originally established in 2005. In the years since then, the needs of the IETF evolved in ways that required changes to its administrative structure. The purpose of this RFC is to document and describe the IETF Administrative Support Activity, version 2.0 (IASA 2.0). It defines the roles and responsibilities of the IETF Administration LLC Board (IETF LLC Board), the IETF Executive Director, and the Internet Society in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IETF LLC Board.
RFC8710 - Multipart Content-Format for the Constrained Application Protocol (CoAP)
This memo defines application/multipart-core, an application-independent media type that can be used to combine representations of zero or more different media types (each with a Constrained Application Protocol (CoAP) Content-Format identifier) into a single representation, with minimal framing overhead.
RFC8709 - Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH) Protocol
This document describes the use of the Ed25519 and Ed448 digital signature algorithms in the Secure Shell (SSH) protocol. Accordingly, this RFC updates RFC 4253.
RFC8708 - Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS)
This document specifies the conventions for using the Hierarchical Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554.
RFC8707 - Resource Indicators for OAuth 2.0
This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access.
RFC8706 - Restart Signaling for IS-IS
This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the DOWN state while still correctly initiating database synchronization.
RFC8705 - OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token.