|
|
| |
| Concise Binary Object Representation (CBOR) Tags for Time,Duration,and Period |
|
| draft-ietf-cbor-time-tag-12.txt |
| Date: |
30/10/2023 |
| Authors: |
Carsten Bormann, Ben Gamari, Henk Birkholz |
| 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. In CBOR, one point of extensibility is the definition of CBOR tags. RFC 8949 defines two tags for time: CBOR tag 0 (RFC3339 time as a string) and tag 1 (POSIX time as int or float). Since then, additional requirements have become known. The present document defines a CBOR tag for time that allows a more elaborate representation of time, as well as related CBOR tags for duration and time period. This document is intended as the reference document for the IANA registration of the CBOR tags defined. // (This cref will be removed by the RFC editor:) The present // revision (–12) addresses the IESG reviews. |
|
|
| |
| CBOR Object Signing and Encryption (COSE) Key Thumbprint |
|
|
This specification defines a method for computing a hash value over a COSE Key. It defines which fields in a COSE Key structure are used in the hash computation, the method of creating a canonical form of the fields, and how to hash the byte sequence. The resulting hash value can be used for identifying or selecting a key that is the subject of the thumbprint. |
| The Privacy Pass HTTP Authentication Scheme |
|
|
This document defines an HTTP authentication scheme for Privacy Pass, a privacy-preserving authentication mechanism used for authorization. The authentication scheme in this document can be used by clients to redeem Privacy Pass tokens with an origin. It can also be used by origins to challenge clients to present Privacy Pass tokens. |
| Out-of-Band STIR for Service Providers |
|
|
The Secure Telephone Identity Revisited (STIR) framework defines means of carrying its Persona Assertion Tokens (PASSporTs) either in- band, within the headers of a SIP request, or out-of-band, through a service that stores PASSporTs for retrieval by relying parties. This specification defines a way that the out-of-band conveyance of PASSporTs can be used to support large service providers, for cases in which in-band STIR conveyance is not universally available. |
|
|
| |
| Extended Mobility Procedures for EVPN-IRB |
|
|
The procedure to handle host mobility in a layer 2 Network with EVPN control plane is defined as part of RFC7432. EVPN has since evolved to find wider applicability across various IRB use cases that include distributing both MAC and IP reachability via a common EVPN control plane. MAC Mobility procedures defined in RFC7432 are extensible to IRB use cases if a fixed 1:1 mapping between host IP and MAC is assumed across host moves. Generic mobility support for IP and MAC addresses that allows these bindings to change across moves IS REQUIRED to support a broader set of EVPN IRB use cases. EVPN all- active multi-homing further introduces scenarios that require additional consideration from mobility perspective. This document enumerates a set of design considerations applicable to mobility across these EVPN IRB use cases and updates sequence number assignment procedures defined in RFC7432 to address these IRB use cases. 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. |
| Application Scenarios for the Quantum Internet |
|
|
The Quantum Internet has the potential to improve application functionality by incorporating quantum information technology into the infrastructure of the overall Internet. This document provides an overview of some applications expected to be used on the Quantum Internet and categorizes them. Some general requirements for the Quantum Internet are also discussed. The intent of this document is to describe a framework for applications, and describe a few selected application scenarios for the Quantum Internet.This document is a product of the Quantum Internet Research Group (QIRG). |
| YANG Data Model for Routing in Fat Trees (RIFT) |
|
| draft-ietf-rift-yang-10.txt |
| Date: |
16/10/2023 |
| Authors: |
Zheng Zhang, Yuehua Wei, Shaowen Ma, Xufeng Liu, Bruno Rijsman |
| Working Group: |
Routing In Fat Trees (rift) |
|
This document defines a YANG data model for the configuration and management of Routing in Fat Trees (RIFT) Protocol. The model is based on YANG 1.1 as defined in RFC7950 and conforms to the Network Management Datastore Architecture (NMDA) as described in RFC8342. |
|
|
| |
| MVPN/EVPN Tunnel Aggregation with Common Labels |
|
|
The MVPN specifications allow a single Point-to-Multipoint (P2MP) tunnel to carry traffic of multiple IP VPNs (abbreviated as VPNs). The EVPN specifications allow a single P2MP tunnel to carry traffic of multiple Broadcast Domains (BDs). These features require the ingress router of the P2MP tunnel to allocate an upstream-assigned MPLS label for each VPN or for each BD. A packet sent on a P2MP tunnel then carries the label that is mapped to its VPN or BD (in some cases, a distinct upstream-assigned label is needed for each flow.) Since each ingress router allocates labels independently, with no coordination among the ingress routers, the egress routers may need to keep track of a large number of labels. The number of labels may need to be as large (or larger) than the product of the number of ingress routers times the number of VPNs or BDs. However, the number of labels can be greatly reduced if the association between a label and a VPN or BD is made by provisioning, so that all ingress routers assign the same label to a particular VPN or BD. New procedures are needed in order to take advantage of such provisioned labels. These new procedures also apply to Multipoint-to-Multipoint (MP2MP) tunnels. This document updates RFCs 6514, 7432 and 7582 by specifying the necessary procedures. |