[{"id":"cmrxvam7n8g3bkh0c4vsm7c4h","channel":"code","topic":"rfc-publications","title":"RFC 9997: YANG-CBOR: Allocating SID Ranges for Private Enterprise Number (PEN) Holders","summary":"YANG-CBOR (RFC 9254, \"Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR)\") defines YANG Schema Item iDentifiers (YANG SIDs), globally unique 63-bit unsigned integers used to identify YANG items. RFC 9595 (\"YANG Schema Item iDentifier (YANG SID)\"","payload":{"url":"https://www.rfc-editor.org/info/rfc9997/","title":"YANG-CBOR: Allocating SID Ranges for Private Enterprise Number (PEN) Holders","rfc_id":"RFC9997","abstract":"YANG-CBOR (RFC 9254, \"Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR)\") defines YANG Schema Item iDentifiers (YANG SIDs), globally unique 63-bit unsigned integers used to identify YANG items. RFC 9595 (\"YANG Schema Item iDentifier (YANG SID)\") defines ways to allocate these SIDs using IANA registries. The present specification employs these SID allocation mechanisms to allocate ranges of 100 000 SIDs (representation size 64 bits) to each holder of an IANA Private Enterprise Number (PEN) of a value below 1 000 000. Holders of PENs of values smaller than 100 000 are also allocated ranges of 10 000 SIDs (representation size 32 bits).","standard":"ietf_rfc","categories":[],"rfc_number":9997,"published_at":"2026-07-23T00:00:00.000Z"},"public_metadata":null,"published_at":"2026-07-23T18:51:20.436Z"},{"id":"cmrxvalmy8g39kh0cbhqhu2dy","channel":"code","topic":"rfc-publications","title":"RFC 10026: Operational Recommendations for DNSSEC Delegation Signer (DS) Automation","summary":"Enabling support for automatic acceptance of DNSSEC Delegation Signer (DS) parameters from the Child DNS operator (via RFCs 7344, 8078, and 9615) requires the Parental Agent, often a registry or registrar, to make a number of technical decisions around acceptance checks, error an","payload":{"url":"https://www.rfc-editor.org/info/rfc10026/","title":"Operational Recommendations for DNSSEC Delegation Signer (DS) Automation","rfc_id":"RFC10026","abstract":"Enabling support for automatic acceptance of DNSSEC Delegation Signer (DS) parameters from the Child DNS operator (via RFCs 7344, 8078, and 9615) requires the Parental Agent, often a registry or registrar, to make a number of technical decisions around acceptance checks, error and success reporting, and multi-party issues such as concurrent updates. This document describes recommendations about how these points are best addressed in practice.","standard":"ietf_rfc","categories":[],"rfc_number":10026,"published_at":"2026-07-23T00:00:00.000Z"},"public_metadata":null,"published_at":"2026-07-23T18:51:19.690Z"},{"id":"cmrqq2q0h6jjbkh0cih5y5zrw","channel":"code","topic":"rfc-publications","title":"RFC 10002: Certificate Management over CMS (CMC)","summary":"This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community: CMC also requires the use of the transport doc","payload":{"url":"https://www.rfc-editor.org/info/rfc10002/","title":"Certificate Management over CMS (CMC)","rfc_id":"RFC10002","abstract":"This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community: CMC also requires the use of the transport document (RFC 10003) and the requirements usage document (RFC 10004) along with this document for a full definition. This document obsoletes RFCs 5272 and 6402.","standard":"ietf_rfc","categories":[],"rfc_number":10002,"published_at":"2026-07-17T00:00:00.000Z"},"public_metadata":null,"published_at":"2026-07-18T18:50:50.801Z"},{"id":"cmrqq2pgh6jj9kh0cel548cmz","channel":"code","topic":"rfc-publications","title":"RFC 10003: Certificate Management over CMS (CMC): Transport Protocols","summary":"This document defines a number of transport mechanisms that are used to move Certificate Management over CMS (CMC) messages. The transport mechanisms described in this document are HTTP, file, mail, and TCP. This document obsoletes RFCs 5273 and 6402.","payload":{"url":"https://www.rfc-editor.org/info/rfc10003/","title":"Certificate Management over CMS (CMC): Transport Protocols","rfc_id":"RFC10003","abstract":"This document defines a number of transport mechanisms that are used to move Certificate Management over CMS (CMC) messages. The transport mechanisms described in this document are HTTP, file, mail, and TCP. This document obsoletes RFCs 5273 and 6402.","standard":"ietf_rfc","categories":[],"rfc_number":10003,"published_at":"2026-07-17T00:00:00.000Z"},"public_metadata":null,"published_at":"2026-07-18T18:50:50.082Z"},{"id":"cmrqq2ov46jj7kh0cya8p3d7u","channel":"code","topic":"rfc-publications","title":"RFC 10004: Certificate Management over CMS (CMC): Compliance Requirements","summary":"This document provides a set of compliance statements about the Certificate Management over CMS (CMC) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents (RFCs 10002 and 10003). This document provid","payload":{"url":"https://www.rfc-editor.org/info/rfc10004/","title":"Certificate Management over CMS (CMC): Compliance Requirements","rfc_id":"RFC10004","abstract":"This document provides a set of compliance statements about the Certificate Management over CMS (CMC) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents (RFCs 10002 and 10003). This document provides the information needed to make a compliant version of CMC. This document obsoletes RFCs 5274 and 6402.","standard":"ietf_rfc","categories":[],"rfc_number":10004,"published_at":"2026-07-17T00:00:00.000Z"},"public_metadata":null,"published_at":"2026-07-18T18:50:49.313Z"},{"id":"cmrpanu8k65r9kh0cop54zvjh","channel":"code","topic":"rfc-publications","title":"RFC 9852: New Protocols Using TLS Must Require TLS 1.3","summary":"TLS 1.3 is widely used, has had comprehensive security proofs, and improves both security and privacy deficiencies in TLS 1.2. Therefore, new protocols that use TLS must require TLS 1.3. As DTLS 1.3 is not widely available or deployed, this prescription does not pertain to DTLS (","payload":{"url":"https://www.rfc-editor.org/info/rfc9852/","title":"New Protocols Using TLS Must Require TLS 1.3","rfc_id":"RFC9852","abstract":"TLS 1.3 is widely used, has had comprehensive security proofs, and improves both security and privacy deficiencies in TLS 1.2. Therefore, new protocols that use TLS must require TLS 1.3. As DTLS 1.3 is not widely available or deployed, this prescription does not pertain to DTLS (in any DTLS version); it pertains to TLS only. This document updates RFC 9325. It discusses post-quantum cryptography and the security and privacy improvements in TLS 1.3 as the rationale for the update.","standard":"ietf_rfc","categories":[],"rfc_number":9852,"published_at":"2026-07-16T00:00:00.000Z"},"public_metadata":null,"published_at":"2026-07-17T18:51:36.020Z"},{"id":"cmrpantpv65r7kh0ccq7azzqk","channel":"code","topic":"rfc-publications","title":"RFC 9955: Hybrid Signature Spectrums","summary":"This document describes classification of design goals and security considerations for hybrid digital signature schemes, including proof composability, non-separability of the component signatures given a hybrid signature, backwards and forwards compatibility, hybrid generality, ","payload":{"url":"https://www.rfc-editor.org/info/rfc9955/","title":"Hybrid Signature Spectrums","rfc_id":"RFC9955","abstract":"This document describes classification of design goals and security considerations for hybrid digital signature schemes, including proof composability, non-separability of the component signatures given a hybrid signature, backwards and forwards compatibility, hybrid generality, and Simultaneous Verification (SV).","standard":"ietf_rfc","categories":[],"rfc_number":9955,"published_at":"2026-07-16T00:00:00.000Z"},"public_metadata":null,"published_at":"2026-07-17T18:51:35.347Z"},{"id":"cmrpant5m65r5kh0clug4ppi1","channel":"code","topic":"rfc-publications","title":"RFC 10015: Deprecating Obsolete Key Exchange Methods in TLS 1.2 and DTLS 1.2","summary":"For (D)TLS 1.2, this document deprecates the use of two key exchanges, namely Diffie-Hellman (DH) over a finite field and RSA. It also discourages the use of static Elliptic Curve Diffie-Hellman (ECDH) cipher suites. These prescriptions apply only to (D)TLS 1.2, since (D)TLS 1.0 ","payload":{"url":"https://www.rfc-editor.org/info/rfc10015/","title":"Deprecating Obsolete Key Exchange Methods in TLS 1.2 and DTLS 1.2","rfc_id":"RFC10015","abstract":"For (D)TLS 1.2, this document deprecates the use of two key exchanges, namely Diffie-Hellman (DH) over a finite field and RSA. It also discourages the use of static Elliptic Curve Diffie-Hellman (ECDH) cipher suites. These prescriptions apply only to (D)TLS 1.2, since (D)TLS 1.0 and TLS 1.1 are deprecated by RFC 8996 and (D)TLS 1.3 either does not use the affected algorithms or does not share the relevant configuration options. (There is no DTLS version 1.1.) This document updates RFCs 4162, 4279, 4346, 4785, 5246, 5288, 5289, 5469, 5487, 5932, 6209, 6347, 6367, 6655, 7905, 8422, and 9325 to either deprecate or discourage the use of cipher suites using the above key exchange methods in (D)TLS 1.2 connections.","standard":"ietf_rfc","categories":[],"rfc_number":10015,"published_at":"2026-07-16T00:00:00.000Z"},"public_metadata":null,"published_at":"2026-07-17T18:51:34.618Z"},{"id":"cmrnv8n235skbkh0c0xfktk0g","channel":"code","topic":"rfc-publications","title":"RFC 9850: The SSLKEYLOGFILE Format for TLS","summary":"This document describes a format that supports logging information about the secrets used in a TLS connection. Recording secrets to a file in SSLKEYLOGFILE format allows diagnostic and logging tools that use this file to decrypt messages exchanged by TLS endpoints. This format is","payload":{"url":"https://www.rfc-editor.org/info/rfc9850/","title":"The SSLKEYLOGFILE Format for TLS","rfc_id":"RFC9850","abstract":"This document describes a format that supports logging information about the secrets used in a TLS connection. Recording secrets to a file in SSLKEYLOGFILE format allows diagnostic and logging tools that use this file to decrypt messages exchanged by TLS endpoints. This format is intended for use in systems where TLS only protects test data.","standard":"ietf_rfc","categories":[],"rfc_number":9850,"published_at":"2026-07-15T00:00:00.000Z"},"public_metadata":null,"published_at":"2026-07-16T18:52:06.459Z"},{"id":"cmrnv8mju5sk9kh0cmpghgh47","channel":"code","topic":"rfc-publications","title":"RFC 9851: TLS 1.2 is in Feature Freeze","summary":"Use of TLS 1.3, which fixes some known deficiencies in TLS 1.2, is growing. This document specifies that no changes will be approved for TLS 1.2 outside of urgent security fixes (as determined by TLS Working Group consensus), new TLS Exporter Labels, and new Application-Layer Pro","payload":{"url":"https://www.rfc-editor.org/info/rfc9851/","title":"TLS 1.2 is in Feature Freeze","rfc_id":"RFC9851","abstract":"Use of TLS 1.3, which fixes some known deficiencies in TLS 1.2, is growing. This document specifies that no changes will be approved for TLS 1.2 outside of urgent security fixes (as determined by TLS Working Group consensus), new TLS Exporter Labels, and new Application-Layer Protocol Negotiation (ALPN) Protocol IDs. This applies to TLS only; it does not apply to DTLS (in any DTLS version).","standard":"ietf_rfc","categories":[],"rfc_number":9851,"published_at":"2026-07-15T00:00:00.000Z"},"public_metadata":null,"published_at":"2026-07-16T18:52:05.802Z"},{"id":"cmrnv8m1d5sk7kh0cpotezkbi","channel":"code","topic":"rfc-publications","title":"RFC 9954: Hybrid Key Exchange in TLS 1.3","summary":"Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if a way is found to defeat the encryption for all but one of the component algorithms. It is motivated by the transition to post-","payload":{"url":"https://www.rfc-editor.org/info/rfc9954/","title":"Hybrid Key Exchange in TLS 1.3","rfc_id":"RFC9954","abstract":"Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if a way is found to defeat the encryption for all but one of the component algorithms. It is motivated by the transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3.","standard":"ietf_rfc","categories":[],"rfc_number":9954,"published_at":"2026-07-15T00:00:00.000Z"},"public_metadata":null,"published_at":"2026-07-16T18:52:05.137Z"},{"id":"cmrnv8lii5sk5kh0cybata78r","channel":"code","topic":"rfc-publications","title":"RFC 9973: TLS 1.3 Extension for Using Certificates with an External Pre-Shared Key","summary":"This document specifies a TLS 1.3 extension that allows TLS clients and servers to authenticate with certificates and provide confidentiality based on encryption with a symmetric key from the usual key agreement algorithm and an external pre-shared key (PSK). This Standards Track","payload":{"url":"https://www.rfc-editor.org/info/rfc9973/","title":"TLS 1.3 Extension for Using Certificates with an External Pre-Shared Key","rfc_id":"RFC9973","abstract":"This document specifies a TLS 1.3 extension that allows TLS clients and servers to authenticate with certificates and provide confidentiality based on encryption with a symmetric key from the usual key agreement algorithm and an external pre-shared key (PSK). This Standards Track RFC obsoletes RFC 8773, which was an Experimental RFC.","standard":"ietf_rfc","categories":[],"rfc_number":9973,"published_at":"2026-07-15T00:00:00.000Z"},"public_metadata":null,"published_at":"2026-07-16T18:52:04.459Z"},{"id":"cmrmftunm5epjkh0cww4nfwhw","channel":"code","topic":"rfc-publications","title":"RFC 9916: Updates to the Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)","summary":"Section 3.4 of RFC 8253 specifies TLS connection establishment restrictions for PCEPS; PCEPS refers to usage of TLS to provide a secure transport for the Path Computation Element Communication Protocol (PCEP). This document adds restrictions to specify what PCEPS implementations ","payload":{"url":"https://www.rfc-editor.org/info/rfc9916/","title":"Updates to the Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)","rfc_id":"RFC9916","abstract":"Section 3.4 of RFC 8253 specifies TLS connection establishment restrictions for PCEPS; PCEPS refers to usage of TLS to provide a secure transport for the Path Computation Element Communication Protocol (PCEP). This document adds restrictions to specify what PCEPS implementations do if they support more than one version of the TLS protocol and to restrict the use of TLS 1.3's early data.","standard":"ietf_rfc","categories":[],"rfc_number":9916,"published_at":"2026-07-14T00:00:00.000Z"},"public_metadata":null,"published_at":"2026-07-15T18:52:56.050Z"},{"id":"cmrmftu535ephkh0c6cv2vfap","channel":"code","topic":"rfc-publications","title":"RFC 9918: Updates to Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication","summary":"RFC 7589 defines how to protect Network Configuration Protocol (NETCONF) messages with TLS 1.2. This document updates RFC 7589 to update support requirements for TLS 1.2 and add TLS 1.3 support requirements, including restrictions on the use of TLS 1.3's early data.","payload":{"url":"https://www.rfc-editor.org/info/rfc9918/","title":"Updates to Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication","rfc_id":"RFC9918","abstract":"RFC 7589 defines how to protect Network Configuration Protocol (NETCONF) messages with TLS 1.2. This document updates RFC 7589 to update support requirements for TLS 1.2 and add TLS 1.3 support requirements, including restrictions on the use of TLS 1.3's early data.","standard":"ietf_rfc","categories":[],"rfc_number":9918,"published_at":"2026-07-14T00:00:00.000Z"},"public_metadata":null,"published_at":"2026-07-15T18:52:55.384Z"},{"id":"cmrmfttmh5epfkh0cynafmd18","channel":"code","topic":"rfc-publications","title":"RFC 9919: The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments","summary":"This specification defines a profile of the Online Certificate Status Protocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) Public Key Infrastructure (PKI) environments and/or in PKI environments that require a lightweight sol","payload":{"url":"https://www.rfc-editor.org/info/rfc9919/","title":"The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments","rfc_id":"RFC9919","abstract":"This specification defines a profile of the Online Certificate Status Protocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) Public Key Infrastructure (PKI) environments and/or in PKI environments that require a lightweight solution to minimize communication bandwidth and client- side processing. This specification obsoletes RFC 5019. The profile specified in RFC 5019 has been updated to allow and recommend the use of SHA-256 over SHA-1.","standard":"ietf_rfc","categories":[],"rfc_number":9919,"published_at":"2026-07-14T00:00:00.000Z"},"public_metadata":null,"published_at":"2026-07-15T18:52:54.713Z"},{"id":"cmrmftt3r5epdkh0ch7su3khf","channel":"code","topic":"rfc-publications","title":"RFC 9933: Carrying SR-Algorithm in Path Computation Element Communication Protocol (PCEP)","summary":"This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) to enhance support for Segment Routing (SR) with a focus on the use of Segment Identifiers (SIDs) and SR-Algorithms in Traffic Engineering (TE). The SR-Algorithm associated with a SID","payload":{"url":"https://www.rfc-editor.org/info/rfc9933/","title":"Carrying SR-Algorithm in Path Computation Element Communication Protocol (PCEP)","rfc_id":"RFC9933","abstract":"This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) to enhance support for Segment Routing (SR) with a focus on the use of Segment Identifiers (SIDs) and SR-Algorithms in Traffic Engineering (TE). The SR-Algorithm associated with a SID defines the path computation algorithm used by Interior Gateway Protocols (IGPs). It introduces mechanisms for PCEP peers to signal the SR-Algorithm associated with SIDs by encoding this information in Explicit Route Object (ERO) and Record Route Object (RRO) subobjects, enables SR-Algorithm constraints for path computation, and defines new metric types for the METRIC object. This document updates RFC 8664 and RFC 9603 to allow such extensions.","standard":"ietf_rfc","categories":[],"rfc_number":9933,"published_at":"2026-07-15T00:00:00.000Z"},"public_metadata":null,"published_at":"2026-07-15T18:52:54.040Z"},{"id":"cmrl0dhwn50rrkh0cn2ap0ud4","channel":"code","topic":"rfc-publications","title":"RFC 9995: CBOR Object Signing and Encryption (COSE) Hash Envelope","summary":"This document defines new CBOR Object Signing and Encryption (COSE) header parameters for signaling a payload as an output of a hash function. This mechanism enables faster validation, as access to the original payload is not required for signature validation. Additionally, hints","payload":{"url":"https://www.rfc-editor.org/info/rfc9995/","title":"CBOR Object Signing and Encryption (COSE) Hash Envelope","rfc_id":"RFC9995","abstract":"This document defines new CBOR Object Signing and Encryption (COSE) header parameters for signaling a payload as an output of a hash function. This mechanism enables faster validation, as access to the original payload is not required for signature validation. Additionally, hints of the hashed payload's content format and availability are defined, providing references to optional discovery mechanisms that can help to find the original payload content.","standard":"ietf_rfc","categories":[],"rfc_number":9995,"published_at":"2026-07-13T00:00:00.000Z"},"public_metadata":null,"published_at":"2026-07-14T18:52:32.615Z"},{"id":"cmrl0dhca50rpkh0crj3bcct2","channel":"code","topic":"rfc-publications","title":"RFC 9999: Remote ATtestation procedureS (RATS) Conceptual Message Wrapper (CMW)","summary":"The conceptual messages introduced by the Remote ATtestation procedureS (RATS) architecture (RFC 9334) are protocol-agnostic data units that are conveyed between RATS roles during RATS interactions. Conceptual messages describe the meaning and function of such data units within R","payload":{"url":"https://www.rfc-editor.org/info/rfc9999/","title":"Remote ATtestation procedureS (RATS) Conceptual Message Wrapper (CMW)","rfc_id":"RFC9999","abstract":"The conceptual messages introduced by the Remote ATtestation procedureS (RATS) architecture (RFC 9334) are protocol-agnostic data units that are conveyed between RATS roles during RATS interactions. Conceptual messages describe the meaning and function of such data units within RATS data flows without specifying a wire format, encoding, transport mechanism, or processing details. The initial set of conceptual messages is defined in Section 8 of RFC 9334 and includes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies. This document introduces the Conceptual Message Wrapper (CMW) that provides a common structure to encapsulate these messages. It defines a dedicated Concise Binary Object Representation (CBOR) tag, corresponding JSON Web Token (JWT) and CBOR ","standard":"ietf_rfc","categories":[],"rfc_number":9999,"published_at":"2026-07-14T00:00:00.000Z"},"public_metadata":null,"published_at":"2026-07-14T18:52:31.882Z"},{"id":"cmrgq3qwv3widkh0colhrz0iz","channel":"code","topic":"rfc-publications","title":"RFC 9846: The Transport Layer Security (TLS) Protocol Version 1.3","summary":"This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document obsoletes RFC 8446, which s","payload":{"url":"https://www.rfc-editor.org/info/rfc9846/","title":"The Transport Layer Security (TLS) Protocol Version 1.3","rfc_id":"RFC9846","abstract":"This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations.","standard":"ietf_rfc","categories":[],"rfc_number":9846,"published_at":"2026-07-11T00:00:00.000Z"},"public_metadata":null,"published_at":"2026-07-11T18:53:56.863Z"},{"id":"cmr3v65zl0gr9kh0ccpco79b0","channel":"code","topic":"rfc-publications","title":"RFC 9994: MPLS Network Action (MNA) Sub-Stack Specification Including In-Stack Network Actions and Data","summary":"This document specifies the MPLS Network Action (MNA) Sub-Stack for carrying network actions and Ancillary Data (AD) in the MPLS label stack. MNA can be used to influence packet-forwarding decisions, carry additional Operations, Administration, and Maintenance (OAM) information i","payload":{"url":"https://www.rfc-editor.org/info/rfc9994/","title":"MPLS Network Action (MNA) Sub-Stack Specification Including In-Stack Network Actions and Data","rfc_id":"RFC9994","abstract":"This document specifies the MPLS Network Action (MNA) Sub-Stack for carrying network actions and Ancillary Data (AD) in the MPLS label stack. MNA can be used to influence packet-forwarding decisions, carry additional Operations, Administration, and Maintenance (OAM) information in the MPLS packet, or perform user-defined operations. This document updates RFC 9789 to refine the list of pieces of information that must be included in any document that defines an MNA.","standard":"ietf_rfc","categories":[],"rfc_number":9994,"published_at":"2026-06-26T00:00:00.000Z"},"public_metadata":null,"published_at":"2026-07-02T18:54:47.505Z"},{"id":"cmr3v65i60gr7kh0cn2vo33d6","channel":"code","topic":"rfc-publications","title":"RFC 10005: BGP Link Bandwidth Extended Community","summary":"This document defines a BGP extended community, the Link Bandwidth Extended Community, which carries bandwidth information to enable weighted load-balancing in multipath scenarios. It specifies the format and processing rules for this extended community type.","payload":{"url":"https://www.rfc-editor.org/info/rfc10005/","title":"BGP Link Bandwidth Extended Community","rfc_id":"RFC10005","abstract":"This document defines a BGP extended community, the Link Bandwidth Extended Community, which carries bandwidth information to enable weighted load-balancing in multipath scenarios. It specifies the format and processing rules for this extended community type.","standard":"ietf_rfc","categories":[],"rfc_number":10005,"published_at":"2026-06-26T00:00:00.000Z"},"public_metadata":null,"published_at":"2026-07-02T18:54:46.878Z"},{"id":"cmr3v650q0gr5kh0c56n6wzcr","channel":"code","topic":"rfc-publications","title":"RFC 9970: Connected Identity for Secure Telephone Identity Revisited (STIR)","summary":"The Session Initiation Protocol (SIP) Identity header field conveys cryptographic identity information about the originators of SIP requests. However, the Secure Telephone Identity Revisited (STIR) framework provides no means for determining the identity of the called party in a ","payload":{"url":"https://www.rfc-editor.org/info/rfc9970/","title":"Connected Identity for Secure Telephone Identity Revisited (STIR)","rfc_id":"RFC9970","abstract":"The Session Initiation Protocol (SIP) Identity header field conveys cryptographic identity information about the originators of SIP requests. However, the Secure Telephone Identity Revisited (STIR) framework provides no means for determining the identity of the called party in a conventional telephone-calling scenario. This document updates prior guidance on the \"connected identity\" problem to reflect the changes to SIP identity that accompanied STIR. It also considers a revised problem space for connected identity as a means of detecting calls that have been retargeted to a party impersonating the intended destination and preventing the spoofing of mid-dialog or dialog-terminating events by intermediaries or third parties.","standard":"ietf_rfc","categories":[],"rfc_number":9970,"published_at":"2026-06-29T00:00:00.000Z"},"public_metadata":null,"published_at":"2026-07-02T18:54:46.251Z"},{"id":"cmr3v64jd0gr3kh0ctigpmzgs","channel":"code","topic":"rfc-publications","title":"RFC 9974: Operations, Administration, and Maintenance (OAM) Requirements for the Bit Index Explicit Replication (BIER) Layer","summary":"This document specifies a list of functional requirements for Operations, Administration, and Maintenance mechanisms, protocols, and tools that support operations in the Bit Index Explicit Replication layer of a network.","payload":{"url":"https://www.rfc-editor.org/info/rfc9974/","title":"Operations, Administration, and Maintenance (OAM) Requirements for the Bit Index Explicit Replication (BIER) Layer","rfc_id":"RFC9974","abstract":"This document specifies a list of functional requirements for Operations, Administration, and Maintenance mechanisms, protocols, and tools that support operations in the Bit Index Explicit Replication layer of a network.","standard":"ietf_rfc","categories":[],"rfc_number":9974,"published_at":"2026-06-29T00:00:00.000Z"},"public_metadata":null,"published_at":"2026-07-02T18:54:45.625Z"},{"id":"cmr3v64200gr1kh0cozmjyw60","channel":"code","topic":"rfc-publications","title":"RFC 9978: Bidirectional Forwarding Detection (BFD) Stability","summary":"This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol to measure BFD Stability. Specifically, it describes a mechanism for the detection of BFD packet loss.","payload":{"url":"https://www.rfc-editor.org/info/rfc9978/","title":"Bidirectional Forwarding Detection (BFD) Stability","rfc_id":"RFC9978","abstract":"This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol to measure BFD Stability. Specifically, it describes a mechanism for the detection of BFD packet loss.","standard":"ietf_rfc","categories":[],"rfc_number":9978,"published_at":"2026-06-29T00:00:00.000Z"},"public_metadata":null,"published_at":"2026-07-02T18:54:45.000Z"},{"id":"cmr3v63ka0gqzkh0cd4un0m1u","channel":"code","topic":"rfc-publications","title":"RFC 9942: CBOR Object Signing and Encryption (COSE) Receipts","summary":"CBOR Object Signing and Encryption (COSE) Receipts prove properties of a Verifiable Data Structure (VDS) to a verifier. VDSs and associated Proof Types enable security properties, such as minimal disclosure, transparency, and non-equivocation. Transparency helps maintain trust ov","payload":{"url":"https://www.rfc-editor.org/info/rfc9942/","title":"CBOR Object Signing and Encryption (COSE) Receipts","rfc_id":"RFC9942","abstract":"CBOR Object Signing and Encryption (COSE) Receipts prove properties of a Verifiable Data Structure (VDS) to a verifier. VDSs and associated Proof Types enable security properties, such as minimal disclosure, transparency, and non-equivocation. Transparency helps maintain trust over time and has been applied to certificates, end-to-end encrypted messaging systems, and supply chain security. This specification enables concise transparency-oriented systems by building on Concise Binary Object Representation (CBOR) and COSE. The extensibility of the approach is demonstrated by providing CBOR encodings for Merkle inclusion and consistency proofs.","standard":"ietf_rfc","categories":[],"rfc_number":9942,"published_at":"2026-06-30T00:00:00.000Z"},"public_metadata":null,"published_at":"2026-07-02T18:54:44.362Z"}]