Index - Month Index of IDs
All IDs - sorted by date)
Concise Binary Object Representation (CBOR) Tags for Time,Duration,and Period | ||||||||||||||
|
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. | |||||||||||||
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. |
Matroska Media Container Format Specifications | ||||||||||||||
|
This document defines the Matroska audiovisual data container structure, including definitions of its structural elements, as well as its terminology, vocabulary, and application. This document updates [RFC8794] to permit the use of a previously reserved EBML Element ID. |
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. |
Preference-based EVPN DF Election | ||||||||||||||
|
The Designated Forwarder (DF) in Ethernet Virtual Private Networks (EVPN) is defined as the Provider Edge (PE) router responsible for sending Broadcast, Unknown unicast and Multicast traffic (BUM) to a multi-homed device/network in the case of an all-active multi-homing Ethernet Segment (ES), or BUM and unicast in the case of single- active multi-homing. The Designated Forwarder is selected out of a candidate list of PEs that advertise the same Ethernet Segment Identifier (ESI) to the EVPN network, according to the Default Designated Forwarder Election algorithm. While the Default Algorithm provides an efficient and automated way of selecting the Designated Forwarder across different Ethernet Tags in the Ethernet Segment, there are some use cases where a more 'deterministic' and user- controlled method is required. At the same time, Network Operators require an easy way to force an on-demand Designated Forwarder switchover in order to carry out some maintenance tasks on the existing Designated Forwarder or control whether a new active PE can preempt the existing Designated Forwarder PE. This document proposes a Designated Forwarder Election algorithm that meets the requirements of determinism and operation control. This document updates RFC8584 by modifying the definition of the DF Election Extended Community. |