Individual Submissions (none) Internet Drafts


      
 The ARK Identifier Scheme
 
 draft-kunze-ark-27.txt
 Date: 21/02/2021
 Authors: John Kunze, Emmanuelle Bermes
 Working Group: Individual Submissions (none)
 Formats: xml txt
The ARK (Archival Resource Key) naming scheme is designed to facilitate the high-quality and persistent identification of information objects. A founding principle of the ARK is that persistence is purely a matter of service and is neither inherent in an object nor conferred on it by a particular naming syntax. The best that an identifier can do is to lead users to the services that support robust reference. The term ARK itself refers both to the scheme and to any single identifier that conforms to it. An ARK has five components: [https://NMA/]ark:[/]NAAN/Name[Qualifier] an optional and mutable Name Mapping Authority (usually a hostname), the "ark:" label, the Name Assigning Authority Number (NAAN), the assigned Name, and an optional and possibly mutable Qualifier supported by the NMA. The NAAN and Name together form the immutable persistent identifier for the object independent of the URL hostname. An ARK is a special kind of URL that connects users to three things: the named object, its metadata, and the provider's promise about its persistence. When entered into the location field of a Web browser, the ARK leads the user to the named object. That same ARK, inflected by appending `?info', returns a metadata record that is both human- and machine-readable. The returned record contains core metadata and a commitment statement from the current provider. Tools exist for minting, binding, and resolving ARKs.
 An IPv4 Flowlabel Option
 
 draft-dreibholz-ipv4-flowlabel-33.txt
 Date: 13/03/2021
 Authors: Thomas Dreibholz
 Working Group: Individual Submissions (none)
 Formats: txt
This draft defines an IPv4 option containing a flowlabel that is compatible to IPv6. It is required for simplified usage of IntServ and interoperability with IPv6.
 Prepaid Extensions to Remote Authentication Dial-In User Service (RADIUS)
 
 draft-lior-radius-prepaid-extensions-22.txt
 Date: 25/02/2013
 Authors: Avi Lior, Parviz Yegani, Kuntal Chowdhury, Hannes Tschofenig, Andreas Pashalidis
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol that enables service providers to charge for prepaid services. The supported charging models supported are volume-based, duration-based, and based on one-time events.
 Applicability of Reliable Server Pooling for Real-Time Distributed Computing
 
 draft-dreibholz-rserpool-applic-distcomp-30.txt
 Date: 13/03/2021
 Authors: Thomas Dreibholz
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the applicability of the Reliable Server Pooling architecture to manage real-time distributed computing pools and access the resources of such pools.
 Secure SCTP
 
 draft-hohendorf-secure-sctp-31.txt
 Date: 13/03/2021
 Authors: Carsten Hohendorf, Esbold Unurkhaan, Thomas Dreibholz
 Working Group: Individual Submissions (none)
 Formats: txt
This document explains the reason for the integration of security functionality into SCTP, and gives a short description of S-SCTP and its services. S-SCTP is fully compatible with SCTP defined in RFC4960, it is designed to integrate cryptographic functions into SCTP.
 Applicability of Reliable Server Pooling for SCTP-Based Endpoint Mobility
 
 draft-dreibholz-rserpool-applic-mobility-29.txt
 Date: 13/03/2021
 Authors: Thomas Dreibholz, Jobin Pulinthanath
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a novel mobility concept based on a combination of SCTP with Dynamic Address Reconfiguration extension and Reliable Server Pooling (RSerPool).
 Reliable Server Pooling (RSerPool) Bakeoff Scoring
 
 draft-dreibholz-rserpool-score-28.txt
 Date: 13/03/2021
 Authors: Thomas Dreibholz, Michael Tuexen
 Working Group: Individual Submissions (none)
 Formats: txt
This memo describes some of the scoring to be used in the testing of Reliable Server Pooling protocols ASAP and ENRP at upcoming bakeoffs.
 Handle Resolution Option for ASAP
 
 draft-dreibholz-rserpool-asap-hropt-28.txt
 Date: 13/03/2021
 Authors: Thomas Dreibholz
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the Handle Resolution option for the ASAP protocol.
 Definition of a Delay Measurement Infrastructure and Delay-Sensitive Least-Used Policy for Reliable Server Pooling
 
 draft-dreibholz-rserpool-delay-27.txt
 Date: 13/03/2021
 Authors: Thomas Dreibholz, Xing Zhou
 Working Group: Individual Submissions (none)
 Formats: txt
This document contains the definition of a delay measurement infrastructure and a delay-sensitive Least-Used policy for Reliable Server Pooling.
 Takeover Suggestion Flag for the ENRP Handle Update Message
 
 draft-dreibholz-rserpool-enrp-takeover-25.txt
 Date: 13/03/2021
 Authors: Thomas Dreibholz, Xing Zhou
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the Takeover Suggestion Flag for the ENRP_HANDLE_UPDATE message of the ENRP protocol.
 The i;codepoint collation
 
 draft-hoehrmann-cp-collation-01.txt
 Date: 14/09/2010
 Authors: Bjoern Hoehrmann
 Working Group: Individual Submissions (none)
 Formats: txt
This memo describes the "i;codepoint" collation. Character strings are compared based on the Unicode scalar values of the characters. The collation supports equality, substring, and ordering operations.
 A Uniform Resource Name (URN) Namespace for Sources of Law (LEX)
 
 draft-spinosa-urn-lex-14.txt
 Date: 27/04/2021
 Authors: PierLuigi Spinosa, Enrico Francesconi, Caterina Lupo
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a Uniform Resource Name (URN) Namespace Identification (NID) convention as prescribed by the Internet Engineering Task Force (IETF) for identifying, naming, assigning, and managing persistent resources in the legal domain.
 Xon/Xoff State Control for Telnet Com Port Control Option
 
 draft-edwards-telnet-xon-xoff-state-control-00.txt
 Date: 23/03/2010
 Authors: Grant Edwards
 Working Group: Individual Submissions (none)
 Formats: pdf txt
This document defines new values for use with the telnet com port control option's SET-CONTROL sub-command defined in RFC2217. These new values provide a mechanism for the telnet client to control and query the outbound Xon/Xoff flow control state of the telnet server's physical serial port. This capability is exposed in the serial port API on some operating systems and is needed by telnet clients that implement a port-redirector service which provides applications local to the redirector/telnet-client with transparent access to the remote serial port on the telnet server.
 Load Sharing for the Stream Control Transmission Protocol (SCTP)
 
 draft-tuexen-tsvwg-sctp-multipath-21.txt
 Date: 02/02/2021
 Authors: Paul Amer, Martin Becke, Thomas Dreibholz, Nasif Ekiz, Jana Iyengar, Preethi Natarajan, Randall Stewart, Michael Tuexen
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Stream Control Transmission Protocol (SCTP) supports multi-homing for providing network fault tolerance. However, mainly one path is used for data transmission. Only timer-based retransmissions are carried over other paths as well. This document describes how multiple paths can be used simultaneously for transmitting user messages.
 Clarification of Proper Use of "@" (at sign) in URI-style Components
 
 draft-accilent-at-sign-00.txt
 Date: 30/07/2010
 Authors: Robert Simpson
 Working Group: Individual Submissions (none)
 Formats: xml txt
Defacto standards have evolved that conflict with existing standards, specifically RFC 3986. This document clarifies the use of the "@" (at sign) in URIs and partial URI-like addresses.
 Hypertext Transfer Protocol (HTTP) Digest Authentication Using GSM 2G Authentication and Key Agreement (AKA)
 
 draft-morand-http-digest-2g-aka-05.txt
 Date: 14/04/2014
 Authors: Lionel Morand
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a one-time password generation mechanism for Hypertext Transfer Protocol (HTTP) Digest access authentication based on Global System for Mobile Communications (GSM) authentication and key generation functions A3 and A8, also known as GSM AKA or 2G AKA. The HTTP Authentication Framework includes two authentication schemes: Basic and Digest. Both schemes employ a shared secret based mechanism for access authentication. The GSM AKA mechanism performs user authentication and session key distribution in GSM and Universal Mobile Telecommunications System (UMTS) networks. GSM AKA is a challenge-response based mechanism that uses symmetric cryptography.
 Extensions to Path Computation Element Communication Protocol (PCEP) for Backup Ingress of a Traffic Engineering Label Switched Path
 
 draft-chen-pce-compute-backup-ingress-17.txt
 Date: 06/01/2021
 Authors: Huaimo Chen
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to send a request for computing a backup ingress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP to a PCE and for a PCE to compute the backup ingress and reply to the PCC with a computation result for the backup ingress.
 Extensions to the Path Computation Element Communication Protocol (PCEP) for Backup Egress of a Traffic Engineering Label Switched Path
 
 draft-chen-pce-compute-backup-egress-17.txt
 Date: 06/01/2021
 Authors: Huaimo Chen
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to send a request for computing a backup egress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP to a PCE and for a PCE to compute the backup egress and reply to the PCC with a computation result for the backup egress.
 Sender Queue Info Option for the SCTP Socket API
 
 draft-dreibholz-tsvwg-sctpsocket-sqinfo-22.txt
 Date: 13/03/2021
 Authors: Thomas Dreibholz, Robin Seggelmann, Martin Becke
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes an extension to the SCTP sockets API for querying information about the sender queue.
 SCTP Socket API Extensions for Concurrent Multipath Transfer
 
 draft-dreibholz-tsvwg-sctpsocket-multipath-22.txt
 Date: 13/03/2021
 Authors: Thomas Dreibholz, Martin Becke, Hakim Adhari
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes extensions to the SCTP sockets API for configuring the CMT-SCTP and CMT/RP-SCTP extensions.
 Encoding the graphemes of the SignWriting Script with the x-ISWA-2010
 
 draft-slevinski-iswa-2010-00.txt
 Date: 03/01/2011
 Authors: Stephen Slevinski, Valerie Sutton
 Working Group: Individual Submissions (none)
 Formats: txt
For concreteness, because the universal character set is not yet universal, because an undocumented and unlabeled coded character set hampers information interchange, a 12-bit coded character set has been created that encodes the graphemes of the SignWriting script as described in the open standard of the International SignWriting Alphabet 2010. The x-ISWA-2010 coded character set is defined with hexadecimal characters and described with Unicode characters, either proposed characters on plane 1 or interchange characters on plane 15. This memo defines a standard coded character set for the Internet community. It is published for reference, examination, implementation, and evaluation. Distribution of this memo is unlimited.
 A Forward-Search P2P TE LSP Inter-Domain Path Computation
 
 draft-chen-pce-forward-search-p2p-path-computation-20.txt
 Date: 06/01/2021
 Authors: Huaimo Chen
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document presents a forward search procedure for computing paths for Point-to-Point (P2P) Traffic Engineering (TE) Label Switched Paths (LSPs) crossing a number of domains using multiple Path Computation Elements (PCEs). In addition, extensions to the Path Computation Element Communication Protocol (PCEP) for supporting the forward search procedure are described.
 Route Flap Damping Deployment Status Survey
 
 draft-shishio-grow-isp-rfd-implement-survey-05.txt
 Date: 21/06/2012
 Authors: Shishio Tsuchiya, Seiichi Kawamura, Randy Bush, Cristel Pelsser
 Working Group: Individual Submissions (none)
 Formats: txt
BGP Route Flap Damping [RFC2439] is a mechanism that targets route stability. It penalyzes routes that flap with the aim of reducing CPU load on the routers. But it has side-effects. Thus, in 2006, RIPE recommended not to use Route Flap Damping (see [RIPE-378]). Now, some researchers propose to turn RFD, with less aggressive parameters, back on [draft-ymbk-rfd-usable]. This document describes results of a survey conducted among service provider on their use of BGP Route Flap Damping.
 A Forward-Search P2MP TE LSP Inter-Domain Path Computation
 
 draft-chen-pce-forward-search-p2mp-path-19.txt
 Date: 06/01/2021
 Authors: Huaimo Chen
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document presents a forward search procedure for computing a path for a Point-to-MultiPoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP) crossing a number of domains through using multiple Path Computation Elements (PCEs). In addition, extensions to the Path Computation Element Communication Protocol (PCEP) for supporting the forward search procedure are described.
 A SAVI Solution for WLAN
 
 draft-bi-savi-wlan-20.txt
 Date: 14/11/2020
 Authors: Jun Bi, Jianping Wu, You Wang, Tao Lin
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a source address validation solution for WLAN enabling 802.11i or other security mechanisms. This mechanism snoops NDP and DHCP packets to bind IP address to MAC address, and relies on the security of MAC address guaranteed by 802.11i or other mechanisms to filter IP spoofing packets. It can work in the special situations described in the charter of SAVI(Source Address Validation Improvements) workgroup, such as multiple MAC addresses on one interface. This document describes three different deployment scenarios, with solutions for migration of binding entries when hosts move from one access point to another.
 Unified User-Agent String
 
 draft-karcz-uuas-01.txt
 Date: 10/11/2014
 Authors: Mateusz Karcz
 Working Group: Individual Submissions (none)
 Formats: txt
User-Agent is a HTTP request-header field. It contains information about the user agent originating the request, which is often used by servers to help identify the scope of reported interoperability problems, to work around or tailor responses to avoid particular user agent limitations, and for analytics regarding browser or operating system use. Over the years contents of this field got complicated and ambiguous. That was the reaction for sending altered version of websites to web browsers other than popular ones. During the development of the WWW, authors of the new web browsers used to construct User-Agent strings similar to Netscape's one. Nowadays contents of the User-Agent field are much longer than 15 years ago. This Memo proposes the Uniform User-Agent String as a way to simplify the User-Agent field contents, while maintaining the previous possibility of their use.
 SNMPD to use cache and shared database based on MIB Classification
 
 draft-haresh-sushrut-mib-classification-01.txt
 Date: 29/03/2012
 Authors: Haresh Khandelwal
 Working Group: Individual Submissions (none)
 Formats: txt
This memo defines classification of SNMP MIBs to either use SNMP cache database and shared database (SDB) mechanism to reduce high CPU usage while SNMP GET REQUEST, GETNEXT REQUEST, GETBULK REQUEST are continuously performed from network management system (NMS)/SNMP manager/SNMP MIB browser to managed device.
 Analysis of Algorithms For Deriving Port Sets
 
 draft-tsou-softwire-port-set-algorithms-analysis-04.txt
 Date: 17/05/2013
 Authors: Tina Tsou, Tetsuya Murakami, Simon Perreault
 Working Group: Individual Submissions (none)
 Formats: txt xml
This memo analyzes some port set definition algorithms used for stateless IPv4 to IPv6 transition technologies. The transition technologies using port set algorithms can be divided into two categories: fully stateless approach and binding approach. Some algorithms can work for both approaches.
 The Applicability of the PCE to Computing Protection and Recovery Paths for Single Domain and Multi-Domain Networks.
 
 draft-chen-pce-protection-applicability-16.txt
 Date: 29/04/2021
 Authors: Huaimo Chen
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. A link or node failure can significantly impact network services in large-scale networks. Therefore it is important to ensure the survivability of large scale networks which consist of various connections provided over multiple interconnected networks with varying technologies. This document examines the applicability of the PCE architecture, protocols, and procedures for computing protection paths and restoration services, for single and multi-domain networks. This document also explains the mechanism of Fast Re-Route (FRR) where a point of local repair (PLR) needs to find the appropriate merge point (MP) to do bypass path computation using PCE.
 NAT traversal for LISP
 
 draft-ermagan-lisp-nat-traversal-19.txt
 Date: 07/05/2021
 Authors: Vina Ermagan, Dino Farinacci, Darrel Lewis, Fabio Maino, Marc Portoles-Comeras, Jesper Skriver, Chris White, Albert Bresco, Albert Cabellos-Aparicio
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes a mechanism for IPv4 NAT traversal for LISP tunnel routers (xTR) and LISP Mobile Nodes (LISP-MN) behind a NAT device. A LISP device both detects the NAT and initializes its state. Forwarding to the LISP device through a NAT is enabled by the LISP Re-encapsulating Tunnel Router (RTR) network element, which acts as an anchor point in the data plane, forwarding traffic from unmodified LISP devices through the NAT.
 An FTP Application Layer Gateway (ALG) for IPv4-to-IPv6 Translation
 
 draft-tsou-behave-ftp46-01.txt
 Date: 16/09/2013
 Authors: Tina Tsou, Simon Perreault, Jing Huang
 Working Group: Individual Submissions (none)
 Formats: xml txt
An FTP ALG for NAT64 was defined in RFC 6384. Its scope was limited to an IPv6 client connecting to an IPv4 server. This memo supports the case of an IPv4 client connecting to an IPv6 server.
 Web Cache Communication Protocol V2,Revision 1
 
 draft-mclaggan-wccp-v2rev1-00.txt
 Date: 02/08/2012
 Authors: Douglas McLaggan
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes version 2 of the Web Cache Communication Protocol (WCCP). The WCCP V2 protocol specifies interactions between one or more routers and one or more web-caches. The interaction may take place within an IPv4 or IPv6 network. The purpose of the interaction is to establish and maintain the transparent redirection of selected types of traffic flowing through a group of routers (or similar devices). The selected traffic is redirected to a group of web-caches (or other traffic optimisation devices) with the aim of optimising resource usage and lowering response times. The protocol does not specify any interaction between the web-caches within a group or between a web-cache and a web-server.
 The application/stream+json Media Type
 
 draft-snell-activity-streams-type-01.txt
 Date: 11/10/2012
 Authors: James Snell
 Working Group: Individual Submissions (none)
 Formats: txt xml
This specification defines and registers the application/stream+json Content Type for the JSON Activity Streams format.
 Cryptographic Security Characteristics of 802.11 Wireless LAN Access Systems
 
 draft-orr-wlan-security-architectures-00.txt
 Date: 15/10/2012
 Authors: Stephen Orr, Anthony Grieco, Dan Harkins
 Working Group: Individual Submissions (none)
 Formats: xml txt
This note identifies all of the places that cryptography is used in Wireless Local Area Network (WLAN) architectures, to simplify the task of selecting the protocols, algorithms, and key sizes needed to achieve a consistent security level across the entire architecture.
 Observations on the experience and nature of Large Interim Meetings
 
 draft-jaeggli-interim-observations-04.txt
 Date: 14/01/2013
 Authors: Joel Jaeggli, Jari Arkko
 Working Group: Individual Submissions (none)
 Formats: xml txt
Planning, particpipation and conclusions from the experience of participating in the IETF LIM activity on september 29th 2012.
 I-PAKE: Identity-Based Password Authenticated Key Exchange
 
 draft-kwon-yoon-kim-ipake-01.txt
 Date: 03/05/2013
 Authors: Taekyoung Kwon, Hyojin Yoon, Sang Kim
 Working Group: Individual Submissions (none)
 Formats: txt
Although password authentication is the most widespread user authentication method today, cryptographic protocols for mutual authentication and key agreement, i.e., password authenticated key exchange (PAKE), in particular authenticated key exchange (AKE) based on a password only, are not actively used in the real world. This document introduces a quite novel form of PAKE protocols that employ a particular concept of ID-based encryption (IBE). The resulting cryptographic protocol is the ID-based password authenticated key exchange (I-PAKE) protocol which is a secure and efficient PAKE protocol in both soft- and hard-augmented models. I-PAKE achieves the security goals of AKE, PAKE, and hard-augmented PAKE. I-PAKE also achieves the great efficiency by allowing the whole pre-computation of the ephemeral Diffie-Hellman public keys by both server and client.
 remoteStorage
 
 draft-dejong-remotestorage-16.txt
 Date: 11/12/2020
 Authors: Michiel de Jong, F. Kooman, S. Kippe
 Working Group: Individual Submissions (none)
 Formats: txt
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.
 Ruoska Encoding
 
 draft-ruoska-encoding-06.txt
 Date: 12/10/2013
 Authors: Jukka-Pekka Makela
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes hierarchically structured binary encoding format called Ruoska Encoding (later RSK). The main design goals are minimal resource usage, well defined structure with good selection of widely known data types, and still extendable for future usage. The main benefit when compared to non binary hierarchically structured formats like XML is simplicity and minimal resource demands. Even basic XML parsing is time and memory consuming operation. When compared to other binary formats like BER encoding of ASN.1 the main benefit is simplicity. ASN.1 with many different encodings is complex and even simple implementation needs a lot of effort. RSK is also more efficient than BER.
 ICANN Registry Interfaces
 
 draft-lozano-icann-registry-interfaces-14.txt
 Date: 04/01/2021
 Authors: Gustavo Ibarra, Eduardo Alvarez
 Working Group: Individual Submissions (none)
 Formats: txt
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 also described in this document.
 Binary Encodings for JavaScript Object Notation: JSON-B,JSON-C,JSON-D
 
 draft-hallambaker-jsonbcd-20.txt
 Date: 13/01/2021
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: xml html txt
Three binary encodings for JavaScript Object Notation (JSON) are presented. JSON-B (Binary) is a strict superset of the JSON encoding that permits efficient binary encoding of intrinsic JavaScript data types. JSON-C (Compact) is a strict superset of JSON-B that supports compact representation of repeated data strings with short numeric codes. JSON-D (Data) supports additional binary data types for integer and floating-point representations for use in scientific applications where conversion between binary and decimal representations would cause a loss of precision. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-jsonbcd.html.
 QoS-level aware Transmission Protocol (QTP) for virtual networks
 
 draft-lan-nvo3-qtp-13.txt
 Date: 28/03/2021
 Authors: Julong Lan, Dongnian Cheng, Yuxiang Hu, Guozhen Cheng, Tong Duan
 Working Group: Individual Submissions (none)
 Formats: txt
This document provides a QoS-level aware Transmission Protocol (QTP) for virtual networks.
 Multicast Traceroute for MVPNs
 
 draft-kebler-kurapati-l3vpn-mvpn-mtrace-06.txt
 Date: 10/12/2020
 Authors: Robert Kebler, Pavan Kurapati, Saud Asif, Mankamana Mishra, Stig Venaas
 Working Group: Individual Submissions (none)
 Formats: xml txt
Mtrace is a tool used to troubleshoot issues in a network deploying Multicast service. When multicast is used within a VPN service offering, the base Mtrace specification does not detect the failures. This document specifies a method of using multicast traceroute in a network offering Multicast in VPN service.
 Use of the WebSocket Protocol as a Transport for the Remote Framebuffer Protocol
 
 draft-realvnc-websocket-02.txt
 Date: 07/10/2013
 Authors: Nicholas Wilson
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Remote Framebuffer protocol (RFB) enables clients to connect to and control remote graphical resources. This document describes a transport for RFB using the WebSocket protocol, and defines a corresponding WebSocket subprotocol, enabling an RFB server to offer resources to clients with WebSocket connectivity, such as web- browsers.
 Metadata Query Protocol
 
 draft-young-md-query-14.txt
 Date: 12/01/2021
 Authors: Ian Young
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a simple protocol for retrieving metadata about named entities, or named collections of entities. The goal of the protocol is to profile various aspects of HTTP to allow requesters to rely on certain, rigorously defined, behaviour. This document is a product of the Research and Education Federations (REFEDS) Working Group process.
 MPLS Payload Protocol Identifier
 
 draft-xu-mpls-payload-protocol-identifier-08.txt
 Date: 22/12/2020
 Authors: Xiaohu Xu, Hamid Assarpour, Shaowen Ma, Francois Clad
 Working Group: Individual Submissions (none)
 Formats: txt xml
The MPLS label stack has no explicit protocol identifier field to indicate the protocol type of the MPLS payload. This document proposes a mechanism for containing a protocol identifier field within the MPLS packet, which is useful for any new encapsulation header (e.g., INT metadata) which may need to be encapsulated with an MPLS header.
 Ideas for a Next Generation of the Reliable Server Pooling Framework
 
 draft-dreibholz-rserpool-nextgen-ideas-15.txt
 Date: 13/03/2021
 Authors: Thomas Dreibholz
 Working Group: Individual Submissions (none)
 Formats: txt
This document collects some idea for a next generation of the Reliable Server Pooling framework.
 Extensions to PCEP for Distributing Label Cross Domains
 
 draft-chen-pce-label-x-domains-12.txt
 Date: 06/01/2021
 Authors: Huaimo Chen, Autumn Liu, Mehmet Toy, Vic liu
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies extensions to PCEP for distributing labels crossing domains for an inter-domain Point-to-Point (P2P) or Point- to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP).
 Informational Add-on for HTTP over the Secure Sockets Layer (SSL) Protocol and/or the Transport Layer Security (TLS) Protocol
 
 draft-hoehlhubmer-https-addon-07.txt
 Date: 25/11/2013
 Authors: Walter Hoehlhubmer
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes an Add-on for websites providing encrypted connectivity (HTTP over TLS). The Add-on has two parts, one for the Domain Name System (DNS) - storing the X.509 certificate hashes - and one for the webserver itself - an additional webpage providing specific informations.
 Generic Fault-Avoidance Routing Protocol for Data Center Networks
 
 draft-sl-rtgwg-far-dcn-15.txt
 Date: 26/11/2020
 Authors: Bin Liu, Yantao Sun, Jing Cheng, Yichen Zhang, Bhumip Khasnabish
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document proposes a generic routing method and protocol for a regular data center network, named as Fault-Avoidance Routing (FAR) protocol. FAR protocol provides a generic routing method for all types of regular topology network architectures that are proposed for large-scale cloud-based data centers over the past few years. FAR protocol is well designed to fully leverage the regularity in the topology and compute its routing table in a concise manner. Fat-tree is taken as an example architecture to illustrate how FAR protocol can be applied in real operational scenarios.
 SAML Profile for the Metadata Query Protocol
 
 draft-young-md-query-saml-14.txt
 Date: 12/01/2021
 Authors: Ian Young
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document profiles the Metadata Query Protocol for use with SAML metadata. This document is a product of the Research and Education Federations (REFEDS) Working Group process. Editorial Note (To be removed by RFC Editor before publication) Discussion of this draft takes place on the MDX mailing list (mdx@lists.iay.org.uk), which is accessed from [MDX.list]. XML versions, latest edits and the issues list for this document are available from [md-query]. The changes in this draft are summarized in Appendix A.15.
 Extensions to the Path Computation Element Protocol (PCEP) to Support Resource Sharing-based Path Computation
 
 draft-zhang-pce-resource-sharing-14.txt
 Date: 16/04/2021
 Authors: Xian Zhang, Haomian Zheng, Oscar de Dios, Victor Lopez, Yunbin Xu
 Working Group: Individual Submissions (none)
 Formats: txt
Resource sharing in a network means two or more Label Switched Paths (LSPs) use common pieces of resource along their paths. This can help save network resources and is useful in scenarios such as LSP recovery or when two LSPs do not need to be active at the same time. A Path Computation Element (PCE) is responsible for path computation with such requirement. Existing extensions to the Path Computation Element Protocol (PCEP) allow one path computation request for an LSP to be associated with other (existing) LSPs through the use of the PCEP Association Object. This document extends PCEP in order to support resource-sharing- based path computation as another use of the Association Object to enable better efficiency in the computation and in the resultant paths and network resource usage.
 Passive DNS - Common Output Format
 
 draft-dulaunoy-dnsop-passive-dns-cof-08.txt
 Date: 05/05/2021
 Authors: Alexandre Dulaunoy, Aaron Kaplan, Paul Vixie, Henry Stern
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes a common output format of Passive DNS Servers which clients can query. The output format description includes also in addition a common semantic for each Passive DNS system. By having multiple Passive DNS Systems adhere to the same output format for queries, users of multiple Passive DNS servers will be able to combine result sets easily.
 EAP-based Authentication Service for CoAP
 
 draft-marin-ace-wg-coap-eap-07.txt
 Date: 21/01/2021
 Authors: Rafael Marin-Lopez, Dan Garcia-Carrillo
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes an authentication service that uses EAP transported by means of CoAP messages with the following purposes: o Authenticate a CoAP-enabled device that enters a new security domain against a AAA infrastructure through a domain Controller. o Bootstrap key material to protect CoAP messages exchanged between them. o Enable the establishment of Security Associations between them.
 WebRTC Dependencies
 
 draft-jennings-rtcweb-deps-27.txt
 Date: 21/01/2021
 Authors: Cullen Jennings
 Working Group: Individual Submissions (none)
 Formats: txt
This draft will never be published as an RFC and is meant purely to help track the IETF dependencies from the W3C WebRTC documents.
 Just because it's an ID doesn't mean anything... at all...
 
 draft-wkumari-not-a-draft-13.txt
 Date: 29/04/2021
 Authors: Warren Kumari
 Working Group: Individual Submissions (none)
 Formats: txt
Anyone can publish an Internet Draft. This doesn't mean that the "IETF thinks" or that "the IETF is planning..." or anything similar.
 A JSON Encoding for HTTP Field Values
 
 draft-reschke-http-jfv-14.txt
 Date: 22/04/2021
 Authors: Julian Reschke
 Working Group: Individual Submissions (none)
 Formats: xml html txt
This document establishes a convention for use of JSON-encoded field values in new HTTP fields.
 Label Distribution Using ARP
 
 draft-kompella-mpls-larp-09.txt
 Date: 14/01/2021
 Authors: Kireeti Kompella, Balaji Rajagopalan, Reji Thomas
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes extensions to the Address Resolution Protocol to distribute MPLS labels for IPv4 and IPv6 host addresses. Distribution of labels via ARP enables simple plug-and-play operation of MPLS, which is key to deploying MPLS in data centers and enterprises.
 Ideas for a Next Generation of the Stream Control Transmission Protocol (SCTP)
 
 draft-dreibholz-tsvwg-sctp-nextgen-ideas-13.txt
 Date: 13/03/2021
 Authors: Thomas Dreibholz
 Working Group: Individual Submissions (none)
 Formats: txt
This document collects some ideas for a next generation of the Stream Control Transmission Protocol (SCTP) for further discussion. It is a result of lessons learned from more than one decade of SCTP deployment.
 Service Function Path Establishment
 
 draft-lan-sfp-establishment-11.txt
 Date: 28/03/2021
 Authors: Julong Lan, Yuxiang Hu, Guozhen Cheng, Peng Wang, Tong Duan
 Working Group: Individual Submissions (none)
 Formats: txt
Service Function Chain architecture leads to more adaptive network nodes. It allows splitting the network function into fine-grained build blocks --- service function, and combining the network functions into service function chain to formulate complicated services. Further, the service function chain should be instantiated by selecting the optimal instance from the candidates for each service function in it. This document discusses the required components during the instantiation of service function chain in the network.
 Application-Level Profile Semantics (ALPS)
 
 draft-amundsen-richardson-foster-alps-06.txt
 Date: 23/01/2021
 Authors: Mike Amundsen, Leonard Richardson, Mark Foster
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes ALPS, a data format for defining simple descriptions of application-level semantics, similar in complexity to HTML microformats. An ALPS document can be used as a profile to explain the application semantics of a document with an application- agnostic media type (such as HTML, HAL, Collection+JSON, Siren, etc.). This increases the reusability of profile documents across media types.
 Additional XML Security Uniform Resource Identifiers (URIs)
 
 draft-eastlake-rfc6931bis-xmlsec-uris-14.txt
 Date: 03/04/2021
 Authors: Donald Eastlake
 Working Group: Individual Submissions (none)
 Formats: txt
This document updates and corrects the IANA registry for the list of URIs intended for use with XML digital signatures, encryption, canonicalization, and key management. These URIs identify algorithms and types of information. This document corrects three errata against and obsoletes RFC 6931. The intent is to keep this draft alive while it accumulates updates until it seems reasonable to publish the next version.
 Egress Peer Engineering using BGP-LU
 
 draft-gredler-idr-bgplu-epe-13.txt
 Date: 28/12/2020
 Authors: Hannes Gredler, Kaliraj Vairavakkalai, Chandrasekar R, Balaji Rajagopalan, Ebben Aries, Luyuan Fang
 Working Group: Individual Submissions (none)
 Formats: xml txt
The MPLS source routing paradigm provides path control for both intra- and inter- Autonomous System (AS) traffic. RSVP-TE is utilized for intra-AS path control. This documents outlines how MPLS routers may use the BGP labeled unicast protocol (BGP-LU) for doing traffic-engineering on inter-AS links.
 Tetrys,an On-the-Fly Network Coding protocol
 
 draft-detchart-nwcrg-tetrys-06.txt
 Date: 05/12/2020
 Authors: Jonathan Detchart, Emmanuel Lochin, Jerome Lacan, Vincent Roca
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes Tetrys, an On-The-Fly Network Coding (NC) protocol that can be used to transport delay and loss-sensitive data over a lossy network. Tetrys can recover from erasures within an RTT-independent delay, thanks to the transmission of coded packets. It can be used for both unicast, multicast and anycast communications.
 Implementing Draft & Release and Draft & Review in Internet Mail
 
 draft-melnikov-email-draft-and-release-04.txt
 Date: 17/02/2021
 Authors: Alexey Melnikov
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes how draft messages intended for Draft & Release and Draft & Review environments can be represented in Internet Email.
 Encapsulating IP in UDP
 
 draft-xu-intarea-ip-in-udp-10.txt
 Date: 22/12/2020
 Authors: Xiaohu Xu, Hamid Assarpour, Shaowen Ma, daniel.bernier@bell.ca, Darren Dukes, Shraddha Hegde, Yiu Lee, Fan Yongbing
 Working Group: Individual Submissions (none)
 Formats: txt xml
Existing IP-in-IP encapsulation technologies are not adequate for efficient load balancing of IP-in-IP traffic across IP networks. This document specifies additional IP-in-IP encapsulation technology, referred to as IP-in-UDP (User Datagram Protocol), which can facilitate the load balancing of IP-in-IP traffic across IP networks.
 TLS Client Authentication via DANE TLSA records
 
 draft-huque-dane-client-cert-06.txt
 Date: 02/05/2021
 Authors: Shumon Huque, Viktor Dukhovni, Ash Wilson
 Working Group: Individual Submissions (none)
 Formats: txt
The DANE TLSA protocol [RFC6698] [RFC7671] describes how to publish Transport Layer Security (TLS) server certificates or public keys in the DNS. This document updates RFC 6698 and RFC 7671. It describes how to additionally use the TLSA record to publish client certificates or public keys, and also the rules and considerations for using them with TLS.
 Bidirectional Forwarding Detection (BFD) for Multi-point Networks and Virtual Router Redundancy Protocol (VRRP) Use Case
 
 draft-mirsky-bfd-p2mp-vrrp-use-case-06.txt
 Date: 26/03/2021
 Authors: Greg Mirsky, Jeff Tantsura, Gyan Mishra
 Working Group: Individual Submissions (none)
 Formats: xml txt html
This document discusses the use of Bidirectional Forwarding Detection (BFD) for multipoint networks to provide Virtual Router Redundancy Protocol (VRRP) with sub-second Master convergence and defines the extension to bootstrap point-to-multipoint BFD session. This draft updates RFC 5798.
 LISP support for Multi-Tuple EIDs
 
 draft-rodrigueznatal-lisp-multi-tuple-eids-11.txt
 Date: 07/04/2021
 Authors: AlbertoRodriguezNatal, Albert Cabellos-Aparicio, Sharon Barkai, Vina Ermagan, Darrel Lewis, Fabio Maino, Dino Farinacci
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes extensions for LISP to support EIDs based on tuples of multiple elements.
 LISP Map Server Reliable Transport
 
 draft-kouvelas-lisp-map-server-reliable-transport-06.txt
 Date: 26/04/2021
 Authors: Johnson Leong, Darrel Lewis, Balaji Venkatachalapathy, Chris Cassar, Isidor Kouvelas, Jesus Arango
 Working Group: Individual Submissions (none)
 Formats: xml txt
The communication between LISP ETRs and Map-Servers is based on unreliable UDP message exchange coupled with periodic message transmission in order to maintain soft state. The drawback of periodic messaging is the constant load imposed on both the ETR and the Map-Server. New use cases for LISP have increased the amount of state that needs to be communicated with requirements that are not satisfied by the current mechanism. This document introduces the use of a reliable transport for ETR to Map-Server communication in order to eliminate the periodic messaging overhead, while providing reliability, flow-control and endpoint liveness detection.
 SMTP Service Extension for Client Identity
 
 draft-storey-smtp-client-id-10.txt
 Date: 07/12/2020
 Authors: William Storey
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines an extension for the Simple Mail Transfer Protocol (SMTP) called "CLIENTID" to provide a method for clients to indicate an identity to the server. This identity is an additional token that may be used for security and/or informational purposes, and with it a server may optionally apply heuristics using this token.
 Tunnel Segment in Segment Routing
 
 draft-li-spring-tunnel-segment-02.txt
 Date: 14/04/2021
 Authors: Zhenbin Li, Cheng Li, Nan Wu
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document introduces a new type of segment, Tunnel Segment, for the segment routing (SR). Tunnel segment can be used to reduce SID stack depth of SR path, span the non-SR domain or provide differentiated services. Forwarding mechanisms and requirements of control plane and data models for tunnel segments are also defined.
 PCEP extensions for Distribution of Link-State and TE Information
 
 draft-dhodylee-pce-pcep-ls-20.txt
 Date: 20/02/2021
 Authors: Dhruv Dhody, Shuping Peng, Young Lee, Daniele Ceccarelli, Aijun Wang, Gyan Mishra
 Working Group: Individual Submissions (none)
 Formats: xml txt
In order to compute and provide optimal paths, a Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). Traditionally, this TED has been obtained from a link state (LS) routing protocol supporting the traffic engineering extensions. This document extends the Path Computation Element Communication Protocol (PCEP) with Link-State and TE Information as an experimental extension.
 MS-originated SMRs
 
 draft-rodrigueznatal-lisp-ms-smr-12.txt
 Date: 07/04/2021
 Authors: AlbertoRodriguezNatal, Albert Cabellos-Aparicio, Vina Ermagan, Fabio Maino, Sharon Barkai
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document extends [I-D.ietf-lisp-rfc6833bis] to allow Map Servers to send SMR messages. This extension is intended to be used in some SDN deployments that use LISP as a southbound protocol with (P)ITRs that are compliant with [I-D.ietf-lisp-rfc6833bis]. In this use-case mapping updates do not come from ETRs, but rather from a centralized controller that pushes the updates directly to the Mapping System. In such deployments, Map Servers will benefit from having a mechanism to inform directly (P)ITRs about updates in the mappings they are serving. Although implementations of this extension exist, this extension is deprecated by [I-D.ietf-lisp-pubsub] and it is being documented for informational purposes. Newer implementations should look into [I-D.ietf-lisp-pubsub] to support PubSub in LISP deployments.
 Node Potential Oriented Multi-NextHop Routing Protocol
 
 draft-lanzhangwang-rtgwg-npmnrp-11.txt
 Date: 28/03/2021
 Authors: Julong Lan, Jianhui Zhang, Bin Wang, Wenfen Liu, Tong Duan
 Working Group: Individual Submissions (none)
 Formats: txt
The Node Potential Oriented Multi-Nexthop Routing Protocol (NP-MNRP) bases on the idea of "hop-by-hop routing forwarding, multi-backup next hop" and combines with the phenomena that water flows from higher place to lower. NP-MNRP defines a metric named as node potential, which is based on hop count and the actual link bandwidth, and calculates multiple next-hops through the potential difference between the nodes.
 PCEP Extensions for BIER-TE
 
 draft-chen-pce-bier-08.txt
 Date: 24/11/2020
 Authors: Ran Chen, Zheng Zhang, Senthil Dhanaraj, Fengwei Qin
 Working Group: Individual Submissions (none)
 Formats: txt
Bit Index Explicit Replication (BIER)-TE shares architecture and packet formats with BIER as described in [RFC8279]. BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies as described in [I-D.ietf-bier-te-arch].BIER-TE Path can be derived from a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Protocol (PCEP) that allow a PCE to compute and initiate the path for the BIER-TE.
 Multiple Ethernet - IPv6 address mapping encapsulation - fixed prefix
 
 draft-matsuhira-me6e-fp-10.txt
 Date: 14/12/2020
 Authors: Naoki Matsuhira
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies Multiple Ethernet - IPv6 address mapping encapsulation - fixed prefix (ME6E-FP) base specification. ME6E-FP makes expantion ethernet network over IPv6 backbone network with encapsuation technoogy. And also, E6ME-FP can stack multiple Ethernet networks. ME6E-FP work on own routing domain.
 Multiple Ethernet - IPv6 address mapping encapsulation - prefix resolution
 
 draft-matsuhira-me6e-pr-10.txt
 Date: 14/12/2020
 Authors: Naoki Matsuhira
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies Multiple Ethernet - IPv6 address mapping encapsulation - Prefix Resolution (ME6E-PR) specification. ME6E-PR makes expantion ethernet network over IPv6 backbone network with encapsuation technoogy. And also, E6ME-PR can stack multiple Ethernet networks. ME6E-PR work on non own routing domain.
 BGP Extensions for Enhanced VPN Auto Discovery
 
 draft-zhuang-bess-enhanced-vpn-auto-discovery-07.txt
 Date: 10/01/2021
 Authors: Shunwan Zhuang, Zhenbin Li, Donald Eastlake, Lucy Yong
 Working Group: Individual Submissions (none)
 Formats: txt
A variety of VPN technologies have been widely deployed to bear different services. As new applications develop, a requirement has been proposed for auto-discovery of Layer 3 Virtual Private Networks (L3VPN) and enhanced auto-discovery requirements for other VPN technologies that already have basic auto-discovery mechanisms. This document identifies some possible applications of these auto- discovery requirements and defines a new BGP NLRI, called the BGP- VPN-INSTANCE NLRI, to satisfy the requirement for auto-discovery of BGP VPN instances. It also defines a new type of extended community, called the Import Route Target, which can be applied to auto- discovery mechanisms of multiple VPN technologies.
 BGP Extensions for IDs Allocation
 
 draft-wu-idr-bgp-segment-allocation-ext-07.txt
 Date: 29/04/2021
 Authors: Huaimo Chen, Zhenbin Li, Zhenqiang Li, Yanhe Fan, Mehmet Toy, Lei Liu
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes extensions to the BGP for IDs allocation. The IDs are SIDs for segment routing (SR), including SR for IPv6 (SRv6). They are distributed to their domains if needed.
 IPv6 Prefix Delegation and Multi-Addressing Models
 
 draft-templin-v6ops-pdhost-27.txt
 Date: 01/01/2021
 Authors: Fred Templin
 Working Group: Individual Submissions (none)
 Formats: xml txt
Requesting nodes typically acquire IPv6 prefixes from a prefix delegation service for the network. The requesting node can provision the prefix according to whether it acts as a router on behalf of any downstream networks and/or as a host on behalf of its local applications. In the latter case, the requesting node can use portions of the delegated prefix for its own multi-addressing purposes. This document therefore considers prefix delegation models for both the classic routing and various multi-addressing use cases.
 Using compression in the Internet Key Exchange Protocol Version 2 (IKEv2)
 
 draft-smyslov-ipsecme-ikev2-compression-11.txt
 Date: 21/02/2021
 Authors: Valery Smyslov
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a method for reducing the size of the IKEv2 messages by using lossless compression. Making IKEv2 messages smaller is desirable for low power consumption battery powered devices. It also helps to avoid IP fragmentation of IKEv2 messages. This document describes how compression is negotiated maintaining backward compatibility and how it is used in IKEv2.
 A MILP Model to Solve the Problem of Loading Balance of Routing and Wavelength Assignment for Optical Transport Networks
 
 draft-yin-milp-rwa-otn-12.txt
 Date: 22/04/2021
 Authors: Shan Yin, Shanguo Huang, Dajiang Wang, Xuan Wang, Yu Zhang
 Working Group: Individual Submissions (none)
 Formats: txt
The RWA problem can be formulated as a Mixed-Integer linear program. Load balancing is a key factor for the optical transport networks. However, the existed approaches using mixed-Integer linear program to solve the RWA problem are not perfect enough without considering the load balancing of the networks. This documentary provides a model of Mixed-Integer Linear Programming to solve the problem of load balancing needed by routing and wavelength assignment (RWA) process in optical transport networks.
 TLS Extension for DANE Client Identity
 
 draft-huque-tls-dane-clientid-04.txt
 Date: 30/12/2020
 Authors: Shumon Huque, Viktor Dukhovni, Ash Wilson
 Working Group: Individual Submissions (none)
 Formats: txt html xml
This document specifies a TLS and DTLS extension to convey a DNS- Based Authentication of Named Entities (DANE) Client Identity to a TLS or DTLS server. This is useful for applications that perform TLS client authentication via DANE TLSA records.
 Mathematical Mesh 3.0 Part I: Architecture Guide
 
 draft-hallambaker-mesh-architecture-16.txt
 Date: 13/01/2021
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt html xml
The Mathematical Mesh is a Threshold Key Infrastructure that makes computers easier to use by making them more secure. Application of threshold cryptography to key generation and use enables users to make use of public key cryptography across multiple devices with minimal impact on the user experience. This document provides an overview of the Mesh data structures, protocols and examples of its use. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh- architecture.html.
 Multiple IPv4 - IPv6 mapped IPv6 address (M46A)
 
 draft-matsuhira-m46a-09.txt
 Date: 14/12/2020
 Authors: Naoki Matsuhira
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies Multiple IPv4 - IPv6 mapped IPv6 address(M46A) spefification. M46A is IPv4 mapped IPv6 address with plane ID. Unique allocation of plane id value enable IPv4 private address unique in IPv6 address space. This address may use IPv4 over IPv6 encapsulation and IPv4 - IPv6 translation.
 Multiple IPv4 - IPv6 address mapping encapsulation - fixed prefix (M46E-FP)
 
 draft-matsuhira-m46e-fp-09.txt
 Date: 14/12/2020
 Authors: Naoki Matsuhira
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies Multiple IPv4 - IPv6 address mapping encapsulation - fixed prefix (M46E-FP) specification. M46E-FP makes backbone network to IPv6 only. And also, M46E-FP can stack many IPv4 networks, i.e. the networks using same IPv4 (private) addresses, without interdependence.
 Multiple IPv4 - IPv6 address mapping encapsulation - prefix resolution (M46E-PR)
 
 draft-matsuhira-m46e-pr-09.txt
 Date: 14/12/2020
 Authors: Naoki Matsuhira
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies M46E Prefix Resolution (M46E-PR) specification. M46E-PR connect IPv4 stub networks between IPv6 backbone network. And also, M46E-PR can stack many IPv4 networks, i.e. the nwtworks using same IPv4 private addresses without interdependence.
 Multiple IPv4 - IPv6 address mapping encapsulation - prefix translator (M46E-PT)
 
 draft-matsuhira-m46e-pt-09.txt
 Date: 14/12/2020
 Authors: Naoki Matsuhira
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies Multiple IPv4 - IPv6 mapping encapsulation - Prefix Translator (M46E-PT) specification. M46E-PT expand IPv4 network plane by connecting M46E-FP domain and M46E-PR domain. M46E- PT translate prefix part of M46E-FP address and M46E-PR address both are IPv6 address. M46E-PT does not translate IPv4 packet which is encapsulated, so transparency of IPv4 packet is not broken.
 Multiple IPv4 - IPv6 address mapping translator (M46T)
 
 draft-matsuhira-m46t-09.txt
 Date: 14/12/2020
 Authors: Naoki Matsuhira
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies Multiple IPv4 - IPv6 address mapping Translator (M46T) specification. M46T enable access to IPv4 only host from IPv6 host. IPv4 host is identified as M46 address in IPv6 address space. The address assigned to IPv4 host may be global IPv4 address or private IPv4 address. M46T does not support access to IPv6 host from IPv4 only host.
 Multiple IPv4 address and port number - IPv6 address mapping encapsulation (M4P6E)
 
 draft-matsuhira-m4p6e-09.txt
 Date: 14/12/2020
 Authors: Naoki Matsuhira
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies Multiple IPv4 address and port number - IPv6 address mapping encapulation (M4P6E) specification.
 Multi-Stage Transparent Server Load Balancing
 
 draft-matsuhira-mslb-09.txt
 Date: 14/12/2020
 Authors: Naoki Matsuhira
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies Multi-Stage Transparent Server Load Balancing (MSLB) specification. MSLB make server load balancing over Layer3 network without packet header change at client and server. MSLB make server load balancing with any protocol and protocol with encription such as IPsec ESP, SSL/TLS.
 Conveying Vendor-Specific Information in the Path Computation Element (PCE) Communication Protocol (PCEP) extensions for Stateful PCE.
 
 draft-dhody-pce-stateful-pce-vendor-12.txt
 Date: 04/05/2021
 Authors: Cheng Li, Haomian Zheng, Siva Sivabalan, Samuel Sidor, Zafar Ali
 Working Group: Individual Submissions (none)
 Formats: txt xml
A Stateful Path Computation Element (PCE) maintains information on the current network state, including: computed Label Switched Path (LSPs), reserved resources within the network, and the pending path computation requests. This information may then be considered when computing new traffic engineered LSPs, and for the associated and the dependent LSPs, received from a Path Computation Client (PCC). RFC 7470 defines a facility to carry vendor-specific information in Path Computation Element Communication Protocol (PCEP). This document extends this capability for the Stateful PCEP messages.
 LISP Distinguished Name Encoding
 
 draft-farinacci-lisp-name-encoding-11.txt
 Date: 14/11/2020
 Authors: Dino Farinacci
 Working Group: Individual Submissions (none)
 Formats: txt
This draft defines how to use the AFI=17 Distinguished Names in LISP.
 LISP Geo-Coordinate Use-Cases
 
 draft-farinacci-lisp-geo-11.txt
 Date: 29/03/2021
 Authors: Dino Farinacci
 Working Group: Individual Submissions (none)
 Formats: txt
This draft describes how Geo-Coordinates can be used in the LISP Architecture and Protocols.
 Multiple Ethernet - IPv6 mapped IPv6 address (ME6A)
 
 draft-matsuhira-me6a-09.txt
 Date: 14/12/2020
 Authors: Naoki Matsuhira
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies Multiple Ethernet - IPv6 mapped IPv6 address(ME6A) spefification. ME6A is Ethernet mapped IPv6 address with plane ID. Unique allocation of plane id value enable duplicated MAC address unique in IPv6 address space. This address may use Ethernet over IPv6 encapsulation.
 OpenPGP Web Key Directory
 
 draft-koch-openpgp-webkey-service-11.txt
 Date: 17/11/2020
 Authors: Werner Koch
 Working Group: Individual Submissions (none)
 Formats: txt xml
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.
 IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters
 
 draft-eastlake-rfc7042bis-04.txt
 Date: 16/03/2021
 Authors: Donald Eastlake, Joe Abley
 Working Group: Individual Submissions (none)
 Formats: txt
Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses several uses of such parameters in IETF protocols, specifies IANA considerations for assignment of points under the IANA OUI (Organizationally Unique Identifier), and provides some values for use in documentation. This document obsoletes RFC 7042.
 Hierarchical PCE Determination
 
 draft-chen-pce-h-discovery-08.txt
 Date: 06/01/2021
 Authors: Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei Liu, Zhenqiang Li
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for determining parent child relations and exchanging the information between a parent and a child PCE in a hierarchical PCE system.
 PCEP Link State Abstraction
 
 draft-chen-pce-h-connect-access-08.txt
 Date: 06/01/2021
 Authors: Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei Liu, Zhenqiang Li
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a child PCE to abstract its domain information to its parent for supporting a hierarchical PCE system.
 Static PCEP Link State
 
 draft-chen-pce-pcc-ted-08.txt
 Date: 06/01/2021
 Authors: Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei Liu, Zhenqiang Li
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to advertise the information about the links without running IGP and for a PCE to build a TED based on the information received.
 Flow Classification in Information Centric Networking
 
 draft-moiseenko-icnrg-flowclass-07.txt
 Date: 13/01/2021
 Authors: Ilya Moiseenko, David Oran
 Working Group: Individual Submissions (none)
 Formats: txt xml
For the ubiquitous and highly important Internet protocols (TCP, UDP, IP), flows are conventionally identified by the "5-tuple" of source and destination IP addresses, source and destination port, and protocol type in an IP packet. Information Centric Networking (ICN) is a new paradigm where network communications are accomplished by requesting named content, instead of sending packets to destination addresses. This document describes mechanisms allowing ICN forwarders, consumers, producers and other ICN nodes to encode, decode, and process equivalence class identifiers (flows) at any desired granularity of a routable name prefix and beyond the routable name prefix. This document is a product of the IRTF Information- Centric Networking Research Group (ICNRG).
 Compact Format of IKEv2 Payloads
 
 draft-smyslov-ipsecme-ikev2-compact-09.txt
 Date: 18/03/2021
 Authors: Valery Smyslov
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a method for reducing the size of the Internet Key Exchange version 2 (IKEv2) messages by using an alternative format for IKE payloads. Standard format of many IKE payloads contains a lot of redundancy. This document takes advantage of this fact and specifies a way to eliminate some redundancy by using denser encoding. Reducing size of IKEv2 messages is desirable for low power consumption battery powered devices. It also helps to avoid IP fragmentation of IKEv2 messages.
 MISP core format
 
 draft-dulaunoy-misp-core-format-13.txt
 Date: 24/12/2020
 Authors: Alexandre Dulaunoy, Andras Iklody
 Working Group: Individual Submissions (none)
 Formats: txt xml
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.
 Inter Stateful Path Computation Element (PCE) Communication Procedures.
 
 draft-litkowski-pce-state-sync-10.txt
 Date: 22/02/2021
 Authors: Stephane Litkowski, Siva Sivabalan, Cheng Li, Haomian Zheng
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computation in response to a Path Computation Client (PCC) request. The Stateful PCE extensions allow stateful control of Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using PCEP. A Path Computation Client (PCC) can synchronize an LSP state information to a Stateful Path Computation Element (PCE). The stateful PCE extension allows a redundancy scenario where a PCC can have redundant PCEP sessions towards multiple PCEs. In such a case, a PCC gives control of a LSP to only a single PCE, and only one PCE is responsible for path computation for this delegated LSP. There are some use cases, where an inter-PCE stateful communication can bring additional resiliency in the design, for instance when some PCC-PCE session fails. The inter-PCE stateful communication may also provide a faster update of the LSP states when such an event occurs. Finally, when, in a redundant PCE scenario, there is a need to compute a set of paths that are part of a group (so there is a dependency between the paths), there may be some cases where the computation of all paths in the group is not handled by the same PCE: this situation is called a split-brain. This split-brain scenario may lead to computation loops between PCEs or suboptimal path computation. This document describes the procedures to allow a stateful communication between PCEs for various use-cases and also the procedures to prevent computations loops.
 Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems to manage the application code of optical interface parameters in DWDM application
 
 draft-ggalimbe-ccamp-flex-if-lmp-11.txt
 Date: 18/11/2020
 Authors: Dharini Hiremagalur, Gert Grammel, Gabriele Galimberti, Ruediger Kunze
 Working Group: Individual Submissions (none)
 Formats: txt
This experimental memo defines extensions to LMP(rfc4209) for managing Optical parameters associated with Wavelength Division Multiplexing (WDM) adding a set of parameters related to multicarrier DWDM interfaces to be used in Spectrum Switched Optical Networks (sson).
 BIER in BABEL
 
 draft-zhang-bier-babel-extensions-04.txt
 Date: 15/11/2020
 Authors: Zheng Zhang, Tony Przygienda
 Working Group: Individual Submissions (none)
 Formats: txt xml
BIER introduces a novel multicast architecture. It does not require a signaling protocol to explicitly build multicast distribution trees, nor does it require intermediate nodes to maintain any per- flow state. Babel defines a distance-vector routing protocol that operates in a robust and efficient fashion both in wired as well as in wireless mesh networks. This document defines a way to carry necessary BIER signaling information in Babel.
 Encapsulating IPsec ESP in UDP for Load-balancing
 
 draft-xu-ipsecme-esp-in-udp-lb-07.txt
 Date: 22/12/2020
 Authors: Xiaohu Xu, Shraddha Hegde, Boris Pismenny, Dacheng Zhang, Liang Xia
 Working Group: Individual Submissions (none)
 Formats: xml txt
IPsec Virtual Private Network (VPN) is widely used by enterprises to interconnect their geographical dispersed branch office locations across the Wide Area Network (WAN) or the Internet, especially in the Software-Defined-WAN (SD-WAN) era. In addition, IPsec is also increasingly used by cloud providers to encrypt IP traffic traversing data center networks and data center interconnect WANs so as to meet the security and compliance requirements, especially in financial cloud and governmental cloud environments. To fully utilize the bandwidth available in the data center network, the data center interconnect WAN or the Internet, load balancing of IPsec traffic over Equal Cost Multi-Path (ECMP) and/or Link Aggregation Group (LAG) is much attractive to those enterprises and cloud providers. This document defines a method to encapsulate IPsec Encapsulating Security Payload (ESP) packets over UDP tunnels for improving load-balancing of IPsec ESP traffic.
 Service Function Chaining Use Cases in Fog RAN
 
 draft-bernardos-sfc-fog-ran-09.txt
 Date: 22/03/2021
 Authors: Carlos Bernardos, Akbar Rahman, Alain Mourad
 Working Group: Individual Submissions (none)
 Formats: txt
Fog Radio Access Networks (RAN) refers to the part of the RAN that is virtualized at the very edge of the network, even at the end-user device. Fog RAN support is considered critical for the 5G mobile network architectures currently being developed in various research, standardization and industry forums. Since fog RAN builds on top of virtualization and can involve several virtual functions running on different virtualized resources, Service function chaining (SFC) support for the fog RAN will be critical. This document describes the overall fog RAN approach and also gives some use cases. Finally it proposes some requirements to be considered in the development of the SFC architecture and related protocols.
 Equal-Cost Multipath Considerations for BGP
 
 draft-lapukhov-bgp-ecmp-considerations-05.txt
 Date: 15/11/2020
 Authors: Petr Lapukhov, Jeff Tantsura
 Working Group: Individual Submissions (none)
 Formats: txt xml
BGP (Border Gateway Protocol) [RFC4271] employs tie-breaking logic to select a single best path among multiple paths available, known as BGP best path selection. At the same time, it has become a common practice to allow for "equal-cost multipath" (ECMP) selection and programming of multiple next-hops in routing tables. This document summarizes some common considerations for the ECMP logic when BGP is used as the routing protocol, with the intent of providing common reference for otherwise unstandardized set of features.
 Adaptive IPv4 Address Space
 
 draft-chen-ati-adaptive-ipv4-address-space-08.txt
 Date: 04/12/2020
 Authors: Abraham Chen, Ramamurthy Ati, Abhay Karandikar, David Crowe
 Working Group: Individual Submissions (none)
 Formats: txt
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 routers for interfacing between the Internet fabic (core plus edge routers) and the end user premises. Incorporating caching proxy technology in the gateway, a fairly large geographical region may enjoy address expansion based on as little 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 local IPv4 address shortage, while being transparent to the rest of the Internet. 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.
 Mobility Capability Negotiation and Protocol Selection
 
 draft-yan-dmm-man-08.txt
 Date: 16/03/2021
 Authors: Zhiwei Yan, Guanggang Geng, Jong-Hyouk Lee, Tao Huang
 Working Group: Individual Submissions (none)
 Formats: txt
Based on different requirements, multiple mobility management protocols have been developed. Different protocols have different functional requirements on the network element or the host and then a scheme should be used in order to support the negotiation and selection of adopted mobility management protocol when a host accesses to a new network. In this draft, this issue is analyzed.
 Network Service Header (NSH) Context Header Allocation: Timestamp
 
 draft-mymb-sfc-nsh-allocation-timestamp-08.txt
 Date: 17/02/2021
 Authors: Tal Mizrahi, Ilan Yerushalmi, David Melman, Rory Browne
 Working Group: Individual Submissions (none)
 Formats: txt
The Network Service Header (NSH) specification defines two possible methods of including metadata (MD): MD Type 0x1 and MD Type 0x2. MD Type 0x1 uses a fixed-length context header. The allocation of this context header, i.e., its structure and semantics, has not been standardized. This memo presents an allocation for the Context Headers of NSH, which incorporates the packet's timestamp, a sequence number, and a source interface identifier.
 Hypertext Transfer Protocol (HTTP) over multicast QUIC
 
 draft-pardue-quic-http-mcast-08.txt
 Date: 18/02/2021
 Authors: Lucas Pardue, Richard Bradbury, Sam Hurst
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a profile of the QUIC protocol and the HTTP/3 mapping that facilitates the transfer of HTTP resources over multicast IP using the QUIC transport as its framing and packetisation layer. Compatibility with the QUIC protocol's syntax and semantics is maintained as far as practical and additional features are specified where this is not possible.
 A Definition of the Term "Soon" for Use in Discussions with Working Group Chairs and Area Directors
 
 draft-farrel-soon-07.txt
 Date: 08/03/2021
 Authors: Adrian Farrel
 Working Group: Individual Submissions (none)
 Formats: txt xml
Many discussions with IETF Area Directors and Working Group Chairs utilize the word "Soon" to qualify a commitment to action. This document attempts to provide a definition of that term so that common expectations may be realistically set.
 RFC Style Guide
 
 draft-flanagan-7322bis-07.txt
 Date: 07/04/2021
 Authors: John Levine, RFC Editor
 Working Group: Individual Submissions (none)
 Formats: txt html xml
This document describes the fundamental and unique style conventions and editorial policies currently in use for the RFC Series. It captures the RFC Editor's basic requirements and offers guidance regarding the style and structure of an RFC. Additional guidance is captured on a website that reflects the experimental nature of that guidance and prepares it for future inclusion in the RFC Style Guide. This document obsoletes RFC 7322, "RFC Style Guide".
 Vehicular Neighbor Discovery for IP-Based Vehicular Networks
 
 draft-jeong-ipwave-vehicular-neighbor-discovery-11.txt
 Date: 21/02/2021
 Authors: Jaehoon Jeong, Yiwen Shen, Zhong Xiang, Sandra Cespedes
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies a Vehicular Neighbor Discovery (VND) as an extension of IPv6 Neighbor Discovery (ND) for IP-based vehicular networks. An optimized Address Registration and a multihop Duplicate Address Detection (DAD) mechanism are performed for having operation efficiency and also saving both wireless bandwidth and vehicle energy. In addition, three new ND options for prefix discovery, service discovery, and mobility information report are defined to announce the network prefixes and services inside a vehicle (i.e., a vehicle's internal network).
 DNS Name Autoconfiguration for Internet-of-Things Devices in IP-Based Vehicular Networks
 
 draft-jeong-ipwave-iot-dns-autoconf-10.txt
 Date: 21/02/2021
 Authors: Jaehoon Jeong, Sejun Lee, J., PARK
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies an autoconfiguration scheme for device discovery and service discovery in IP-based vehicular networks. Through the device discovery, this document supports the global (or local) DNS naming of Internet-of-Things (IoT) devices, such as sensors, actuators, and in-vehicle units. By this scheme, the DNS name of an IoT device can be autoconfigured with the device's model information in wired and wireless target networks (e.g., vehicle, road network, home, office, shopping mall, and smart grid). Through the service discovery, IoT users (e.g., drivers, passengers, home residents, and customers) in the Internet (or local network) can easily identify each device for monitoring and remote-controlling it in a target network.
 OSPF Extensions for Broadcast Inter-AS TE Link
 
 draft-chen-ospf-ias-lk-06.txt
 Date: 06/01/2021
 Authors: Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei Liu, Zhenqiang Li, Yi Yang
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document presents extensions to the Open Shortest Path First (OSPF) for advertising broadcast inter-AS Traffic Engineering (TE) links.
 ISIS Extensions for Broadcast Inter-AS TE Link
 
 draft-chen-isis-ias-lk-06.txt
 Date: 06/01/2021
 Authors: Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei Liu, Zhenqiang Li, Yi Yang
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document presents extensions to the ISIS protocol for advertising broadcast inter-AS Traffic Engineering (TE) links.
 BGP Logical Link Discovery Protocol (LLDP) Peer Discovery
 
 draft-acee-idr-lldp-peer-discovery-08.txt
 Date: 07/12/2020
 Authors: Acee Lindem, Keyur Patel, Shawn Zandi, Jeffrey Haas, Xiaohu Xu
 Working Group: Individual Submissions (none)
 Formats: txt
Link Layer Discovery Protocol (LLDP) or IEEE Std 802.1AB is implemented in networking equipment from many vendors. It is natural for IETF protocols to avail this protocol for simple discovery tasks. This document describes how BGP would use LLDP to discover directly connected and 2-hop peers when peering is based on loopback addresses.
 Deployments With Insertion of IPv6 Segment Routing Headers
 
 draft-voyer-6man-extension-header-insertion-10.txt
 Date: 20/11/2020
 Authors: Dan Voyer, Clarence Filsfils, Darren Dukes, Satoru Matsushima, John Leddy, Zhenbin Li, Jim Guichard
 Working Group: Individual Submissions (none)
 Formats: xml txt
SRv6 is deployed in multiple provider networks. This document describes the usage of SRH insertion and deletion within the SR domain and how security and end-to-end integrity is guaranteed.
 NEAT Sockets API
 
 draft-dreibholz-taps-neat-socketapi-08.txt
 Date: 02/02/2021
 Authors: Thomas Dreibholz
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a BSD Sockets-like API on top of the callback-based NEAT User API. This facilitates porting existing applications to use a subset of NEAT's functionality.
 Service and Neighbor Vehicle Discovery in IPv6-Based Vehicular Networks
 
 draft-yan-ipwave-nd-07.txt
 Date: 15/11/2020
 Authors: Zhiwei Yan, Jian Weng, Guanggang Geng, Jong-Hyouk Lee, Jaehoon Jeong
 Working Group: Individual Submissions (none)
 Formats: txt
For Cooperative Adaptive Cruise Control (C-ACC), platooning and other typical use cases in Intelligent Transportation System (ITS), IPv6 communication between neighbor vehicles and between vehicle and server pose the following two issues: 1) how to discover a neighbor vehicle and the demanded service; and 2) how to discover the link- layer address and other metadata of the neighbor vehicle and selected server. This document presents a solution to these problems based on DNS-SD/mDNS [RFC6762][RFC6763].
 Performance Measurement (PM) with Alternate Marking Method in Service Function Chaining (SFC) Domain
 
 draft-mirsky-sfc-pmamm-13.txt
 Date: 30/03/2021
 Authors: Greg Mirsky, Giuseppe Fioccola, Tal Mizrahi
 Working Group: Individual Submissions (none)
 Formats: txt html xml
This document describes how the alternate marking method can be used as the efficient performance measurement method taking advantage of the actual data flows in a Service Function Chaining (SFC) domain.
 BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP
 
 draft-mirsky-mpls-p2mp-bfd-14.txt
 Date: 30/03/2021
 Authors: Greg Mirsky, Gyan Mishra, Donald Eastlake
 Working Group: Individual Submissions (none)
 Formats: xml html txt
This document describes procedures for using Bidirectional Forwarding Detection (BFD) for multipoint networks to detect data plane failures in Multiprotocol Label Switching (MPLS) point-to-multipoint (p2mp) Label Switched Paths (LSPs) using active tails with unsolicited notifications mode. It also describes the applicability of LSP Ping, as in-band, and the control plane, as out-band, solutions to bootstrap a BFD session in this environment.
 Loop avoidance using Segment Routing
 
 draft-bashandy-rtgwg-segment-routing-uloop-10.txt
 Date: 25/12/2020
 Authors: Ahmed Bashandy, Clarence Filsfils, Stephane Litkowski, Bruno Decraene, Pierre Francois, Peter Psenak
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents a mechanism aimed at providing loop avoidance in the case of IGP network convergence event. The solution relies on the temporary use of SR policies ensuring loop-freeness over the post-convergence paths from the converging node to the destination.
 Responder Initiated IP Addresses Update in MOBIKE
 
 draft-smyslov-ipsecme-ikev2-r-mobike-07.txt
 Date: 29/11/2020
 Authors: Valery Smyslov
 Working Group: Individual Submissions (none)
 Formats: txt
IKEv2 Mobility and Multihoming Protocol (MOBIKE), defined in [RFC4555] allows peers to update their IP addresses without re- establishing IKE and IPsec Security Associations (SAs). In the MOBIKE protocol it is the Initiator of the IKE SA, who is responsible for selecting new SA addresses and for initiating the IP addresses update procedure. This document presents an extension to the MOBIKE protocol that allows the Responder to initiate IP address update. The document updates [RFC4555].
 Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Network Slicing
 
 draft-king-teas-applicability-actn-slicing-10.txt
 Date: 31/03/2021
 Authors: Daniel King, John Drake, Haomian Zheng, Adrian Farrel
 Working Group: Individual Submissions (none)
 Formats: xml txt
Network abstraction is a technique that can be applied to a network domain. It utilizes a set of policies to select network resources and obtain a view of potential connectivity across the network. Network slicing is an approach to network operations that builds on the concept of network abstraction to provide programmability, flexibility, and modularity. It may use techniques such as Software Defined Networking (SDN) and Network Function Virtualization (NFV) to create multiple logical or virtual networks, each tailored for a set of services that share the same set of requirements. Abstraction and Control of Traffic Engineered Networks (ACTN) is described in RFC 8453. It defines an SDN-based architecture that relies on the concept of network and service abstraction to detach network and service control from the underlying data plane. This document outlines the applicability of ACTN to network slicing in a Traffic Engineering (TE) network that utilizes IETF technology. It also identifies the features of network slicing not currently within the scope of ACTN, and indicates where ACTN might be extended.
 BFD in Demand Mode over Point-to-Point MPLS LSP
 
 draft-mirsky-bfd-mpls-demand-09.txt
 Date: 30/03/2021
 Authors: Greg Mirsky
 Working Group: Individual Submissions (none)
 Formats: txt xml html
This document describes procedures for using Bidirectional Forwarding Detection (BFD) in Demand mode to detect data plane failures in Multiprotocol Label Switching (MPLS) point-to-point Label Switched Paths.
 SFC OAM for path consistency
 
 draft-ao-sfc-oam-path-consistency-11.txt
 Date: 30/03/2021
 Authors: Greg Mirsky, Ting Ao, Zhonghua Chen, Kent Leung, Gyan Mishra
 Working Group: Individual Submissions (none)
 Formats: xml html txt
Service Function Chain (SFC) defines an ordered set of service functions (SFs) to be applied to packets and/or frames and/or flows selected due to classification. SFC Operation, Administration and Maintenance can monitor the continuity of the SFC, i.e., that all SFC elements are reachable to each other in the downstream direction. But SFC OAM must support verification that the order of traversing these SFs corresponds to the state defined by the SFC control plane or orchestrator, the metric referred to in this document as the path consistency of the SFC. This document defines a new SFC active OAM method to support SFC consistency check, i.e., verification that all elements of the given SFC are being traversed in the expected order.
 Controlled Return Path for Service Function Chain (SFC) OAM
 
 draft-ao-sfc-oam-return-path-specified-09.txt
 Date: 30/03/2021
 Authors: Greg Mirsky, Ting Ao, Zhonghua Chen, Gyan Mishra
 Working Group: Individual Submissions (none)
 Formats: html txt xml
This document defines an extension to the Service Function Chain (SFC) Operation, Administration and Maintenance (OAM) that enables control of the Echo Reply return path directing it over a Reverse Service Function Path. Enforcing the specific return path can be used to verify the bidirectional connectivity of SFC and increase the robustness of SFC OAM.
 MPT Network Layer Multipath Library
 
 draft-lencse-tsvwg-mpt-07.txt
 Date: 13/12/2020
 Authors: Gabor Lencse, Szabolcs Szilagyi, Ferenc Fejes, Marius Georgescu
 Working Group: Individual Submissions (none)
 Formats: txt
Although several contemporary IT devices have multiple network interfaces, communication sessions are restricted to use only one of them at a time due to the design of the TCP/IP protocol stack: the communication endpoint is identified by an IP address and a TCP or UDP port number. The simultaneous use of these multiple interfaces for a communication session would improve user experience through higher throughput and improved resilience to network failures. MPT is a network layer multipath solution, which provides a tunnel over multiple paths using the GRE-in-UDP specification, thus being different from both MPTCP and Huawei's GRE Tunnel Bonding Protocol. MPT can also be used as a router, routing the packets among several networks between the tunnel endpoints, thus establishing a multipath site-to-site connection. The version of tunnel IP and the version of path IP are independent from each other, therefore MPT can also be used for IPv6 transition purposes.
 Update to Private Header Field P-Visited-Network-ID in Session Initiation Protocol (SIP) Requests and Responses
 
 draft-jesske-update-p-visited-network-02.txt
 Date: 24/11/2020
 Authors: Roland Jesske
 Working Group: Individual Submissions (none)
 Formats: txt
The Third Generation Partnership Project (3GPP) has identified cases where the private header field P-Visited-Network-ID SIP private header extensions, which is defined in RFC 7315 and updated by RFC 7976, needs to be included in SIP requests and responses. This document updates RFC 7976, in order to allow inclusion of the P- Visited-Network-ID header field in responses.
 Problem Statement and Considerations for ROAs issued with Multiple Prefixes
 
 draft-yan-sidrops-roa-considerations-06.txt
 Date: 25/03/2021
 Authors: Zhiwei Yan, Randy Bush, Guanggang Geng, Jiankang Yao
 Working Group: Individual Submissions (none)
 Formats: txt
The address space holder needs to issue an ROA object when it authorizes one or more ASes to originate routes to multiple prefixes. During the process of ROA issuance, the address space holder needs to specify an origin AS for a list of IP prefixes. Besides, the address space holder has a free choice to put multiple prefixes into a single ROA or issue separate ROAs for each prefix based on the current specification. This memo analyzes and presents some operational problems which may be caused by the misconfigurations of ROAs containing multiple IP prefixes. Some suggestions and considerations also have been proposed.
 LISP for the Mobile Network
 
 draft-farinacci-lisp-mobile-network-11.txt
 Date: 01/04/2021
 Authors: Dino Farinacci, Padma Pillay-Esnault, Uma Chunduri
 Working Group: Individual Submissions (none)
 Formats: txt
This specification describes how the LISP architecture and protocols can be used in a LTE/5G mobile network to support session survivable EID mobility. A recommendation is provided to SDOs on how to integrate LISP into the mobile network.
 Reassignment of System Ports to the IESG
 
 draft-kuehlewind-system-ports-05.txt
 Date: 10/02/2020
 Authors: Mirja Kuehlewind, Sabrina Tanamal
 Working Group: Individual Submissions (none)
 Formats: xml txt
In the IANA Service Name and Transport Protocol Port Number Registry, a large number of System Ports are currently assigned to individuals or companies who have registered the port for the use with a certain protocol before RFC6335 was published. For some of these ports, RFCs exist that describe the respective protocol; for others, RFCs are under development that define, re-define, or assign the protocol used for the respective port, such as in case of so-far unused UDP ports that have been registered together with the respective TCP port. In these cases the IESG has the change control about the protocol used on the port (as described in the corresponding RFC) but change control for the port allocation iis designated to others. Under existing operational procedures, this means the original assignee needs to be involved in chnage to the port assignment. As it is not always possible to get in touch with the original assignee, particularly because of out-dated contact information, this current practice of handling historical allocation of System Ports does not scale well on a case-by-case basis. To address this, this document instructs IANA to perform actions with the goal to reassign System Ports to the IESG that were assigned to individuals prior to the publication of RFC6335, where appropriate.
 Guide for building an ECC pki
 
 draft-moskowitz-ecdsa-pki-10.txt
 Date: 31/01/2021
 Authors: Robert Moskowitz, Henk Birkholz, Liang Xia, Michael Richardson
 Working Group: Individual Submissions (none)
 Formats: xml txt
This memo provides a guide for building a PKI (Public Key Infrastructure) using openSSL. All certificates in this guide are ECDSA, P-256, with SHA256 certificates. Along with common End Entity certificates, this guide provides instructions for creating IEEE 802.1AR iDevID Secure Device certificates.
 IPv6 Source Routing for ultralow Latency
 
 draft-foglar-ipv6-ull-routing-08.txt
 Date: 22/01/2021
 Authors: Andreas Foglar, Mike Parker, Theodoros Rokkas
 Working Group: Individual Submissions (none)
 Formats: txt
This Internet-Draft describes a hierarchical addressing scheme for IPv6, intentionally very much simplified to allow for very fast source routing experimentation using simple forwarding nodes. Research groups evaluate achievable latency reduction for special applications such as radio access networks, industrial networks or other networks requiring very low latency.
 MISP object template format
 
 draft-dulaunoy-misp-object-template-format-04.txt
 Date: 05/01/2021
 Authors: Alexandre Dulaunoy, Andras Iklody
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the MISP object template format which describes a simple JSON format to represent the various templates used to construct MISP objects. A public directory of common vocabularies MISP object templates [MISP-O] is available and relies on the MISP object reference format.
 Simple Group Keying Protocol (SGKP)
 
 draft-ietf-trill-group-keying-07.txt
 Date: 10/01/2021
 Authors: Donald Eastlake, Dacheng Zhang
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a simple general group keying protocol that provides for the distribution of shared secret keys to group members and the management of such keys. It assumes that secure pairwise keys can be created between any two group members.
 Elliptic curve 2y^2=x^3+x over field size 8^91+5
 
 draft-brown-ec-2y2-x3-x-mod-8-to-91-plus-5-07.txt
 Date: 01/04/2021
 Authors: Daniel Brown
 Working Group: Individual Submissions (none)
 Formats: txt
Multi-curve elliptic curve cryptography with curve 2y^2=x^3+x/GF(8^91+5) hedges a risk of new curve-specific attacks. This curve features: isomorphism to Miller's curve from 1985; low Kolmogorov complexity (little room for embedded weaknesses of Gordon, Young--Yung, or Teske); similarity to a Bitcoin curve; Montgomery form; complex multiplication by i (Gallant--Lambert--Vanstone); prime field; easy reduction, inversion, Legendre symbol, and square root; five 64-bit-word field arithmetic; string-as-point encoding; and 34-byte keys.
 Clarifying Use of LSP Ping to Bootstrap BFD over MPLS LSP
 
 draft-mirsky-mpls-bfd-bootstrap-clarify-02.txt
 Date: 30/03/2021
 Authors: Greg Mirsky, Yanhua Zhao, Gyan Mishra
 Working Group: Individual Submissions (none)
 Formats: html txt xml
This document, if approved, updates RFC 5884 by clarifying procedures for using MPLS LSP ping to bootstrap Bidirectional Forwarding Detection (BFD) over MPLS Label Switch Path.
 A YANG Data Model for Client-layer Tunnel
 
 draft-zheng-ccamp-client-tunnel-yang-08.txt
 Date: 18/02/2021
 Authors: Haomian Zheng, Aihua Guo, Italo Busi, Yunbin Xu, Yang Zhao, Xufeng Liu
 Working Group: Individual Submissions (none)
 Formats: xml txt
A transport network is a server-layer network to provide connectivity services to its client. In this draft the tunnel of client is described, with the definition of client tunnel YANG model.
 Echo Request/Reply for Enabled In-situ OAM Capabilities
 
 draft-xiao-ippm-ioam-conf-state-08.txt
 Date: 20/01/2021
 Authors: Xiao Min, Greg Mirsky, Lei Bo
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes an extension to the echo request/reply mechanisms used in IPv6, MPLS and SFC environments, which can be used within an IOAM domain, allowing the IOAM encapsulating node to acquire the enabled IOAM capabilities of each IOAM transit node and/ or IOAM decapsulating node.
 AsciiRFC: Authoring Internet-Drafts And RFCs Using AsciiDoc
 
 draft-ribose-asciirfc-08.txt
 Date: 17/04/2018
 Authors: Ronald Tse, Nick Nicholas, Paolo Brasolin
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes an AsciiDoc syntax extension called AsciiRFC, designed for authoring IETF Internet-Drafts and RFCs. AsciiDoc is a human readable document markup language which affords more granular control over markup than comparable schemes such as Markdown. The AsciiRFC syntax is designed to allow the author to entirely focus on text, providing the full power of the resulting RFC XML through the AsciiDoc language, while abstracting away the need to manually edit XML, including references. This document itself was written and generated into RFC XML v2 (RFC7749) and RFC XML v3 (RFC7991) directly through asciidoctor-rfc, an AsciiRFC generator.
 A Unified Stateful/Stateless Configuration Service for IPv6
 
 draft-templin-6man-dhcpv6-ndopt-11.txt
 Date: 01/01/2021
 Authors: Fred Templin
 Working Group: Individual Submissions (none)
 Formats: txt xml
IPv6 Neighbor Discovery (IPv6ND) specifies a control message set for nodes to discover neighbors, routers, prefixes and other services on the link. It also supports a manner of StateLess Address AutoConfiguration (SLAAC), while the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) specifies a separate stateful service. This document presents IPv6ND extensions for providing a unified stateful/stateless configuration service.
 Ground-Based LISP for the Aeronautical Telecommunications Network
 
 draft-haindl-lisp-gb-atn-06.txt
 Date: 06/03/2021
 Authors: Bernhard Haindl, Manfred Lindner, Reshad Rahman, Marc Portoles-Comeras, Victor Moreno, Fabio Maino, Balaji Venkatachalapathy
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the use of the LISP architecture and protocols to address the requirements of the worldwide Aeronautical Telecommunications Network with Internet Protocol Services, as articulated by the International Civil Aviation Organization. The ground-based LISP overlay provides mobility and multi-homing services to the IPv6 networks hosted on commercial aircrafts, to support Air Traffic Management communications with Air Traffic Controllers and Air Operation Controllers. The proposed architecture doesn't require support for LISP protocol in the airborne routers, and can be easily deployed over existing ground infrastructures.
 HTTP Live Streaming 2nd Edition
 
 draft-pantos-hls-rfc8216bis-09.txt
 Date: 27/04/2021
 Authors: Roger Pantos
 Working Group: Individual Submissions (none)
 Formats: txt
This document obsoletes RFC 8216. It describes a protocol for transferring unbounded streams of multimedia data. It specifies the data format of the files and the actions to be taken by the server (sender) and the clients (receivers) of the streams. It describes version 10 of this protocol.
 A Decent LISP Mapping System (LISP-Decent)
 
 draft-farinacci-lisp-decent-07.txt
 Date: 08/03/2021
 Authors: Dino Farinacci, Colin Cantrell
 Working Group: Individual Submissions (none)
 Formats: txt
This draft describes how the LISP mapping system designed to be distributed for scale can also be decentralized for management and trust.
 Health Check Response Format for HTTP APIs
 
 draft-inadarei-api-health-check-05.txt
 Date: 18/11/2020
 Authors: Irakli Nadareishvili
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document proposes a service health check response format for HTTP APIs.
 A feature freezer for the Concise Data Definition Language (CDDL)
 
 draft-bormann-cbor-cddl-freezer-07.txt
 Date: 21/04/2021
 Authors: Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: txt html xml
In defining the Concise Data Definition Language (CDDL), some features have turned up that would be nice to have. In the interest of completing this specification in a timely manner, the present document was started to collect nice-to-have features that did not make it into the first RFC for CDDL, RFC 8610. It is now time to discuss thawing some of the concepts discussed here. A number of additional proposals have been added.
 Simple Group Keying Protocol TRILL Use Protfiles
 
 draft-ietf-trill-link-gk-profiles-06.txt
 Date: 10/01/2021
 Authors: Donald Eastlake, Dacheng Zhang
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies use profiles for the application of the simple group keying protocol (SGKP) to multi-destination TRILL Extended RBridge Channel message security (RFC 7978) and TRILL over IP packet security (draft-ietf-trill-over-ip).
 LURK Extension version 1 for (D)TLS 1.2 Authentication
 
 draft-mglt-lurk-tls12-04.txt
 Date: 25/01/2021
 Authors: Daniel Migault, Ioana Boureanu
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the LURK Extension 'tls12' which enables interactions between a LURK Client and a LURK Server in a context of authentication with (D)TLS 1.2.
 IPv4+ The Extended Protocol Based On IPv4
 
 draft-tang-ipv4plus-06.txt
 Date: 23/01/2021
 Authors: ZiQiang Tang
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies version 4+ of the Internet Protocol (IPv4+). IPv4 is very successful,simple and elegant. continuation and expansion of the IPv4 is necessary. Existing systems, devices only need to upgrade the software to support IPv4+, without the need to update new hardwares,saving investment costs. Ipv4+ is also an interstellar Protocol, so the Internet will evolve into a star Internet.
 Unified Identifier in IPv6 Segment Routing Networks
 
 draft-mirsky-6man-unified-id-sr-09.txt
 Date: 30/03/2021
 Authors: Weiqiang Cheng, Greg Mirsky, Shaofu Peng, Liu Aihua, Gyan Mishra
 Working Group: Individual Submissions (none)
 Formats: html txt xml
Segment Routing architecture leverages the paradigm of source routing. It can be realized in a network data plane by prepending the packet with a list of instructions, a.k.a. segments. A segment can be encoded as a Multi-Protocol Label Switching (MPLS) label, IPv4 address, or IPv6 address. Segment Routing can be applied in MPLS data plane by encoding segments in the MPLS label stack. It also can be applied to IPv6 data plane by encoding a list of segment identifiers in IPv6 Segment Routing Extension Header (SRH). This document extends the use of the SRH to unified segment identifiers encoded, for example, as MPLS label or IPv4 address, to compress the SRH, and support more detailed network programming and interworking between SR-MPLS and SRv6 domains.
 Hybrid Two-Step Performance Measurement Method
 
 draft-mirsky-ippm-hybrid-two-step-09.txt
 Date: 30/03/2021
 Authors: Greg Mirsky, Wang Lingqiang, Guo Zhui, Haoyu Song
 Working Group: Individual Submissions (none)
 Formats: xml txt html
Development of, and advancements in, automation of network operations brought new requirements for measurement methodology. Among them is the ability to collect instant network state as the packet being processed by the networking elements along its path through the domain. This document introduces a new hybrid measurement method, referred to as hybrid two-step, as it separates the act of measuring and/or calculating the performance metric from the act of collecting and transporting network state.
 Synchronizing Internet Clock frequency protocol (sic)
 
 draft-alavarez-hamelin-tictoc-sic-07.txt
 Date: 29/04/2021
 Authors: Jose Alvarez-Hamelin, David Samaniego, Alfredo Ortega, Ruediger Geib
 Working Group: Individual Submissions (none)
 Formats: txt xml
Synchronizing Internet Clock (sic) Frequency specifies a new secure method to synchronize clocks on the Internet, assuring smoothness (i.e., frequency stability) and robustness to man-in-the-middle attacks. This protocol is oriented to assure the quality of Internet Performance measurements, where they are frequently obtained as the difference of timestamps, hence frequency stability is needed. In 90% of all cases, Synchronized Internet Clock Frequency is highly accurate, with a Maximum Time Interval Error of fewer than 25 microseconds by a minute. Synchronized Internet Clock Frequency is based on a regular packet exchange and works with commodity terminal hardware.
 Extension for Stateful PCE to allow Optional Processing of PCEP Objects
 
 draft-dhody-pce-stateful-pce-optional-08.txt
 Date: 05/05/2021
 Authors: Cheng Li, Haomian Zheng, Stephane Litkowski
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document introduces a mechanism to mark some of the Path Computation Element (PCE) Communication Protocol (PCEP) objects as optional during PCEP messages exchange for the Stateful PCE model to allow relaxing some constraints. This document introduces this relaxation and updates RFC 8231.
 Hierarchy of IP Controllers (HIC)
 
 draft-li-teas-hierarchy-ip-controllers-07.txt
 Date: 28/04/2021
 Authors: Zhenbin Li, Dhruv Dhody, Huaimo Chen
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the interactions between various IP controllers in a hierarchical fashion to provide various IP services. It describes how the Abstraction and Control of Traffic Engineered Networks (ACTN) framework is applied to the Hierarchy of IP controllers (HIC) as well as document the interactions with other protocols like BGP, Path Computation Element Communication Protocol (PCEP) to provide end to end dynamic services spanning multiple domains and controllers (e.g. Layer 3 Virtual Private Network (L3VPN), Seamless MPLS etc).
 Multilinear Galois Mode (MGM)
 
 draft-smyshlyaev-mgm-20.txt
 Date: 12/04/2021
 Authors: Stanislav Smyshlyaev, Vladislav Nozdrunov, Vasily Shishkin, Ekaterina Griboedova
 Working Group: Individual Submissions (none)
 Formats: xml txt
Multilinear Galois Mode (MGM) is an authenticated encryption with associated data (AEAD) block cipher mode based on EtM principle. MGM is defined for use with 64-bit and 128-bit block ciphers. MGM has been standardized in Russia. It is used as an AEAD mode for the GOST block cipher algorithms in many protocols, e.g. TLS 1.3 and IPsec. This document provides a reference for MGM to enable review of the mechanisms in use and to make MGM available for use with any block cipher.
 Using Identity as Raw Public Key in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
 
 draft-wang-tls-raw-public-key-with-ibc-14.txt
 Date: 11/04/2021
 Authors: HAIGUANG Wang, Yanjiang Yang, Xin Kang, Zhaohui Cheng, chenmeiling
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies the use of identity as a raw public key in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The TLS protocol procedures are kept unchanged, but signature algorithms are extended to support Identity-based signature (IBS). A few Identity-based signature algorithms from different standard organizations are supported in the current version.
 Blockchain Transaction Protocol for Constraint Nodes
 
 draft-urien-core-blockchain-transaction-protocol-05.txt
 Date: 15/12/2020
 Authors: Pascal Urien
 Working Group: Individual Submissions (none)
 Formats: txt
The goal of the blockchain transaction protocol for constraint nodes is to enable the generation of blockchain transactions by constraint nodes, according to the following principles: - transactions are triggered by Provisioning-Messages that include the needed blockchain parameters. - binary encoded transactions are returned in Transaction-Messages, which include sensors/actuators data. Constraint nodes, associated with blockchain addresses, compute the transaction signature.
 Shared Brotli Compressed Data Format
 
 draft-vandevenne-shared-brotli-format-07.txt
 Date: 28/01/2021
 Authors: Jyrki Alakuijala, Thai Duong, Evgenii Kliuchnikov, Robert Obryk, Zoltan Szabadka, Lode Vandevenne
 Working Group: Individual Submissions (none)
 Formats: txt
This specification defines a data format for shared brotli compression, which adds support for shared dictionaries, large window, patching and a container format to brotli [RFC7932]. Shared dictionaries and large window support allow significant compression gains compared to regular brotli, and patching allows smaller patches of binary files.
 Cumulative DMZ Link Bandwidth and load-balancing
 
 draft-mohanty-bess-ebgp-dmz-03.txt
 Date: 15/03/2021
 Authors: satyamoh@cisco.com, Arie Vayner, Akshay Gattani, Ajay Kini
 Working Group: Individual Submissions (none)
 Formats: txt xml
The DMZ Link Bandwidth draft provides a way to load-balance traffic to a destination (which is in a different AS than the source) which is reachable via more than one path. Typically, the link bandwidth (either configured on the link of the EBGP egress interface or set via a policy) is encoded in an extended community and then sent to the IBGP peer which employs multi-path. The link-bandwidth value is then extracted from the path extended community and is used as a weight in the FIB, which does the load-balancing. This draft extends the usage of the DMZ link bandwidth to another setting where the ingress BGP speaker requires knowledge of the cumulative bandwidth while doing the load-balancing. The draft also proposes neighbor- level knobs to enable the link bandwidth extended community to be regenerated and then advertised to EBGP peers to override the default behavior of not advertising optional non-transitive attributes to EBGP peers.
 Geneve encapsulation for In-situ OAM Data
 
 draft-brockners-ippm-ioam-geneve-05.txt
 Date: 19/11/2020
 Authors: Frank Brockners, Shwetha Bhandari, Vengada Govindan, Carlos Pignataro, Nagendra Nainar, Hannes Gredler, John Leddy, Stephen Youell, Tal Mizrahi, Petr Lapukhov, Barak Gafni, Aviv Kfir, Mickey Spiegel
 Working Group: Individual Submissions (none)
 Formats: txt
In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document proposes a new Geneve tunnel option and outlines how IOAM data fields are carried in the option data field.
 EVPN All Active Usage Enhancement
 
 draft-eastlake-bess-enhance-evpn-all-active-06.txt
 Date: 06/01/2021
 Authors: Donald Eastlake, Zhenbin Li, Haibo Wang, Russ White
 Working Group: Individual Submissions (none)
 Formats: txt
A principal feature of EVPN is the ability to support multihoming from a customer equipment (CE) to multiple provider edge equipment (PE) active with all-active links. This draft specifies an improvement to load balancing such links.
 Bidirectional Forwarding Detection (BFD) for Segment Routing Policies for Traffic Engineering
 
 draft-ali-spring-bfd-sr-policy-06.txt
 Date: 16/11/2020
 Authors: Zafar Ali, Ketan Talaulikar, Clarence Filsfils, Nagendra Nainar, Carlos Pignataro
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routing (SR) allows a headend node to steer a packet flow along any path using a segment list which is referred to as a SR Policy. Intermediate per-flow states are eliminated thanks to source routing. The header of a packet steered in an SR Policy is augmented with the ordered list of segments associated with that SR Policy. Bidirectional Forwarding Detection (BFD) is used to monitor different kinds of paths between node. BFD mechanisms can be also used to monitor the availability of the path indicated by a SR Policy and to detect any failures. Seamless BFD (S-BFD) extensions provide a simplified mechanism which is suitable for monitoring of paths that are setup dynamically and on a large scale. This document describes the use of Seamless BFD (S-BFD) mechanism to monitor the SR Policies that are used for Traffic Engineering (TE) in SR deployments.
 Multipath Extensions for QUIC (MP-QUIC)
 
 draft-deconinck-quic-multipath-07.txt
 Date: 03/05/2021
 Authors: Quentin De Coninck, Olivier Bonaventure
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies extensions to the QUIC protocol to enable the simultaneous usage of multiple paths for a single connection. These extensions are compliant with the single-path QUIC design and preserve QUIC privacy features. Discussion about this draft is encouraged either on the QUIC IETF mailing list quic@ietf.org or on the GitHub repository which contains the draft: https://github.com/qdeconinck/draft-deconinck-multipath- quic.
 mLDP Extensions for Multi-Topology Routing
 
 draft-wijnands-mpls-mldp-multi-topology-01.txt
 Date: 26/11/2020
 Authors: IJsbrand Wijnands, Kamran Raza, Mankamana Mishra, Anuj Budhiraja, Zhaohui Zhang, Arkadiy Gulko
 Working Group: Individual Submissions (none)
 Formats: txt
Multi-Topology Routing (MTR) is a technology to enable service differentiation within an IP network. Flexible Algorithm (FA) is another mechanism of creating a sub-topology within a topology using defined topology constraints and computation algorithm. In order to deploy mLDP in a network that supports MTR and/or FA, mLDP is required to become topology and FA aware. This document specifies extensions to mLDP to support MTR with FA such that when building a Multi-Point LSPs it can follow a particular topology and algorithm.
 Service Function discovery in fog environments
 
 draft-bernardos-sfc-discovery-06.txt
 Date: 22/03/2021
 Authors: Carlos Bernardos, Alain Mourad
 Working Group: Individual Submissions (none)
 Formats: txt
Service function chaining (SFC) allows the instantiation of an ordered set of service functions and subsequent "steering" of traffic through them. Service functions provide an specific treatment of received packets, therefore they need to be known so they can be used in a given service composition via SFC. This document discusses the need for service function discovery mechanisms and propose some solutions for sfc-aware nodes to discover available service functions in fog environments.
 EVPN VXLAN Bypass VTEP
 
 draft-eastlake-bess-evpn-vxlan-bypass-vtep-07.txt
 Date: 06/01/2021
 Authors: Donald Eastlake, Zhenbin Li, Shunwan Zhuang, Russ White
 Working Group: Individual Submissions (none)
 Formats: txt
A principal feature of EVPN is the ability to support multihoming from a customer equipment (CE) to multiple provider edge equipment (PE) with all-active links. This draft specifies a mechanism to simplify PEs used with VXLAN tunnels and enhance VXLAN Active-Active reliability.
 Origin Validation Policy Considerations for Dropping Invalid Routes
 
 draft-sriram-sidrops-drop-invalid-policy-06.txt
 Date: 24/11/2020
 Authors: Kotikalapudi Sriram, Oliver Borchert, Doug Montgomery
 Working Group: Individual Submissions (none)
 Formats: txt
Deployment of Resource Public Key Infrastructure (RPKI) and Route Origin Authorizations (ROAs) is expected to occur gradually over several or many years. During the incremental deployment period, network operators would wish to have a meaningful policy for dropping Invalid routes. Their goal is to balance (A) dropping Invalid routes so hijacked routes can be eliminated, versus (B) tolerance for missing or erroneously created ROAs for customer prefixes. This document considers a Drop Invalid if Still Routable (DISR) policy that is based on these considerations. The key principle of DISR policy is that an Invalid route can be dropped if a Valid or NotFound route exists for a subsuming less specific prefix.
 Protecting EST Payloads with OSCORE
 
 draft-selander-ace-coap-est-oscore-05.txt
 Date: 05/05/2021
 Authors: Goeran Selander, Shahid Raza, Martin Furuhed, Malisa Vucinic, Timothy Claeys
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies public-key certificate enrollment procedures protected with lightweight application-layer security protocols suitable for Internet of Things (IoT) deployments. The protocols leverage payload formats defined in Enrollment over Secure Transport (EST) and existing IoT standards including the Constrained Application Protocol (CoAP), Concise Binary Object Representation (CBOR) and the CBOR Object Signing and Encryption (COSE) format.
 Connected Identity for STIR
 
 draft-peterson-stir-rfc4916-update-03.txt
 Date: 22/02/2021
 Authors: Jon Peterson, Chris Wendt
 Working Group: Individual Submissions (none)
 Formats: txt
The SIP Identity header conveys cryptographic identity information about the originators of SIP requests. The Secure Telephone Identity Revisited (STIR) framework however provides no means for determining the identity of the called party in a traditional telephone calling scenario. This document updates prior guidance on the "connected identity" problem to reflect the changes to SIP Identity that accompanied STIR, and 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, as well as the spoofing of mid-dialog or dialog-terminating events by intermediaries or third parties.
 Traffic Accounting in Segment Routing Networks
 
 draft-ali-spring-sr-traffic-accounting-05.txt
 Date: 12/04/2021
 Authors: Clarence Filsfils, Ketan Talaulikar, Siva Sivabalan, Martin Horneffer, Robert Raszuk, Stephane Litkowski, Dan Voyer, Rick Morton
 Working Group: Individual Submissions (none)
 Formats: txt
Capacity planning is the continuous art of forecasting traffic load and failures to evolve the network topology, its capacity, and its routing to meet a defined Service-Level Agreement (SLA). This document takes a holistic view of network capacity planning and identifies the role of traffic accounting in network operation and capacity planning, without creating any additional states in the SR fabric.
 OAuth 2.0 Assisted Token
 
 draft-ideskog-assisted-token-05.txt
 Date: 08/03/2021
 Authors: Jacob Ideskog, Travis Spencer
 Working Group: Individual Submissions (none)
 Formats: txt xml html
This document extends the OAuth 2.0 framework to include an additional authorization flow for single page applications called the assisted token flow. It enables OAuth clients written in scripting languages, like JavaScript, to request user authorization using a simplified method compared to other flows. Communication does not rely on redirection of the user agent, but instead leverages HTML's iframe element, child windows, and the postMessage interface. This communication is done using an additional endpoint, the assisted token endpoint.
 ICANN Registrar Interfaces
 
 draft-icann-registrar-interfaces-06.txt
 Date: 04/01/2021
 Authors: Gustavo Ibarra, Eduardo Alvarez
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the interfaces provided by ICANN to Registrars and Data Escrow Agents to fulfill the data escrow requirements of the Registrar Accreditation Agreement and the Registrar Data Escrow Specifications.
 Optimization of RWA Problem through OSNR
 
 draft-yin-rwa-osnr-07.txt
 Date: 16/11/2020
 Authors: Shan Yin, Shanguo Huang, Shuang Zhou, Xiangkai Meng, Rong Ma
 Working Group: Individual Submissions (none)
 Formats: txt
This documentary provides a kind of routing optimization method. In the basic of RWA solution method, both the output power of the route and the OSNR value of the optical signal noise ratio are considered. The selected optimal route has a lower bit error rate and the whole communication network performance is improved.
 OSPF Flooding Reduction in Massively Scalable Data Centers (MSDCs)
 
 draft-xu-lsr-ospf-flooding-reduction-in-msdc-04.txt
 Date: 22/12/2020
 Authors: Xiaohu Xu, Luyuan Fang, Jeff Tantsura, Shaowen Ma
 Working Group: Individual Submissions (none)
 Formats: txt xml
OSPF is one of the used underlay routing protocol for MSDC (Massively Scalable Data Center) networks. For a given OSPF router within the CLOS topology, it would receive multiple copies of exactly the same LSA from multiple OSPF neighbors. In addition, two OSPF neighbors may send each other the same LSA simultaneously. The unnecessary link-state information flooding wastes the precious process resource of OSPF routers greatly due to the presence of too many OSPF neighbors for each OSPF router within the CLOS topology. This document proposes extensions to OSPF so as to reduce the OSPF flooding within such MSDC networks. The reduction of the OSPF flooding is much beneficial to improve the scalability of MSDC networks. These modifications are applicable to both OSPFv2 and OSPFv3.
 IS-IS Flooding Reduction in MSDC
 
 draft-xu-lsr-isis-flooding-reduction-in-msdc-03.txt
 Date: 22/12/2020
 Authors: Xiaohu Xu, Luyuan Fang, Jeff Tantsura, Shaowen Ma
 Working Group: Individual Submissions (none)
 Formats: xml txt
IS-IS is commonly used as an underlay routing protocol for MSDC (Massively Scalable Data Center) networks. For a given IS-IS router within the CLOS topology, it would receive multiple copies of exactly the same LSP from multiple IS-IS neighbors. In addition, two IS-IS neighbors may send each other the same LSP simultaneously. The unnecessary link-state information flooding wastes the precious process resource of IS-IS routers greatly due to the fact that there are too many IS-IS neighbors for each IS-IS router within the CLOS topology. This document proposes some extensions to IS-IS so as to reduce the IS-IS flooding within MSDC networks greatly. The reduction of the IS-IS flooding is much beneficial to improve the scalability of MSDC networks.
 IS-IS Multi Topology Deployment Considerations
 
 draft-chunduri-lsr-isis-mt-deployment-cons-04.txt
 Date: 24/11/2020
 Authors: Uma Chunduri, Jeff Tantsura, Shraddha Hegde
 Working Group: Individual Submissions (none)
 Formats: txt
This document analyzes IS-IS Multi Topology (MT) applicability in various IS-IS deployments. This document explores the nuances around the terminology and usage of various IS-IS address families, topologies with different considerations, for choosing the right combination for a specific deployment scenario. This document also discusses various ways one can deploy IPv6 only IS-IS topology.
 DLEP IEEE 802.1Q Aware Credit Window Extension
 
 draft-berger-manet-dlep-ether-credit-extension-05.txt
 Date: 04/12/2020
 Authors: David Wiggins, Lou Berger
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables a Ethernet IEEE 802.1Q aware credit- window scheme for destination-specific and shared flow control.
 SR Policy Implementation and Deployment Considerations
 
 draft-filsfils-spring-sr-policy-considerations-07.txt
 Date: 04/04/2021
 Authors: Clarence Filsfils, Ketan Talaulikar, Przemyslaw Krol, Martin Horneffer, Paul Mattes
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routing (SR) allows a headend node to steer a packet flow along any path. Intermediate per-flow states are eliminated thanks to source routing. SR Policy framework enables the instantiation and the management of necessary state on the headend node for flows along a source routed paths using an ordered list of segments associated with their specific SR Policies. This document describes some of the implementation and deployment aspects that are useful for operationalizing the SR Policy architecture.
 RSCA method with Dividing Frequency Slots Area in Space Division Multiplexing Elastic Optical Networks
 
 draft-huang-rsca-sdm-eon-05.txt
 Date: 15/11/2020
 Authors: Shanguo Huang, Shan Yin, Shuang Zhou
 Working Group: Individual Submissions (none)
 Formats: txt
This documentary provides a routing, spectrum and core assignment method with the dividing frequency slots area for space division multiplexing elastic optical networks. This effective RSCA method to solve this problem better. The proposed method utilizes the Frequency Slots Area (FSA) concept and first-last fit policy of frequency slots assignment to have less spectrum fragments, lower crosstalk, smaller traffic blocking probability and higher spectrum resource utilization.
 IMAP Service Extension for Client Identity
 
 draft-yu-imap-client-id-05.txt
 Date: 23/11/2020
 Authors: Deion Yu
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines an Internet Message Access Protocol (IMAP) service extension called "CLIENTID" which provides a method for clients to indicate an identity to the server. This identity is an additional token that may be used for security and/or informational purposes, and with it a server may optionally apply heuristics using this token.
 SR For SDWAN: VPN with Underlay SLA
 
 draft-dukes-spring-sr-for-sdwan-03.txt
 Date: 22/02/2021
 Authors: Darren Dukes, Clarence Filsfils, Gaurav Dawra, Xiaohu Xu, Dan Voyer, Pablo Camarillo, Francois Clad, Stefano Salsano
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes how SR enables underlay Service Level Agreements (SLA) to a VPN with scale and security while ensuring service opacity. This solution applies to Over-The-Top VPN (OTT VPN) and Software-Defined WAN (SDWAN).
 Segment Routing Traffic Accounting Counters
 
 draft-filsfils-spring-sr-traffic-counters-01.txt
 Date: 16/04/2021
 Authors: Clarence Filsfils, Zafar Ali, Martin Horneffer, Dan Voyer, Muhammad Durrani, Robert Raszuk
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routing (SR) allows a headend node to steer a packet flow along any path. Intermediate per-flow states are eliminated thanks to source routing. Traffic accounting plays a critical role in network operation. A traffic account solution is required for SR networks that provides the necessary functionality without creating any additional per SR path states in the fabric. This document describes counters for traffic accounting in SR networks.
 General Security Considerations for Cryptoassets Custodians
 
 draft-vcgtf-crypto-assets-security-considerations-07.txt
 Date: 16/12/2020
 Authors: Masashi Sato, Masaki Shimaoka, Hirotaka Nakajima
 Working Group: Individual Submissions (none)
 Formats: xml txt html
This document discusses the technical and operational risks of cryptoassets custodians and its security controls to avoid the unintended transactions for its customers. 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/cgtf/draft-crypto-assets-security-considerations.
 GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.2
 
 draft-smyshlyaev-tls12-gost-suites-10.txt
 Date: 07/03/2021
 Authors: Stanislav Smyshlyaev, Dmitry Belyavsky, Markku-Juhani Saarinen
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies three new cipher suites for the Transport Layer Security (TLS) protocol Version 1.2 to support the Russian cryptographic standard algorithms (called GOST algorithms). This specification is developed to facilitate implementations that wish to support the GOST algorithms. This document does not imply IETF endorsement of the cipher suites.
 The IPv6 Tunnel Payload Forwarding (TPF) Option
 
 draft-bonica-6man-vpn-dest-opt-15.txt
 Date: 02/02/2021
 Authors: Ron Bonica, Yuji Kamite, Luay Jalil, Yifeng Zhou, Gang Chen
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document explains how IPv6 options can be used in IPv6 tunnels. It also defines the IPv6 Tunnel Payload Forwarding (TPF) option.
 DNS Web Service Discovery
 
 draft-hallambaker-web-service-discovery-05.txt
 Date: 13/01/2021
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml html
This document describes a standardized approach to discovering Web Service Endpoints from a DNS name. Services are advertised using the DNS SRV and TXT records and the HTTP Well Known Service conventions. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-web-service- discovery.html.
 BGP FlowSpec Payload Matching
 
 draft-khare-idr-bgp-flowspec-payload-match-08.txt
 Date: 07/03/2021
 Authors: Anurag Khare, Philippe BERGEON, Vijay Kestur, Luay Jalil, Kirill Kasavchenko
 Working Group: Individual Submissions (none)
 Formats: txt
The rise in frequency, volume, and pernicious effects of DDoS attacks has elevated them from fare for the specialist to generalist press. Numerous reports detail the taxonomy of DDoS attacks, the varying motivations of their attackers, as well as the resulting impact for their targets ranging from internet or business services to network infrastrutures. BGP FlowSpec (RFC 5575, "Dissemination of Flow Specification Rules") can be used to rapidly disseminate filtering rules to mitigate (distributed) denial-of-service (DoS) attacks. Operators can use existing FlowSpec components to match typical n-tuple criteria in pre-defined packet header fields such as IP protocol, IP prefix or port number. Recent enhancements to IP Router forwarding plane filter implementations also allow matches at arbitrary locations within the packet header or payload. This capability can be used to essentially match a signature for the attack traffic and can be combined with traditional n-tuple filter criteria to mitigate volumetric DDoS attacks and reduce false positive to a minimum. To support this new filtering capability we define a new FlowSpec component, "Flexible Match Conditions", with similar matching semantics to those of existing components. This component will allow the operator to define a new match condition using a combination of offset and pattern values.
 PIM Backup Designated Router Procedure
 
 draft-mankamana-pim-bdr-05.txt
 Date: 08/04/2021
 Authors: Mankamana Mishra, Sridhar Santhanam, Aravind Paramasivam, Joseph Goh, Gyan Mishra
 Working Group: Individual Submissions (none)
 Formats: txt xml
On a multi-access network, one of the PIM routers is elected as a Designated Router (DR). On the last hop LAN, the PIM DR is responsible for tracking local multicast listeners and forwarding traffic to these listeners if the group is operating in PIM-SM. In this document, we propose a mechanism to elect backup DR on a shared LAN. A backup DR on LAN would be useful for faster convergence. This draft introduces the concept of a Backup Designated Router (BDR) and the procedure to implement it.
 PCE Controlled ID Space
 
 draft-li-pce-controlled-id-space-08.txt
 Date: 22/02/2021
 Authors: Cheng Li, Mach Chen, Aijun Wang, Weiqiang Cheng, Chao Zhou
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Path Computation Element Communication Protocol (PCEP) provides a mechanisms for the Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The Stateful PCE extensions allow stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using PCEP. Furthermore, PCE can be used for computing paths in the SR networks. Stateful PCE provide active control of MPLS-TE LSPs via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. Further, stateful PCE could also create and remove PCE-initiated LSPs by itself. A PCE-based Central Controller (PCECC) simplify the processing of a distributed control plane by integrating with elements of Software-Defined Networking (SDN). In some use cases, such as PCECC or Binding Segment Identifier (SID) for Segment Routing (SR), there are requirements for a stateful PCE to make allocation of labels, SIDs, etc. These use cases require PCE aware of various identifier spaces from where to make allocations on behalf of a PCC. This document describes a mechanism for a PCC to inform the PCE of the identifier space set aside for the PCE control via PCEP. The identifier could be an MPLS label, a SID or any other to-be-defined identifier that can be allocated by a PCE.
 IGP Extensions for Segment Routing based Enhanced VPN
 
 draft-dong-lsr-sr-enhanced-vpn-05.txt
 Date: 22/02/2021
 Authors: Jie Dong, Zhibo Hu, Zhenbin Li, Xiongyan Tang, Ran Pang, Lee JooHeon, Stewart Bryant
 Working Group: Individual Submissions (none)
 Formats: xml txt
Enhanced VPN (VPN+) aims to provide enhanced VPN services to support some application's needs of enhanced isolation and stringent performance requirements. VPN+ requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. A Virtual Transport Network (VTN) is a virtual underlay network which has a customized network topology and a set of network resources allocated from the physical network. A VTN could be used to support one or a group of VPN+ services. This document specifies the IGP mechanisms with necessary extensions to build a set of Segment Routing (SR) based VTNs. Each VTN can have a customized topology and a set of network resources allocated. Multiple VTNs may shared the same topology, and multiple VTNs may share the same set of network resources on some network segments. This allows flexible combination of network topology and network resource attributes to build a relatively large number of VTNs with a small number of logical topologies. The proposed mechanism is applicable to both Segment Routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6).
 LSP Ping/Traceroute for Prefix SID in Presence of Multi-Algorithm/Multi- Topology Networks
 
 draft-iqbal-spring-mpls-ping-algo-02.txt
 Date: 23/02/2021
 Authors: Zafar Ali, Carlos Pignataro, Faisal Iqbal
 Working Group: Individual Submissions (none)
 Formats: txt
[RFC8287] defines the extensions to MPLS LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifier (SIDs) with an MPLS data plane. The machinery defined in [RFC8287] works well in single topology, single algorithm deployments where each Prefix SID is only associated with a single IP prefix. In multi-topology networks, or networks deploying multiple algorithms for the same IP Prefix, MPLS echo request needs to carry additional information in the Target FEC Stack sub-TLVs to properly validate IGP Prefix SID. This document updates [RFC8287] by modifying IPv4 and IPv6 IGP-Prefix Segment ID FEC sub-TLVs to also include algorithm identification while maintaining backwards compatibility. This document also introduces new Target FEC Stack sub-TLVs for Prefix SID validation in multi-topology networks.
 TLS 1.3 Authentication and Integrity only Cipher Suites
 
 draft-camwinget-tls-ts13-macciphersuites-11.txt
 Date: 06/05/2021
 Authors: Nancy Cam-Winget, Jack Visoky
 Working Group: Individual Submissions (none)
 Formats: xml txt
There are use cases, specifically in Internet of Things (IoT) and constrained environments that do not require confidentiality, though message integrity for all communications and at least server, if not mutual authentication during tunnel establishment, are both still mandated. This document gives examples of such use cases, although a threat model is necessary to determine whether or not a given situation falls into this category of use cases. In order to serve these use cases, this document defines the use of HMAC-only cipher suites for TLS 1.3, which provides server and optionally mutual authentication and data authenticity, but not data confidentiality. The approach described in this document is not endorsed by the IETF and does not have IETF consensus, but is presented here to enable interoperable implementation of a reduced security mechanism that provides authentication and message integrity without supporting confidentiality.
 Design Considerations for Low Power Internet Protocols
 
 draft-ayers-low-power-interop-03.txt
 Date: 11/02/2021
 Authors: Hudson Ayers, P Levis
 Working Group: Individual Submissions (none)
 Formats: txt
Low-power wireless networks provide IPv6 connectivity through 6LoWPAN, a set of standards to aggressively compress IPv6 packets over small maximum transfer unit (MTU) links such as 802.15.4. The entire purpose of IP was to interconnect different networks, but we find that different 6LoWPAN implementations fail to reliably communicate with one another. These failures are due to stacks implementing different subsets of the standard out of concern for code size. We argue that this failure stems from 6LoWPAN's design, not implementation, and is due to applying traditional Internet protocol design principles to low-power networks. We propose three design principles for Internet protocols on low- power networks, designed to prevent similar failures in the future. These principles are based around the importance of providing flexible tradeoffs between code size and energy efficiency. We apply these principles to 6LoWPAN and show that the modified protocol provides a wide range of implementation strategies while allowing implementations with different strategies to reliably communicate.
 LISP Data-Plane Telemetry
 
 draft-farinacci-lisp-telemetry-05.txt
 Date: 29/11/2020
 Authors: Dino Farinacci, Said Ouissal, Erik Nordmark
 Working Group: Individual Submissions (none)
 Formats: txt
This draft specs a JSON formatted RLOC-record for telemetry data which decapsulating xTRs include in RLOC-probe Map Reply messages.
 Security Policy Translation in Interface to Network Security Functions
 
 draft-yang-i2nsf-security-policy-translation-08.txt
 Date: 22/02/2021
 Authors: Jaehoon Jeong, Patrick Lingga, Jinhyuk Yang, Chaehong Chung
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document proposes a scheme of security policy translation (i.e., Security Policy Translator) in Interface to Network Security Functions (I2NSF) Framework. When I2NSF User delivers a high-level security policy for a security service, Security Policy Translator in Security Controller translates it into a low-level security policy for Network Security Functions (NSFs). For this security policy translation, this document specifies the mapping between a high-level security policy based on the Consumer-Facing Interface YANG data model and a low-level security policy based on the NSF-Facing Interface YANG data model. Also, it describes an architecture of a security policy translator along with an NSF database, and the process of security policy translation with the NSF database.
 Design Discussion of Route Leaks Solution Methods
 
 draft-sriram-idr-route-leak-solution-discussion-05.txt
 Date: 12/03/2021
 Authors: Kotikalapudi Sriram
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document captures the design rationale of the route leaks solution document (see draft-ietf-idr-route-leak-detection- mitigation, draft-ietf-grow-route-leak-detection-mitigation). The designers needed to balance many competing factors, and this document provides insights into the design questions and their resolution.
 LURK Extension version 1 for (D)TLS 1.3 Authentication
 
 draft-mglt-lurk-tls13-04.txt
 Date: 25/01/2021
 Authors: Daniel Migault
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the LURK Extension 'tls13' which enables interactions between a LURK Client and a LURK Server in a context of authentication with (D)TLS 1.3.
 Multiple ALTO Resources Query Using Multipart Message
 
 draft-zhang-alto-multipart-05.txt
 Date: 14/01/2021
 Authors: Jingxuan Zhang, Y. Yang
 Working Group: Individual Submissions (none)
 Formats: xml html txt
Many ALTO use cases involve multiple ALTO information resources like different network maps, cost maps and property maps to achieve their own specific goals. To make the ALTO client query them one by one is not only inefficient but also error-prone. The inconsistent responses can be performed because of the unstable communication environment, and finally conduct the unexpected traffic optimization. Further more, some ALTO information resources may have correlation, which means one's input parameters may depends on another one's response. To address those issues, some advanced query schema is required. This document proposes an ALTO extension to support the multiple ALTO resources query in the single request using the HTTP multipart message and the existing JSON query languages.
 Node Protection for RSVP-TE tunnels on a shared MPLS forwarding plane
 
 draft-chandra-mpls-rsvp-shared-labels-np-05.txt
 Date: 03/01/2021
 Authors: Chandrasekar R, Vishnu Beeram, Harish Sitaraman
 Working Group: Individual Submissions (none)
 Formats: txt xml
Segment Routed RSVP-TE tunnels provide the ability to use a shared MPLS forwarding plane at every hop of the Label Switched Path (LSP). The shared forwarding plane is realized with the use of 'Traffic Engineering (TE) link labels' that get shared by LSPs traversing these TE links. This paradigm helps significantly reduce the forwarding plane state required to support a large number of LSPs on a Label Switching Router (LSR). These tunnels require the ingress Label Edge Router (LER) to impose a stack of labels. If the ingress LER cannot impose the full label stack, it can use the assistance of one or more delegation hops along the path of the LSP to impose parts of the label stack. The procedures for a Point of Local Repair (PLR) to provide local protection against link failures using facility backup for Segment Routed RSVP-TE tunnels are well defined and do not require specific protocol extensions. This document defines the procedures for a PLR to provide local protection against transit node failures using facility backup for these tunnels. The procedures defined in this document include protection against delegation hop failures.
 Building blocks for Slicing in Segment Routing Network
 
 draft-ali-spring-network-slicing-building-blocks-04.txt
 Date: 21/02/2021
 Authors: Zafar Ali, Clarence Filsfils, Pablo Camarillo, Dan Voyer
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes how to build network slice using the Segment Routing based technology. It explains how the building blocks specified for the Segment Routing can be used for this purpose.
 Terminology for Cryptoassets
 
 draft-nakajima-crypto-asset-terminology-05.txt
 Date: 31/12/2020
 Authors: Hirotaka Nakajima, Masanori Kusunoki, Keiichi Hida, Yuji Suga, Tatsuya Hayashi
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document provides terminology used in cryptoassets.
 A YANG Data Model for Network Bridge Management
 
 draft-vassilev-netmod-network-bridge-05.txt
 Date: 17/02/2021
 Authors: Vladimir Vassilev
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document introduces new YANG model of a flow capable network bridge.
 MPLS Extension Header
 
 draft-song-mpls-extension-header-04.txt
 Date: 29/04/2021
 Authors: Haoyu Song, Zhenbin Li, Tianran Zhou, Loa Andersson
 Working Group: Individual Submissions (none)
 Formats: txt xml
Motivated by the need to support multiple in-network services and functions in an MPLS network, this document describes a generic and extensible method to encapsulate extension headers into MPLS packets. The encapsulation method allows stacking multiple extension headers and quickly accessing any of them as well as the original upper layer protocol header and payload. We show how the extension header can be used to support several new network applications and optimize some existing network services.
 Flexible Session Protocol
 
 draft-gao-flexible-session-protocol-06.txt
 Date: 18/04/2021
 Authors: Jun-an Gao
 Working Group: Individual Submissions (none)
 Formats: xml txt
FSP is a connection-oriented transport layer protocol that provides mobility and multihoming support by introducing the concept of 'upper layer thread ID', which is associated with some shared secret that is applied with some secure hash or authenticated encryption algorithm to protect authenticity of the origin of the FSP packets. It is able to provide following services to the upper layer application: o Stream-oriented send-receive with native message boundary o Flexibility to exploit authenticated encryption o On-the-wire compression o Light-weight session management
 Transport Network aware Mobility for 5G
 
 draft-clt-dmm-tn-aware-mobility-09.txt
 Date: 12/02/2021
 Authors: Uma Chunduri, Renwei Li, Sridhar Bhaskaran, John Kaippallimalil, Jeff Tantsura, Luis Contreras, Praveen Muley
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a framework and mapping from slices in 5G mobile systems to transport slices in IP, Layer 2 and Layer 1 transport networks. Slices in 5G systems are characterized by latency bounds, reservation guarantees, jitter, data rates, availability, mobility speed, usage density, criticality and priority. These characteristics should be mapped to the transport network slice characteristics that include bandwidth, latency and criteria such as isolation, directionality and disjoint routes. Mobile slice criteria need to be mapped to the appropriate transport slice and capabilities offered in backhaul, midhaul and fronthaul connectivity segments between radio side network functions and user plane function(gateway). This document describes how mobile network functions map its slice criteria to identifiers in IP and Layer 2 packets that transport network segments use to grant transport layer services during UE mobility scenarios. Applicability of this framework and underlying transport networks, which can enable different slice properties are also discussed. This is based on mapping between mobile and transport underlays (L2, Segment Routing, IPv6, MPLS and IPv4).
 BGP-LS Advertisement of Segment Routing Service Segments
 
 draft-dawra-idr-bgp-ls-sr-service-segments-05.txt
 Date: 15/02/2021
 Authors: Gaurav Dawra, Clarence Filsfils, Ketan Talaulikar, Francois Clad, daniel.bernier@bell.ca, Jim Uttaro, Bruno Decraene, Hani Elmalky, Xiaohu Xu, Jim Guichard, Cheng Li
 Working Group: Individual Submissions (none)
 Formats: txt
Service functions are deployed as, physical or virtualized elements along with network nodes or on servers in data centers. Segment Routing (SR) brings in the concept of segments which can be topological or service instructions. Service segments are SR segments that are associated with service functions. SR Policies are used for the setup of paths for steering of traffic through service functions using their service segments. BGP Link-State (BGP-LS) enables distribution of topology information from the network to a controller or an application in general so it can learn the network topology. This document specifies the extensions to BGP-LS for the advertisement of service functions along their associated service segments. The BGP-LS advertisement of service function information along with the network nodes that they are attached to, or associated with, enables controllers compute and setup service paths in the network.
 Implementation notes for RFC7991,
 
 draft-levkowetz-xml2rfc-v3-implementation-notes-12.txt
 Date: 15/12/2020
 Authors: Henrik Levkowetz
 Working Group: Individual Submissions (none)
 Formats: html txt xml
This memo documents issues and observations found while implementing RFC 7991. Individual notes are organised into separate sections, depending on their character.
 Subject Identifiers for Security Event Tokens
 
 draft-ietf-secevent-subject-identifiers-07.txt
 Date: 08/03/2021
 Authors: Annabelle Backman, Marius Scurtescu
 Working Group: Individual Submissions (none)
 Formats: xml txt
Security events communicated within Security Event Tokens may support a variety of identifiers to identify subjects related to the event. This specification formalizes the notion of subject identifiers as structured information that describe a subject, and named formats that define the syntax and semantics for encoding subject identifiers as JSON objects. It also defines a registry for defining and allocating names for such formats, as well as the "sub_id" JSON Web Token (JWT) claim.
 YANG Data Model for IS-IS SRv6
 
 draft-hu-isis-srv6-yang-05.txt
 Date: 22/01/2021
 Authors: Zhibo Hu, Dan Ye, Yingzhen Qu, Xuesong Geng, Qiufang Ma
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines a YANG data model that can be used to configure and manage IS-IS SRv6 [I-D.ietf-lsr-isis-srv6-extensions].
 The Multihash Data Format
 
 draft-multiformats-multihash-02.txt
 Date: 19/02/2021
 Authors: Juan Benet, Manu Sporny
 Working Group: Individual Submissions (none)
 Formats: txt xml
Cryptographic hash functions often have multiple output sizes and encodings. This variability makes it difficult for applications to examine a series of bytes and determine which hash function produced them. Multihash is a universal data format for encoding outputs from hash functions. It is useful to write applications that can simultaneously support different hash function outputs as well as upgrade their use of hashes over time; Multihash is intended to address these needs.
 Access Extensions for ANCP
 
 draft-lihawi-ancp-protocol-access-extension-06.txt
 Date: 05/04/2021
 Authors: Hongyu Li, Thomas Haag, Birgit Witschurke
 Working Group: Individual Submissions (none)
 Formats: txt xml
The purpose of this document is to specify extensions to ANCP (Access Node Control Protocol) (RFC6320) to support PON as described in RFC6934 and some other DSL Technologies including G.fast. This document updates RFC6320 by modifications to terminologies, flows and specifying new TLV types. This document updates RFC6320 by modifications to terminologies, flows and specifying new TLV types.
 IPv6-based discovery and association of Virtualization Infrastructure Manager (VIM) and Network Function Virtualization Orchestrator (NFVO)
 
 draft-bernardos-intarea-vim-discovery-05.txt
 Date: 22/02/2021
 Authors: Carlos Bernardos, Alain Mourad
 Working Group: Individual Submissions (none)
 Formats: txt
Virtualized resources do not need to be limited to those available in traditional data centers, where the infrastructure is stable, static, typically homogeneous and managed by a single admin entity. Computational capabilities are becoming more and more ubiquitous, with terminal devices getting extremely powerful, as well as other types of devices that are close to the end users at the edge (e.g., vehicular onboard devices for infotainment, micro data centers deployed at the edge, etc.). It is envisioned that these devices would be able to offer storage, computing and networking resources to nearby network infrastructure, devices and things (the fog paradigm). These resources can be used to host functions, for example to offload/complement other resources available at traditional data centers, but also to reduce the end-to-end latency or to provide access to specialized information (e.g., context available at the edge) or hardware. This document describes mechanisms allowing dynamic discovery of virtualization resources and orchestrators in IPv6-based networks. In the current version, mechanisms based on piggybacking options on IPv6 neighbor discovery are explored. New IPv6 neighbor discovery options are defined. Additional mechanisms will be explored in future releases of this document.
 Discovery of OSCORE Groups with the CoRE Resource Directory
 
 draft-tiloca-core-oscore-discovery-08.txt
 Date: 22/02/2021
 Authors: Marco Tiloca, Christian Amsuess, Peter van der Stok
 Working Group: Individual Submissions (none)
 Formats: txt
Group communication over the Constrained Application Protocol (CoAP) can be secured by means of Group Object Security for Constrained RESTful Environments (Group OSCORE). At deployment time, devices may not know the exact security groups to join, the respective Group Manager, or other information required to perform the joining process. This document describes how a CoAP endpoint can use descriptions and links of resources registered at the CoRE Resource Directory to discover security groups and to acquire information for joining them through the respective Group Manager. A given security group may protect multiple application groups, which are separately announced in the Resource Directory as sets of endpoints sharing a pool of resources. This approach is consistent with, but not limited to, the joining of security groups based on the ACE framework for Authentication and Authorization in constrained environments.
 Postcard-based On-Path Flow Data Telemetry using Packet Marking
 
 draft-song-ippm-postcard-based-telemetry-09.txt
 Date: 19/02/2021
 Authors: Haoyu Song, Greg Mirsky, Clarence Filsfils, Ahmed Abdelsalam, Tianran Zhou, Zhenbin Li, Jongyoon Shin, Kyungtae Lee
 Working Group: Individual Submissions (none)
 Formats: xml txt
The document describes a packet-marking variation of the Postcard- Based Telemetry (PBT), referred to as PBT-M. Unlike the instruction- based PBT, as embodied in IOAM DEX, PBT-M does not require the encapsulation of a telemetry instruction header, so it avoids some of the implementation challenges of the instruction-based PBT. However, PBT-M has unique issues that need to be considered. This document serves as a scheme overview and provides design guidelines applicable to implementations in different network protocols.
 Secure EVPN
 
 draft-sajassi-bess-secure-evpn-04.txt
 Date: 22/02/2021
 Authors: Ali Sajassi, Ayan Banerjee, Samir Thoria, David Carrel, Brian Weis, John Drake
 Working Group: Individual Submissions (none)
 Formats: txt
The applications of EVPN-based solutions ([RFC7432] and [RFC8365]) have become pervasive in Data Center, Service Provider, and Enterprise segments. It is being used for fabric overlays and inter- site connectivity in the Data Center market segment, for Layer-2, Layer-3, and IRB VPN services in the Service Provider market segment, and for fabric overlay and WAN connectivity in Enterprise networks. For Data Center and Enterprise applications, there is a need to provide inter-site and WAN connectivity over public Internet in a secured manner with same level of privacy, integrity, and authentication for tenant's traffic as IPsec tunneling using IKEv2. This document presents a solution where BGP point-to-multipoint signaling is leveraged for key and policy exchange among PE devices to create private pair-wise IPsec Security Associations without IKEv2 point-to-point signaling or any other direct peer-to-peer session establishment messages.
 Enhanced Alternate Marking Method
 
 draft-zhou-ippm-enhanced-alternate-marking-06.txt
 Date: 18/01/2021
 Authors: Tianran Zhou, Giuseppe Fioccola, Shinyoung Lee, Mauro Cociglio, Weidong Li
 Working Group: Individual Submissions (none)
 Formats: txt
This document extends the IPv6 alternate marking option to provide the enhanced capabilities.
 Terminology,Power,and Inclusive Language in Internet-Drafts and RFCs
 
 draft-knodel-terminology-05.txt
 Date: 22/02/2021
 Authors: Mallory Knodel, Niels ten Oever
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document argues for more inclusive language conventions sometimes used by RFC authors and the RFC Production Centre in Internet-Drafts that are work in progress, and in new RFCs that may be published in any of the RFC series, in order to foster greater knowledge transfer and improve diversity of participation in the IETF.
 PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) for SRv6
 
 draft-dhody-pce-pcep-extension-pce-controller-srv6-06.txt
 Date: 21/02/2021
 Authors: Zhenbin Li, Shuping Peng, Xuesong Geng, Mahendra Negi
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Path Computation Element (PCE) is a core component of Software- Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands. PCE was developed to derive paths for MPLS Label Switched Paths (LSPs), which are supplied to the head end of the LSP using the Path Computation Element Communication Protocol (PCEP). But SDN has a broader applicability than signaled (G)MPLS traffic-engineered (TE) networks, and the PCE may be used to determine paths in a range of use cases. PCEP has been proposed as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller. A PCE-based Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. This document specifies the procedures and PCEP protocol extensions when a PCE-based controller is also responsible for configuring the forwarding actions on the routers for Segment Routing (SR) in IPv6 (SRv6), in addition to computing the SRv6 paths for packet flows and telling the edge routers what instructions to attach to packets as they enter the network.
 PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) for P2MP LSPs
 
 draft-dhody-pce-pcep-extension-pce-controller-p2mp-06.txt
 Date: 21/02/2021
 Authors: Zhenbin Li, Shuping Peng, Xuesong Geng, Mahendra Negi
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Path Computation Element (PCE) is a core component of Software- Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands. The PCE has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE Label Switched Paths (LSPs). PCE was developed to derive paths for MPLS P2MP LSPs, which are supplied to the head end (root) of the LSP using PCEP. PCEP has been proposed as a control protocol to allow the PCE to be fully enabled as a central controller. A PCE-based Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the P2MP LSP can be calculated/set up/initiated and the label forwarding entries can also be downloaded through a centralized PCE server to each network device along the P2MP path, while leveraging the existing PCE technologies as much as possible. This document specifies the procedures and PCEP extensions for using the PCE as the central controller for P2MP TE LSP by provisioning labels along the path of the static P2MP LSP.
 Architecture for Use of BGP as Central Controller
 
 draft-cth-rtgwg-bgp-control-06.txt
 Date: 24/01/2021
 Authors: Yujia Luo, Liang Ou, Xiang Huang, Gyan Mishra, Huaimo Chen, Shunwan Zhuang, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: xml txt
BGP is a core part of a network including Software-Defined Networking (SDN) system. It has the traffic engineering information on the network topology and can compute optimal paths for a given traffic flow across the network. This document describes some reference architectures for BGP as a central controller. A BGP-based central controller can simplify the operations on the network and use network resources efficiently for providing services with high quality.
 SR-TE Path Midpoint Restoration
 
 draft-hu-spring-segment-routing-proxy-forwarding-14.txt
 Date: 29/04/2021
 Authors: Zhibo Hu, Huaimo Chen, Junda Yao, Chris Bowers, Yongqing Zhu, Yisong Liu
 Working Group: Individual Submissions (none)
 Formats: xml txt
Segment Routing Traffic Engineering (SR-TE) supports explicit paths using segment lists containing adjacency-SIDs, node-SIDs and binding- SIDs. The current SR FRR such as TI-LFA provides fast re-route protection for the failure of a node along a SR-TE path by the direct neighbor or say point of local repair (PLR) to the failure. However, once the IGP converges, the SR FRR is no longer sufficient to forward traffic of the path around the failure, since the non-neighbors of the failure will no longer have a route to the failed node. This document describes a mechanism for the restoration of the routes to the failure of a SR-TE path after the IGP converges. It provides the restoration of the routes to an adjacency segment, a node segment and a binding segment of the path. With the restoration of the routes to the failure, the traffic is continuously sent to the neighbor of the failure after the IGP converges. The neighbor as a PLR fast re- routes the traffic around the failure.
 SRIFT: Segment Routing in Fat Trees
 
 draft-zzhang-rift-sr-03.txt
 Date: 22/02/2021
 Authors: Zhaohui Zhang, Jeff Tantsura, Jordan Head, Don Fedyk
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies signaling procedures for Segment Routing in RIFT. Each node's loopback address, Segment Routing Global Block (SRGB) and Node Segment Identifier (Node-SID), which are typically assigned by a configuration management system and distibuted by routing protocols, are distributed southbound from the Top Of Fabric (TOF) nodes via RIFT's Key-Value distribution mechanism, so that each node can compute how to reach a segment represented by the active SID in a packet. An SR controller signals SR policies to ingress nodes so that they can send packets with a desired segment list to steer traffic.
 AC-Aware Bundling Service Interface in EVPN
 
 draft-sajassi-bess-evpn-ac-aware-bundling-03.txt
 Date: 16/02/2021
 Authors: Ali Sajassi, Mankamana Mishra, Samir Thoria, Patrice Brissette, Jorge Rabadan, John Drake
 Working Group: Individual Submissions (none)
 Formats: txt xml
EVPN provides an extensible and flexible multi-homing VPN solution over an MPLS/IP network for intra-subnet connectivity among Tenant Systems and End Devices that can be physical or virtual. EVPN multihoming with IRB is one of the common deployment scenarios. There are deployments which requires capability to have multiple subnets designated with multiple VLAN IDs in single bridge domain. [RFC7432] defines three different type of service interface which serve different requirements but none of them address the requirement to be able to support multiple subnets within single bridge domain. In this draft we define new service interface type to support multiple subnets in single bridge domain. Service interface proposed in this draft will be applicable to multihoming case only.
 Flowspec Indirection-id Redirect for SRv6
 
 draft-ietf0-idr-srv6-flowspec-path-redirect-05.txt
 Date: 06/01/2021
 Authors: Gunter Van de Velde, Keyur Patel, Zhenbin Li, Huaimo Chen
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines extensions to "FlowSpec Redirect to indirection-id Extended Community" for SRv6. This extended community can trigger advanced redirection capabilities to flowspec clients for SRv6. When activated, this flowspec extended community is used by a flowspec client to retrieve the corresponding next-hop and encoding information within a localised indirection-id mapping table. The functionality detailed in this document allows a network controller to decouple the BGP flowspec redirection instruction from the operation of the available paths.
 In-situ Flow Information Telemetry
 
 draft-song-opsawg-ifit-framework-14.txt
 Date: 02/04/2021
 Authors: Haoyu Song, Fengwei Qin, Huanan Chen, Jaewhan Jin, Jongyoon Shin
 Working Group: Individual Submissions (none)
 Formats: xml txt
As network scale increases and network operation becomes more sophisticated, traditional Operation, Administration and Maintenance (OAM) methods, which include proactive and reactive techniques, running in active and passive modes, are no longer sufficient to meet the monitoring and measurement requirements. On-path telemetry techniques which provide high-precision flow insight and real-time issue notification are emerging to support suitable quality of experience for users and applications, and fault or network deficiency identification before they become critical. Centering on the new data plane on-path telemetry techniques, this document outlines a high-level framework to provide an operational environment that utilizes these techniques to enable the collection and correlation of performance information from the network. The framework identifies the components that are needed to coordinate the existing protocol tools and telemetry mechanisms, and addresses key deployment challenges for flow-oriented on-path telemetry techniques, especially in carrier networks. The framework is informational and intended to guide system designers attempting to apply the referenced techniques as well as to motivate further work to enhance the ecosystem .
 SRv6 and MPLS interworking
 
 draft-agrawal-spring-srv6-mpls-interworking-05.txt
 Date: 22/02/2021
 Authors: Swadesh Agrawal, Zafar Ali, Clarence Filsfils, Dan Voyer, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes SRv6 and MPLS/SR-MPLS interworking and co- existence procedures.
 OAM for Service Programming with Segment Routing
 
 draft-ali-spring-sr-service-programming-oam-03.txt
 Date: 22/02/2021
 Authors: Zafar Ali, Clarence Filsfils, Nagendra Nainar, Carlos Pignataro, Francois Clad, Faisal Iqbal, Xiaohu Xu
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines the Operations, Administrations and Maintenance (OAM) for service programming in SR-enabled MPLS and IP networks.
 Segment Routing Header encapsulation for In-situ OAM Data
 
 draft-ali-spring-ioam-srv6-03.txt
 Date: 15/11/2020
 Authors: Zafar Ali, Rakesh Gandhi, Clarence Filsfils, Frank Brockners, Nagendra Nainar, Carlos Pignataro, Cheng Li, Mach Chen, Gaurav Dawra
 Working Group: Individual Submissions (none)
 Formats: txt
OAM and PM information from the SR endpoints can be piggybacked in the data packet. The OAM and PM information piggybacking in the data packets is also known as In-situ OAM (IOAM). IOAM records operational and telemetry information in the data packet while the packet traverses a path between two points in the network. This document defines how IOAM data fields are transported as part of the Segment Routing with IPv6 data plane (SRv6) header.
 Private Discovery
 
 draft-bradley-dnssd-private-discovery-05.txt
 Date: 28/12/2020
 Authors: Bob Bradley
 Working Group: Individual Submissions (none)
 Formats: txt html xml
This document specifies a protocol for advertising and discovering devices and services while preserving privacy and confidentiality.
 RPKI Route Origin Validation State Unverified
 
 draft-borchert-sidrops-rpki-state-unverified-04.txt
 Date: 15/01/2021
 Authors: Oliver Borchert, Doug Montgomery
 Working Group: Individual Submissions (none)
 Formats: txt
In case operators decide not to evaluate BGP route prefixes according to RPKI route origin validation (ROV), none of the available states as specified in RFC 6811 do properly represent this decision. This document introduces "Unverified" as well-defined validation state which allows to properly identify route prefixes as not evaluated according to RPKI route origin validation.
 BGPsec Validation State Unverified
 
 draft-borchert-sidrops-bgpsec-state-unverified-04.txt
 Date: 15/01/2021
 Authors: Oliver Borchert, Doug Montgomery
 Working Group: Individual Submissions (none)
 Formats: txt
In case operators decide to delay BGPsec path validation, none of the available states do properly represent this decision. This document introduces "Unverified" as a well-defined validation state which allows to properly identify a non-evaluated BGPsec routes as not verified.
 The Standards on a Cloud Service Framework and Protocol for Construction,Migration,Deployment,and Publishing of Internet-Oriented Scalable Web Software Systems in Non-Programming Mode
 
 draft-yangcan-core-web-software-built-in-cloud-04.txt
 Date: 21/11/2020
 Authors: Can Yang, Linghui Du, Haibo Sun, Kemin Qu, Guoqiang Han
 Working Group: Individual Submissions (none)
 Formats: txt xml
This draft mainly focuses on the scalable architecture and publishing protocol standard of REST-based SAAS cloud model Web software in non- programming mode, stipulates the data structure pattern and data exchange protocol for the construction and release of REST-based scalable Web cloud service software systems. Using the standardized framework and protocol, users can easily and quickly design their own software systems in the cloud, transfer and release data, which may make conventional software development so ease to improve the efficiency of complex database construction and server management. Without having to write codes under the standard framework, users can get consistent style background to create service, rapidly develop web application systems with the function of standard data management and data maintenance, and directly publish the software system to the end users of the Internet for access and use. And provide RESTful APIs to facilitate external access to required service resources. The framework can thus greatly shorten the software development life cycle, and save a great deal of development cost and maintenance overhead.
 Realm Crossover for SASL and GSS-API via Diameter
 
 draft-vanrein-diameter-sasl-04.txt
 Date: 26/01/2021
 Authors: Rick van Rein, Henri Manson
 Working Group: Individual Submissions (none)
 Formats: txt xml
SASL and GSS-API are used for authentication in many application protocols. This specification extends them to allow credentials of a home realm to be used against external services. To this end, it introduces end-to-end encryption for SASL that is safe to relay through a foreign server.
 Multiple Layer Resource Optimization for Optical as a Service
 
 draft-multiple-layer-resource-optimization-05.txt
 Date: 18/04/2021
 Authors: Hui Yang, Kaixuan Zhan, Ao Yu, Qiuyan Yao, Jie Zhang
 Working Group: Individual Submissions (none)
 Formats: txt
We have established a neural network model optimized by adaptive artificial fish swarm algorithm. Then we propose a novel multi-path pre-reserved resource allocation strategy to increase resource utilization. The results prove the effectiveness of our method.
 Security Classes for IoT devices
 
 draft-urien-lwig-security-classes-05.txt
 Date: 15/12/2020
 Authors: Pascal Urien
 Working Group: Individual Submissions (none)
 Formats: txt
This draft attempts to define security classes for constraint IoT devices. A device security is characterized by five Boolean security attributes: one time programmable memory (OTP), firmware loader (FLD), secure firmware loader (FLD-SEC), tamper resistant key (TRT- KEY) and diversified key (DIV-KEY). This leads to the definition of 6 classes of devices, embedding or not OTP resource, whose security increases with the class number (0 to 5). The suffix + indicates OTP availability.
 Considerations for Large Authoritative DNS Servers Operators
 
 draft-moura-dnsop-authoritative-recommendations-08.txt
 Date: 19/02/2021
 Authors: Giovane Moura, Wes Hardaker, John Heidemann, Marco Davids
 Working Group: Individual Submissions (none)
 Formats: txt xml
Recent research work has explored the deployment characteristics and configuration of the Domain Name System (DNS). This document summarizes the conclusions from these research efforts and offers specific, tangible advice to operators when configuring authoritative DNS servers. It is possible that the results presented in this document could be applicable in a wider context than just the DNS protocol, as some of the results may generically apply to any stateless/short-duration, anycasted service. This document is not an IETF consensus document: it is published for informational purposes.
 MessageVortex Protocol
 
 draft-gwerder-messagevortexmain-07.txt,.ps
 Date: 02/04/2021
 Authors: Martin Gwerder
 Working Group: Individual Submissions (none)
The MessageVortex (referred to as Vortex) protocol achieves different degrees of anonymity, including sender, receiver, and third-party anonymity, by specifying messages embedded within the existing transfer protocols, such as SMTP or XMPP, sent via peer nodes to one or more recipients. The protocol outperforms others by decoupling the transport from the final transmitter and receiver. No trust is placed into any infrastructure except for that of the sending and receiving parties of the message. The creator of the routing block (routing block builder; RBB) has full control over the message flow. Routing nodes gain no non-obvious knowledge about the messages even when collaborating. While third-party anonymity is always achieved, the protocol also allows for either sender or receiver anonymity.
 Multicast DF Election for EVPN based on bandwidth or quantity
 
 draft-liu-bess-evpn-mcast-bw-quantity-df-election-03.txt
 Date: 20/02/2021
 Authors: Yisong Liu, Mike McBride, Zheng Zhang, Jingrong Xie
 Working Group: Individual Submissions (none)
 Formats: txt
Ethernet Virtual Private Network (EVPN, RFC7432) is becoming prevalent in Data Centers, Data Center Interconnect (DCI) and Service Provider VPN applications. When multi-homing from a CE to multiple PEs, including links in an EVPN instance on a given Ethernet Segment, in an all-active redundancy mode, [RFC7432] describes a basic mechanism to elect a Designated Forwarder (DF), and [RFC8584] improves basic DF election by a HRW algorithm. [I- D.ietf-bess-evpn-per-mcast-flow-df-election] enhances the HRW algorithm for the multicast flows to perform DF election at the granularity of (ESI, VLAN, Mcast flow). This document specifies a new algorithm, based on multicast bandwidth utilization and multicast state quantity, in order for the multicast flows to elect a DF.
 The Multibase Data Format
 
 draft-multiformats-multibase-03.txt
 Date: 19/02/2021
 Authors: Juan Benet, Manu Sporny
 Working Group: Individual Submissions (none)
 Formats: txt xml
Raw binary data is often encoded using a mechanism that enables the data to be included in human-readable text-based formats. This mechanism is often referred to as "base-encoding the data". Base- encoding is often used when expressing binary data in hyperlinks, cryptographic keys in web pages, or security tokens in application software. There are a variety of base-encodings, such as base32, base58, and base64. It is not always possible to differentiate one base-encoding from another. The purpose of this specification is to provide a mechanism to be able to deterministically identify the base-encoding for a particular string of data.
 Cryptographic Hyperlinks
 
 draft-sporny-hashlink-07.txt
 Date: 02/05/2021
 Authors: Manu Sporny, Leonard Rosenthol
 Working Group: Individual Submissions (none)
 Formats: xml txt
When using a hyperlink to fetch a resource from the Internet, it is often useful to know if the resource has changed since the data was published. Cryptographic hashes, such as SHA-256, are often used to determine if published data has changed in unexpected ways. Due to the nature of most hyperlinks, the cryptographic hash is often published separately from the link itself. This specification describes a data model and serialization formats for expressing cryptographically protected hyperlinks. The mechanisms described in the document enables a system to publish a hyperlink in a way that empowers a consuming application to determine if the resource associated with the hyperlink has changed in unexpected ways.
 Generic Multi-Access (GMA) Encapsulation Protocol
 
 draft-zhu-intarea-gma-09.txt
 Date: 01/04/2021
 Authors: Jing Zhu, Satish Kanugovi
 Working Group: Individual Submissions (none)
 Formats: txt
Today, a device can be simultaneously connected to multiple networks, e.g. Wi-Fi, LTE, 5G, and DSL. It is desirable to combine them seamlessly below transport layer (L4) to improve quality of experience for applications that do not have such (multi-path) capability built in. Such optimization requires additional control information, e.g. Sequence Number, in each (IP) data packet. This document presents a new light weight and flexible encapsulation protocol for this need. The solution has been developed by the authors based on their experiences in multiple standards bodies including the IETF and 3GPP, is not an Internet Standard and does not represent the consensus opinion of the IETF. This document will enable other developers to build interoperable implementations.
 CoRE Resource Directory Extensions
 
 draft-amsuess-core-resource-directory-extensions-05.txt
 Date: 22/02/2021
 Authors: Christian Amsuess
 Working Group: Individual Submissions (none)
 Formats: xml txt html
A collection of extensions to the Resource Directory [I-D.ietf-core-resource-directory] that can stand on their own, and have no clear future in specification yet.
 Mathematical Mesh 3.0 Part IX: The Trust Mesh
 
 draft-hallambaker-mesh-trust-08.txt
 Date: 13/01/2021
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml html
This paper extends Shannon's concept of a 'work factor' as applied to evaluation of cryptographic algorithms to provide an objective measure of the practical security offered by a protocol or infrastructure design. Considering the hypothetical work factor based on an informed estimate of the probable capabilities of an attacker with unknown resources provides a better indication of the relative strength of protocol designs than the computational work factor of the best-known attack. The social work factor is a measure of the trustworthiness of a credential issued in a PKI based on the cost of having obtained the credential through fraud at a certain point in time. Use of the social work factor allows evaluation of Certificate Authority based trust models and peer to peer (Web of Trust) models to be evaluated in the same framework. The analysis demonstrates that both approaches have limitations and that in certain applications, a blended model is superior to either by itself. The final section of the paper describes a proposal to realize this blended model using the Mathematical Mesh. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-trust.html.
 Brand Indicators for Message Identification (BIMI)
 
 draft-blank-ietf-bimi-02.txt
 Date: 09/03/2021
 Authors: Seth Blank, Peter Goldstein, Thede Loder, Terry Zink, Marc Bradshaw
 Working Group: Individual Submissions (none)
 Formats: txt
Brand Indicators for Message Identification (BIMI) permits Domain Owners to coordinate with Mail User Agents (MUAs) to display brand- specific Indicators next to properly authenticated messages. There are two aspects of BIMI coordination: a scalable mechanism for Domain Owners to publish their desired Indicators, and a mechanism for Mail Transfer Agents (MTAs) to verify the authenticity of the Indicator. This document specifies how Domain Owners communicate their desired Indicators through the BIMI Assertion Record in DNS and how that record is to be interpreted by MTAs and MUAs. MUAs and mail- receiving organizations are free to define their own policies for making use of BIMI data and for Indicator display as they see fit.
 Receivers Guidance for Implementing Branded Indicators for Message Identification (BIMI)
 
 draft-brotman-ietf-bimi-guidance-03.txt
 Date: 09/03/2021
 Authors: Alex Brotman, Terry Zink, Marc Bradshaw
 Working Group: Individual Submissions (none)
 Formats: txt
This document is meant to assist receivers or other mailbox providers by providing guidance to implementing Brand Indicators for Message Identification (BIMI). This document is a companion to the main BIMI drafts which should first be consulted and reviewed.
 MPLS Extension Header Architecture
 
 draft-andersson-mpls-eh-architecture-01.txt
 Date: 11/03/2021
 Authors: Loa Andersson, Jim Guichard, Haoyu Song, Stewart Bryant
 Working Group: Individual Submissions (none)
 Formats: txt
Extension Headers (EH) carry information on in-network services and functions in an MPLS network. This document describes an architecture for EHs and what actions an EH capable Label Switching Router (LSR) takes when finding or not finding an EH in the packet. Multiprotocol Label Switching (MPLS) is a widely deployed forwarding technology. It uses label stack entries that are pre-pended to either the EH or the ACH which in turn is pre-pended to the payload. The label stack entries are used to identify the forwarding actions by each LSR. Actions may include pushing, swapping or popping the labels, and using the labels to determine the next hop for forwarding the packet. Labels may also be used to establish the context under which the packet is forwarded. The extension headers are carried after the MPLS Label Stack, and the presence of EHs are indicated in the label stack by an Extension Header Indicator (EHI).
 Illustrations for SRv6 Network Programming
 
 draft-filsfils-spring-srv6-net-pgm-illustration-04.txt
 Date: 30/03/2021
 Authors: Clarence Filsfils, Pablo Camarillo, Zhenbin Li, Satoru Matsushima, Bruno Decraene, Dirk Steinberg, David Lebrun, Robert Raszuk, John Leddy
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document illustrates how SRv6 Network Programming [RFC8986] can be used to create interoperable and protected overlays with underlay optimization and service programming.
 Options for MPLS Extension Header Indicator
 
 draft-song-mpls-eh-indicator-02.txt
 Date: 05/05/2021
 Authors: Haoyu Song, Zhenbin Li, Tianran Zhou, Loa Andersson
 Working Group: Individual Submissions (none)
 Formats: txt xml
The intention of this document is to enumerate and describe the candidate schemes that can be used to indicate the presence of the MPLS extension header(s) following the MPLS label stack. After a careful evaluation of these options by comparing their pros and cons, it is expected that one should be chosen as the final standard scheme for MPLS extension header indicator.
 IKEv2 Optional SA&TS Payloads in Child Exchange
 
 draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04.txt
 Date: 20/04/2021
 Authors: Sandeep Kampati, Wei Pan, Bharath Meduri, chenmeiling
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes a method for reducing the size of the Internet Key Exchange version 2 (IKEv2) exchanges at time of rekeying IKE SAs and Child SAs by removing or making optional of SA & TS payloads. Reducing size of IKEv2 exchanges is desirable for low power consumption battery powered devices. It also helps to avoid IP fragmentation of IKEv2 messages.
 MPLS Label Operations in MPLS EH capable networks
 
 draft-andersson-mpls-eh-label-stack-operations-01.txt
 Date: 11/03/2021
 Authors: Loa Andersson, Jim Guichard, Haoyu Song, Stewart Bryant
 Working Group: Individual Submissions (none)
 Formats: txt
Extension Headers (EH) carry information on in-network services and functions in an MPLS network. This document describes the operations on the MPLS label stack when an EH is found in the packet.
 Mathematical Mesh 3.0 Part II: Uniform Data Fingerprint.
 
 draft-hallambaker-mesh-udf-12.txt
 Date: 13/01/2021
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: html txt xml
This document describes the naming and addressing schemes used in the Mathematical Mesh. The means of generating Uniform Data Fingerprint (UDF) values and their presentation as text sequences and as URIs are described. A UDF consists of a binary sequence, the initial eight bits of which specify a type identifier code. Type identifier codes have been selected so as to provide a useful mnemonic indicating their purpose when presented in Base32 encoding. Two categories of UDF are described. Data UDFs provide a compact presentation of a fixed length binary data value in a format that is convenient for data entry. A Data UDF may represent a cryptographic key, a nonce value or a share of a secret. Fingerprint UDFs provide a compact presentation of a Message Digest or Message Authentication Code value. A Strong Internet Name (SIN) consists of a DNS name which contains at least one label that is a UDF fingerprint of a policy document controlling interpretation of the name. SINs allow a direct trust model to be applied to achieve end-to-end security in existing Internet applications without the need for trusted third parties. UDFs may be presented as URIs to form either names or locators for use with the UDF location service. An Encrypted Authenticated Resource Locator (EARL) is a UDF locator URI presenting a service from which an encrypted resource may be obtained and a symmetric key that may be used to decrypt the content. EARLs may be presented on paper correspondence as a QR code to securely provide a machine- readable version of the same content. This may be applied to automate processes such as invoicing or to provide accessibility services for the partially sighted. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html.
 Mathematical Mesh 3.0 Part III : Data At Rest Encryption (DARE)
 
 draft-hallambaker-mesh-dare-11.txt
 Date: 13/01/2021
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: xml txt html
This document describes the Data At Rest Encryption (DARE) Envelope and Container syntax. The DARE Envelope syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary content data. The DARE Container syntax describes an append-only sequence of entries, each containing a DARE Envelope. DARE Containers may support cryptographic integrity verification of the entire data container content by means of a Merkle tree. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html.
 The IPv6 Compact Routing Header (CRH)
 
 draft-bonica-6man-comp-rtg-hdr-24.txt
 Date: 07/01/2021
 Authors: Ron Bonica, Yuji Kamite, Andrew Alston, Daniam Henriques, Luay Jalil
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines two new Routing header types. Collectively, they are called the Compact Routing Headers (CRH). Individually, they are called CRH-16 and CRH-32.
 Transport parameters for 0-RTT connections
 
 draft-kuhn-quic-0rtt-bdp-08.txt
 Date: 22/02/2021
 Authors: Nicolas Kuhn, Stephan Emile, Gorry Fairhurst, Tom Jones
 Working Group: Individual Submissions (none)
 Formats: txt xml
0-RTT mechanisms reduce the time it takes for the first bytes of application data to be processed in a transport connection and can greatly reduce connection latency during setup. The 0-RTT transport features described by quic-transport help clients establish secure connections with a minimal number of round-trips. This document describes a generic method to exchange path parameters relating to transport. The additional transport parameters can help a connection that continues after an interruption or restarts by sharing connection properties. They can be used to increase the performance for a path with large RTT.
 Bidirectional Forwarding Detection (BFD) for EVPN Ethernet Segment Failover Use Case
 
 draft-zwm-bess-es-failover-03.txt
 Date: 15/11/2020
 Authors: Zheng Zhang, Yubao Wang, Greg Mirsky
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document introduces a method for fast switchover of Designated Forwarder for Ethernet Segment failover by using Bidirectional Forwarding Detection protocol.
 Support for Path MTU (PMTU) in the Path Computation Element (PCE) communication Protocol (PCEP).
 
 draft-li-pce-pcep-pmtu-04.txt
 Date: 06/05/2021
 Authors: Shuping Peng, Cheng Li, Liuyan Han, Luc-Fabrice Ndifor
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Since the SR does not require signaling, the path maximum transmission unit (MTU) information for SR path is not available. This document specify the extension to PCE communication protocol (PCEP) to carry path (MTU) in the PCEP messages.
 A YANG Data Model for Segment Routing (SR) Policy and SRv6 support in Path Computation Element Communications Protocol (PCEP)
 
 draft-li-pce-pcep-srv6-yang-03.txt
 Date: 22/02/2021
 Authors: Cheng Li, Siva Sivabalan, Shuping Peng, Mike Koldychev, Luc-Fabrice Ndifor
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document augments a YANG data model for the management of Path Computation Element Communications Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs in support for Segment Routing in IPv6 (SRv6) and SR Policy. The data model includes configuration data and state data (status information and counters for the collection of statistics).
 Encapsulation for BIER in Non-MPLS IPv6 Networks
 
 draft-xie-bier-ipv6-encapsulation-10.txt
 Date: 22/02/2021
 Authors: Jingrong Xie, Liang Geng, Mike McBride, Rajiv Asati, Senthil Dhanaraj, Yongqing Zhu, Zhuangzhuang Qin, MooChang Shin, Gyan Mishra, Xuesong Geng
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document proposes a BIER IPv6 (BIERv6) encapsulation for Non- MPLS IPv6 Networks using the IPv6 Destination Option extension header. This document updates RFC 8296.
 Composite Keys and Signatures For Use In Internet PKI
 
 draft-ounsworth-pq-composite-sigs-04.txt
 Date: 28/01/2021
 Authors: Mike Ounsworth, Massimiliano Pala
 Working Group: Individual Submissions (none)
 Formats: txt xml
With the widespread adoption of post-quantum cryptography will come the need for an entity to possess multiple public keys on different cryptographic algorithms. Since the trustworthiness of individual post-quantum algorithms is at question, a multi-key cryptographic operation will need to be performed in such a way that breaking it requires breaking each of the component algorithms individually. This requires defining new structures for holding composite public keys and composite signature data. This document defines the structures CompositePublicKey, CompositeSignatureValue, and CompositeParams, which are sequences of the respective structure for each component algorithm. This document also defines algorithms for generating and verifying composite signatures. This document makes no assumptions about what the component algorithms are, provided that their algorithm identifiers and signature generation and verification algorithms are defined.
 A YANG Data Model for Network Interconnect Tester Management
 
 draft-vassilev-bmwg-network-interconnect-tester-05.txt
 Date: 16/02/2021
 Authors: Vladimir Vassilev
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document introduces new YANG model for use in network interconnect testing containing modules of traffic generator and traffic analyzer.
 YANG data model for SFF
 
 draft-ao-sfc-yang-03.txt
 Date: 27/12/2020
 Authors: Ran Chen, Xufeng Liu, Huanan Chen, Wei Wei, Ting Ao
 Working Group: Individual Submissions (none)
 Formats: txt
This document is to define the YANG data model for SFF configuration.
 Requirements and Challenges for User-level Service Managements of IoT Network by utilizing Artificial Intelligence
 
 draft-choi-icnrg-aiot-05.txt
 Date: 23/11/2020
 Authors: Junkyun Choi, Jaeseob Han, Gyeong Lee, Na Kim
 Working Group: Individual Submissions (none)
 Formats: txt pdf
This document describes the requirements and challenges to employ artificial intelligence (AI) into the constraint Internet of Things (IoT) service environment for embedding intelligence and increasing efficiency. The IoT service environment includes heterogeneous and multiple IoT devices and systems that work together in a cooperative and intelligent way to manage homes, buildings, and complex autonomous systems. Therefore, it is becoming very essential to integrate IoT and AI technologies to increase the synergy between them. However, there are several limitations to achieve AI enabled IoT as the availability of IoT devices is not always high, and IoT networks cannot guarantee a certain level of performance in real-time applications due to resource constraints. This document intends to present a right direction to empower AI in IoT for learning and analyzing the usage behaviors of IoT devices/systems and human behaviors based on previous records and experiences. With AI enabled IoT, the IoT service environment can be intelligently managed in order to compensate for the unexpected performance degradation often caused by abnormal situations.
 BGP Flow Specification for SRv6
 
 draft-li-idr-flowspec-srv6-05.txt
 Date: 29/03/2021
 Authors: Zhenbin Li, Lei Li, Huaimo Chen, Christoph Loibl, Gyan Mishra, Yanhe Fan, Yongqing Zhu, Lei Liu, Xufeng Liu
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document proposes extensions to BGP Flow Specification for SRv6 for filtering SRv6 packets that match a sequence of conditions.
 Enhanced Topology Independent Loop-free Alternate Fast Re-route
 
 draft-li-rtgwg-enhanced-ti-lfa-04.txt
 Date: 05/05/2021
 Authors: Cheng Li, Zhibo Hu, Yongqing Zhu, Shraddha Hegde
 Working Group: Individual Submissions (none)
 Formats: xml txt
Topology Independent Loop-free Alternate Fast Re-route (TI-LFA) aims at providing protection of node and adjacency segments within the Segment Routing (SR) framework. A key aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the point of local repair. However, the TI-LFA FRR path may skip the node even if it is specified in the SID list to be traveled. This document defines Enhanced TI-LFA(TI-LFA+) by adding a No-bypass indicator for segments to ensure that the FRR route will not bypass the specific node, such as firewall. Also, this document defines No- bypass flag and No-FRR flag in SRH to indicate not to bypass nodes and not to perform FRR on all the nodes along the SRv6 path, respectively.
 Arm's Platform Security Architecture (PSA) Attestation Token
 
 draft-tschofenig-rats-psa-token-08.txt
 Date: 24/03/2021
 Authors: Hannes Tschofenig, Simon Frost, Mathias Brossard, Adrian Shaw, Thomas Fossati
 Working Group: Individual Submissions (none)
 Formats: xml html txt
The Platform Security Architecture (PSA) is a family of hardware and firmware security specifications, as well as open-source reference implementations, to help device makers and chip manufacturers build best-practice security into products. Devices that are PSA compliant are able to produce attestation tokens as described in this memo, which are the basis for a number of different protocols, including secure provisioning and network access control. This document specifies the PSA attestation token structure and semantics. The PSA attestation token is a profiled Entity Attestation Token (EAT). This specification describes what claims are used in an attestation token generated by PSA compliant systems, how these claims get serialized to the wire, and how they are cryptographically protected.
 Weighted HRW and its applications
 
 draft-mohanty-bess-weighted-hrw-02.txt
 Date: 08/12/2020
 Authors: satyamoh@cisco.com, Mankamana Mishra, Acee Lindem, Ali Sajassi, John Drake
 Working Group: Individual Submissions (none)
 Formats: xml txt
Rendezvous Hashing also known as Highest Random Weight (HRW) has been used in many load balancing applications where the central problem is how to map an object to as server such that the mapping is uniform and also minimally affected by the change in the server set. Recently, it has found use in DF election algorithms in the EVPN context and load balancing using DMZ. This draft deals with the problem of achieving load balancing with minimal disruption when the servers have different weights. It provides an algorithm to do so and also describes a few use-case scenarios where this algorithmic technique can apply.
 On Media-Types,Content-Types,and related terminology
 
 draft-bormann-core-media-content-type-format-04.txt
 Date: 22/02/2021
 Authors: Carsten Bormann, Henk Birkholz
 Working Group: Individual Submissions (none)
 Formats: html xml txt
There is a lot of confusion about media-types, content-types, and related terminology. This memo is an attempt at clearing it up, so we can use consistent terminology in CoRE and related specifications. It also defines some ABNF that can be used in these specifications.
 Urban Air Mobility Implications for Intelligent Transportation Systems
 
 draft-templin-ipwave-uam-its-04.txt
 Date: 04/01/2021
 Authors: Fred Templin
 Working Group: Individual Submissions (none)
 Formats: txt xml
Urban Air Mobility concerns the introduction of manned and unmanned aircraft within urban environments, while Intelligent Transportation Systems have traditionally considered only terrestrial vehicles operating on city streets and highways. This document considers the implications for introduction of low-altitude aircraft within urban environments operating in harmony with ground transportation.
 Multi-Subject JSON Web Token (JWT)
 
 draft-yusef-oauth-nested-jwt-04.txt
 Date: 10/03/2021
 Authors: Rifaat Shekh-Yusef
 Working Group: Individual Submissions (none)
 Formats: txt xml
This specification defines a mechanism for including multiple subjects in a JWT. A primary subject in an enclosing JWT with its own claims, and a related subject in a nested JWT with its own claims.
 Autonomic setup of fog monitoring agents
 
 draft-bernardos-anima-fog-monitoring-03.txt
 Date: 19/11/2020
 Authors: Carlos Bernardos, Alain Mourad
 Working Group: Individual Submissions (none)
 Formats: txt
The concept of fog computing has emerged driven by the Internet of Things (IoT) due to the need of handling the data generated from the end-user devices. The term fog is referred to any networked computational resource in the continuum between things and cloud. In fog computing, functions can be stiched together composing a service function chain. These functions might be hosted on resources that are inherently heterogeneous, volatile and mobile. This means that resources might appear and disappear, and the connectivity characteristics between these resources may also change dynamically. This calls for new orchestration solutions able to cope with dynamic changes to the resources in runtime or ahead of time (in anticipation through prediction) as opposed to today's solutions which are inherently reactive and static or semi-static. A fog monitoring solution can be used to help predicting events so an action can be taken before an event actually takes place. This solution is composed of agents running on the fog nodes plus a controller hosted at another device (running in the infrastructure or in another fog node). Since fog environments are inherently volatile and extremely dynamic, it is convenient to enable the use of autonomic technologies to autonomously set-up the fog monitoring platform. This document aims at presenting this use case as well as specifying how to use GRASP as needed in this scenario.
 In Situ OAM Profiles
 
 draft-mizrahi-ippm-ioam-profile-04.txt
 Date: 17/02/2021
 Authors: Tal Mizrahi, Frank Brockners, Shwetha Bhandari, Ramesh Sivakolundu, Carlos Pignataro, Aviv Kfir, Barak Gafni, Mickey Spiegel, Tianran Zhou, Jennifer Lemon
 Working Group: Individual Submissions (none)
 Formats: txt
In Situ Operations, Administration and Maintenance (IOAM) is used for monitoring network performance and for detecting traffic bottlenecks and anomalies. This is achieved by incorporating IOAM data into in- flight data packets. This document introduces the concept of use case-driven IOAM profiles. An IOAM profile defines a use case or a set of use cases for IOAM, and an associated set of rules that restrict the scope and features of the IOAM specification, thereby limiting it to a subset of the full functionality. The motivation for defining profiles is to limit the scope of IOAM features, allowing simpler implementation, verification, and interoperability testing in the context of specific use cases that do not require the full functionality of IOAM.
 DCCP Extensions for Multipath Operation with Multiple Addresses
 
 draft-amend-tsvwg-multipath-dccp-04.txt
 Date: 22/02/2021
 Authors: Markus Amend, Dirk Hugo, Anna Brunstrom, Andreas Kassler, Veselin Rakocevic, Stephen Johnson
 Working Group: Individual Submissions (none)
 Formats: xml html txt
DCCP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a DCCP session could improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failures. This document presents a set of extensions to traditional DCCP to support multipath operation. Multipath DCCP provides the ability to simultaneously use multiple paths between peers. The protocol offers the same type of service to applications as DCCP and it provides the components necessary to establish and use multiple DCCP flows across potentially disjoint paths.
 OPAQUE with TLS 1.3
 
 draft-sullivan-tls-opaque-01.txt
 Date: 22/02/2021
 Authors: Nick Sullivan, Hugo Krawczyk, Owen Friel, Richard Barnes
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes two mechanisms for enabling the use of the OPAQUE password-authenticated key exchange in TLS 1.3.
 Time-Based Uni-Directional Attestation
 
 draft-birkholz-rats-tuda-04.txt
 Date: 13/01/2021
 Authors: Andreas Fuchs, Henk Birkholz, Ira McDonald, Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines the method and bindings used to convey Evidence via Time-based Uni-Directional Attestation (TUDA) in Remote ATtestation procedureS (RATS). TUDA does not require a challenge- response handshake and thereby does not rely on the conveyance of a nonce to prove freshness of remote attestation Evidence. TUDA enables the creation of Secure Audit Logs that can constitute believable Evidence about both current and past operational states of an Attester. In TUDA, RATS entities require access to a Handle Distributor to which a trustable and synchronized time-source is available. The Handle Distributor takes on the role of a Time Stamp Authority (TSA) to distribute Handles incorporating Time Stamp Tokens (TST) to the RATS entities. RATS require an Attesting Environment that generates believable Evidence. While a TPM is used as the corresponding root of trust in this specification, any other type of root of trust can be used with TUDA.
 SRv6 Implementation and Deployment Status
 
 draft-matsushima-spring-srv6-deployment-status-11.txt
 Date: 17/02/2021
 Authors: Satoru Matsushima, Clarence Filsfils, Zafar Ali, Zhenbin Li, Kalyani Rajaraman
 Working Group: Individual Submissions (none)
 Formats: txt
This draft provides an overview of IPv6 Segment Routing (SRv6) deployment status. It lists various SRv6 features that have been deployed in the production networks. It also provides an overview of SRv6 implementation and interoperability testing status.
 The SODP (Secure Object Delivery Protocol) Server Interfaces: NSA's Profile for Delivery of Certificates,CRLs,and Symmetric Keys to Clients
 
 draft-turner-sodp-profile-08.txt
 Date: 08/09/2020
 Authors: Michael Jenkins, Sean Turner
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies protocol interfaces profiled by the US NSA (United States National Security Agency) for NSS (National Security System) servers that provide public key certificates, CRLs (Certificate Revocation Lists), and symmetric keys to NSS clients. Servers that support these interfaces are referred to as SODP (Secure Object Delivery Protocol) servers. The intended audience for this profile comprises developers of client devices that will obtain key management services from NSA-operated SODP servers. Interfaces supported by SODP servers include: EST (Enrollment over Secure Transport) and its extensions as well as CMC (Certificate Management over CMS (Cryptographic Message Syntax)). This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems (SP 800- 59). It is also appropriate for other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.
 Hybrid Post-Quantum Key Encapsulation Methods (PQ KEM) for Transport Layer Security 1.2 (TLS)
 
 draft-campagna-tls-bike-sike-hybrid-06.txt
 Date: 09/03/2021
 Authors: Matt Campagna, Eric Crockett
 Working Group: Individual Submissions (none)
 Formats: pdf xml txt
Hybrid key exchange refers to executing two independent key exchanges and feeding the two resulting shared secrets into a Pseudo Random Function (PRF), with the goal of deriving a secret which is as secure as the stronger of the two key exchanges. This document describes new hybrid key exchange schemes for the Transport Layer Security 1.2 (TLS) protocol. The key exchange schemes are based on combining Elliptic Curve Diffie-Hellman (ECDH) with a post-quantum key encapsulation method (PQ KEM) using the existing TLS PRF.
 Vehicular Mobility Management for IP-Based Vehicular Networks
 
 draft-jeong-ipwave-vehicular-mobility-management-05.txt
 Date: 21/02/2021
 Authors: Jaehoon Jeong, Bien Mugabarigira, Yiwen Shen, Zhong Xiang
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies a Vehicular Mobility Management (VMM) scheme for IP-based vehicular networks. The VMM scheme takes advantage of a vehicular link model based on a multi-link subnet. With a vehicle's mobility information (e.g., position, speed, acceleration/ deceleration, and direction) and navigation path (i.e., trajectory), it can provide a moving vehicle with proactive and seamless handoff along with its trajectory.
 Mathematical Mesh 3.0 Part V: Protocol Reference
 
 draft-hallambaker-mesh-protocol-08.txt
 Date: 13/01/2021
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: html txt xml
The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The core protocols of the Mesh are described with examples of common use cases and reference data. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-protocol.html.
 Mathematical Mesh 3.0 Part IV: Schema Reference
 
 draft-hallambaker-mesh-schema-07.txt
 Date: 13/01/2021
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: xml html txt
The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The core protocols of the Mesh are described with examples of common use cases and reference data. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html.
 Datagram PLPMTUD for UDP Options
 
 draft-fairhurst-tsvwg-udp-options-dplpmtud-04.txt
 Date: 01/04/2021
 Authors: Gorry Fairhurst, Tom Jones
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies how a UDP Options sender implements Datagram Packetization Layer Path Maximum Transmission Unit Discovery (DPLPMTUD) as a robust method for Path Maximum Transmission Unit Discovery. This is a robust method for Path MTU Discovery (PMTUD) that uses the UDP Options Packetization Layer (PL). It allows a datagram application that uses this PL, to discover the largest size of datagram that can be sent across a network path.
 IPv6 Neighbor Discovery on Wireless Networks
 
 draft-thubert-6man-ipv6-over-wireless-08.txt
 Date: 24/11/2020
 Authors: Pascal Thubert
 Working Group: Individual Submissions (none)
 Formats: xml html txt
This document describes how the original IPv6 Neighbor Discovery and Wireless ND (WiND) can be applied on various abstractions of wireless media.
 In-Network Computing for App-Centric Micro-Services
 
 draft-sarathchandra-coin-appcentres-04.txt
 Date: 26/01/2021
 Authors: Dirk Trossen, Chathura Sarathchandra, Michael Boniface
 Working Group: Individual Submissions (none)
 Formats: txt
The application-centric deployment of 'Internet' services has increased over the past ten years with many millions of applications providing user-centric services, executed on increasingly more powerful smartphones that are supported by Internet-based cloud services in distributed data centres, the latter mainly provided by large scale players such as Google, Amazon and alike. This draft outlines a vision for evolving those data centres towards executing app-centric micro-services; we dub this evolved data centre as an AppCentre. Complemented with the proliferation of such AppCentres at the edge of the network, they will allow for such micro-services to be distributed across many places of execution, including mobile terminals themselves, while specific micro-service chains equal today's applications in existing smartphones. We outline the key enabling technologies that needs to be provided for such evolution to be realized, including references to ongoing standardization efforts in key areas.
 BGP-LS Filters : A Framework for Network Slicing and Enhanced VPNs
 
 draft-drake-bess-enhanced-vpn-06.txt
 Date: 04/02/2021
 Authors: John Drake, Adrian Farrel, Luay Jalil, Avinash Lingala
 Working Group: Individual Submissions (none)
 Formats: txt xml
Future networks that support advanced services, such as those enabled by 5G mobile networks, envision a set of overlay networks each with different performance and scaling properties. These overlays are known as network slices and are realized over a common underlay network. In the context of IETF technologies, they are known as IETF network slices. In order to support IETF network slicing, as well as to offer enhanced VPN services in general, it is necessary to define a mechanism by which specific resources (links and/or nodes) of an underlay network can be used by a specific network slice, VPN, or set of VPNs. This document sets out such a mechanism for use in Segment Routing networks.
 Public Key Authenticated Encryption for JOSE: ECDH-1PU
 
 draft-madden-jose-ecdh-1pu-04.txt
 Date: 06/05/2021
 Authors: Neil Madden
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the ECDH-1PU public key authenticated encryption algorithm for JWE. The algorithm is similar to the existing ECDH-ES encryption algorithm, but adds an additional ECDH key agreement between static keys of the sender and recipient. This additional step allows the recipient to be assured of sender authenticity without requiring a nested signed-then-encrypted message structure.
 Use of the Walnut Digital Signature Algorithm with CBOR Object Signing and Encryption (COSE)
 
 draft-atkins-suit-cose-walnutdsa-07.txt
 Date: 26/01/2021
 Authors: Derek Atkins
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies the conventions for using the Walnut Digital Signature Algorithm (WalnutDSA) for digital signatures with the CBOR Object Signing and Encryption (COSE) syntax. WalnutDSA is a lightweight, quantum-resistant signature scheme based on Group Theoretic Cryptography with implementation and computational efficiency of signature verification in constrained environments, even on 8- and 16-bit platforms. The goal of this publication is to document a way to use the lightweight, quantum-resistant WalnutDSA signature algorithm in COSE in a way that would allow multiple developers to build compatible implementations. As of this publication, the security properties of WalnutDSA have not been evaluated by the IETF and its use has not been endorsed by the IETF. WalnutDSA(TM) and Walnut Digital Signature Algorithm(TM) are trademarks of Veridify Security Inc..
 IS-IS Extensions To Support The IPv6 Compressed Routing Header (CRH)
 
 draft-bonica-lsr-crh-isis-extensions-04.txt
 Date: 08/03/2021
 Authors: Parag Kaneriya, Rejesh Shetty, Shraddha Hegde, Ron Bonica
 Working Group: Individual Submissions (none)
 Formats: xml txt
Source nodes can use the IPv6 Compressed Routing Header (CRH) to steer packets through a specified path. This document defines IS-IS extensions that support the CRH.
 Security Considerations for SRv6 Networks
 
 draft-li-spring-srv6-security-consideration-06.txt
 Date: 05/05/2021
 Authors: Cheng Li, Zhenbin Li, Chongfeng Xie, Hui Tian, Jianwei Mao
 Working Group: Individual Submissions (none)
 Formats: txt xml
SRv6 inherits potential security vulnerabilities from Source Routing in general, and also from IPv6. This document describes various threats and security concerns related to SRv6 networks and existing approaches to solve these threats.
 The Cooperative Communication Method of the Converged Multi-media Wireless Resource Management Network
 
 draft-liu-mwrmn-03.txt
 Date: 15/11/2020
 Authors: Yi Liu
 Working Group: Individual Submissions (none)
 Formats: txt xml
This paper describes a cooperative communication method of theconverged multi-media wireless resource management network.It can maximize the utilization of heterogeneous network resources and optimize the access to wireless resources of the network in the form of Mesh, which solves the problem of collaborative wireless resource management in multi-media converged networks. Through the overall consideration of multi-media converged networks including wired network, wireless network, broadband network, and narrowband network, joint access control and resource scheduling for network devices with different characteristics in heterogeneous networks are realized.
 Design of the native Cyberspace Map
 
 draft-jilongwang-opsawg-cybersmap-03.txt
 Date: 14/12/2020
 Authors: Jilong Wang, Miao Congcong, Changqing An, Shuying Zhuang
 Working Group: Individual Submissions (none)
 Formats: txt xml
This memo discusses the design of the native cyberspace map which is stable and flexible to describe cyberspace. Although we have accepted the cyberspace as a parallel new world, we even have not defined its basic coordinate system, which means cyberspace have no its basic space dimension till now. The objective of this draft is to illustrate the basic design methodology of the native coordinate system of cyberspace, and show how to design cyberspace map on this basis.
 A Framework for Constructing Service Function Chaining Systems Based on Segment Routing
 
 draft-li-spring-sr-sfc-control-plane-framework-04.txt
 Date: 05/05/2021
 Authors: Cheng Li, Ahmed El Sawaf, Ruizhao Hu, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: xml txt
Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological sub-paths, called "segments". Segment routing architecture can be implemented over an MPLS data plane as well as an IPv6 data plane. Service Function Chaining (SFC) provides support for the creation of composite services that consist of an ordered set of Service Functions (SF) that are to be applied to packets and/or frames selected as a result of classification. SFC can be implemented based on several technologies, such as Network Service Header (NSH) and SR. This document describes a framework for constructing SFC based on Segment Routing. The document reviews the control plane solutions for route distribution of service function instance and service function path, and steering packets into a service function chain.
 Multicast-only Fast Reroute Based on Topology Independent Loop-free Alternate Fast Reroute
 
 draft-liu-pim-mofrr-tilfa-03.txt
 Date: 20/02/2021
 Authors: Yisong Liu, Mike McBride, Zheng Zhang, Jingrong Xie
 Working Group: Individual Submissions (none)
 Formats: txt
Multicast-only Fast Reroute (MoFRR) has been defined in [RFC7431], but the selection of the secondary multicast next hop only according to the loop-free alternate fast reroute, which has restrictions in multicast deployments. This document describes a mechanism for Multicast-only Fast Reroute by using Topology Independent Loop-free Alternate fast reroute, which is independent of network topology and can achieve covering more network environments.
 Guidelines for Internet Congestion Control at Endpoints
 
 draft-fairhurst-tsvwg-cc-05.txt
 Date: 17/11/2020
 Authors: Gorry Fairhurst
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document is for discussion by the TSVWG. It provides guidance on the design of methods to avoid congestion collapse and to provide congestion control. Recommendations and requirements on this topic are distributed across many documents in the RFC series. This therefore seeks to gather and consolidate these recommendations in an annexe. Based on these specifications, and Internet engineering experience, the document provides input to the design of new congestion control methods in protocols. The present document is for discussion and comment by the IETF. If published, it plans to update or replace the Best Current Practice in BCP 41, which currently includes "Congestion Control Principles" provided in RFC2914.
 Preferred Path Loop-Free Alternate (pLFA)
 
 draft-bryant-rtgwg-plfa-01.txt
 Date: 22/12/2020
 Authors: Stewart Bryant, Uma Chunduri, Toerless Eckert
 Working Group: Individual Submissions (none)
 Formats: txt xml
Fast re-route (FRR) is a technique that allows productive forwarding to continue in a network after a failure has occurred, but before the network has has time to re-converge. This is achieved by forwarding a packet on an alternate path that will not result in the packet looping. Preferred Path Routing (PPR) provides a method of injecting explicit paths into the routing protocol. The use of PPR to support FRR has a number of advantages. This document describes the advantages of using PPR to provide a loop-free alternate FRR path, and provides a framework for its use in this application.
 PCEP Operational Clarification
 
 draft-koldychev-pce-operational-03.txt
 Date: 19/02/2021
 Authors: Mike Koldychev, Siva Sivabalan, Shuping Peng, Diego Achaval, Hari Kotni
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document is meant to provide better clarity about how PCEP operates and hence to facilitate better interoperability between different equipment vendors. The content of this document has been compiled based on the feedback from several multi-vendor interop exercises. Several constructs are introduced to facilitate this, such as the LSP-DB and the ASSO-DB.
 Carrying SID Algorithm information in PCE-based Networks.
 
 draft-tokar-pce-sid-algo-03.txt
 Date: 22/02/2021
 Authors: Alexej Tokar, Samuel Sidor, Siva Sivabalan, Shuping Peng, Mahendra Negi
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Algorithm associated with a prefix Segment-ID (SID) defines the path computation Algorithm used by Interior Gateway Protocols (IGPs). This information is available to controllers such as the Path Computation Element (PCE) via topology learning. This document proposes an approach for informing headend routers regarding the Algorithm associated with each prefix SID used in PCE-computed paths, as well as signalling a specific SID algorithm as a constraint to the PCE.
 Using GOST ciphers in ESP and IKEv2
 
 draft-smyslov-esp-gost-05.txt
 Date: 26/04/2021
 Authors: Valery Smyslov
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a set of encryption transforms for use in the Encapsulating Security Payload (ESP) and in the Internet Key Exchange version 2 (IKEv2) protocols. The transforms are based on Russian cryptographic standard algorithms (GOST) in a Multilinear Galois Mode (MGM).
 BMP Extension for Path Status TLV
 
 draft-cppy-grow-bmp-path-marking-tlv-08.txt
 Date: 27/04/2021
 Authors: Camilo Cardona, Paolo Lucente, Pierre Francois, Yunan Gu, Thomas Graf
 Working Group: Individual Submissions (none)
 Formats: xml txt
The BGP Monitoring Protocol (BMP) provides an interface for obtaining BGP Path information. BGP Path Information is conveyed within BMP Route Monitoring (RM) messages. This document proposes an extension to BMP to convey the status of a BGP path before and after being processed by the BGP best-path selection algorithm. This extension makes use of the TLV mechanims described in draft-ietf-grow-bmp-tlv [I-D.ietf-grow-bmp-tlv] and draft-lucente-grow-bmp-tlv-ebit [I-D.lucente-grow-bmp-tlv-ebit].
 Group OSCORE Profile of the Authentication and Authorization for Constrained Environments Framework
 
 draft-tiloca-ace-group-oscore-profile-05.txt
 Date: 22/02/2021
 Authors: Marco Tiloca, Rikard Hoeglund, Ludwig Seitz, Francesca Palombini
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. The profile uses Group OSCORE to provide communication security between a Client and a (set of) Resource Server(s) as members of an OSCORE Group. The profile securely binds an OAuth 2.0 Access Token with the public key of the Client associated to the signing private key used in the OSCORE group. The profile uses Group OSCORE to achieve server authentication, as well as proof-of-possession for the Client's public key. Also, it provides proof of the Client's membership to the correct OSCORE group, by binding the Access Token to information from the Group OSCORE Security Context, thus allowing the Resource Server(s) to verify the Client's membership upon receiving a message protected with Group OSCORE from the Client.
 SR Path Ingress Protection
 
 draft-chen-idr-sr-ingress-protection-04.txt
 Date: 29/04/2021
 Authors: Huaimo Chen, Mehmet Toy, Aijun Wang, Zhenqiang Li, Lei Liu, Xufeng Liu
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes extensions to Border Gateway Protocol (BGP) for protecting the ingress node of a Segment Routing (SR) tunnel or path.
 SR Path Ingress Protection
 
 draft-chen-pce-sr-ingress-protection-05.txt
 Date: 29/04/2021
 Authors: Huaimo Chen, Mehmet Toy, Aijun Wang, Zhenqiang Li, Lei Liu, Xufeng Liu
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes extensions to Path Computation Element (PCE) communication Protocol (PCEP) for protecting the ingress node of a Segment Routing (SR) tunnel or path.
 Test Tools for IoT DDoS vulnerability scanning
 
 draft-faibish-iot-ddos-usecases-04.txt
 Date: 21/12/2020
 Authors: Sorin Faibish, Mashruf Chowdhury
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies several usecases related to the different ways IoT devices are exploited by malicious adversaries to instantiate Distributed Denial of Services (DDoS) attacks. The attacks are generted from IoT devices that have no proper protection against generating unsolicited communication messages targeting a certain network and creating large amounts of network traffic. The attackers take advantage of breaches in the configuration data in unprotected IoT devices exploited for DDoS attacks. The attackers take advantage of the IoT devices that can send network packets that were generated by malicious code that interacts with an OS implementation that runs on the IoT devices. The prupose of this draft is to present possible IoT DDoS usecases that need to be prevented by TEE. The major enabler of such attacks is related to IoT devices that have no OS or unprotected EE OS and run code that is downloaded to them from the TA and modified by man-in-the-middle that inserts malicious code in the OS. This draft adds list of MUD files for most IoT devices.
 Distributed SFC control for fog environments
 
 draft-bernardos-sfc-distributed-control-03.txt
 Date: 18/01/2021
 Authors: Carlos Bernardos, Alain Mourad
 Working Group: Individual Submissions (none)
 Formats: txt
Service function chaining (SFC) allows the instantiation of an ordered set of service functions and subsequent "steering" of traffic through them. In order to set up and maintain SFC instances, a control plane is required, which typically is centralized. In certain environments, such as fog computing ones, such centralized control might not be feasible, calling for distributed SFC control solutions. This document introduces the role of SFC pseudo- controller and specifies solutions to select and initialize such new logical function.
 Protocol Assisted Protocol (PASP)
 
 draft-li-rtgwg-protocol-assisted-protocol-04.txt
 Date: 19/02/2021
 Authors: Zhenbin Li, Shuanglong Chen, Yingzhen Qu, Yunan Gu
 Working Group: Individual Submissions (none)
 Formats: txt
For routing protocol troubleshooting, different approaches exibit merits w.r.t. different situations. They can be generally divided into two categories, the distributive way and the centralized way. A very commonly used distributive approach is to log in possiblly all related devices one by one to check massive data via CLI. Such approach provides very detailed device information, however it requires operators with high NOC (Network Operation Center) experience and suffers from low troubleshooting efficiency and high cost. The centralized approach is realized by collecting data from devices via approaches, like the streaming Telemetry or BMP(BGP Monitoring Protocol) RFC7854 [RFC7854], for the centralized server to analyze all gathered data. Such approach allows a comprehensive view fo the whole network and facilitates automated troubleshooting, but is limited by the data collection boundary set by different management domains, as well as high network bandwidth and CPU computation costs. This document proposes a semi-distributive and semi-centralized approach for fast routing protocol troubleshooting, localizing the target device and possibly the root cause, more precisely. It defines a new protocol, called the PASP (Protocol assisted Protocol), for devices to exchange protocol related information between each other in both active and on-demand manners. It allow devices to request specific information from other devices and receive replies to the requested data. It also allows actively transmission of information without request to inform other devices to better react w.r.t. network issues.
 Encapsulation of Path Segment in SRv6
 
 draft-li-6man-srv6-path-segment-encap-06.txt
 Date: 08/05/2021
 Authors: Cheng Li, Weiqiang Cheng, Yongqing Zhu, Zhenbin Li, Dhruv Dhody
 Working Group: Individual Submissions (none)
 Formats: xml txt
Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding an ordered list of instructions, called "segments". The SR architecture can be implemented over an IPv6 data plane, called SRv6. In some use-cases such as end-to-end SR Path Protection and Performance Measurement (PM), an SRv6 path needs to be identified. An SRv6 Path Segment can be used for identifying an SRv6 path. This document defines a P-flag in the Segment Routing Header to indicate the appearence of SRv6 Path Segment.
 Application-aware IPv6 Networking (APN6) Encapsulation
 
 draft-li-6man-app-aware-ipv6-network-03.txt
 Date: 22/02/2021
 Authors: Zhenbin Li, Shuping Peng, Cong Li, Chongfeng Xie, Dan Voyer, Xing Li, Peng Liu, Chang Liu, Kentaro Ebisawa
 Working Group: Individual Submissions (none)
 Formats: xml txt
Application-aware IPv6 Networking (APN6) framework makes use of IPv6 encapsulation in order to convey the application-aware information along with the data packet to the network so to facilitate the service deployment and SLA guarantee. This document defines the encodings of the application characteristic information, for the APN6 framework, that can be exchanged between an application or a network edge device such as CPE (Customer-Premises Equipment) and the network infrastructure through the use of IPv6 extension headers.
 Network Programming extension: SRv6 uSID instruction
 
 draft-filsfils-spring-net-pgm-extension-srv6-usid-10.txt
 Date: 10/03/2021
 Authors: Clarence Filsfils, Pablo Camarillo, Dezhong Cai, Dan Voyer, Israel Meilik, Keyur Patel, Wim Henderickx, Prem Jonnalagadda, David Melman, Yisong Liu, Jim Guichard
 Working Group: Individual Submissions (none)
 Formats: xml txt
The SRv6 "micro segment" (SRv6 uSID or uSID for short) instruction is a straightforward extension of the SRv6 Network Programming model: o The SRv6 Control Plane is leveraged without any change o The SRH dataplane encapsulation is leveraged without any change o Any SID in the SID list can carry micro segments o Based on the Compressed SRv6 Segment List Encoding in SRH
 Describing Protocol Data Units with Augmented Packet Header Diagrams
 
 draft-mcquistin-augmented-ascii-diagrams-08.txt
 Date: 05/05/2021
 Authors: Stephen McQuistin, Vivian Band, Dejice Jacob, Colin Perkins
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a machine-readable format for specifying the syntax of protocol data units within a protocol specification. This format is comprised of a consistently formatted packet header diagram, followed by structured explanatory text. It is designed to maintain human readability while enabling support for automated parser generation from the specification document. This document is itself an example of how the format can be used.
 HTTP Transport Authentication
 
 draft-schinazi-httpbis-transport-auth-05.txt
 Date: 12/03/2021
 Authors: David Schinazi
 Working Group: Individual Submissions (none)
 Formats: xml txt html
The most common existing authentication mechanisms for HTTP are sent with each HTTP request, and authenticate that request instead of the underlying HTTP connection, or transport. While these mechanisms work well for existing uses of HTTP, they are not suitable for emerging applications that multiplex non-HTTP traffic inside an HTTP connection. This document describes the HTTP Transport Authentication Framework, a method of authenticating not only an HTTP request, but also its underlying transport.
 EVPN Interoperability Modes
 
 draft-krattiger-evpn-modes-interop-03.txt
 Date: 28/01/2021
 Authors: Lukas Krattiger, Ali Sajassi, Samir Thoria, Jorge Rabadan, John Drake
 Working Group: Individual Submissions (none)
 Formats: txt
Ethernet VPN (EVPN) provides different functional modes in the area of Service Interface, Integrated Route and Bridge (IRB) and IRB Core connectivity. This document specifies how the different EVPN functional modes and types can interoperate with each other. This document doesn't aim to redefine the existing functional modes but extend them for interoperability.
 Indication of Local DNS Privacy Service During User Access
 
 draft-yan-dprive-local-service-indication-04.txt
 Date: 13/12/2020
 Authors: Zhiwei Yan, Guanggang Geng, Yang Liu, Xinchang Zhang, Xiaomin Zhu
 Working Group: Individual Submissions (none)
 Formats: txt
This document aims to support the indication of privacy service capability of recursive resolver during the end-user accesses the network.
 PCEP Extension for SR-MPLS Entropy Label Position
 
 draft-peng-pce-entropy-label-position-05.txt
 Date: 19/02/2021
 Authors: Shaofu Peng, Quan Xiong, Fengwei Qin
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document proposes a set of extensions for PCEP to configure the entropy label position for SR-MPLS networks.
 PCE TE Constraints for Network Slicing
 
 draft-peng-pce-te-constraints-05.txt
 Date: 11/04/2021
 Authors: Shaofu Peng, Quan Xiong, Fengwei Qin
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document proposes a set of extensions for PCEP to support the TE constraints of network slicing during path computation, e.g, IGP instance, virtual network, Slice-id, specific application, color template and FA-id etc.
 Maintaining CCNx or NDN flow balance with highly variable data object sizes
 
 draft-oran-icnrg-flowbalance-05.txt
 Date: 14/02/2021
 Authors: David Oran
 Working Group: Individual Submissions (none)
 Formats: html txt xml
Deeply embedded in some ICN architectures, especially Named Data Networking (NDN) and Content-Centric Networking (CCNx) is the notion of flow balance. This captures the idea that there is a one-to-one correspondence between requests for data, carried in Interest messages, and the responses with the requested data object, carried in Data messages. This has a number of highly beneficial properties for flow and congestion control in networks, as well as some desirable security properties. For example, neither legitimate users nor attackers are able to inject large amounts of un-requested data into the network. Existing congestion control approaches however have a difficult time dealing effectively with a widely varying MTU of ICN data messages, because the protocols allow a dynamic range of 1-64K bytes. Since Interest messages are used to allocate the reverse link bandwidth for returning Data, there is large uncertainty in how to allocate that bandwidth. Unfortunately, most current congestion control schemes in CCNx and NDN only count Interest messages and have no idea how much data is involved that could congest the inverse link. This document proposes a method to maintain flow balance by accommodating the wide dynamic range in Data message size.
 Support for Data Reduction Attributes in nfsv4 Version 2
 
 draft-faibish-nfsv4-data-reduction-attributes-04.txt
 Date: 21/12/2020
 Authors: Sorin Faibish, Philip Shilane
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes extending NFSv4 operations to add new RECOMMENDED attributes to be used in the protocol to provide information about the data reduction properties of files. The new data reduction attributes are proposed to allow the client application to communicate to the NFSv4 server data reduction attributes associated with files and directories using new metadata, communicated to the Block Storage data reduction engines. Corresponding new RECOMMENDED attributes are proposed to allow clients and client applications to query the server for data reduction attributes support and allow to get and set data reduction attributes on files and directories. Such data reduction metadata is used as hints to the file server about what type of data reduction to apply. The proposed data reduction attributes include achievable ratios for compression and deduplication plus whether each data reduction technique applies to a file or directory.
 YANG Data Model for OSPFv3 Segment Routing
 
 draft-acee-lsr-ospfv3-sr-yang-04.txt
 Date: 29/04/2021
 Authors: Acee Lindem, Yingzhen Qu
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a YANG data module augmenting the IETF OSPF Segment Routing (SR) YANG model to support OSPFv3 extensions for SR. It can be used to configure and manage OSPFv3 Segment Routing in MPLS data plane.
 Commercial National Security Algorithm (CNSA) Suite Profile for TLS and DTLS 1.2 and 1.3
 
 draft-cooley-cnsa-dtls-tls-profile-07.txt
 Date: 20/01/2021
 Authors: Dorothy Cooley
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a base profile for TLS protocol versions 1.2 and 1.3, as well as DTLS protocol versions 1.2 and 1.3 for use with the United States Commercial National Security Algorithm (CNSA) Suite. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that use TLS or DTLS. It is also appropriate for all other US Government systems that process high-value information. The profile is made publicly available here for use by developers and operators of these and any other system deployments.
 OAuth 2.0 Client Intermediary Metadata
 
 draft-parecki-oauth-client-intermediary-metadata-03.txt
 Date: 22/02/2021
 Authors: Aaron Parecki
 Working Group: Individual Submissions (none)
 Formats: xml txt
This specification defines a mechanism for including information about additional parties involved in an OAuth transaction by adding a new section to the OAuth 2.0 Dynamic Client Registration request, as well as requires that authorization servers surface this information to users during an OAuth transaction.
 BRSKI Cloud Registrar
 
 draft-friel-anima-brski-cloud-04.txt
 Date: 06/04/2021
 Authors: Owen Friel, Rifaat Shekh-Yusef, Michael Richardson
 Working Group: Individual Submissions (none)
 Formats: txt xml html
This document specifies the behaviour of a BRSKI Cloud Registrar, and how a pledge can interact with a BRSKI Cloud Registrar when bootstrapping. RFCED REMOVE: It is being actively worked on at https://github.com/ anima-wg/brski-cloud
 New Cryptographic Algorithms for HIP
 
 draft-moskowitz-hip-new-crypto-09.txt
 Date: 28/01/2021
 Authors: Robert Moskowitz, Stuart Card, Adam Wiethuechter
 Working Group: Individual Submissions (none)
 Formats: xml txt html
This document provides new cryptographic algorithms to be used with HIP. The Edwards Elliptic Curve and the Keccak sponge functions are the main focus. The HIP parameters and processing instructions impacted by these algorithms are defined.
 Additional Parameter sets for LMS Hash-Based Signatures
 
 draft-fluhrer-lms-more-parm-sets-04.txt
 Date: 12/04/2021
 Authors: Scott Fluhrer, Quynh Dang
 Working Group: Individual Submissions (none)
 Formats: txt xml
This note extends LMS (RFC 8554) by defining parameter sets by including additional hash functions. Hese include hash functions that result in signatures with significantly smaller than the signatures using the current parameter sets, and should have sufficient security. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.
 A YANG Module for uCPE management.
 
 draft-shytyi-opsawg-vysm-09.txt
 Date: 18/11/2020
 Authors: Dmytro Shytyi, Laurent Beylier, Luigi Iannone
 Working Group: Individual Submissions (none)
 Formats: txt pdf xml
This document provides a YANG data model for uCPE management (VYSM) and definition of the uCPE equipment. The YANG Model serves as a base framework for managing an universal Customer-Premises Equipment (uCPE) subsystem. The model can be used by a Network Orchestrator.
 SRv6 NET-PGM extension: Insertion
 
 draft-filsfils-spring-srv6-net-pgm-insertion-04.txt
 Date: 11/01/2021
 Authors: Clarence Filsfils, Pablo Camarillo, John Leddy, Dan Voyer, Satoru Matsushima, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: txt xml
Traffic traversing an SR domain is encapsulated in an outer IPv6 header for its journey through the SR domain. To implement transport services strictly within the SR domain, the SR domain may require insertion or deletion of an SRH after the outer IPv6 header of the SR domain. Any segment within the SRH is strictly contained within the SR domain. This document extends SRv6 Network Programming [I-D.ietf-spring-srv6-network-programming] with new SR endpoint and transit behaviors to be performed only within the SR domain in any packet owned by the domain.
 Oblivious DNS Over HTTPS
 
 draft-pauly-dprive-oblivious-doh-06.txt
 Date: 08/03/2021
 Authors: Eric Kinnear, Patrick McManus, Tommy Pauly, Tanya Verma, Christopher Wood
 Working Group: Individual Submissions (none)
 Formats: txt html xml
This document describes an extension to DNS Over HTTPS (DoH) that allows hiding client IP addresses via proxying encrypted DNS transactions. This improves privacy of DNS operations by not allowing any one server entity to be aware of both the client IP address and the content of DNS queries and answers.
 Alternative Approach for Mixing Preshared Keys in IKEv2 for Post-quantum Security
 
 draft-smyslov-ipsecme-ikev2-qr-alt-03.txt
 Date: 03/02/2021
 Authors: Valery Smyslov
 Working Group: Individual Submissions (none)
 Formats: txt
An IKEv2 extension defined in [RFC8784] allows IPsec traffic to be protected against someone storing VPN communications today and decrypting it later, when (and if) quantum computers are available. However, this protection doesn't cover an initial IKEv2 SA, which might be unacceptable in some scenarios. This specification defines an alternative way get the same protection against quantum computers, which allows to extend it on the initial IKEv2 SA.
 MPLS Data Plane Encapsulation for In-situ OAM Data
 
 draft-gandhi-mpls-ioam-sr-06.txt
 Date: 18/02/2021
 Authors: Rakesh Gandhi, Zafar Ali, Clarence Filsfils, Frank Brockners, Bin Wen, Voitek Kozak
 Working Group: Individual Submissions (none)
 Formats: xml txt
In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the data packet while the packet traverses a path between two nodes in the network. This document defines how IOAM data fields are transported with MPLS data plane encapsulation using new Generic Associated Channel (G-ACh).
 Path Steering in CCNx and NDN
 
 draft-oran-icnrg-pathsteering-03.txt
 Date: 30/04/2021
 Authors: Ilya Moiseenko, David Oran
 Working Group: Individual Submissions (none)
 Formats: xml html txt
Path Steering is a mechanism to discover paths to the producers of ICN content objects and steer subsequent Interest messages along a previously discovered path. It has various uses, including the operation of state-of-the-art multipath congestion control algorithms and for network measurement and management. This specification derives directly from the design published in _Path Switching in Content Centric and Named Data Networks_ (4th ACM Conference on Information-Centric Networking - ICN'17) and therefore does not recapitulate the design motivations, implementation details, or evaluation of the scheme. Some technical details are different however, and where there are differences, the design documented here is to be considered definitive.
 ACME for Subdomains
 
 draft-friel-acme-subdomains-04.txt
 Date: 08/03/2021
 Authors: Owen Friel, Richard Barnes, Tim Hollebeek, Michael Richardson
 Working Group: Individual Submissions (none)
 Formats: txt
This document outlines how ACME can be used by a client to obtain a certificate for a subdomain identifier from a certification authority. The client has fulfilled a challenge against a parent domain but does not need to fulfill a challenge against the explicit subdomain as certificate policy allows issuance of the subdomain certificate without explicit subdomain ownership proof.
 LISP Site External Connectivity
 
 draft-jain-lisp-site-external-connectivity-03.txt
 Date: 23/04/2021
 Authors: Prakash Jain, Victor Moreno, Sanjay Hooda
 Working Group: Individual Submissions (none)
 Formats: txt xml
This draft defines how to register/retrieve default-pETR mapping information in LISP when the destination is not registered/known to the local site and its mapping system (e.g. the destination is an internet or external site destination).
 Prefix Unreachable Announcement
 
 draft-wang-lsr-prefix-unreachable-annoucement-06.txt
 Date: 25/03/2021
 Authors: Aijun Wang, Gyan Mishra, Zhibo Hu, Yaqun Xiao
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes a mechanism to solve an existing issue with Longest Prefix Match (LPM), that exists where an operator domain is divided into multiple areas or levels where summarization is utilized. This draft addresses a fail-over issue related to a multi areas or levels domain, where a link or node down event occurs resulting in an LPM component prefix being omitted from the FIB resulting in black hole sink of routing and connectivity loss. This draft introduces a new control plane convergence signaling mechanism using a negative prefix called Prefix Unreachable Announcement (PUA), utilized to detect a link or node down event and signal the RIB that the event has occurred to force immediate control plane convergence.
 Lzip Compressed Format and the application/lzip Media Type
 
 draft-diaz-lzip-03.txt
 Date: 24/04/2021
 Authors: Antonio Diaz
 Working Group: Individual Submissions (none)
 Formats: txt
Lzip is a lossless compressed data format designed for data sharing, long-term archiving, and parallel compression/decompression. Lzip uses a simplified form of the Lempel-Ziv-Markov chain-Algorithm (LZMA) stream format, chosen to maximize safety and interoperability. Lzip can achieve higher compression ratios than gzip. This document describes the lzip format and registers a media type and content encoding to be used when transporting lzip-compressed content via Multipurpose Internet Mail Extensions (MIME).
 The Computerate Specifying Paradigm
 
 draft-petithuguenin-computerate-specifying-08.txt
 Date: 25/04/2021
 Authors: Marc Petit-Huguenin
 Working Group: Individual Submissions (none)
 Formats: html xml txt
This document specifies a paradigm named Computerate Specifying, designed to simultaneously document and formally specify communication protocols. This paradigm can be applied to any document produced by any Standard Developing Organization (SDO), but this document targets specifically documents produced by the IETF.
 GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3
 
 draft-smyshlyaev-tls13-gost-suites-03.txt
 Date: 14/12/2020
 Authors: Stanislav Smyshlyaev, Evgeny Alekseev, Ekaterina Griboedova, Alexandra Babueva
 Working Group: Individual Submissions (none)
 Formats: xml txt
The purpose of this document is to make the Russian cryptographic standards available to the Internet community for their implementation in the Transport Layer Security (TLS) Protocol Version 1.3. This specification defines four new cipher suites and seven new signature schemes based on GOST R 34.12-2015, GOST R 34.11-2012 and GOST R 34.10-2012 algorithms.
 Use Cases and Requirements for Web Packages
 
 draft-yasskin-wpack-use-cases-02.txt
 Date: 13/04/2021
 Authors: Jeffrey Yasskin
 Working Group: Individual Submissions (none)
 Formats: html xml txt
This document lists use cases for signing and/or bundling collections of web pages, and extracts a set of requirements from them. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the WPACK Working Group mailing list (wpack@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/wpack/. Source for this draft and an issue tracker can be found at https://github.com/WICG/webpackage.
 Compressed Routing Header (CRH) Helper Option
 
 draft-bonica-6man-crh-helper-opt-03.txt
 Date: 19/04/2021
 Authors: Xing Li, Congxiao Bao, Eddie Ruan, Ron Bonica
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines the IPv6 Compressed Routing Header (CRH) Helper option. When a source node sends a packet with a CRH, it can use the CRH Helper option to provide additional information to downstream nodes.
 EVPN-VPWS Seamless Integration with Legacy VPWS
 
 draft-brissette-bess-evpn-vpws-seamless-02.txt
 Date: 11/03/2021
 Authors: Patrice Brissette, Ali Sajassi, LucAndre Burdet, Jim Uttaro, Dan Voyer, Iman Ghamari, Eddie Leyton
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies mechanisms for backward compatibility of Ethernet VPN Virtual Private Wire Service (EVPN-VPWS) solutions with legacy Virtual Private Wire Service (VPWS). It provides mechanisms for seamless integration in the same MPLS/IP network on a per- pseudowire or per flexible-crossconnect service basis. Implementation of this document enables service providers to introduce EVPN-VPWS PEs in their brown-field deployments of legacy VPWS networks. This document specifies control-plane and forwarding behaviour needed for auto-discovery of a pseudowire in order to enable seamless integration between EVPN-VPWS and VPWS PEs.
 Architecture Discussion on SRv6 Mobile User plane
 
 draft-kohno-dmm-srv6mob-arch-04.txt
 Date: 06/05/2021
 Authors: Miya Kohno, Francois Clad, Pablo Camarillo, Zafar Ali
 Working Group: Individual Submissions (none)
 Formats: txt
SRv6 mobile user plane is standardized in IETF. It accomplishes the mobile user-plane functions in a simple, flexible and scalable manner, by utilizing the network programming nature of SRv6. It leverages common native IPv6 data plane and creates interoperable overlays with underlay optimization. This document discusses the solution approach and its architectural benefits of common data plane across domains and across overlay/ underlay.
 DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over SRv6
 
 draft-wang-detnet-tsn-over-srv6-03.txt
 Date: 25/04/2021
 Authors: Xueshun Wang, Jinyou Dai, Jianhua Liu, Feng Zhang
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies the Deterministic Networking data plane when TSN networks interconnected over an Segment Routing IPv6 Packet Switched Networks.
 State-updating mechanism in RSVP-TE for MPLS network
 
 draft-gao-mpls-teas-rsvpte-state-update-03.txt
 Date: 02/05/2021
 Authors: Jun Gao, Jinyou Dai
 Working Group: Individual Submissions (none)
 Formats: txt
RSVP-TE has the following advantages: source routing capability, and the ability to reserve resources hop by hop along the LSP path. RSVP takes a "soft state" approach to manage the reservation state in routers and hosts. The use of 'Refresh messages' to cover many possible failures has resulted in a number of operational problems. One problem relates to scaling, another relates to the reliability and latency of RSVP Signaling. This document describes a number of mechanisms that can be used to reduce processing overhead requirements of refresh messages. These extension present no backwards compatibility issues.
 Segment-Routing over Forwarding Adjacency Links
 
 draft-saad-sr-fa-link-03.txt
 Date: 15/02/2021
 Authors: Tarek Saad, Vishnu Beeram, Colby Barth, Siva Sivabalan
 Working Group: Individual Submissions (none)
 Formats: txt
Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) networks can be used to form Forwarding Adjacency (FA) links that carry traffic in those networks. An FA link can be assigned Traffic Engineering (TE) parameters that allow other LSR(s) to include it in their constrained path computation. FA link(s) can be also assigned Segment-Routing (SR) segments that enable the steering of traffic on to the associated FA link(s). The TE and SR attributes of an FA link can be advertised using known protocols that carry link state information. This document elaborates on the usage of FA link(s) and their attributes in SR enabled networks.
 Color Operation with BGP Label Unicast
 
 draft-chan-idr-bgp-lu2-03.txt
 Date: 07/03/2021
 Authors: Louis Chan
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies how to carry colored path advertisement via an enhancement to the existing protocol BGP Label Unicast. It would allow backward compatibility with RFC8277. The targeted solution is to use stack of labels advertised via BGP Label Unicast 2.0 for end to end traffic steering across multiple IGP domains. The operation is similar to Segment Routing. This proposed protocol will convey the necessary reachability information to the ingress PE node to construct an end to end path. Another two problems addressed here are the interworking with Flex-Algo, and the MPLS label space limit problem. Please note that there is a major change of protocol format starting from version 01 draft. Except the optional BGP capability code, these rest of BGP attributes used in this draft are defined in previous RFC or in use today in other scenario.
 Performance Measurement for Geneve
 
 draft-xiao-nvo3-pm-geneve-02.txt
 Date: 23/11/2020
 Authors: Xiao Min, Greg Mirsky, Santosh Pallagatti
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the method to achieve Performance Measurement (PM) in point-to-point Generic Network Virtualization Encapsulation (Geneve) tunnels used to make up an overlay network.
 A YANG Data Model for Client Signal Performance Monitoring
 
 draft-zheng-ccamp-client-pm-yang-03.txt
 Date: 10/01/2021
 Authors: Haomian Zheng, Italo Busi, Zheng Yanlei
 Working Group: Individual Submissions (none)
 Formats: txt xml
A transport network is a server-layer network to provide connectivity services to its client. Given the client signal is configured, the followup function for performance monitoring, such as latency and bit error rate, would be needed for network operation. This document describes the data model to support the performance monitoring functionalities.
 Requirements for IoT Services based on Visible Light Communications
 
 draft-sjkoh-requirements-iot-vlc-01.txt
 Date: 17/11/2020
 Authors: Seok Koh, Cheol-Min Kim
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the requirements for IoT Services based on Visible Light Communication (VLC) to effectively provide IoT services in the VLC-based networks. This document includes the overview of VLC technology and the concepts of VLC-based IoT services, and the requirements for IoT services in the VLC-based networks.
 BGP-LS Extensions for Segment Routing based Enhanced VPN
 
 draft-dong-idr-bgpls-sr-enhanced-vpn-03.txt
 Date: 22/02/2021
 Authors: Jie Dong, Zhibo Hu, Zhenbin Li, Xiongyan Tang, Ran Pang
 Working Group: Individual Submissions (none)
 Formats: xml txt
Enhanced VPN (VPN+) aims to provide enhanced VPN services to support some applications' needs of enhanced isolation and stringent performance requirements. VPN+ requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. A Virtual Transport Network (VTN) is a virtual underlay network which consists of a customized network topology and a set of network resource allocated from the physical network. A VTN could be used as the underlay to support one or a group of VPN+ services. This document specifies the BGP-LS mechanisms with necessary extensions to advertise the information of Segment Routing (SR) based VTNs to a centralized network controller. Each VTN can have a customized topology and a set of network resources allocated. Multiple VTNs may shared the same topology, and multiple VTNs may share the same set of network resources on some network segments. This allows flexible combination of network topology and network resource attributes to build a large number of VTNs with a relatively small number of logical topologies. The proposed mechanism is applicable to both segment routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6).
 Context-Aware Navigation Protocol for IP-Based Vehicular Networks
 
 draft-jeong-ipwave-context-aware-navigator-03.txt
 Date: 21/02/2021
 Authors: Jaehoon Jeong, Bien Mugabarigira, Yiwen Shen, Zhong Xiang, Zeung Kim
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document proposes a Context-Aware Navigation Protocol (CNP) for IP-based vehicular networks for cooperative navigation among vehicles in road networks. This CNP aims at the enhancement of driving safety through a light-weight driving information sharing method. The CNP protocol uses an IPv6 Neighbor Discovery (ND) option to convey driving information such as a vehicle's position, speed, acceleration/deceleration, and direction, and a driver's driving action (e.g., braking and accelerating).
 Basic Support for Security and Privacy in IP-Based Vehicular Networks
 
 draft-jeong-ipwave-security-privacy-03.txt
 Date: 21/02/2021
 Authors: Jaehoon Jeong, Yiwen Shen, J., PARK
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes possible attacks of security and privacy in IP Wireless Access in Vehicular Environments (IPWAVE). It also proposes countermeasures for those attacks.
 SRv6 Deployment Consideration
 
 draft-tian-spring-srv6-deployment-consideration-04.txt
 Date: 10/01/2021
 Authors: Hui Tian, Feng Zhao, Chongfeng Xie, Tong Li, Jichun Ma, Robbins Mwehair, Edmore Chingwena, Shuping Peng, Zhenbin Li, Yaqun Xiao
 Working Group: Individual Submissions (none)
 Formats: txt xml
SRv6 has significant advantages over SR-MPLS and has attracted more and more attention and interest from network operators and verticals. Smooth network migration towards SRv6 is a key focal point and this document provides network design and migration guidance and recommendations on solutions in various scenarios. Deployment cases with SRv6 are also introduced.
 Alternative Delta Time Encoding for CCNx Using Compact Floating-Point Arithmetic
 
 draft-gundogan-icnrg-ccnx-timetlv-03.txt
 Date: 18/01/2021
 Authors: Cenk Gundogan, Thomas Schmidt, David Oran, Matthias Waehlisch
 Working Group: Individual Submissions (none)
 Formats: txt
CCNx utilizes delta time for a number of functions. When using CCNx in environments with constrained nodes and/or bandwidth constrained networks, it is valuable to have a compressed representation of delta time. In order to do so, either accuracy or dynamic range has to be sacrificed. Since the current uses of delta time do not require both simultaneously, one can consider a logarithmic encoding such as that specified in [IEEE.754.2019]. This document updates _CCNx messages in TLV Format_ (RFC8609) to specify this alternative encoding.
 IETF Network Slice YANG Data Model
 
 draft-liu-teas-transport-network-slice-yang-03.txt
 Date: 02/05/2021
 Authors: Xufeng Liu, Jeff Tantsura, Igor Bryskin, Luis Contreras, Qin WU, Sergio Belotti, Reza Rokui
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a YANG data model for managing and controlling IETF network slices, defined in [I-D.ietf-teas-ietf-network-slices].
 Service Assurance for Intent-based Networking Architecture
 
 draft-claise-opsawg-service-assurance-architecture-05.txt
 Date: 23/04/2021
 Authors: Benoit Claise, Jean Quilbeuf, Diego Lopez, Dan Voyer, Thangam Arumugam
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes an architecture for Service Assurance for Intent-based Networking (SAIN). This architecture aims at assuring that service instances are correctly running. As services rely on multiple sub-services by the underlying network devices, getting the assurance of a healthy service is only possible with a holistic view of network devices. This architecture not only helps to correlate the service degradation with the network root cause but also the impacted services when a network component fails or degrades.
 Transport Protocol Issues of In-Network Computing Systems
 
 draft-kunze-coinrg-transport-issues-04.txt
 Date: 08/02/2021
 Authors: Ike Kunze, Klaus Wehrle, Dirk Trossen
 Working Group: Individual Submissions (none)
 Formats: txt
Today's transport protocols offer a variety of functionality based on the notion that the network is to be treated as an unreliable communication medium. Some, like TCP, establish a reliable connection on top of the unreliable network while others, like UDP, simply transmit datagrams without a connection and without guarantees into the network. These fundamental differences in functionality have a significant impact on how COIN approaches can be designed and implemented. Furthermore, traditional transport protocols are not designed for the multi-party communication principles that underlie many COIN approaches. This document raises several questions regarding the use of transport protocols in connection with COIN.
 IETF Network Slice Use Cases and Attributes for Northbound Interface of IETF Network Slice Controllers
 
 draft-contreras-teas-slice-nbi-04.txt
 Date: 22/02/2021
 Authors: Luis Contreras, Shunsuke Homma, Jose Ordonez-Lucena
 Working Group: Individual Submissions (none)
 Formats: txt
This document analyses the needs of potential customers of network slices realized with IETF techniques in several use cases, identifies the functionalities for the North Bound Interface (NBI) of an IETF Network Slice Controller to satisfy such requests.
 IS-IS Flooding Scale Considerations
 
 draft-ginsberg-lsr-isis-flooding-scale-04.txt
 Date: 11/04/2021
 Authors: Les Ginsberg, Peter Psenak, Acee Lindem, Tony Przygienda
 Working Group: Individual Submissions (none)
 Formats: xml txt
Link State PDU flooding rates in use are much slower than what modern networks can support. The use of IS-IS at larger scale requires faster flooding rates to achieve desired convergence goals. This document discusses issues associated with increasing flooding rates and some recommended practices which allow faster flooding rates to be used safely.
 Notification of Revoked Access Tokens in the Authentication and Authorization for Constrained Environments (ACE) Framework
 
 draft-tiloca-ace-revoked-token-notification-04.txt
 Date: 22/02/2021
 Authors: Marco Tiloca, Ludwig Seitz, Francesca Palombini, Sebastian Echeverria, Grace Lewis
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a method of the Authentication and Authorization for Constrained Environments (ACE) framework, which allows an Authorization Server to notify Clients and Resource Servers (i.e., registered devices) about revoked Access Tokens. The method relies on resource observation for the Constrained Application Protocol (CoAP), with Clients and Resource Servers observing a Token Revocation List on the Authorization Server. Resulting unsolicited notifications of revoked Access Tokens complement alternative approaches such as token introspection, while not requiring additional endpoints on Clients and Resource Servers.
 YANG Modules for Service Assurance
 
 draft-claise-opsawg-service-assurance-yang-07.txt
 Date: 23/04/2021
 Authors: Benoit Claise, Jean Quilbeuf, Paolo Lucente, Paolo Fasano, Thangam Arumugam
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document proposes YANG modules for the Service Assurance for Intent-based Networking Architecture.
 TLS 1.3 Extended Key Schedule
 
 draft-jhoyla-tls-extended-key-schedule-03.txt
 Date: 03/12/2020
 Authors: Jonathan Hoyland, Christopher Wood
 Working Group: Individual Submissions (none)
 Formats: html xml txt
TLS 1.3 is sometimes used in situations where it is necessary to inject extra key material into the handshake. This draft aims to describe methods for doing so securely. This key material must be injected in such a way that both parties agree on what is being injected and why, and further, in what order.
 Bijective MAC for Constraint Nodes
 
 draft-urien-core-bmac-07.txt
 Date: 15/12/2020
 Authors: Pascal Urien
 Working Group: Individual Submissions (none)
 Formats: txt
In this draft context, things are powered by micro controllers units (MCU) comprising a set of memories such as static RAM (SRAM), FLASH and EEPROM. The total memory size, ranges from 10KB to a few megabytes. In this context code and data integrity are major security issues, for the deployment of Internet of Things infrastructure. The goal of the bijective MAC (bMAC) is to compute an integrity value, which cannot be guessed by malicious software. In classical keyed MACs, MAC is computing according to a fixed order. In the bijective MAC, the content of N addresses is hashed according to a permutation P (i.e. bijective application). The bijective MAC key is the permutation P. The number of permutations for N addresses is N!. So the computation of the bMAC requires the knowledge of the whole space memory; this is trivial for genuine software, but could very difficult for corrupted software, especially for time stamped bMAC.
 TLS DNSSEC Chain Extension
 
 draft-dukhovni-tls-dnssec-chain-05.txt
 Date: 05/05/2021
 Authors: Viktor Dukhovni, Shumon Huque, Willem Toorop, Paul Wouters, Melinda Shore
 Working Group: Individual Submissions (none)
 Formats: txt html xml
This document describes an experimental TLS extension for in-band transport of the complete set of DNSSEC validated records needed to perform DANE authentication of a TLS server without the need to perform separate out-of-band DNS lookups. When the requisite DNS records do not exist, the extension conveys a validated denial of existence proof. This experimental extension is developed outside the IETF and is published here to guide implementation of the extension and to ensure interoperability among implementations.
 User Plane Message Encoding
 
 draft-murakami-dmm-user-plane-message-encoding-03.txt,.ps
 Date: 07/03/2021
 Authors: Tetsuya Murakami, Satoru Matsushima, Kentaro Ebisawa, Pablo Camarillo, Ravi Shekhar
 Working Group: Individual Submissions (none)
This document defines the encoding of User Plane messages into Segment Routing Header (SRH). The SRH carries the User Plane messages over SRv6 Network.
 Deadline-aware Transport Protocol
 
 draft-shi-quic-dtp-03.txt
 Date: 21/01/2021
 Authors: Yong Cui, Zhiwen Liu, Hang Shi, Jie Zhang, Kai Zheng, Wei Wang
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines Deadline-aware Transport Protocol (DTP) to provide block-based deliver-before-deadline transmission. The intention of this memo is to describe a mechanism to fulfill unreliable transmission based on QUIC as well as how to enhance timeliness of data delivery.
 SR-MPLS Data Plane with IPv6 Control Plane
 
 draft-filsfils-spring-sr-mpls-ipv6-control-plane-03.txt
 Date: 29/11/2020
 Authors: Clarence Filsfils, Francois Clad, Ketan Talaulikar
 Working Group: Individual Submissions (none)
 Formats: txt
This document reminds the existence of the "Segment Routing (SR) MPLS data-plane with IPv6 control-plane" solution that is mature from a standardization, productization and commercial deployment viewpoint.
 Abstract
 
 draft-chen-top-level-interface-protocol-03.txt
 Date: 25/04/2021
 Authors: Yuying Chen, Jiagui Xie, Zhiping Li, Hongyan Liu
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes an Extensible Provisioning Protocol (EPP) for the provisioning and management of enterprises and identifiers between the server which is called Business Management System(BMS) and is entitled to manage the identifier top-level node and the client which is also referred to as Second Node Management System (SNMS).Specified in XML, the mapping defines EPP command syntax and semantics as applied to enterprise and identifier management.
 Segment Routing Mapped To IPv6 (SRm6)
 
 draft-bonica-spring-sr-mapped-six-03.txt
 Date: 29/03/2021
 Authors: Ron Bonica, Shraddha Hegde, Yuji Kamite, Andrew Alston, Daniam Henriques, Luay Jalil, Joel Halpern, Jen Linkova, Gang Chen
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes Segment Routing Mapped to IPv6 (SRm6). SRm6 is a Segment Routing (SR) solution that supports a wide variety of use-cases while complying with IPv6 specifications. SRm6 is optimized for ASIC-based routers that operate at high data rates.
 Data Aggregation in IPv6-based Vehicular Networks
 
 draft-yan-ipwave-aggregation-02.txt
 Date: 15/11/2020
 Authors: Zhiwei Yan, Jong-Hyouk Lee, Jaehoon Jeong, Yong-Jin Park, Hidenori Nakazato
 Working Group: Individual Submissions (none)
 Formats: txt
Considering the large-scale but small-sized information exchange in the vehicular information network, this draft document aims at outlining the requirements to support the data aggregation in vehicular networks based on the concept of Information-centric networking (ICN), in order to make the information retrieval and dissemination in an efficient way.
 The Base58 Encoding Scheme
 
 draft-msporny-base58-03.txt
 Date: 31/03/2021
 Authors: Satoshi Nakamoto, Manu Sporny
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies the base 58 encoding scheme, including an introduction to the benefits of the approach, the encoding and decoding algorithm, alternative alphabets, and security considerations.
 Operatonal Considerations for Voucher infrastructure for BRSKI MASA
 
 draft-richardson-anima-masa-considerations-05.txt
 Date: 12/03/2021
 Authors: Michael Richardson, Jie Yang
 Working Group: Individual Submissions (none)
 Formats: xml html txt
This document describes a number of operational modes that a BRSKI Manufacturer Authorized Signing Authority (MASA) may take on. Each mode is defined, and then each mode is given a relevance within an over applicability of what kind of organization the MASA is deployed into. This document does not change any protocol mechanisms.
 RPKI validated cache Update in SLURM over HTTPs (RUSH)
 
 draft-madi-sidrops-rush-03.txt
 Date: 17/11/2020
 Authors: Di Ma, Hanbing Yan, Melchior Aelmans
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a method for transferring RPKI validated cache update information in JSON object format over HTTPs.
 Abstract
 
 draft-wu-identifier-sln-objects-mapping-02.txt
 Date: 19/12/2020
 Authors: Hongjie Wu, Zhiping Li, Jian Chen, Xiaotian Fan
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies the format, contents and semantics of data escrow deposits for Industrial Internet Identifier Second-level Node (SLN). SLN directly serves enterprises and provides services such as identifier registration, identifier resolution, data sharing, etc. The mapping objects in this document mainly refers to the enterprise registration information of the SLN and the Enterprise-level Node (ELN) registered in the SLN.
 Industrial Internet Identifier Node (IIIN) Data Escrow Specification
 
 draft-industrial-internet-identifier-data-escrow-02.txt
 Date: 19/12/2020
 Authors: Hongjie Wu, Zhiping Li, Jian Chen, Xiaotian Fan
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies the format and contents of data escrow deposits targeted primarily for Industrial Internet Identifier Node (IIIN) which provides identifier registration. However, this specification was designed to be independent of the underlying objects that are being escrowed, therefore it could be used for purposes other than IIIN.
 IGP Flexible Algorithm with L2bundles
 
 draft-peng-lsr-flex-algo-l2bundles-05.txt
 Date: 07/12/2020
 Authors: Yongqing Zhu, Shaofu Peng, Ran Chen, Greg Mirsky
 Working Group: Individual Submissions (none)
 Formats: txt
IGP Flex Algorithm proposes a solution that allows IGPs themselves to compute constraint based paths over the network, and it also specifies a way of using Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets along the constraint-based paths. This document describes how to create Flex-algo plane with L2bundles scenario.
 Resource Allocation Model for Hybrid Switching Networks
 
 draft-sun-nmrg-hybrid-switching-02.txt
 Date: 19/12/2020
 Authors: Weiqiang Sun, Junyi Shao, Weisheng Hu
 Working Group: Individual Submissions (none)
 Formats: txt
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.
 Inter-domain Network Slicing via BGP-LU
 
 draft-zhou-idr-inter-domain-lcu-02.txt
 Date: 12/01/2021
 Authors: Ran Chen, Chunning Dai, Shaofu Peng
 Working Group: Individual Submissions (none)
 Formats: txt
This document aims to solve inter-domain network slicing problems using existing technologies. It attempts to establish multiple BGP- LU LSPs of different colors for a prefix to stitch multiple network segments.
 Threshold Modes in Elliptic Curves
 
 draft-hallambaker-threshold-05.txt
 Date: 13/01/2021
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: html txt xml
Threshold cryptography operation modes are described with application to the Ed25519, Ed448, X25519 and X448 Elliptic Curves. Threshold key generation allows generation of keypairs to be divided between two or more parties with verifiable security guaranties. Threshold decryption allows elliptic curve key agreement to be divided between two or more parties such that all the parties must co-operate to complete a private key agreement operation. The same primitives may be applied to improve resistance to side channel attacks. A Threshold signature scheme is described in a separate document. https://mailarchive.ietf.org/arch/browse/cfrg/ (http://whatever)Discussion of this draft should take place on the CFRG mailing list (cfrg@irtf.org), which is archived at .
 Threshold Signatures in Elliptic Curves
 
 draft-hallambaker-threshold-sigs-06.txt
 Date: 13/01/2021
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt html xml
A Threshold signature scheme is described. The signatures created are computationally indistinguishable from those produced using the Ed25519 and Ed448 curves as specified in RFC8032 except in that they are non-deterministic. Threshold signatures are a form of digital signature whose creation requires two or more parties to interact but does not disclose the number or identities of the parties involved. https://mailarchive.ietf.org/arch/browse/cfrg/ (http://whatever)Discussion of this draft should take place on the CFRG mailing list (cfrg@irtf.org), which is archived at .
 Delegated Authority for Bootstrap Voucher Artifacts
 
 draft-richardson-anima-voucher-delegation-03.txt
 Date: 22/03/2021
 Authors: Michael Richardson, Wei Pan
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes an extension of the RFC8366 Voucher Artifact in order to support delegation of signing authority. The initial voucher pins a public identity, and that public indentity can then issue additional vouchers. This chain of authorization can support permission-less resale of devices, as well as guarding against business failure of the BRSKI [I-D.ietf-anima-bootstrapping-keyinfra] Manufacturer Authorized Signing Authority (MASA).
 OSPF Graceful Restart Enhancements
 
 draft-basavaraj-lsr-ospf-gr-enhancements-02.txt
 Date: 27/12/2020
 Authors: Sami Boutros, Ankur Dubey, Vijayalaxmi Basavaraj, Acee Lindem
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes enhancements to the OSPF graceful restart procedures to improve routing convergence in some OSPF network deployments. This document updates RFC 3623 and RFC 5187.
 MASQUE Obfuscation
 
 draft-schinazi-masque-obfuscation-04.txt
 Date: 12/03/2021
 Authors: David Schinazi
 Working Group: Individual Submissions (none)
 Formats: txt xml html
This document describes MASQUE Obfuscation. MASQUE Obfuscation is a mechanism that allows co-locating and obfuscating networking applications behind an HTTPS web server. The currently prevalent use-case is to allow running a proxy or VPN server that is indistinguishable from an HTTPS server to any unauthenticated observer. We do not expect major providers and CDNs to deploy this behind their main TLS certificate, as they are not willing to take the risk of getting blocked, as shown when domain fronting was blocked. An expected use would be for individuals to enable this behind their personal websites via easy to configure open-source software. This document is a straw-man proposal. It does not contain enough details to implement the protocol, and is currently intended to spark discussions on the approach it is taking. Discussion of this work is encouraged to happen on the MASQUE IETF mailing list masque@ietf.org or on the GitHub repository which contains the draft: https://github.com/DavidSchinazi/masque-drafts.
 Passive Interface Attribute
 
 draft-wang-lsr-passive-interface-attribute-06.txt
 Date: 14/11/2020
 Authors: Aijun Wang, Zhibo Hu, Gyan Mishra
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the mechanism that can be used to differentiate the passive interfaces from the normal interfaces within ISIS or OSPF domain.
 (strong) AuCPace,an augmented PAKE
 
 draft-haase-aucpace-03.txt
 Date: 06/02/2021
 Authors: Bjoern Haase
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes AuCPace which is an augmented PAKE protocol for two parties. The protocol was tailored for constrained devices and smooth migration for compatibility with legacy user credential databases. It is designed to be compatible with any group of both prime- and non-prime order and comes with a security proof providing composability guarantees.
 Client-Cert HTTP Header: Conveying Client Certificate Information from TLS Terminating Reverse Proxies to Origin Server Applications
 
 draft-bdc-something-something-certificate-05.txt
 Date: 23/03/2021
 Authors: Brian Campbell
 Working Group: Individual Submissions (none)
 Formats: txt xml html
This document defines the HTTP header field "Client-Cert" that allows a TLS terminating reverse proxy to convey the client certificate of a mutually-authenticated TLS connection to the origin server in a common and predictable manner.
 IGP Extensions for Segment Routing Service Segment
 
 draft-lz-lsr-igp-sr-service-segments-04.txt
 Date: 21/01/2021
 Authors: Liu Yao, Zheng Zhang, Yongqing Zhu
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines extensions to the link-state routing protocols (IS-IS and OSPF) in order to carry service segment information via IGP.
 Stateless and Scalable Network Slice Identification for SRv6
 
 draft-filsfils-spring-srv6-stateless-slice-id-02.txt
 Date: 13/01/2021
 Authors: Clarence Filsfils, Francois Clad, Pablo Camarillo, Kamran Raza
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a stateless and scalable solution to achieve network slicing with SRv6.
 SRv6 vSID: Network Programming extension for variable length SIDs
 
 draft-decraene-spring-srv6-vlsid-05.txt
 Date: 22/02/2021
 Authors: Bruno Decraene, Robert Raszuk, Zhenbin Li, Cheng Li
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document proposes an extension to Segment Routing IPv6 (SRv6) Network Programming to allow for SRv6 Segment Identifier (SID) of smaller variable length. The use of smaller SRv6 SID reduces the size the SRv6 Header (SRH). This reduces the overhead for both the traffic volume and the network processor. It is a straightforward extension to the SRv6 Network Programming model and its SRH encapsulation.
 Changing the Default QUIC ACK Policy
 
 draft-fairhurst-quic-ack-scaling-04.txt
 Date: 15/03/2021
 Authors: Gorry Fairhurst, Ana Custura, Tom Jones
 Working Group: Individual Submissions (none)
 Formats: txt xml
Acknowledgement packets (ACKs) are used by transport protocols to confirm the delivery of packets, and their reception is used in a variety of other ways (to measure path round trip time, to gauge path congestion, etc). However, the transmission of ACKs also consumes resources at the receiver, forwarding resource in the network and processing resources at the sender. On network paths with significant path asymmetry, transmission of ACKs can limit the available throughput or can reduce the efficient use of network capacity. This occurs when the return capacity is significantly more constrained than the forward capacity, and/or the cost of transmission per packet is a significant component of the total transmission cost. In these cases, reducing the ratio of ACK packets to data packets can improve link utilisation and reduce link transmission costs. It can also reduce processing overhead at the sender and receiver. This document proposes a change to the default acknowledgement policy of the QUIC transport protocol to improve performance over paths with appreciable asymmetry.
 Lightweight Authorization for Authenticated Key Exchange.
 
 draft-selander-ace-ake-authz-03.txt
 Date: 04/05/2021
 Authors: Goeran Selander, John Mattsson, Malisa Vucinic, Michael Richardson, Aurelio Schellenbaum
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes a procedure for augmenting the authenticated Diffie-Hellman key exchange EDHOC with third party assisted authorization targeting constrained IoT deployments (RFC 7228).
 Using GOST algorithms in IKEv2
 
 draft-smyslov-ike2-gost-05.txt
 Date: 21/02/2021
 Authors: Valery Smyslov
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a set of cryptographic transforms for use in the Internet Key Exchange version 2 (IKEv2) protocol. The transforms are based on Russian cryptographic standard algorithms (GOST).
 Scalability Considerations for Enhanced VPN (VPN+)
 
 draft-dong-teas-enhanced-vpn-vtn-scalability-02.txt
 Date: 22/02/2021
 Authors: Jie Dong, Zhenbin Li, Fengwei Qin, Guangming Yang, Jim Guichard
 Working Group: Individual Submissions (none)
 Formats: txt xml
Enhanced VPN (VPN+) aims to provide enhancements to existing VPN services to support the needs of new applications, particularly including the applications that are associated with 5G services. VPN+ could be used to provide network slicing, and may also be of use in more generic scenarios, such as enterprise services which have demanding requirement. With the requirement for VPN+ services increase, scalability would become an important factor for the deployment of VPN+. This document describes the scalability considerations in the control plane and data plane to enable VPN+ services, some optimization mechanisms are also described.
 Carrying Virtual Transport Network Identifier in IPv6 Extension Header
 
 draft-dong-6man-enhanced-vpn-vtn-id-03.txt
 Date: 22/02/2021
 Authors: Jie Dong, Zhenbin Li, Chongfeng Xie, Chenhao Ma
 Working Group: Individual Submissions (none)
 Formats: txt xml
A Virtual Transport Network (VTN) is a virtual network which has a customized network topology and a set of dedicated or shared network resources allocated from the network infrastructure. A VTN can be used as the underlay for one or a group of VPNs to provide enhanced VPN (VPN+) services. In packet forwarding, some fields in data packet needs to be used to identify the VTN the packet belongs to, so that the VTN-specific processing can be performed. This document proposes a new option type to carry VTN ID in an IPv6 extension header to identify the Virtual Transport Network (VTN) the packet belongs to. The procedure for processing of the VTN option is also specified.
 Generalized SRv6 Network Programming
 
 draft-cl-spring-generalized-srv6-np-03.txt
 Date: 14/03/2021
 Authors: Weiqiang Cheng, Zhenbin Li, Cheng Li, Chongfeng Xie, Cong Li, Hui Tian, Feng Zhao
 Working Group: Individual Submissions (none)
 Formats: txt xml
As the deployment of SRv6, some new requirements are proposed, such as SRv6 compression, transporting over SR-MPLS/MPLS and IPv4 domains. Therefore, it is necessary to consider other types of segments or sub-paths in the end-to-end SRv6 network programming. This document proposes Generalized Segment Routing over IPv6 (G-SRv6) Networking Programming, which supports to encode multiple types of Segments in a SRH, called Generalized SRH (G-SRH). These Segments can be called Generalized Segment, and the ID can be Generalized Segment Identifier (G-SID), which may include an SRv6 SID(128 bits), C-SIDs, MPLS labels, or IPv4 tunnel information. This document also defines the mechanisms of Generalized SRv6 Networking Programming and the requirements of related protocol extensions of control plane and data plane.
 Generalized Segment Routing Header
 
 draft-lc-6man-generalized-srh-03.txt
 Date: 09/02/2021
 Authors: Zhenbin Li, Cheng Li, Weiqiang Cheng, Chongfeng Xie, Cong Li, Hui Tian, Feng Zhao
 Working Group: Individual Submissions (none)
 Formats: txt xml
Generalized SRv6 network programming defines the enhanced mechanisms of SRv6 to encode SRv6 SIDs, Compressed SIDs and even the MPLS labels or IPv4 tunnel information in a single SRH. This type of SRH is called Generalized SRH (G-SRH), which can reduce the overhead of SRv6 and also provide more flexibility for network programming. This document defines the encapsulation and packet processing of G-SRH.
 5G End-to-end Network Slice Mapping from the view of Transport Network
 
 draft-geng-teas-network-slice-mapping-03.txt
 Date: 22/02/2021
 Authors: Xuesong Geng, Jie Dong, Ran Pang, Liuyan Han, Tomonobu Niwa, Jaewhan Jin, Chang Liu, Nikesh Nageshar
 Working Group: Individual Submissions (none)
 Formats: xml txt
Network Slicing is one of the core featrures in 5G. End-to-end network slice consists of 3 major types of network segments: Access Network (AN), Mobile Core Network (CN) and Transport Network (TN). This draft describes the procedure of mapping 5G end-to-end network slice to transport network slice defined in IETF. This draft also intends to expose some gaps in the existing network management plane and data plane technologies to support inter-domain network slice mapping. Further work may require cooperation between IETF and 3GPP (or other standard organizations). Data model specification, signaling protocol extension and new encapsulation definition are out of the scope of this draft.
 BGP Extension for SR-MPLS Entropy Label Position
 
 draft-zhou-idr-bgp-srmpls-elp-02.txt
 Date: 22/02/2021
 Authors: Liu Yao, Shaofu Peng
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document proposes extensions for BGP to indicate the entropy label position in the SR-MPLS label stack when distributing SR Policy candidate paths.
 SDP Mapping into HTTP structured headers
 
 draft-gruessing-sdp-http-02.txt
 Date: 06/02/2021
 Authors: James Gruessing
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies a HTTP header based representation of the Session Description Protocol which can be used in describing media being negotiated or delivered via HTTP. Note to Readers _RFC Editor: please remove this section before publication_ Source code and issues for this draft can be found at https://github.com/fiestajetsam/I-D/tree/main/draft-gruessing-sdp- http [1].
 New UUID Formats
 
 draft-peabody-dispatch-new-uuid-format-01.txt
 Date: 27/04/2021
 Authors: Brad Peabody, Kyzer Davis
 Working Group: Individual Submissions (none)
 Formats: txt xml html
This document presents new time-based UUID formats which are suited for use as a database key. A common case for modern applications is to create a unique identifier for use as a primary key in a database table. This identifier usually implements an embedded timestamp that is sortable using the monotonic creation time in the most significant bits. In addition the identifier is highly collision resistant, difficult to guess, and provides minimal security attack surfaces. None of the existing UUID versions, including UUIDv1, fulfill each of these requirements in the most efficient possible way. This document is a proposal to update [RFC4122] with three new UUID versions that address these concerns, each with different trade-offs.
 Quic Timestamps For Measuring One-Way Delays
 
 draft-huitema-quic-ts-05.txt
 Date: 17/03/2021
 Authors: Christian Huitema
 Working Group: Individual Submissions (none)
 Formats: txt xml
The TIMESTAMP frame can be added to Quic packets when one way delay measurements are useful. The timestamp is set to the number of microseconds from the beginning of the node's epoch to the time at which the packet is sent. The draft defines the "enable_timestamp" transport parameter for negotiating the use of this extension frame, and the TIMESTAMP frame.
 Adaptive Subscription to YANG Notification
 
 draft-wang-netconf-adaptive-subscription-03.txt
 Date: 20/01/2021
 Authors: Qin WU, Wei Song, Peng Liu, Qiufang Ma
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines a YANG data model and associated mechanism enabling subscriber's adaptive subscriptions to a publisher's event streams with various different period intervals to report updates. Applying these elements allows publishers automatically adjust the volume of telemetry traffic sent from publisher to the receivers.
 Telemetry Data Export capability
 
 draft-tao-netconf-data-export-capabilities-03.txt
 Date: 20/01/2021
 Authors: Qin WU, Qiufang Ma, Peng Liu
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document proposes a YANG module for telemetry data export capabilities which augments system Capabilities model and provides additional telemetry data export attributes associated with system capabilities for transport dependent capability advertisement.
 Approaches on Supporting IOAM in IPv6
 
 draft-song-ippm-ioam-ipv6-support-02.txt
 Date: 04/01/2021
 Authors: Haoyu Song, Zhenbin Li, Shuping Peng, Jim Guichard
 Working Group: Individual Submissions (none)
 Formats: xml txt
It has been proposed to encapsulate IOAM tracing option data fields in IPv6 HbH options header. However, due to size of the trace data and the extension header location in the IPv6 packets, the proposal creates practical challenges for implementation, especially when other extension headers, such as a routing header, also exist and require in-network processing. We propose several alternative approaches to address this challenge, including separating the IOAM trace data to a different extension header, using the postcard-based telemetry (e.g., IOAM DEX) instead, and applying the segment IOAM trace export scheme, based on the network scenario and application requirements. We discuss the pros and cons of each approach and hope to foster standard convergence and industry adoption.
 Application-aware Networking (APN) Framework
 
 draft-li-apn-framework-02.txt
 Date: 22/02/2021
 Authors: Zhenbin Li, Shuping Peng, Dan Voyer, Cong Li, Peng Liu, Chang Cao, Kentaro Ebisawa, Stefano Previdi, Jim Guichard
 Working Group: Individual Submissions (none)
 Formats: xml txt
A multitude of applications are carried over the network, which have varying needs for network bandwidth, latency, jitter, and packet loss, etc. Some new emerging applications (e.g. 5G) have very demanding performance requirements. However, in current networks, the network and applications are decoupled, that is, the network is not aware of the applications' requirements in a fine granularity. Therefore, it is difficult to provide truly fine-granularity traffic operations for the applications and guarantee their SLA requirements. This document proposes a new framework, named Application-aware Networking (APN), where application characteristic information such as application-aware identification and network performance requirements is carried in the packet encapsulation in order to facilitate service provisioning, perform fine-granularity traffic steering and network resource adjustment.
 Enhanced Performance and Liveness Monitoring in Segment Routing Networks
 
 draft-gandhi-spring-sr-enhanced-plm-04.txt
 Date: 09/02/2021
 Authors: Rakesh Gandhi, Clarence Filsfils, Navin Vaghamshi, Moses Nagarajah, Richard Foote
 Working Group: Individual Submissions (none)
 Formats: xml txt
Segment Routing (SR) leverages the source routing paradigm. SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document defines procedures for Enhanced Performance and Liveness Monitoring (PLM) for end-to-end SR paths including SR Policies for both SR-MPLS and SRv6 data planes, those reduce the deployment and operational complexities in a network.
 Announcing Supported Authentication Methods in IKEv2
 
 draft-smyslov-ipsecme-ikev2-auth-announce-03.txt
 Date: 08/03/2021
 Authors: Valery Smyslov
 Working Group: Individual Submissions (none)
 Formats: txt
This specification defines a mechanism that allows the Internet Key Exchange version 2 (IKEv2) implementations to indicate the list of supported authentication methods to their peers while establishing IKEv2 Security Association (SA). This mechanism improves interoperability when IKEv2 partners are configured with multiple different credentials to authenticate each other.
 Indicators of Compromise (IoCs) and Their Role in Attack Defence
 
 draft-paine-smart-indicators-of-compromise-02.txt
 Date: 13/01/2021
 Authors: Kirsty Paine, Ollie Whitehouse
 Working Group: Individual Submissions (none)
 Formats: xml txt
Indicators of Compromise (IoCs) are an important technique in attack defence (often called cyber defence). This document outlines the different types of IoC, their associated benefits and limitations, and discusses their effective use. It also contextualises the role of IoCs in defending against attacks through describing a recent case study. This draft does not pre-suppose where IoCs can be found or should be detected - as they can be discovered and deployed in networks, endpoints or elsewhere - rather, engineers should be aware that they need to be detectable (either by endpoints, security appliances or network-based defences, or ideally all) to be effective. The purpose of this draft is to document both the operational issues, but also the best practices associated with use of IoCs today. This draft provides a foundation for proposals for new approaches to operational challenges in network security.
 Inserting,Processing And Deleting IPv6 Extension Headers
 
 draft-bonica-6man-ext-hdr-update-05.txt
 Date: 08/03/2021
 Authors: Ron Bonica, Tatuya Jinmei
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document provides guidance regarding the processing, insertion, and deletion of IPv6 extension headers. It updates RFC 8200.
 Bootstrapped TLS Authentication
 
 draft-friel-tls-eap-dpp-02.txt
 Date: 21/02/2021
 Authors: Owen Friel, Dan Harkins
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a TLS extension that enables a server to prove to a client that it has knowledge of the public key of a key pair where the client has knowledge of the private key of the key pair. Unlike standard TLS key exchanges, the public key is never exchanged in TLS protocol messages. Proof of knowledge of the public key is used by the client to bootstrap trust in the server. The use case outlined in this document is to establish trust in an EAP server.
 BGP Extensions for Unified SID in TE Policy
 
 draft-liu-idr-segment-routing-te-policy-complement-04.txt
 Date: 23/11/2020
 Authors: Liu Yao, Shaofu Peng
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines extensions to BGP in order to advertise Unified SIDs in SR-TE policies.
 A User-Focused Internet Threat Model
 
 draft-lazanski-users-threat-model-t-02.txt
 Date: 07/01/2021
 Authors: Dominique Lazanski
 Working Group: Individual Submissions (none)
 Formats: txt
RFC 3552 introduces a threat model that does not include endpoint security. Yet increasingly protocol development is making assumptions about endpoint security capabilities which have not been defined. RFC 3552 is 17 years old and threat landscape has changed. Security issues and cyber attacks have increased and there are more devices, users, and applications on the endpoint than ever. This draft proposes a new approach to the Internet threat model which will include endpoint security, focus on users and provide an update to the threat model in RFC 3552. It brings together Security Considerations for Protocol Designers draft-lazanski-protocol-sec-design-model-t-01 which is a comprehensive document that lists threats, attack vectors, examples and considerations for designing protocols, as well as draft-taddei-smart- cless-introduction-02 which lays out security concerns, capabilities and limitations for endpoints in general and draft-mcfadden-smart- endpoint-taxonomy-for-cless-01 which outlines a clear taxonomy for endpoint security and identifies changes in technology, economic and protocol development that has impacted and changed endpoint security. Taken together these drafts reflect a comprehensive and clear set of security threats and design considerations for the Internet.
 BGP for Network High Availability
 
 draft-chen-idr-ctr-availability-02.txt
 Date: 15/03/2021
 Authors: Huaimo Chen, Yanhe Fan, Aijun Wang, Lei Liu, Xufeng Liu
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes protocol extensions to BGP for improving the reliability or availability of a network controlled by a controller cluster.
 PCEP Extension for SRv6 Unified SIDs
 
 draft-xiong-pce-segment-routing-ipv6-complement-04.txt
 Date: 19/02/2021
 Authors: Quan Xiong, Shaofu Peng
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document proposes PCEP extensions for SRv6 Path which applied to the use of SRv6 Unified SIDs.
 PCE for Network High Availability
 
 draft-chen-pce-ctr-availability-02.txt
 Date: 15/03/2021
 Authors: Huaimo Chen, Aijun Wang, Lei Liu, Xufeng Liu
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes extensions to Path Computation Element (PCE) communication Protocol (PCEP) for improving the reliability or availability of a network controlled by a controller cluster.
 IGP for Network High Availability
 
 draft-chen-lsr-ctr-availability-02.txt
 Date: 15/03/2021
 Authors: Huaimo Chen, Mehmet Toy, Aijun Wang, Lei Liu, Xufeng Liu
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes protocol extensions to OSPF and IS-IS for improving the reliability or availability of a network controlled by a controller cluster.
 Egress Protection for Segment Routing (SR) networks
 
 draft-hegde-rtgwg-egress-protection-sr-networks-01.txt
 Date: 15/11/2020
 Authors: Shraddha Hegde, Wen Lin, Shaofu Peng
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies a Fast Reroute(FRR) mechanism for protecting IP/MPLS services that use Segment Routing (SR) paths for transport against egress node and egress link failures. The mechanism is based on egress protection framework described in [RFC8679]. The egress protection mechanism can be further simplified in Segment Routing networks with anycast SIDs and anycast Locators. This document addresses all kinds of networks that use Segment Routing transport such as SR-MPLS over IPv4, SR-MPLS over IPv6, SRv6 and SRm6.
 Use cases of Application-aware Networking (APN) in Edge Computing
 
 draft-liu-apn-edge-usecase-02.txt
 Date: 12/01/2021
 Authors: Peng Liu, Zongpeng Du, Shuping Peng, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: txt xml
The ever-emerging new services are imposing more and more highly demanding requirements on the network. However, the current deployments could not fully accommodate those requirements due to limited capabilities. For example, it is difficult to utilize the traditional centralized deployment mode to meet the low-latency demand of some latency-sensitive applications. Moreover, the total amount of centralized service data is growing exponentially, which brings great pressure on the network bandwidth. There has been a clear trend that decentralized sites comprising of computing and storage resources are deployed at various locations to provide services. In particular, when the sites are deployed at the network edge, i.e. the Edge Computing, it can better handle the business needs of the users nearby, which provides the possibilities to provide differentiated network and computing services. In order to achieve the full benefits of the edge computing, it actually implies a precondition that the network should be aware of the applications' requirements in order to steer their traffic to the network paths that can satisfy their requirements. Application-aware networking (APN) fits as the missing puzzle piece to bridge the applications and the network to accommodate the edge services' needs, fully releasing the benefits of the edge computing. This document describes the various application scenarios in edge computing to which the APN can be beneficial, including augmented reality, cloud gaming and remote control, which empowers the video business, users interaction business and user-device interaction business. In those scenarios, APN can identify the specific requirements of edge computing applications on the network, process close to the users, provide SLA guaranteed network services such as low latency and high reliability.
 Use Cases for RATS
 
 draft-chen-rats-usecase-03.txt
 Date: 26/01/2021
 Authors: chenmeiling, Li Su
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document presents three scenarios from the Internet Service Providers' perspective as an supplement use case of the RATS work group. And make some discussions of access authentication, application authentication and trusted link. The requirements of trusted link is put forward to establish a protecttive network connection, thus ensure the native network security.
 An Architecture for Network Function Interconnect
 
 draft-bookham-rtgwg-nfix-arch-02.txt
 Date: 27/12/2020
 Authors: Colin Bookham, Andrew Stone, Jeff Tantsura, Muhammad Durrani, Bruno Decraene
 Working Group: Individual Submissions (none)
 Formats: txt xml
The emergence of technologies such as 5G, the Internet of Things (IoT), and Industry 4.0, coupled with the move towards network function virtualization, means that the service requirements demanded from networks are changing. This document describes an architecture for a Network Function Interconnect (NFIX) that allows for interworking of physical and virtual network functions in a unified and scalable manner across wide-area network and data center domains while maintaining the ability to deliver against SLAs.
 Distributed SFC control operation
 
 draft-bernardos-sfc-distributed-control-operation-02.txt
 Date: 22/02/2021
 Authors: Carlos Bernardos, Alain Mourad
 Working Group: Individual Submissions (none)
 Formats: txt
Service function chaining (SFC) allows the instantiation of an ordered set of service functions and subsequent "steering" of traffic through them. In order to set up and maintain SFC instances, a control plane is required, which typically is centralized. In certain environments, such as fog computing ones, such centralized control might not be feasible, calling for distributed SFC control solutions. This document describes a general framework for distributed SFC operation.
 NSH extensions for local distributed SFC control
 
 draft-bernardos-sfc-nsh-distributed-control-02.txt
 Date: 22/02/2021
 Authors: Carlos Bernardos, Alain Mourad
 Working Group: Individual Submissions (none)
 Formats: txt
Service function chaining (SFC) allows the instantiation of an ordered set of service functions and subsequent "steering" of traffic through them. In order to set up and maintain SFC instances, a control plane is required, which typically is centralized. In certain environments, such as fog computing ones, such centralized control might not be feasible, calling for distributed SFC control solutions. This document specifies several NSH extensions to provide in-band SFC control signaling.
 SFC function mobility with Mobile IPv6
 
 draft-bernardos-dmm-sfc-mobility-02.txt
 Date: 22/02/2021
 Authors: Carlos Bernardos, Alain Mourad
 Working Group: Individual Submissions (none)
 Formats: txt
Service function chaining (SFC) allows the instantiation of an ordered set of service functions and subsequent "steering" of traffic through them. In order to set up and maintain SFC instances, a control plane is required, which typically is centralized. In certain environments, such as fog computing ones, such centralized control might not be feasible, calling for distributed SFC control solutions. This document specifies Mobile IPv6 extensions to enable function migration in SFC.
 Algorithm Related IGP-Adjacency SID Advertisement
 
 draft-peng-lsr-algorithm-related-adjacency-sid-02.txt
 Date: 07/12/2020
 Authors: Shaofu Peng, Ran Chen, Ketan Talaulikar
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routing architecture supports the use of multiple routing algorithms, i.e, different constraint-based shortest-path calculations can be supported. There are two standard algorithms: SPF and Strict-SPF, defined in Segment Routing architecture. There are also other user defined algorithms according to Flex-algo applicaiton. However, an algorithm identifier is often included as part of a Prefix-SID advertisement, that maybe not satisfy some scenarios where multiple algorithm share the same link resource. This document complement that the algorithm identifier can be also included as part of a Adjacency-SID advertisement
 Using Flex-Algo for Segment Routing based VTN
 
 draft-zhu-lsr-isis-sr-vtn-flexalgo-02.txt
 Date: 22/02/2021
 Authors: Yongqing Zhu, Jie Dong, Zhibo Hu
 Working Group: Individual Submissions (none)
 Formats: xml txt
Enhanced VPN (VPN+) aims to provide enhanced VPN service to support some application's needs of enhanced isolation and stringent performance requirements. VPN+ requires integration between the overlay VPN connectivity and the characteristics provided the underlay network. A Virtual Transport Network (VTN) is a virtual underlay network which has a customized network topology and a set of network resources allocated from the physical network. A VTN could be used as the underlay for one or a group of VPN+ services. In some network scenarios, each VTN can be associated with a unique Flex-Algo Identifier. This document describes a mechanism to build the SR based VTNs using SR Flex-Algo and IGP L2 bundle with minor extensions.
 BGP-LS with Multi-topology for Segment Routing based Virtual Transport Networks
 
 draft-xie-idr-bgpls-sr-vtn-mt-02.txt
 Date: 25/01/2021
 Authors: Chongfeng Xie, Cong Li, Jie Dong, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: txt xml
Enhanced VPN (VPN+) aims to provide enhanced VPN service to support some applications' needs of enhanced isolation and stringent performance requirements. VPN+ requires integration between the overlay VPN and the underlay network. A Virtual Transport Network (VTN) is a virtual underlay network which consists of a customized network topology and a set of network resource allocated from the physical network. A VTN could be used as the underlay to support one or a group of VPN+ services. When Segment Routing is used as the data plane of VTNs, each VTN can be allocated with a group of SIDs to identify the topology and resource attributes of network segments in the VTN. The association between the network topology, the network resource attributes and the SR SIDs may need to be distributed to a centralized network controller. For network scenarios where each VTN can be identified by a unique topology ID, this document describes a mechanism to distribute the information of SR based VTNs using BGP-LS with Multi- Topology.
 BGP-LS with Flex-Algo for Segment Routing based Virtual Transport Networks
 
 draft-zhu-idr-bgpls-sr-vtn-flexalgo-01.txt
 Date: 22/02/2021
 Authors: Yongqing Zhu, Jie Dong, Zhibo Hu
 Working Group: Individual Submissions (none)
 Formats: txt xml
Enhanced VPN (VPN+) aims to provide enhanced VPN service to support some application's needs of enhanced isolation and stringent performance requirements. VPN+ requires integration between the overlay VPN and a particular set of resources in the underlay network. A Virtual Transport Network (VTN) is a virtual underlay network which has a customized network topology and a set of network resources allocated from the physical network. A VTN could be used to support one or a group of VPN+ services. When Segment Routing is used as the data plane to provide VTNs, each VTN can be allocated with a group of SIDs to identify the topology and resource attributes of network segments in the VTN. The association between the network topology, the network resource attributes and the SR SIDs may need to be distributed to a centralized network controller. For network scenarios where each VTN can be identified by a unique Flex-Algo ID, this document describes a mechanism to distribute the information of SR based VTNs using BGP-LS with Flex-Algo.
 Security Considerations for Protocol Designers
 
 draft-lazanski-protocol-sec-design-model-t-02.txt
 Date: 07/01/2021
 Authors: Dominique Lazanski
 Working Group: Individual Submissions (none)
 Formats: txt
This document is a non-exhaustive set of considerations for protocol designers and implementers with regards to attack defence. This document follows on from the way forward outlined in draft-lazanski- users-threat-model-t-01. These considerations both supplement and support the work on threat models. They can be used as an aid to analyse protocol design choice and in turn to help combat threats and defend users of these protocols and systems against malicious attacks. First, we list well-known classes of attacks that pose threats, with relevant case studies and descriptions. Next, we give a list of defence measures against these attacks to be considered when designing and deploying protocols. Naturally, deployments of protocols vary greatly between use cases; therefore, some attacks and defensive measures outlined may require more consideration than others, dependent on use case. This RFC can be used by protocol designers to write the Security Considerations section in an RFC. The impact on attack defence of a protocol should be considered in multiple use cases across the multiple layers of the internet. Defence against malicious attacks can be improved and it can be weakened by design features of protocols. Designers should acknowledge the role of protocols in attack prevention, detection and mitigation; this document aims to be a useful guide in doing so.
 Micro-burst Decreasing in Layer3 Network for Low-Latency Traffic
 
 draft-du-detnet-layer3-low-latency-02.txt
 Date: 22/02/2021
 Authors: Zongpeng Du, Peng Liu
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document introduces the problem of micro-bursts in layer3 network, and proposed a method to decrease the micro-bursts in layer3 network for low-latency traffic.
 BCP72 - A Problem Statement
 
 draft-mcfadden-smart-threat-changes-02.txt
 Date: 10/01/2021
 Authors: Mark McFadden
 Working Group: Individual Submissions (none)
 Formats: txt
RFC3552/BCP72 describes an Internet Threat model that has been used in Internet protocol design. More than seventeen years have passed since RFC3552 was written and the structure and topology of the Internet have changed. With those changes comes a question: has the Internet Threat Model changed? Or, is the model described in RFC3552 still mostly accurate? This draft attempts to describe a non- exhaustive list of changes in the current threat environment. It finds that there are both qualitative and quantitative differences from the environment described in RFC3552 and is intended as input to the IAB program on the Internet threat model started in 2020.
 Forwarding Layer Problem Statement
 
 draft-bryant-arch-fwd-layer-ps-02.txt
 Date: 04/01/2021
 Authors: Stewart Bryant, Uma Chunduri, Toerless Eckert, Alexander Clemm
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document considers the problems that need to addressed in IP in order to address the use cases and new network services described in draft-bryant-arch-fwd-layer-uc-00.
 MoWIE for Network Aware Application
 
 draft-huang-alto-mowie-for-network-aware-app-02.txt
 Date: 05/01/2021
 Authors: Chunshan Xiong, Yunfei Zhang, Richard Yang, Gang Li, Yixue Lei, Yunbo Han
 Working Group: Individual Submissions (none)
 Formats: txt
With the quick deployment of 5G networks in the world, cloud based interactive services such as clouding gaming have gained substantial attention and are regarded as potential killer applications. To ensure users' quality of experience (QoE), a cloud interactive service may require not only high bandwidth (e.g., high-resolution media transmission) but also low delay (e.g., low latency and low lagging). However, the bandwidth and delay experienced by a mobile and wireless user can be dynamic, as a function of many factors, and unhandled changes can substantially compromise users' QoE. In this document, we investigate network-aware applications (NAA), which realize cloud based interactive services with improved QoE, by efficient utilization of Mobile and Wireless Information Exposure (MoWIE) . In particular, this document demonstrates, through realistic evaluations, that mobile network information such as MCS (Modulation and Coding Scheme) can effectively expose the dynamicity of the underlying network and can be made available to applications through MoWIE; using such information, the applications can then adapt key control knobs such as media codec scheme, encapsulation and application logical function to minimize QoE deduction. Based on the evaluations, we discuss how MoWIE can be a systematic extension of the ALTO protocol, to expose more lower-layer and finer grain network dynamics.
 SPAKE2+,an Augmented PAKE
 
 draft-bar-cfrg-spake2plus-02.txt
 Date: 10/12/2020
 Authors: Tim Taubert, Christopher Wood
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes SPAKE2+, a Password Authenticated Key Exchange (PAKE) protocol run between two parties for deriving a strong shared key with no risk of disclosing the password. SPAKE2+ is an augmented PAKE protocol, as only one party has knowledge of the password. This method is simple to implement, compatible with any prime order group and is computationally efficient.
 Enhancing Security and Privacy with In-Network Computing
 
 draft-fink-coin-sec-priv-02.txt
 Date: 11/03/2021
 Authors: Ina Fink, Klaus Wehrle
 Working Group: Individual Submissions (none)
 Formats: txt
With the growing interconnection of devices, cyber security and data protection are of increasing importance. This is especially the case regarding cyber-physical systems due to their close entanglement with the physical world. Misbehavior and information leakage can lead to financial and physical damage and endanger human lives and well- being. Thus, hard security and privacy requirements are necessary to be met. Furthermore, a thorough investigation of incidents is essential for ultimate protection. Computing in the Network (COIN) allows the processing of traffic and data directly in the network and at line-rate. Thus, COIN presents a promising solution for efficiently providing security and privacy mechanisms as well as event analysis. This document discusses select mechanisms to demonstrate how COIN concepts can be applied to counter existing shortcomings of cyber security and data privacy.
 Proxy Operations for CoAP Group Communication
 
 draft-tiloca-core-groupcomm-proxy-03.txt
 Date: 22/02/2021
 Authors: Marco Tiloca, Esko Dijk
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies the operations performed by a forward-proxy or reverse-proxy, when using the Constrained Application Protocol (CoAP) in group communication scenarios. Such CoAP proxy processes a single request, sent by a CoAP client over unicast, and distributes the request over IP multicast to a group of CoAP servers. It then collects the individual responses from these CoAP servers and sends these responses to the CoAP client such that the client is able to distinguish the responses and their origin servers through addressing information.
 A CBOR Tag for Unprotected CWT Claims Sets
 
 draft-birkholz-rats-uccs-03.txt
 Date: 08/03/2021
 Authors: Henk Birkholz, Jeremy O'Donoghue, Nancy Cam-Winget, Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: xml html txt
CBOR Web Token (CWT, RFC 8392) Claims Sets sometimes do not need the protection afforded by wrapping them into COSE, as is required for a true CWT. This specification defines a CBOR tag for such unprotected CWT Claims Sets (UCCS) and discusses conditions for its proper use.
 CBOR Encoded X.509 Certificates (C509 Certificates)
 
 draft-mattsson-cose-cbor-cert-compress-08.txt
 Date: 22/02/2021
 Authors: Shahid Raza, Joel Hoglund, Goeran Selander, John Mattsson, Martin Furuhed
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 Certificates. The CBOR encoding supports a large subset of RFC 5280 and significantly reduces the size of certificates compatible with e.g. RFC 7925, IEEE 802.1AR (DevID), CNSA, and CA/Browser Forum Baseline Requirements. When used to re-encode DER encoded X.509 certificates, the CBOR encoding can in many cases reduce the size of RFC 7925 profiled certificates with over 50%. The CBOR encoded structure can alternatively be signed directly ("natively signed"), which does not require re-encoding for the signature to be verified. The document also specifies COSE headers as well as a TLS certificate type for C509 certificates. NOTE: "C509" is a placeholder, name to be decided by the COSE WG.
 Reference Integrity Measurement Extension for Concise Software Identities
 
 draft-birkholz-rats-coswid-rim-02.txt
 Date: 13/01/2021
 Authors: Henk Birkholz, Patrick Uiterwijk, David Waltermire, Shwetha Bhandari, Jessica Fitzgerald-McKay
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies the CDDL and usage description for Reference Integrity Measurements (RIM) in Remote Attestation Procedures (RATS). The specification is based on Concise Software Identification (CoSWID) and TCG Reference Integrity Manifest Information Model - based on Host Integrity at Runtime and Start-up (HIRS). Extension points defined in CoSWID used to augment CoSWID tags with new attributes that can express the TCG Reference Integrity Manifest extensions.
 BGP Well Known Large Community
 
 draft-heitz-idr-wklc-02.txt
 Date: 07/03/2021
 Authors: Jakob Heitz, Kotikalapudi Sriram, Brian Dickson, John Heasley
 Working Group: Individual Submissions (none)
 Formats: xml txt
A range of BGP Autonomous System Numbers is reserved to create a set of BGP Well Known Large Communities.
 WebTransport using HTTP/2
 
 draft-kinnear-webtransport-http2-02.txt
 Date: 22/02/2021
 Authors: Alan Frindell, Eric Kinnear, Tommy Pauly, Victor Vasiliev, Guowu Xie
 Working Group: Individual Submissions (none)
 Formats: txt html xml
WebTransport [OVERVIEW] is a protocol framework that enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport. This document describes a WebTransport protocol that is based on HTTP/2 [RFC7540] and provides support for unidirectional streams, bidirectional streams and datagrams, all multiplexed within the same HTTP/2 connection.
 Abstract
 
 draft-wu-identifier-data-escrow-interface-02.txt
 Date: 19/12/2020
 Authors: Hongjie Wu, Jian Chen, Xiaotian Fan, Zhiping Li
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the Data Escrow report requirement and technical details of the interfaces provides by the Top-level Node (TLN) to its contracted parties. Second-level Node (SLN) MUST periodically send data escrow report to Top-level Node (TLN) and Data Escrow Agent (DEA). DEA MUST sends report verify result to TLN and SLN after processing the report.
 Crowd Sourced Remote ID
 
 draft-moskowitz-drip-crowd-sourced-rid-05.txt
 Date: 15/11/2020
 Authors: Robert Moskowitz, Stuart Card, Adam Wiethuechter, Shuai Zhao, Henk Birkholz
 Working Group: Individual Submissions (none)
 Formats: xml pdf txt
This document describes using the ASTM Broadcast Remote ID (B-RID) specification in a "crowd sourced" smart phone environment to provide much of the FAA mandated Network Remote ID (N-RID) functionality. This crowd sourced B-RID data will use multilateration to add a level of reliability in the location data on the Unmanned Aircraft (UA). The crowd sourced environment will also provide a monitoring coverage map to authorized observers.
 The MASQUE Protocol
 
 draft-schinazi-masque-protocol-03.txt
 Date: 12/03/2021
 Authors: David Schinazi
 Working Group: Individual Submissions (none)
 Formats: xml html txt
This document describes MASQUE (Multiplexed Application Substrate over QUIC Encryption). MASQUE is a framework that allows concurrently running multiple networking applications inside an HTTP/3 connection. For example, MASQUE can allow a QUIC client to negotiate proxying capability with an HTTP/3 server, and subsequently make use of this functionality while concurrently processing HTTP/3 requests and responses. Discussion of this work is encouraged to happen on the MASQUE IETF mailing list masque@ietf.org or on the GitHub repository which contains the draft: https://github.com/DavidSchinazi/masque-drafts.
 DNS Server Selection: DNS Server Information with Assertion Token
 
 draft-reddy-add-server-policy-selection-08.txt
 Date: 29/03/2021
 Authors: Tirumaleswar Reddy.K, Dan Wing, Michael Richardson, Mohamed Boucadair
 Working Group: Individual Submissions (none)
 Formats: xml txt
The document defines a mechanism that is meant to communicate DNS resolver information to DNS clients for use as a criteria for server selection decisions. Such an information that is cryptographically signed to attest its authenticity is used for the selection of DNS resolvers. Typically, evaluating the resolver information and the signatory, DNS clients with minimal or no human intervention can select the DNS servers for resolving domain names. This assertion is useful for encrypted DNS (e.g., DNS-over-TLS, DNS- over-HTTPS, or DNS-over-QUIC) servers that are either public resolvers or discovered in a local network.
 Real-time text solutions for multi-party sessions
 
 draft-hellstrom-avtcore-multi-party-rtt-solutions-06.txt
 Date: 17/12/2020
 Authors: Gunnar Hellstrom
 Working Group: Individual Submissions (none)
 Formats: txt html xml
This document specifies methods for Real-Time Text (RTT) media handling in multi-party calls. The main discussed transport is to carry Real-Time text by the RTP protocol in a time-sampled mode according to RFC 4103. The mechanisms enable the receiving application to present the received real-time text media, separated per source, in different ways according to user preferences. Some presentation related features are also described explaining suitable variations of transmission and presentation of text. Call control features are described for the SIP environment. A number of alternative methods for providing the multi-party negotiation, transmission and presentation are discussed and a recommendation for the main ones is provided. The main solution for SIP based centralized multi-party handling of real-time text is achieved through a media control unit coordinating multiple RTP text streams into one RTP stream. Alternative methods using a single RTP stream and source identification inline in the text stream are also described, one of them being provided as a lower functionality fallback method for endpoints with no multi-party awareness for RTT. Bridging methods where the text stream is carried without the contents being dealt with in detail by the bridge are also discussed. Brief information is also provided for multi-party RTT in the WebRTC environment. The intention is to provide background for decisions, specification and implementation of selected methods.
 Per-Node Capabilities for Optimum Operational Data Collection
 
 draft-claise-netconf-metadata-for-collection-01.txt
 Date: 28/12/2020
 Authors: Benoit Claise, Munish Nayyar, Adithya Sesani
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes a YANG module that provides per-node capabilities for optimum operational data collection. This YANG module augments the YANG Modules for describing System Capabilities and YANG-Push Notification capabilities. This module defines augmented nodes to publish the metadata information specific to YANG node-identifier as per ietf-system- capabilities datatree. Complementary RPCs, based on the same node capabilities, simplify the data collection operations.
 UAS Operator Privacy for RemoteID Messages
 
 draft-moskowitz-drip-operator-privacy-07.txt
 Date: 19/04/2021
 Authors: Robert Moskowitz, Stuart Card, Adam Wiethuechter
 Working Group: Individual Submissions (none)
 Formats: xml txt html
This document describes a method of providing privacy for UAS Operator/Pilot information specified in the ASTM UAS Remote ID and Tracking messages. This is achieved by encrypting, in place, those fields containing Operator sensitive data using a hybrid ECIES.
 Reliable and Available Wireless Architecture/Framework
 
 draft-pthubert-raw-architecture-05.txt
 Date: 15/11/2020
 Authors: Pascal Thubert, Georgios Papadopoulos, Rex Buddenberg
 Working Group: Individual Submissions (none)
 Formats: txt
Due to uncontrolled interferences, including the self-induced multipath fading, deterministic networking can only be approached on wireless links. The radio conditions may change -way- faster than a centralized routing can adapt and reprogram, in particular when the controller is distant and connectivity is slow and limited. RAW separates the routing time scale at which a complex path is recomputed from the forwarding time scale at which the forwarding decision is taken for an individual packet. RAW operates at the forwarding time scale. The RAW problem is to decide, within the redundant solutions that are proposed by the routing, which will be used for each individual packet to provide a DetNet service while minimizing the waste of resources.
 Secure UAS Network RID and C2 Transport
 
 draft-moskowitz-drip-secure-nrid-c2-02.txt
 Date: 25/12/2020
 Authors: Robert Moskowitz, Stuart Card, Adam Wiethuechter, Andrei Gurtov
 Working Group: Individual Submissions (none)
 Formats: xml html txt
This document provides the mechanisms for secure transport of UAS Network-RemoteID and Command-and-Control messaging. Both HIP and DTLS based methods are described.
 QUIC Version Aliasing
 
 draft-duke-quic-version-aliasing-05.txt
 Date: 04/05/2021
 Authors: Martin Duke
 Working Group: Individual Submissions (none)
 Formats: xml html txt
The QUIC transport protocol preserves its future extensibility partly by specifying its version number. There will be a relatively small number of published version numbers for the foreseeable future. This document provides a method for clients and servers to negotiate the use of other version numbers in subsequent connections and encrypts Initial Packets using secret keys instead of standard ones. If a sizeable subset of QUIC connections use this mechanism, this should prevent middlebox ossification around the current set of published version numbers and the contents of QUIC Initial packets, as well as improving the protocol's privacy properties.
 Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS
 
 draft-btw-add-ipsecme-ike-02.txt
 Date: 19/02/2021
 Authors: Mohamed Boucadair, Tirumaleswar Reddy.K, Dan Wing, Valery Smyslov
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies a new Internet Key Exchange Protocol Version 2 (IKEv2) Configuration Payload Attribute Types for encrypted DNS with a focus on DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), and DNS- over-QUIC (DoQ).
 LTP Fragmentation
 
 draft-templin-dtn-ltpfrag-04.txt
 Date: 08/03/2021
 Authors: Fred Templin
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Licklider Transmission Protocol (LTP) provides a reliable datagram convergence layer for the Delay/Disruption Tolerant Networking (DTN) Bundle Protocol. In common practice, LTP is often configured over UDP/IP sockets and inherits its maximum segment size from the maximum-sized UDP datagram, however when this size exceeds the maximum IP packet size for the path a service known as IP fragmentation must be employed. This document discusses LTP interactions with IP fragmentation and mitigations for managing the amount of IP fragmentation employed.
 BGP Maximum Prefix Limits Inbound
 
 draft-sas-idr-maxprefix-inbound-02.txt
 Date: 14/04/2021
 Authors: Melchior Aelmans, stucchi-lists@glevia.com, Job Snijders
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes mechanisms to limit the negative impact of route leaks [RFC7908] and/or resource exhaustion in BGP [RFC4271] implementations.
 RPL Storing Root-ACK
 
 draft-jadhav-roll-storing-rootack-02.txt
 Date: 30/11/2020
 Authors: Rahul Jadhav
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document explains problems with DAO-ACK handling in RPL Storing MOP and provides updates to RFC6550 to solve those problems.
 Optimizing ACK mechanism for QUIC
 
 draft-li-quic-optimizing-ack-in-wlan-01.txt
 Date: 16/11/2020
 Authors: Tong Li, Kai Zheng, Rahul Jadhav, Jiao Kang
 Working Group: Individual Submissions (none)
 Formats: xml txt
The dependence on frequent acknowledgments (ACKs) is an artifact of current transport protocol designs rather than a fundamental requirement. This document analyzes the problems caused by contentions and collisions on wireless medium between data packets and ACKs in WLAN and it proposes an ACK mechanism that minimizes the intensity of ACK Frame in QUIC, improving the performance of transport layer connection.
 Describing QUIC's Protocol Data Units with Augmented Packet Header Diagrams
 
 draft-mcquistin-quic-augmented-diagrams-04.txt
 Date: 05/05/2021
 Authors: Stephen McQuistin, Vivian Band, Dejice Jacob, Colin Perkins
 Working Group: Individual Submissions (none)
 Formats: html txt xml
This document describes the core transport protocol data units used in the QUIC protocol using a machine-readable augmented packet header diagram format. It is intended as an example of the augmented packet header diagram language, and not as a contribution to the development of the QUIC protocol.
 PMS/Head-end based MPLS Ping and Traceroute in Inter-domain SR Networks
 
 draft-ninan-mpls-spring-inter-domain-oam-02.txt
 Date: 16/04/2021
 Authors: Shraddha Hegde, Kapil Arora, Mukul Srivastava, Samson Ninan, Nagendra Nainar
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routing (SR) architecture leverages source routing and tunneling paradigms and can be directly applied to the use of a Multiprotocol Label Switching (MPLS) data plane. A network may consist of multiple IGP domains or multiple ASes under the control of same organization. It is useful to have the LSP Ping and traceroute procedures when an SR end-to-end path spans across multiple ASes or domains. This document describes mechanisms to facilitae LSP ping and traceroute in inter-AS/inter-domain SR networks in an efficient manner with simple OAM protocol extension which uses dataplane forwarding alone for sending Echo-Reply.
 BGP Classful Transport Planes
 
 draft-kaliraj-idr-bgp-classful-transport-planes-07.txt
 Date: 15/02/2021
 Authors: Kaliraj Vairavakkalai, Natrajan Venkataraman, Balaji Rajagopalan, Gyan Mishra, Mazen Khaddam, Xiaohu Xu, Rafal Szarecki
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies a mechanism, referred to as "service mapping", to express association of overlay routes with underlay routes satisfying a certain SLA, using BGP. The document describes a framework for classifying underlay routes into transport classes, and mapping service routes to specific transport class. The "Transport class" construct maps to a desired SLA, and can be used to realize the "Topology Slice" in 5G Network slicing architecture. This document specifies BGP protocol procedures that enable dissimination of such service mapping information that may span multiple co-operating administrative domains. These domains may be administetered by the same provider or closely co-ordinating provider networks. It makes it possible to advertise multiple tunnels to the same destination address, thus avoiding need of multiple loopbacks on the egress node. A new BGP transport layer address family (SAFI 76) is defined for this purpose that uses RFC-4364 technology and follows RFC-8277 NLRI encoding. This new address family is called "BGP Classful Transport", aka BGP CT. It carries transport prefixes across tunnel domain boundaries (e.g. in Inter-AS Option-C networks), parallel to BGP LU (SAFI 4) . It dissiminates "Transport class" information for the transport prefixes across the participating domains, which is not possible with BGP LU. This makes the end-to-end network a "Transport Class" aware tunneled network.
 Use Identity as Raw Public Key in EAP-TLS
 
 draft-chen-emu-eap-tls-ibs-01.txt
 Date: 15/11/2020
 Authors: chenmeiling, Li Su, HAIGUANG Wang
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies the use of identity as a raw public key in EAP-TLS both for TLS1.2 and TLS1.3, EAP-TLS for TLS1.2 is defined in RFC 5216 and EAP-TLS for TLS1.3 is defined in the draft draft-ietf- tls-dtls13. The protocol procedures of EAP-TLS-IBS will consistent with EAP-TLS's interactive process, Identity-based signature will be extended to support EAP-TLS's signature algorithms.
 Notable CBOR Tags
 
 draft-bormann-cbor-notable-tags-03.txt
 Date: 12/02/2021
 Authors: Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: html xml txt
The Concise Binary Object Representation (CBOR, 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. In CBOR, one point of extensibility is the definition of CBOR tags. RFC 7049 and its revision 7049bis define a basic set of tags as well as a registry that can be used to contribute additional tag definitions [IANA.cbor-tags]. Since RFC 7049 was published, some 80 tag definitions have been added to that registry. The present document provides a roadmap to a large subset of these tag definitions. Where applicable, it points to a IETF standards or standard development document that specifies the tag. Where no such document exists, the intention is to collect specification information from the sources of the registrations. After some more development, the present document is intended to be useful as a reference document for the IANA registrations of the CBOR tags the definitions of which have been collected.
 SCRAM-SHA-512 and SCRAM-SHA-512-PLUS Simple Authentication and Security Layer (SASL) Mechanisms
 
 draft-melnikov-scram-sha-512-01.txt
 Date: 18/11/2020
 Authors: Alexey Melnikov
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document registers the Simple Authentication and Security Layer (SASL) mechanisms SCRAM-SHA-512 and SCRAM-SHA-512-PLUS.
 Anycast SID for Flexible and Robust Service in SRv6
 
 draft-li-spring-anycast-sid-service-02.txt
 Date: 22/03/2021
 Authors: Taixin Li, Xu Zhou, Zhe Chen, Yihao Jia
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routing enables an operator or an application to specify a packet processing program. When Segment Routing is applied to IPv6 data plane, the list of IPv6 SIDs in SRH can specify a series of execution endpoints that hold service functions that process the packet. However, steering traffic dynamically to the different execution endpoints requires a specific "re-encapsulating". This procedure may be complex and take time. This document proposes A-SID (Anycast-SID) based on SRv6 to achieve flexible and robust service provision. It uses anycast SID to identify service functions and locates the service functions based on anycast routing. The proposed solution can stay compatibility with the existing SRv6.
 Light Weighted EVPN
 
 draft-wang-bess-evpn-cmac-overload-reduction-06.txt
 Date: 08/05/2021
 Authors: Yubao Wang, Ran Chen
 Working Group: Individual Submissions (none)
 Formats: html xml txt
SRv6 EVPN [I-D.ietf-bess-srv6-services] is not sufficient for some light-weighted use cases. When PBB EVPN [RFC7623] over SRv6 is used to support these light-weighted EVPN services, it is complicated to make use of the SID list to carry a function that is aiming for C-MACs. In [RFC8986], End.DX2 function is defined, this function can be used in EVPN VPLS. When it is used in EVPN VPLS, the data-plane learning defined in End.DT2U function can also be transplanted into End.DX2 function. On the basis of such extended End.DX2 function, SRv6 EVPN can be improved to meet all the requirements per [RFC7623] and bring us some other benefits. Such SRv6 EVPN is called light-weighted SRv6 EVPN, and it will be more simpler than PBB EVPN over SRv6. It is easy for the light-weighted SRv6 EVPN to carry a SID that is aiming for customer ethernet packets, because there will be no other ethernet header between the SID list and the customer ethernet header. These SIDs may be user-defined functions for the customer ethernet headers.
 Generalized SRv6 Network Programming for SRv6 Compression
 
 draft-cl-spring-generalized-srv6-for-cmpr-03.txt
 Date: 29/04/2021
 Authors: Weiqiang Cheng, Zhenbin Li, Cheng Li, Francois Clad, Liu Aihua, Chongfeng Xie, Yisong Liu, Shay Zadok
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes Generalized Segment Routing over IPv6 (G-SRv6) Networking Programming for SRv6 compression. G-SRv6 can reduce the overhead of SRv6 by encoding the Generalized SIDs(G-SID) in SID list, and it also supports to program SRv6 SIDs and G-SIDs in a single SRH to support incremental deployment and smooth upgrade. G-SRv6 is fully compatible with SRv6 with no modification of SRH, no new address consumption, no new route creation, and even no modification of control plane. G-SRv6 for Compression is designed based on the Compressed SRv6 Segment List Encoding in SRH [I-D.filsfilscheng-spring-srv6-srh-comp-sl-enc] framework.
 A Simple LISP NAT-Traversal Implementation
 
 draft-farinacci-lisp-simple-nat-01.txt
 Date: 14/11/2020
 Authors: Dino Farinacci
 Working Group: Individual Submissions (none)
 Formats: txt
This informational draft documents the lispers.net LISP NAT-Traversal implementation.
 Compressed SRv6 Segment List Encoding in SRH
 
 draft-filsfilscheng-spring-srv6-srh-comp-sl-enc-02.txt
 Date: 17/11/2020
 Authors: Weiqiang Cheng, Clarence Filsfils, Zhenbin Li, Dezhong Cai, Dan Voyer, Francois Clad, Shay Zadok, Jim Guichard, Liu Aihua
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a compressed SRv6 Segment List Encoding in the SRH. This solution does not require any SRH data plane change nor any SRv6 control plane change. This solution leverages the SRv6 Network Programming model.
 Secure Frame (SFrame)
 
 draft-omara-sframe-02.txt
 Date: 29/03/2021
 Authors: Emad Omara, Justin Uberti, Alex Gouaillard, Sergio Murillo
 Working Group: Individual Submissions (none)
 Formats: txt xml html
This document describes the Secure Frame (SFrame) end-to-end encryption and authentication mechanism for media frames in a multiparty conference call, in which central media servers (SFUs) can access the media metadata needed to make forwarding decisions without having access to the actual media. The proposed mechanism differs from other approaches through its use of media frames as the encryptable unit, instead of individual RTP packets, which makes it more bandwidth efficient and also allows use with non-RTP transports.
 Internet Protocol Encapsulation of AX.25 Frames
 
 draft-learmonth-intarea-rfc1226-bis-02.txt
 Date: 19/11/2020
 Authors: Iain Learmonth
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes a method for the encapsulation of AX.25 Link Access Protocol for Amateur Packet Radio frames within IPv4 and IPv6 packets. Obsoletes RFC1226. Note Comments are solicited and should be addressed to the author(s). The sources for this draft are at: https://github.com/irl/draft-rfc1226-bis
 The GNU Name System
 
 draft-schanzen-gns-04.txt
 Date: 06/05/2021
 Authors: Martin Schanzenbach, Christian Grothoff, Bernd Fix
 Working Group: Individual Submissions (none)
 Formats: html txt xml
This document contains the GNU Name System (GNS) technical specification.
 Route Distinguisher Outbound Route Filter (RD-ORF) for BGP-4
 
 draft-wang-idr-rd-orf-05.txt
 Date: 23/11/2020
 Authors: Wei Wang, Aijun Wang, Haibo Wang, Gyan Mishra, Shunwan Zhuang, Jie Dong
 Working Group: Individual Submissions (none)
 Formats: xml txt
This draft defines a new Outbound Route Filter (ORF) type, called the Route Distinguisher ORF (RD-ORF). RD-ORF is applicable when the routers do not exchange VPN routing information directly (e.g. routers in single-domain connect via Route Reflector, or routers in Option B/Option AB/Option C cross-domain scenario).
 Network Tokens
 
 draft-yiakoumis-network-tokens-02.txt
 Date: 22/12/2020
 Authors: Yiannis Yiakoumis, Nick McKeown, Frode Sorensen
 Working Group: Individual Submissions (none)
 Formats: txt
Network tokens is a method for endpoints to explicitly and securely coordinate with networks about how their traffic is treated. They are inserted by endpoints in existing protocols, interpreted by trusted networks, and may be signed or encrypted to meet security and privacy requirements. Network tokens provide a means for network operators to expose datapath services (such as a zero-rating service, a user-driven QoS service, or a firewall whitelist), and for end users and application providers to access such services. Network tokens are inspired and derived by existing security tokens (like JWT and CWT), and borrow several of their core ideas along with security and privacy properties.
 Security Needs for the NFSv4 Protocols
 
 draft-dnoveck-nfsv4-security-needs-02.txt
 Date: 21/01/2021
 Authors: David Noveck, Chuck Lever
 Working Group: Individual Submissions (none)
 Formats: txt xml html
This document discusses the inadequate approach to security within the family of NFSv4 protocol specifications and proposes steps to correct the situation. Because the security architecture is similar for all NFSv4 minor versions, we recommend a single new standards- track document to encapsulate NFSv4 security fundamentals, and propose the introduction of several additional security-related documents.
 Use cases of Application-aware Networking (APN) in Game Acceleration
 
 draft-zhang-apn-acceleration-usecase-01.txt
 Date: 14/12/2020
 Authors: Shuai Zhang, Chang Cao, Shuping Peng, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: xml txt
With the development of the Internet, game industry has risen rapidly, from handheld game consoles to PC games and mobile games. The types of games are diversified, while the number of game users is increasing year by year. The game market is maturing quickly. Nowadays, the scale of game users is large and they belong to the easy-to-consume groups. Among all the games, those require frequent interactions and involve video streaming usually have highly demanding requirements on the network in terms of guaranteed network latency and reliability. Therefore, from the aspect of ensuring better gaming experience, it is desirable of differentiating the particular gaming application flows and providing high-priority network services for those demanding gamers. This document describes the game acceleration scenarios using Application-aware Networking (APN) technology. In these scenarios, APN can identify the specific requirements of particular gaming applications, steer the flows to the game processors close to the users, and provide SLA guaranteed network services such as low latency and high reliability.
 Attestation Event Stream Subscription
 
 draft-birkholz-rats-network-device-subscription-02.txt
 Date: 31/03/2021
 Authors: Henk Birkholz, Eric Voit, Wei Pan
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines how to subscribe to an Event Stream of attestation related Evidence on TPM-based network devices.
 Identity Module for TLS Version 1.3
 
 draft-urien-tls-im-04.txt
 Date: 16/01/2021
 Authors: Pascal Urien
 Working Group: Individual Submissions (none)
 Formats: txt
TLS 1.3 will be deployed in the Internet of Things ecosystem. In many IoT frameworks, TLS or DTLS protocols, based on pre-shared key (PSK), are used for device authentication. So PSK tamper resistance, is a critical market request, in order to prevent hijacking issues. If DH exchange is used with certificate bound to DH ephemeral public key, there is also a benefit to protect its signature procedure. The TLS identity module (im) MAY be based on secure element; it realizes some HKDF operations bound to PSK, and cryptographic signature if certificates are used. Secure Element form factor could be standalone chip, or embedded in SoC like eSIM.
 DTN Bundle Protocol Security COSE Security Context
 
 draft-bsipos-dtn-bpsec-cose-05.txt
 Date: 16/03/2021
 Authors: Brian Sipos
 Working Group: Individual Submissions (none)
 Formats: xml txt html
This document defines a security context suitable for using CBOR Object Signing and Encryption (COSE) algorithms within Bundle Protocol Security (BPSec) integrity and confidentiality blocks. A profile of COSE and for PKIX certificates are also defined for BPSec interoperation.
 Trusted Path Routing
 
 draft-voit-rats-trustworthy-path-routing-02.txt
 Date: 02/04/2021
 Authors: Eric Voit
 Working Group: Individual Submissions (none)
 Formats: txt
There are end-users who believe encryption technologies like IPSec alone are insufficient to protect the confidentiality of their highly sensitive traffic flows. These end-users want their flows to traverse devices which have been freshly appraised and verified. This specification describes Trusted Path Routing. Trusted Path Routing protects sensitive flows as they transit a network by forwarding traffic to/from sensitive subnets across network devices recently appraised as trustworthy.
 Initializing a DNS Resolver with Priming Queries
 
 draft-klh-dnsop-rfc8109bis-01.txt
 Date: 16/11/2020
 Authors: Peter Koch, Matt Larson, Paul Hoffman
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the queries that a DNS resolver should emit to initialize its cache. The result is that the resolver gets both a current NS Resource Record Set (RRset) for the root zone and the necessary address information for reaching the root servers. This document, when published, obsoletes RFC 8109.
 SCHC over PPP
 
 draft-thubert-intarea-schc-over-ppp-03.txt
 Date: 21/04/2021
 Authors: Pascal Thubert
 Working Group: Individual Submissions (none)
 Formats: txt html xml
This document extends RFC 5172 to signal the use of SCHC as the compression method between a pair of nodes over PPP. Combined with RFC 2516, this enables the use of SCHC over Ethernet and Wi-Fi.
 Hop-by-Hop Forwarding Options Header
 
 draft-li-6man-hbh-fwd-hdr-01.txt
 Date: 19/02/2021
 Authors: Zhenbin Li, Shuping Peng, Gyan Mishra
 Working Group: Individual Submissions (none)
 Formats: txt xml
RFC8200 specifies the HBH header that is assumed to be processed by each hop in the delivery path of the packet. However, RFC8200 also expects that nodes processing the HBH header have been explicitly configured to do so. Therefore, it cannot be assumed that a HBH header present in the packet is processed. It all depends on the configuration of each node across the path. Moreover, in most of networks today, the processing of the HBH header is done in the control plane (slow processing path) which incurs several limitations among which resources consumption and security risk. For these reasons, over time, the Hop-by-Hop Options header has been sparsely used without any form of large scale deployment. Also, most of already defined HBH options are forwarding options which contain forwarding plane information that needs not to be sent to the control plane. This document proposes a new Hop-by-Hop Forwarding Options Header in order to carry Hop-by-Hop options that are solely intended to and processed by the forwarding plane. This new HBH header is confined in and dedicated to the forwarding plane while the current HBH header can still be used for control plane options.
 BGP UPDATE for SDWAN Edge Discovery
 
 draft-dunbar-idr-sdwan-edge-discovery-04.txt
 Date: 07/03/2021
 Authors: Linda Dunbar, Susan Hares, Robert Raszuk, Kausik Majumdar
 Working Group: Individual Submissions (none)
 Formats: txt
The document describes the encoding of BGP UPDATE messages for the SDWAN edge node discovery. In the context of this document, BGP Route Reflectors (RR) is the component of the SDWAN Controller that receives the BGP UPDATE from SDWAN edges and in turns propagates the information to the intended peers that are authorized to communicate via the SDWAN overlay network.
 QUIC-based UDP Transport for Secure Shell (SSH)
 
 draft-bider-ssh-quic-09.txt
 Date: 02/12/2020
 Authors: denis bider
 Working Group: Individual Submissions (none)
 Formats: txt xml html
The Secure Shell protocol (SSH) [RFC4251] is widely used for purposes including secure remote administration, file transfer using SFTP and SCP, and encrypted tunneling of TCP connections. Because it is based on TCP, SSH suffers similar problems as motivate the HTTP protocol to transition to UDP-based QUIC [QUIC]. These include: unauthenticated network intermediaries can trivially disconnect SSH sessions; SSH connections are lost when mobile clients change IP addresses; performance limitations in OS-based TCP stacks; many round-trips to establish a connection; duplicate flow control on the level of the connection as well as channels. This memo specifies SSH key exchange over UDP and leverages QUIC to provide a UDP-based transport.
 Using TLS Application-Layer Protocol Settings (ALPS) in HTTP
 
 draft-vvv-httpbis-alps-01.txt
 Date: 21/01/2021
 Authors: Victor Vasiliev
 Working Group: Individual Submissions (none)
 Formats: xml html txt
This document describes the use of TLS Application-Level Protocol Settings (ALPS) in HTTP/2 and HTTP/3. Additionally, it defines a set of additional HTTP SETTINGS parameters that would normally be impractical without ALPS.
 Multipath TCP Extension for Robust Session Establishment
 
 draft-amend-tcpm-mptcp-robe-01.txt
 Date: 22/02/2021
 Authors: Markus Amend, Jiao Kang
 Working Group: Individual Submissions (none)
 Formats: xml html txt
Multipath TCP extends the plain, single-path limited, TCP towards the capability of multipath transmission. This greatly improves the reliability and performance of TCP communication. For backwards compatibility reasons the Multipath TCP was designed to setup successfully an initial path first, after which subsequent paths can be added for multipath transmission. For that reason the Multipath TCP has the same limitations as the plain TCP during connection setup, in case the selected path is not functional. This document proposes a set of implementations and possible combinations thereof, that provide a more Robust Establishment (RobE) of MPTCP sessions. It includes RobE_TIMER, RobE_SIM, RobE_eSIM and RobE_IPS. RobE_TIMER is designed to stay close to MPTCP in that standard functionality is used wherever possible. Resiliency against network outages is achieved by modifying the SYN retransmission timer: If one path is defective, another path is used. RobE_SIM and RobE_eSIM provides the ability to simultaneously use multiple paths for connection setup. They ensure connectivity if at least one functional path out of a bunch of paths is given and offers beside that the opportunity to significantly improve loading times of Internet services. RobE_IPS provides a heuristic to select properly an initial path for connection establishment with a remote host based on empirical data derived from previous connection information. In practice, these independent solutions can be complementary used. This document also presents the design and protocol procedure for those combinations in addition to the respective stand-alone solutions.
 Distributed Ledger Time-Stamp
 
 draft-intesigroup-dlts-01.txt
 Date: 07/01/2021
 Authors: Emanuele Cisbani, Daniele Ribaudo, Giuseppe Damiano
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines a standard to extend Time Stamp Tokens with Time Attestations recorded on Distributed Ledgers. The aim is to provide long-term validity to Time Stamp Tokens, backward compatible with currently available software.
 DNS Access Denied Error Page
 
 draft-reddy-dnsop-error-page-07.txt
 Date: 20/04/2021
 Authors: Tirumaleswar Reddy.K, Neil Cook, Dan Wing, Mohamed Boucadair
 Working Group: Individual Submissions (none)
 Formats: txt xml
When a DNS server filters a query, the response to such query conveys no detailed explanation that elaborates why that query was blocked, leading thus to end-user confusion. A solution to this problem is needed in order to enhance the user experience. This document defines a method to return an URI that explains the reason why a DNS query was filtered by a DNS server.
 Multipath sequence maintenance
 
 draft-amend-iccrg-multipath-reordering-02.txt
 Date: 22/02/2021
 Authors: Markus Amend, Dirk Hugo
 Working Group: Individual Submissions (none)
 Formats: xml html txt
This document discusses the issue of packet re-ordering which occurs as a specific problem in multi-path connections without reliable transport protocols such as TCP. The topic is relevant for devices connected via multiple accesses technologies towards the network as is foreseen e.g. within Access Traffic Selection, Switching, and Splitting (ATSSS) service of 3rd Generation Partnership Project (3GPP) enabling fixed mobile converged (FMC) scenario.
 Definition of a Uniform Resource Name (URN) Namespace for the Schema for Academia (SCHAC)
 
 draft-milinovic-6338bis-01.txt
 Date: 21/04/2021
 Authors: Miroslav Milinovic
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes a Uniform Resource Name (URN) namespace for the Schema for Academia (SCHAC). The namespace described in this document is for naming persistent resources defined by the SCHAC participants internationally, their working groups, and other designated subordinates. The main use of this namespace will be for the creation of controlled vocabulary values for attributes in the SCHAC schema. These values will be associated with particular instances of persons or objects belonging to any of the SCHAC object classes. This document obsoletes RFC 6338.
 Self-configuring Stub Networks: Problem Statement
 
 draft-lemon-stub-networks-ps-01.txt
 Date: 02/03/2021
 Authors: Ted Lemon
 Working Group: Individual Submissions (none)
 Formats: xml txt html
IETF currently provides protocols for automatically connecting single hosts to existing network infrastructure. This document describes a related problem: the problem of connecting a stub network (a collection of hosts behind a router) automatically to existing network infrastructure in the same manner.
 Transport Considerations for IP and UDP Proxying in MASQUE
 
 draft-westerlund-masque-transport-issues-01.txt
 Date: 12/01/2021
 Authors: Magnus Westerlund, Marcus Ihlar, Zaheduzzaman Sarker, Mirja Kuehlewind
 Working Group: Individual Submissions (none)
 Formats: txt
The HTTP Connect method uses back-to-back TCP connections to and from a proxy. Such a solution takes care of many transport aspects as well as IP Flow related concerns. With UDP and IP proxying on the other hand, there are several per-packet and per-flow aspects that need consideration to preserve the properties of end- to-end IP/UDP flows. The aim of this document is to highlight and provide solutions for these issues related to UDP and IP proxying.
 Simple Two-way Active Measurement Protocol Extensions for Hop-by-Hop OAM Data Collection
 
 draft-wang-ippm-stamp-hbh-extensions-03.txt
 Date: 22/02/2021
 Authors: Yali Wang, Tianran Zhou, Hongwei Yang, Chang Liu
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines optional TLVs which are carried in Simple Two- way Active Measurement Protocol (STAMP) test packets to enhance the STAMP base functions. Such extensions to STAMP enable OAM data measurement and collection at every node and link along a STAMP test packet's delivery path without maintaining a state for each configured STAMP-Test session at every devices.
 Concepts of Digital Twin Network
 
 draft-zhou-nmrg-digitaltwin-network-concepts-03.txt
 Date: 22/02/2021
 Authors: Cheng Zhou, Hongwei Yang, Xiaodong Duan, Diego Lopez, Antonio Pastor, Qin WU, Mohamed Boucadair, Christian Jacquenet
 Working Group: Individual Submissions (none)
 Formats: txt xml
Digital Twin technology has been seen as a rapid adoption technology in Industry 4.0. The application of Digital Twin technology in the telecommunications field is meant to realize efficient and intelligent management and accelerate network innovation. This document presents an overview of the concepts of Digital Twin Network (DTN), provides the definition and DTN, and then describes the benefits and key challenges of such technology.
 Private Line Emulation over Packet Switched Networks
 
 draft-schmutzer-bess-ple-02.txt
 Date: 22/02/2021
 Authors: Steven Gringeri, Jeremy Whittaker, Nicolai Leymann, Christian Schmutzer, Luca Chiesa, Nagendra Nainar, Carlos Pignataro, Gerald Smallegange, Chris Brown, Faisal Dada
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes a method for encapsulating high-speed bit- streams as virtual private wire services (VPWS) over packet switched networks (PSN) providing complete signal transport transparency.
 Private Line Emulation VPWS Signalling
 
 draft-schmutzer-bess-ple-vpws-signalling-02.txt
 Date: 03/05/2021
 Authors: Steven Gringeri, Jeremy Whittaker, Christian Schmutzer, Patrice Brissette
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies the mechanisms to allow for dynamic signalling of Virtual Private Wire Services (VPWS) carrying bit- stream signals over Packet Switched Networks (PSN).
 Stateless SRv6 Point-to-Multipoint Path
 
 draft-chen-pim-srv6-p2mp-path-02.txt
 Date: 21/02/2021
 Authors: Huaimo Chen, Mike McBride, Yanhe Fan, Mehmet Toy, Aijun Wang, Lei Liu, Xufeng Liu
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes a solution for a SRv6 Point-to-Multipoint (P2MP) Path/Tree to deliver the traffic from the ingress of the path to the multiple egresses/leaves of the path in a SR domain. There is no state stored in the core of the network for a SR P2MP path like a SR Point-to-Point (P2P) path in this solution.
 Bitmask Route Target
 
 draft-zzhang-idr-bitmask-route-target-01.txt
 Date: 21/04/2021
 Authors: Zhaohui Zhang, Srihari Sangli, Jeffrey Haas
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies a new type of Route Target called Bitmask Route Target as a BGP Community Container. The key element of a Bitmask Route Target is a Bitmask. Two Bitmask Route Targets are considered equivalent for the purpose of controlling route propagation (via Route Target Constraints) and importation if the result of logical "AND" operation of the Bitmask of the two is non- zero.
 Generic Route Constraint Distribution Mechanism for BGP
 
 draft-zzhang-idr-bgp-rt-constrains-extension-02.txt
 Date: 21/04/2021
 Authors: Zhaohui Zhang, Jeffrey Haas
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a mechanism based upon Constrained Route Distribution for BGP (RFC 4684) that works with various types of BGP Community-like Path Attributes. Similar to RFC 4684, this mechanism can be used to build a route distribution graph to limit the propagation of BGP Routes. Unlike RFC 4684, this mechanism is not restricted to BGP Extended Communities (RFC 4360).
 MPLS-based Service Function Path(SFP) Consistency Verification
 
 draft-lm-mpls-sfc-path-verification-02.txt
 Date: 21/02/2021
 Authors: Liu Yao, Greg Mirsky
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes extensions to MPLS LSP ping mechanisms to support verification between the control/management plane and the data plane state for SR-MPLS service programming and MPLS-based NSH SFC. This document defines the signaling of the Generic Associated Channel (G-ACh) over a Service Function Path (SFP) with an MPLS forwarding plane using the basic unit defined in RFC 8595. The document updates RFC 8595 in respect to SFF's handiling TTL expiration. The document also describes the processing of the G-ACh by the elements of the SFP.
 Principles for the Involvement of Intermediaries in Internet Protocols
 
 draft-thomson-tmi-01.txt
 Date: 03/01/2021
 Authors: Martin Thomson
 Working Group: Individual Submissions (none)
 Formats: html xml txt
This document proposes a set of principles for designing protocols with rules for intermediaries. The goal of these principles is to limit the ways in which intermediaries can produce undesirable effects and to protect the useful functions that intermediaries legitimately provide.
 Seamless SR Problem Statement
 
 draft-hegde-spring-mpls-seamless-sr-05.txt
 Date: 22/02/2021
 Authors: Shraddha Hegde, Chris Bowers, Xiaohu Xu, Arkadiy Gulko, Alex Bogdanov, Jim Uttaro, Luay Jalil, Mazen Khaddam, Andrew Alston, Luis Contreras
 Working Group: Individual Submissions (none)
 Formats: xml txt
This draft documents a set of use cases and requirements for end-to- end intent-based paths spanning multi-domain packet networks. The document explicitly focuses on use cases that require high scale and availability, which will likely benefit from distributed solutions. It is intended that the requirements in this document serve as a basis for future IETF work to develop distributed solutions for inter-domain intent-based transport paths.
 TCP ACK Rate Request Option
 
 draft-gomez-tcpm-ack-rate-request-02.txt
 Date: 19/02/2021
 Authors: Carles Gomez, Jon Crowcroft
 Working Group: Individual Submissions (none)
 Formats: xml txt
TCP Delayed Acknowledgments (ACKs) is a widely deployed mechanism that allows reducing protocol overhead in many scenarios. However, Delayed ACKs may also contribute to suboptimal performance. When a relatively large congestion window (cwnd) can be used, less frequent ACKs may be desirable. On the other hand, in relatively small cwnd scenarios, eliciting an immediate ACK may avoid unnecessary delays that may be incurred by the Delayed ACKs mechanism. This document specifies the TCP ACK Rate Request (TARR) option. This option allows a sender to indicate the ACK rate to be used by a receiver, and it also allows to request immediate ACKs from a receiver.
 Bit Index Explicit Replication (BIER) Encapsulation for In-situ OAM (IOAM) Data
 
 draft-xzlnp-bier-ioam-01.txt
 Date: 08/01/2021
 Authors: Xiao Min, Zheng Zhang, Yisong Liu, Nagendra Nainar, Carlos Pignataro
 Working Group: Individual Submissions (none)
 Formats: xml txt
In-situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information while the packet traverses a particular network domain. Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. The BIER header contains a bit-string in which each bit represents exactly one egress router to forward the packet to. This document outlines the requirements to carry IOAM data in BIER header and specifies how IOAM data fields are encapsulated in BIER header.
 Traffic Steering using BGP Flowspec with SRv6 Policy
 
 draft-jiang-idr-ts-flowspec-srv6-policy-03.txt
 Date: 21/02/2021
 Authors: Jiang Wenying, Yisong Liu, Shuanglong Chen
 Working Group: Individual Submissions (none)
 Formats: xml txt
BGP Flow Specification (FlowSpec) [I-D.ietf-idr-rfc5575bis] has been proposed to distribute BGP FlowSpec NLRI to FlowSpec clients to mitigate (distributed) denial-of-service attacks, and to provide traffic filtering in the context of a BGP/MPLS VPN service. Recently, traffic steering applications in the context of SRv6 using FlowSpec aslo attract attention. This document introduces the usage of BGP FlowSpec to steer packets into an SRv6 Policy.
 Signal Degrade Indication in Segment Routing over MPLS Network
 
 draft-han-mpls-sdi-sr-01.txt
 Date: 21/02/2021
 Authors: Liuyan Han, Fan Yang, Junfeng Zhao
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a typical use case of MPLS-TP, where signal degrade defect needs to be correctly detected and transmitted via OAM messages within network. When MPLS-TP evolves to Segment Routing MPLS, transit node has no knowledge of labels to be encapsulated in MPLS label stack. Transit node cannot spread OAM messages with signal degrade defect indication. Thus, a solution is proposed in this draft.
 Forwarding Layer Use Cases
 
 draft-bryant-arch-fwd-layer-uc-01.txt
 Date: 04/01/2021
 Authors: Stewart Bryant, Uma Chunduri, Toerless Eckert, Alexander Clemm
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document considers the new and emerging use cases for IP. These use cases are difficult to address with IP in its current format and demonstrate the need to evolve the protocol.
 PFC-Free Low Delay Control Protocol
 
 draft-dai-tsvwg-pfc-free-congestion-control-01.txt
 Date: 11/04/2021
 Authors: Huichen Dai, Binzhang Fu, Kun Tan
 Working Group: Individual Submissions (none)
 Formats: txt xml html
Today, low-latency transport protocols like RDMA over Converged Ethernet (RoCE) can provide good delay and throughput performance in small and lightly loaded high-speed datacenter networks due to lossless transport based on priority-based flow control (PFC). However, PFC suffers from various issues from performance degradation and unreliability (e.g., deadlock), limiting the deployment of RoCE to only small scale clusters (~1000). This document presents LDCP, a new transport that scales loss- sensitive transports, e.g., RDMA, to entire data-centers containing tens of thousands machines, without dependency on PFC for losslessness, i.e., PFC-free. LDCP develops a novel end-to-end congestion control scheme and achieves very low queue occupancy even under high network utilization or large traffic churns, resulting in almost no packet loss. Meanwhile, LDCP allows a new flow to jump start at full speed at the very beginning and therefore minimizes the latency for short RPC-style transactions. LDCP relies on only WRED and ECN, two widely supported features on switches, so it can be easily deployed in existing network infrastructures. Finally, LDCP is simple by design and thus can be easily implemented by programmable or ASIC NICs.
 SCRAM-SHA3-512 and SCRAM-SHA3-512-PLUS Simple Authentication and Security Layer (SASL) Mechanisms
 
 draft-melnikov-scram-sha3-512-01.txt
 Date: 20/11/2020
 Authors: Alexey Melnikov
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document registers the Simple Authentication and Security Layer (SASL) mechanisms SCRAM-SHA3-512 and SCRAM-SHA3-512-PLUS.
 Trustworthiness Vectors for the Software Updates of Internet of Things (SUIT) Workflow Model
 
 draft-birkholz-rats-suit-claims-01.txt
 Date: 13/01/2021
 Authors: Henk Birkholz, Brendan Moran
 Working Group: Individual Submissions (none)
 Formats: txt xml
The IETF Remote Attestation Procedures (RATS) architecture defines Conceptual Messages as input and output of the appraisal process that assesses the trustworthiness of remote peers: Evidence and Attestation Results. Based on the Trustworthiness Vectors defined in Trusted Path Routing, this document defines a core set of Claims to be used in Evidence and Attestation Results for the Software Update for the Internet of Things (SUIT) Workflow Model. Consecutively, this document is in support of the Trusted Execution Environment Provisioning (TEEP) architecture, which defines the assessment of remote peers via RATS and uses SUIT for evidence generation as well as a remediation measure to improve trustworthiness of given remote peers.
 YANG Data Model for MPLS LSP Ping
 
 draft-nainar-mpls-lsp-ping-yang-01.txt
 Date: 21/01/2021
 Authors: Nagendra Nainar, Carlos Pignataro, Guangying Zheng
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the YANG data model for Multi-Protocol Label Switching (MPLS) LSP Ping. The model is based on YANG 1.1 as defined in RFC 7950 and conforms to the Network Management Datastore Architecture (NMDA) as described in RFC 8342.
 Error Performance Measurement in Packet-switched Networks
 
 draft-mirsky-ippm-epm-03.txt
 Date: 26/03/2021
 Authors: Greg Mirsky, Xiao Min, Liuyan Han
 Working Group: Individual Submissions (none)
 Formats: html txt xml
This document describes the use of the error performance metric to characterize a packet-switched network's conformance to the pre- defined set of performance objectives. In this document, metrics that characterize error performance in a packet-switched network (PSN) are defined, as well as methods to measure and calculate them. Also, the requirements for an active Operation, Administration, and Maintenance protocol to support the error performance measurement in PSN are discussed, and potential candidate protocols are analyzed. All metrics and measurement methods are equally applicable to underlay and overlay networks.
 Cacheable OSCORE
 
 draft-amsuess-core-cachable-oscore-01.txt
 Date: 22/02/2021
 Authors: Christian Amsuess, Marco Tiloca
 Working Group: Individual Submissions (none)
 Formats: html xml txt
Group communication with the Constrained Application Protocol (CoAP) can be secured end-to-end using Group Object Security for Constrained RESTful Environments (Group OSCORE), also across untrusted intermediary proxies. However, this sidesteps the proxies' abilities to cache responses from the origin server(s). This specification restores cachability of protected responses at proxies, by introducing consensus requests which any client in a group can send to one server or multiple servers in the same group.
 Client Hint Reliability
 
 draft-davidben-http-client-hint-reliability-02.txt
 Date: 30/11/2020
 Authors: David Benjamin
 Working Group: Individual Submissions (none)
 Formats: html txt xml
This document defines the Critical-CH HTTP response header, and the ACCEPT_CH HTTP/2 and HTTP/3 frames to allow HTTP servers to reliably specify their Client Hint preferences, with minimal performance overhead. 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/davidben/http-client-hint-reliability.
 RFC 7258 additions due to evolving Internet thread model
 
 draft-arkko-farrell-arch-model-t-7258-additions-02.txt
 Date: 22/02/2021
 Authors: Jari Arkko, Stephen Farrell
 Working Group: Individual Submissions (none)
 Formats: txt
Communications security has been at the center of many security improvements in the Internet. The goal has been to ensure that communications are protected against outside observers and attackers. RFC 7258 is the IETF guidance on taking into account pervasive monitoring threats in Internet technology development work. This memo suggests additions to RFC 7258 to cater for the evolving threats. For instance, it may be necessary to also worry about information collected by a legitimate protocol participant being misused for pervasive monitoring purposes.
 RFC 3552 additions due to evolving Internet thread model
 
 draft-arkko-farrell-arch-model-t-3552-additions-01.txt
 Date: 22/02/2021
 Authors: Jari Arkko, Stephen Farrell
 Working Group: Individual Submissions (none)
 Formats: txt
Communications security has been at the center of many security improvements in the Internet. The goal has been to ensure that communications are protected against outside observers and attackers. This memo suggests additions to the RFC 3552 threat model to cater for the evolving security and privacy issues seen on the Internet today. For instance, it is often also necessary to protect against endpoints that are compromised, malicious, or whose interests simply do not align with the interests of users. While such protection is difficult, there are some measures that can be taken and we argue that investigation of these issues is warranted.
 BGP Extension for Advertising In-situ Flow Information Telemetry (IFIT) Capabilities
 
 draft-wang-idr-bgp-ifit-capabilities-02.txt
 Date: 22/02/2021
 Authors: Yali Wang, Shunwan Zhuang, Yunan Gu, Ran Pang
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines extensions to BGP to advertise the In-situ Flow Information Telemetry (IFIT) capabilities. Within an IFIT domain, IFIT-capability advertisement from the tail node to the head node assists the head node to determine whether a particular IFIT Option type can be encapsulated in data packets. Such advertisement would be useful for mitigating the leakage threat and facilitating the deployment of IFIT measurements on a per-service and on-demand basis.
 Advertising Proxy for DNS-SD Service Registration Protocol
 
 draft-sctl-advertising-proxy-01.txt
 Date: 22/02/2021
 Authors: Stuart Cheshire, Ted Lemon
 Working Group: Individual Submissions (none)
 Formats: txt html xml
An Advertising Proxy allows a device that accepts service registra- tions using Service Registration Protocol (SRP) to make those regis- trations visible to legacy clients that only implement Multicast DNS.
 AS Hijack Detection and Mitigation
 
 draft-sriram-sidrops-as-hijack-detection-01.txt
 Date: 14/01/2021
 Authors: Kotikalapudi Sriram, Doug Montgomery
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document proposes a method for detection and mitigation of AS hijacking. In this mechanism, an AS operator registers a new object in the RPKI called 'ROAs Exist for All Prefixes (REAP)'. REAP is digitally signed using the AS holder's certificate. By registering a REAP object, the AS operator is declaring that they have Route Origin Authorization (ROA) coverage for all prefixes originated by their AS. A receiving AS will mark a route as Invalid if the prefix is not covered by any Validated ROA Payload (VRP) and the route origin AS has signed a REAP. Here Invalid means that the route is determined to be an AS hijack.
 Secure Negotiation of Incompatible Protocols in TLS
 
 draft-thomson-tls-snip-01.txt
 Date: 03/01/2021
 Authors: Martin Thomson
 Working Group: Individual Submissions (none)
 Formats: txt html xml
An extension is defined for TLS that allows a client and server to detect an attempt to force the use of less-preferred application protocol even where protocol options are incompatible. This supplements application-layer protocol negotiation, which allows choices between compatible protocols to be authenticated.
 Autonomic Control Plane challenges for Layer-Two Switched Networks
 
 draft-richardson-anima-l2-friendly-acp-01.txt
 Date: 28/01/2021
 Authors: Michael Richardson, Wei Pan
 Working Group: Individual Submissions (none)
 Formats: html xml txt
This document details the challenges with building an Autonomic Control Plane on Campus/Enterprise networks which are built out of layer-two (Ethernet) switched technologies. This document does not propose a specific solution as yet, but details a number of possibilities, and what it would take to standardize each possibility.
 Compact UUIDs for Constrained Grammars
 
 draft-taylor-uuid-ncname-01.txt
 Date: 17/01/2021
 Authors: Dorian Taylor
 Working Group: Individual Submissions (none)
 Formats: xml html txt
The Universally Unique Identifier is a suitable standard for, as the name suggests, uniquely identifying entities in a symbol space large enough that the identifiers do not collide. Many formal grammars, however, are too restrictive to permit the use of UUIDs in their canonical representation (described in RFC 4122 and elsewhere), despite it being useful to do so. This document specifies an alternative compact representation for UUIDs that preserves some properties of the canonical form, with three encoding varietals, to fit these more restrictive contexts.
 Extensions to enable wireless reliability and availability in multi- access edge deployments
 
 draft-bernardos-raw-mec-01.txt
 Date: 18/01/2021
 Authors: Carlos Bernardos, Alain Mourad
 Working Group: Individual Submissions (none)
 Formats: txt
There are several scenarios involving multi-hop heterogeneous wireless networks requiring reliable and available features combined with multi-access edge computing, such as Industry 4.0. This document describes solutions integrating IETF RAW and ETSI MEC, fostering discussion about extensions at both IETF and ETSI MEC to better support these scenarios.
 IP Flow Information Export (IPFIX) Information Elements Extension for Forwarding Exceptions
 
 draft-mvmd-opsawg-ipfix-fwd-exceptions-02.txt
 Date: 04/02/2021
 Authors: Venkata Munukutla, Shivam Vaid, Aditya Mahale, Devang Patel
 Working Group: Individual Submissions (none)
 Formats: txt xml
This draft proposes couple of new Forwarding exceptions related Information Elements (IEs) and Templates for the IP Flow Information Export (IPFIX) protocol. These new Information Elements and Exception Template can be used to export information about any forwarding errors in a network. This essential information is adequate to correlate packet drops to any control plane entity and map it to an impacted service. Once exceptions are correlated to a particular entity, an action can be assigned to mitigate such problems essentially enabling self-driving networks.
 SVG Tiny Portable/Secure
 
 draft-svg-tiny-ps-abrotman-01.txt
 Date: 09/03/2021
 Authors: Alex Brotman, J. Adams
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies SVG Tiny Portable/Secure (SVG Tiny PS) -- A Scalable Vector Graphics (SVG) profile to be used with documents that are intended for use with more secure requirements, and in some cases, in conjunction with a limited rendering engine.
 Service Binding Mapping for DNS Servers
 
 draft-schwartz-svcb-dns-03.txt
 Date: 19/04/2021
 Authors: Benjamin Schwartz
 Working Group: Individual Submissions (none)
 Formats: html xml txt
The SVCB DNS record type expresses a bound collection of endpoint metadata, for use when establishing a connection to a named service. DNS itself can be such a service, when the server is identified by a domain name. This document provides the SVCB mapping for named DNS servers, allowing them to indicate support for new transport protocols.
 SRv6 SID Allocation
 
 draft-cp-spring-srv6-sid-allocation-01.txt
 Date: 22/02/2021
 Authors: Ran Chen, Shaofu Peng
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a SRv6 SID allocation method.
 Least-Common Scope Communications
 
 draft-mudric-6man-lcs-02.txt
 Date: 14/11/2020
 Authors: Dusan Mudric, Alexandre Petrescu
 Working Group: Individual Submissions (none)
 Formats: xml txt
This draft formulates a security problem statement. The problem arises when a Host uses its Global Unicast Address (GUA) to communicate with another Host situated on the same link. To address this problem, we suggest to select and use addresses of a least scope that are common.
 A Taxonomy of operational security considerations for manufacturer installed keys and Trust Anchors
 
 draft-richardson-t2trg-idevid-considerations-03.txt
 Date: 22/02/2021
 Authors: Michael Richardson
 Working Group: Individual Submissions (none)
 Formats: txt xml html
This document provides a taxonomy of methods used by manufacturers of silicon and devices to secure private keys and public trust anchors. This deals with two related activities: how trust anchors and private keys are installed into devices during manufacturing, and how the related manufacturer held private keys are secured against disclosure. This document does not evaluate the different mechanisms, but rather just serves to name them in a consistent manner in order to aid in communication. RFCEDITOR: please remove this paragraph. This work is occurring in https://github.com/mcr/idevid-security-considerations
 Path Computation Element Communication Protocol (PCEP) Extensions to Enable IFIT
 
 draft-chen-pce-pcep-ifit-02.txt
 Date: 09/02/2021
 Authors: Huanan Chen, Hang Yuan, Tianran Zhou, Weidong Li, Giuseppe Fioccola, Yali Wang
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines PCEP extensions to distribute In-situ Flow Information Telemetry (IFIT) information. So that IFIT behavior can be enabled automatically when the path is instantiated. In-situ Flow Information Telemetry (IFIT) refers to network OAM data plane on-path telemetry techniques, in particular the most popular are In-situ OAM (IOAM) and Alternate Marking. The IFIT attributes here described can be generalized for all path types but the application to Segment Routing (SR) is considered in this document. This document extends PCEP to carry the IFIT attributes under the stateful PCE model.
 Usage scenarios of Application-aware Networking (APN) for SD-WAN
 
 draft-yang-apn-sd-wan-usecase-01.txt
 Date: 18/02/2021
 Authors: Feng Yang, Weiqiang Cheng, Shuping Peng, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the usage of Application-aware Networking (APN) in SD-WAN scenarios. In these scenarios, APN is able to identify a particular application, steer its traffic flows along explicit path across the network, and provide SLA guaranteed network services such as low latency and high reliability.
 BGP Extensions for Services in SRv6 and MPLS Coexisting Network
 
 draft-ls-bess-srv6-mpls-coexisting-vpn-01.txt
 Date: 07/01/2021
 Authors: Liu Yao, Bing Song
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document proposes a method to achieve VPN/EVPN in a network where SRv6 and SR-MPLS/MPLS coexist, including extensions of BGP.
 The "id-" prefix for Digest Algorithms
 
 draft-polli-id-digest-algorithms-01.txt
 Date: 18/12/2020
 Authors: Roberto Polli
 Working Group: Individual Submissions (none)
 Formats: txt xml html
This document defines the "id-" prefix for digest-algorithms used in the Digest HTTP field. This prefix explicits that the value of the digest-algorithm is independent from Content-Encoding.
 OSPF Transport Instance Extensions
 
 draft-acee-lsr-ospf-transport-instance-02.txt
 Date: 21/02/2021
 Authors: Acee Lindem, Yingzhen Qu, Abhay Roy, Sina Mirtorabi
 Working Group: Individual Submissions (none)
 Formats: txt
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 convenient to envision using 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 mechanism to relegate this ancillary information to a separate OSPF instance and minimize the impact.
 Secure Element for TLS Version 1.3
 
 draft-urien-tls-se-02.txt
 Date: 27/03/2021
 Authors: Pascal Urien
 Working Group: Individual Submissions (none)
 Formats: txt
This draft presents ISO7816 interface for TLS1.3 stack running in secure element. It presents supported cipher suites and key exchange modes, and describes embedded software architecture. TLS 1.3 is the de facto security stack for emerging Internet of Things (IoT) devices. Some of them are constraint nodes, with limited computing resources. Furthermore cheap System on Chip (SoC) components usually provide tamper resistant features, so private or pre shared keys are exposed to hacking. According to the technology state of art, some ISO7816 secure elements are able to process TLS 1.3, but with a limited set of cipher suites. There are two benefits for TLS-SE; first fully tamper resistant processing of TLS protocol, which increases the security level insurance; second embedded software component ready for use, which relieves the software of the burden of cryptographic libraries and associated attacks. TLS-SE devices may also embed standalone applications, which are accessed via internet node, using a routing procedure based on SNI extension.
 Soure Address Validation: Gap Analysis
 
 draft-li-opsec-sav-gap-analysis-01.txt
 Date: 10/01/2021
 Authors: Dan Li, Jianping Wu, Yunan Gu, Lancheng Qin, Tao Lin
 Working Group: Individual Submissions (none)
 Formats: txt pdf xml
This document identifies scenarios where existing IP spoofing approaches for detection and mitigation don't perform perfectly. Exsiting SAV (source address validation) approaches, either Ingress ACL filtering [RFC2827], unicast Reverse Path Forwarding (uRPF) [RFC3704], Feasible Path uRPF [RFC 3704], or Enhanced Feasible-Path uRPF [RFC8704] has limitations regarding eihter automated implemetation objective or detection accuracy objective (0% false positive and 0% false negative). This document provides the gap analysis of the exsting SAV approaches, and also provides solution discussions.
 Email Author Header Field
 
 draft-crocker-email-author-04.txt
 Date: 20/03/2021
 Authors: Dave Crocker
 Working Group: Individual Submissions (none)
 Formats: txt xml
Internet mail defines the From: header field to indicate the author of the message's content and the Sender: field to indicate who initially handled the message, on the author's behalf. The Sender: field is optional, if it has the same information as the From: field. This was not a problem, until development of stringent protections on use of the From: field. It has prompted Mediators, such as mailing lists, to modify the From: field, to circumvent mail rejection caused by those protections. In effect, the From: field has become dominated by its role as a handling identifier. The current specification augments the altered use of the From: field, by specifying the Author: field, which ensures identification of the original author of the message and is not subject to modification by Mediators. This version is published as an Experiment, to assess community interest, functional efficacy, and technical adequacy.
 YANG data model for BGP Segment Routing Extensions
 
 draft-deevi-spring-bgp-sr-yang-01.txt
 Date: 11/01/2021
 Authors: krishnadeevi, Kamran Raza, Kausik Majumdar, Bruno Decraene
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a YANG data model that can be used to configure and manage Segment Routing extensions in BGP.
 YANG data model for BGP Segment Routing TE Extensions
 
 draft-deevi-idr-bgp-srte-yang-01.txt
 Date: 11/01/2021
 Authors: krishnadeevi, Kamran Raza, Kausik Majumdar, Bruno Decraene, Zhichun Jiang
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a YANG data model that can be used to configure and manage Segment Routing TE extensions in BGP.
 Egress TLV for Nil FEC in Label Switched Path Ping and Traceroute Mechanisms
 
 draft-rathi-mpls-egress-tlv-for-nil-fec-04.txt
 Date: 21/02/2021
 Authors: Deepti Rathi, Kapil Arora, Shraddha Hegde, Zafar Ali, Nagendra Nainar
 Working Group: Individual Submissions (none)
 Formats: txt xml
MPLS ping and traceroute mechanism as described in RFC 8029 and related extensions for SR as defined in RFC 8287 is very useful to precisely validate the control plane and data plane synchronization. All intermediate nodes may not have been upgraded to support validation procedures. A simple mpls ping and traceroute mechanism comprises of ability to traverse any path without having to validate the control plane state. RFC 8029 supports this mechanism with Nil FEC. The procedures described in RFC 8029 are mostly applicable when the Nil FEC is used as intermediate FEC in the label stack. When all labels are represented using Nil FEC, it poses some challenges. This document introduces new TLV as additional extension to exisiting Nil FEC and describes mpls ping and traceroute procedures using Nil FEC with this additional extensions to overcome these challenges.
 Revised BGP Maximum Prefix Limits Outbound
 
 draft-sas-idr-maxprefix-outbound-02.txt
 Date: 18/02/2021
 Authors: Melchior Aelmans, stucchi-lists@glevia.com, Job Snijders
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document updates RFC4271 by adding a control mechanism which limits the negative impact of outbound route leaks (RFC7908) in order to prevent resource exhaustion in Border Gateway Protocol (BGP) implementations.
 An Interoperability Architecture for Blockchain/DLT Gateways
 
 draft-hardjono-blockchain-interop-arch-02.txt
 Date: 20/04/2021
 Authors: Thomas Hardjono, Martin Hargreaves, Ned Smith
 Working Group: Individual Submissions (none)
 Formats: txt
With the increasing interest in the potential use of blockchain systems for virtual assets, there is a need for these assets to have mobility across blockchain systems. An interoperability architecture for blockchain systems is needed in order to permit the secure flow of virtual assets between blockchain systems, satisfying the properties of transfer atomicity, consistency and durability. The architecture must recognize that there are different blockchain systems, and that the interior constructs in these blockchains maybe incompatible with one another. Gateway nodes perform the transfer of virtual assets between blockchain systems while masking the complexity of the interior constructs of the blockchain that they represent.
 Open Digital Asset Protocol
 
 draft-hargreaves-odap-02.txt
 Date: 08/05/2021
 Authors: Martin Hargreaves, Thomas Hardjono, Rafael Belchior
 Working Group: Individual Submissions (none)
 Formats: txt
This memo describes the Open Digital Asset Protocol (ODAP). ODAP is an asset transfer protocol that operates between two gateway devices. The protocol includes a description of virtual or digital assets held on distributed ledgers in an open and interoperable format, a session negotiation part and message passing flows between gateways connecting disparate distributed ledger technologies (DLTs).
 IPv6 Neighbor Discovery Overlay Multilink Network Interface (OMNI) Option
 
 draft-templin-6man-omni-option-09.txt
 Date: 12/02/2021
 Authors: Fred Templin, Tony Whyman
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines a new IPv6 Neighbor Discovery (ND) option termed the "Overlay Multilink Network Interface (OMNI) Option". The OMNI option may appear in any IPv6 ND message type; it is processed by interface types that recognize the option and ignored by all other interface types. The option supports functions such as prefix registration and multilink coordination, and is extensible to support additional functions in the future.
 Processing of the Hop-by-Hop Options Header
 
 draft-peng-v6ops-hbh-03.txt
 Date: 21/01/2021
 Authors: Shuping Peng, Zhenbin Li, Chongfeng Xie, Zhuangzhuang Qin, Gyan Mishra
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the processing of the Hop-by-Hop Options Header (HBH) in today's routers in the aspects of standards specification, common implementations, and default operations. This document outlines the reasons why the Hop-by-Hop Options Header is rarely utilized in current networks. In addition, this document describes how the HBH could be used as a powerful mechanism allowing deployment and operations of new services requiring a more optimized way to leverage network resources of an infrastructure. The Hop-by- Hop Options Header is taken into consideration by several network operators as a valuable container for carrying the information facilitating the introduction of new services. The desired, and proposed, processing behavior of the HBH and the migration strategies towards it are also suggested.
 The 'haptics' Top-level Media Type
 
 draft-muthusamy-dispatch-haptics-01.txt
 Date: 15/11/2020
 Authors: Yeshwant Muthusamy, Chris Ullrich
 Working Group: Individual Submissions (none)
 Formats: txt
This memo serves to register and document the 'haptics' top-level media type, under which subtypes for representation formats for haptics may be registered. This document also serves as a registration application for a set of intended subtypes, which are representative of some existing subtypes already in use.
 Federated TLS Authentication
 
 draft-halen-fed-tls-auth-01.txt
 Date: 12/04/2021
 Authors: Jakob Schlyter, =?utf-8?q?Stefan_Hal=C3=A9n?=
 Working Group: Individual Submissions (none)
 Formats: xml html txt
This document describes how to establish a secure end-to-end channel between two parties within a federation, where both client and server are mutually authenticated. The trust relationship is based upon a trust anchor held and published by the federation. A federation is a trusted third party that inter-connect different trust domains with a common set of policies and standards.
 How often and how long should IETF virtual meetings be?
 
 draft-richardson-shmoo-how-many-fine-dinners-02.txt
 Date: 28/11/2020
 Authors: Michael Richardson
 Working Group: Individual Submissions (none)
 Formats: xml html txt
This document recommends a model for IETF virtual meetings that emphasizes new work, community building and cross-area concerns. This document recommends virtual meetings be planned a reduced amount of overlap among sessions, with short sessions with generous gaps.
 MSYNC
 
 draft-bichot-msync-01.txt
 Date: 06/04/2021
 Authors: Sophie Bale, Remy Brebion, Guillaume Bichot
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the Multicast Synchronisation (MSYNC) Protocol that aims at transferring video media objects over IP multicast operating preferably RTP. Although generic, MSYNC has been primarily designed for transporting HTTP adaptive streaming (HAS) objects including manifest/playlists and media segments (e.g. MP4, CMAF) according to an HAS protocol such as Apple HLS or MPEG DASH between a multicast server and a multicast gateway.
 Secure Crypto Config
 
 draft-kaimindermann-securecryptoconfig-01.txt
 Date: 18/04/2021
 Authors: Kai Mindermann, Lisa Teis
 Working Group: Individual Submissions (none)
 Formats: xml html txt
Choosing secure cryptography algorithms and their corresponding parameters is difficult. Also, current cryptography APIs cannot change their default configuration which renders them inherently insecure. The Secure Crypto Config provides a method that allows cryptography libraries to change the default cryptography algorithms over time and at the same time stay compatible with previous cryptography operations. This is achieved by combining three things standardized by the Secure Crypto Config: (1) A process that is repeated every two years, where a new set of default configurations for standardized cryptography primitives is published in a specific format. (2) A Secure Crypto Config Interface that describes a common API to use cryptography primitives in software (3) using COSE to derive the parameters from output of cryptography primitives, otherwise future changes of the default configuration would change existing applications behavior.
 QUIC-Aware Proxying Using CONNECT-UDP
 
 draft-pauly-masque-quic-proxy-01.txt
 Date: 13/04/2021
 Authors: Tommy Pauly, David Schinazi
 Working Group: Individual Submissions (none)
 Formats: xml html txt
This document defines an extension to the CONNECT-UDP HTTP method that adds specific optimizations for QUIC connections that are proxied. This extension allows a proxy to reuse UDP 4-tuples for multiple connections. It also defines a mode of proxying in which QUIC short header packets can be forwarded through the proxy rather than being re-encapsulated and re-encrypted.
 Multipath Communication with Satellite and Terrestrial Links
 
 draft-deutschmann-sat-ter-multipath-01.txt
 Date: 18/04/2021
 Authors: Joerg Deutschmann, Kai-Steffen Hielscher, Reinhard German
 Working Group: Individual Submissions (none)
 Formats: xml txt
Multipath communication enables the combination of low data rate, low latency terrestrial links and high data rate, high latency links (e.g., geostationary satellite links) to provide a full-fledged Internet access. However, the combination of such heterogeneous links is challenging from a technical point of view. This document describes a possible solution, i.e. an architecture and scheduling mechanism. The applicability of this approach to encrypted transport protocols (e.g., Multipath QUIC) is also discussed.
 Binary Application Record Encoding (BARE)
 
 draft-devault-bare-01.txt
 Date: 20/11/2020
 Authors: Drew DeVault
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Binary Application Record Encoding (BARE) is a data format used to represent application records for storage or transmission between programs. BARE messages are concise and have a well-defined schema, and implementations may be simple and broadly compatible. A schema language is also provided to express message schemas out-of-band. Comments Comments are solicited and should be addressed to the mailing list at ~sircmpwn/public-inbox@lists.sr.ht and/or the author(s).
 Short Hierarchical IP Addresses at Edge Networks
 
 draft-song-ship-edge-01.txt
 Date: 20/04/2021
 Authors: Haoyu Song
 Working Group: Individual Submissions (none)
 Formats: xml txt
To mitigate the IPv6 header overhead in edge networks, this draft proposes to use short hierarchical addresses excluding the network prefix within edge networks. An edge network can be further organized into a hierarchical architecture containing one or more levels of networks. The border routers for each hierarchical level are responsible for address augmenting and pruning. Specifically, the top-level border routers convert the internal IP header to and from the standard IPv6 header. This draft presents an incrementally deployable scheme allowing packet header to be effectively compressed in edge networks without affecting the network interoperability.
 Simple TWAMP (STAMP) Extensions for Segment Routing Networks
 
 draft-gandhi-ippm-stamp-srpm-03.txt
 Date: 29/04/2021
 Authors: Rakesh Gandhi, Clarence Filsfils, Dan Voyer, Mach Chen, Bart Janssens, Richard Foote
 Working Group: Individual Submissions (none)
 Formats: txt xml
Segment Routing (SR) leverages the source routing paradigm. SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document specifies RFC 8762 (Simple Two-Way Active Measurement Protocol (STAMP)) extensions for SR networks, for both SR-MPLS and SRv6 data planes by augmenting the optional extensions defined in RFC 8972.
 Automated Certificate Management Environment (ACME) Service Discovery
 
 draft-tweedale-acme-discovery-01.txt
 Date: 16/11/2020
 Authors: Fraser Tweedale
 Working Group: Individual Submissions (none)
 Formats: txt xml html
This document specifies a DNS-based Service Discovery (DNS-SD) profile that enables Automated Certificate Management Environment (ACME) clients to locate ACME servers in their network environment.
 DetNet Control Plane Signaling
 
 draft-trossen-detnet-control-signaling-01.txt
 Date: 11/02/2021
 Authors: Dirk Trossen, Juergen Schmitt
 Working Group: Individual Submissions (none)
 Formats: txt
This document provides solutions for control plane signaling, in accordance with the control plane framework developed in the DetNet WG. The solutions cover distributed, centralized, and hybrid signaling scenarios in the TSN and SDN domain. We propose changes to RSVP IntServ for a better integration with Layer 2 technologies for resource reservation, outlining example API specifications for the realization of the revised RSVP (called RSVP-TSN in the document).
 Secure Reporting of Update Status
 
 draft-moran-suit-report-01.txt
 Date: 22/02/2021
 Authors: Brendan Moran
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Software Update for the Internet of Things (SUIT) manifest provides a way for many different update and boot workflows to be described by a common format. However, this does not provide a feedback mechanism for developers in the event that an update or boot fails. This specification describes a lightweight feedback mechanism that allows a developer in possession of a manifest to reconstruct the decisions made and actions performed by a manifest processor.
 Media Types with Multiple Suffixes
 
 draft-w3cdidwg-media-types-with-multiple-suffixes-01.txt
 Date: 11/01/2021
 Authors: Amy Guy
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document updates RFC 6838 "Media Type Specifications and Registration Procedures" to describe how to interpret subtypes with multiple suffixes.
 OSPF extension for 5G Edge Computing Service
 
 draft-dunbar-lsr-5g-edge-compute-ospf-ext-04.txt
 Date: 10/03/2021
 Authors: Linda Dunbar, Huaimo Chen, Aijun Wang
 Working Group: Individual Submissions (none)
 Formats: txt
This draft describes an OSPF extension for routers to advertise the running status and environment of the directly attached 5G Edge Computing servers. The AppMetaData can be used by the routers in the 5G Local Data Network to make intelligent decisions to optimize the forwarding of flows from UEs. The goal is to improve latency and performance for 5G Edge Computing services.
 User Devices Explicit Monitoring
 
 draft-cnbf-ippm-user-devices-explicit-monitoring-01.txt
 Date: 19/02/2021
 Authors: Mauro Cociglio, Massimo Nilo, Fabio Bulgarella, Giuseppe Fioccola
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a methodology to monitor network performance exploiting user devices. This can be achieved using the Explicit Flow Measurement Techniques, protocol independent methods that employ few marking bits, inside the header of each packet, for loss and delay measurement. User devices and servers, marking the traffic, signal these metrics to intermediate network observers allowing them to measure connection performance, and to locate the network segment where impairments happen. In addition or in alternative to network observers, a probe can be installed on the user device with remarkable benefits in terms of hardware deployment and measurement scalability.
 IPv6 Solution for 5G Edge Computing Sticky Service
 
 draft-dunbar-6man-5g-edge-compute-sticky-service-04.txt
 Date: 01/04/2021
 Authors: Linda Dunbar, John Kaippallimalil
 Working Group: Individual Submissions (none)
 Formats: txt
This draft describes the IPv6-based solutions that can stick an application flow originated from a mobile device to the same ANYCAST server location when the mobile device moves from one 5G cell site to another. The proposed solution expands the Application-aware ID and Service-Para options specified by [APN6] by including the ANYCAST Sticky Service location information in the IPv6 Hop-by- Hop or Destination Optional Header.
 Revised Cookie Processing in the IKEv2 Protocol
 
 draft-smyslov-ipsecme-ikev2-cookie-revised-01.txt
 Date: 27/04/2021
 Authors: Valery Smyslov
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a revised processing of cookies in the Internet Key Exchange protocol Version 2 (IKEv2). It is intended to solve a problem in IKEv2 when due to packets loss and reordering peers may erroneously fail to authenticate each other when cookies are used in the initial IKEv2 exchange.
 An Enhanced Source Routing Header Based on RH3
 
 draft-han-6man-enhanced-source-routing-header-02.txt
 Date: 18/01/2021
 Authors: Han Jie, Wang Huilai
 Working Group: Individual Submissions (none)
 Formats: txt
IPv6 Routing header type 3 (termed as RH3) is defined and used in Low-Power and Lossy Networks (LLNs) that are typically constrained in resources (limited communication data rate, processing power, energy capacity, memory). Based on the mechanisms introduced by RH3, this document specifies an new IPv6 Routing Header type that provides encapsulation capability of segments with various lengths and can be applied to more scenarios.
 An MPLS SR OAM option reducing the number of end-to-end path validations
 
 draft-geib-spring-oam-opt-01.txt
 Date: 30/04/2021
 Authors: Ruediger Geib
 Working Group: Individual Submissions (none)
 Formats: txt html xml
MPLS traceroute implementations validate dataplane connectivity and isolate faults by sending messages along every end-to-end Label Switched Path (LSP) combination between a source and a destination node. This requires a growing number of path validations in networks with a high number of equal cost paths between origin and destination. Segment Routing (SR) introduces MPLS topology awareness combined with Source Routing. By this combination, SR can be used to implement an MPLS traceroute option lowering the total number of LSP validations as compared to commodity MPLS traceroute.
 Bidirectional Forwarding Detection (BFD) on Multi-chassis Link Aggregation Group (MC-LAG) Interfaces
 
 draft-mtm-rtgwg-bfd-mc-lag-02.txt
 Date: 26/03/2021
 Authors: Greg Mirsky, Jeff Tantsura, Gyan Mishra
 Working Group: Individual Submissions (none)
 Formats: xml txt html
This document describes the use of Bidirectional Forwarding Detection for Multi-chassis Link Aggregation Group to provide faster than Link Aggregation Control Protocol convergence. This specification enhances RFC 7130 "Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces".
 Blockchain Gateways: Use-Cases
 
 draft-sardon-blockchain-gateways-usecases-01.txt
 Date: 03/02/2021
 Authors: Aetienne Sardon, Thomas Hardjono, Mike McBride
 Working Group: Individual Submissions (none)
 Formats: txt xml
In the past five years there has been a growing interest in using blockchains and DLT systems as a means to create a new mechanism to issue, distribute and manage virtual assets. However, as DLT systems consisting of peer-to-peer (P2P) network of nodes increase in number, there is an increasing need to interconnect these networks to permit virtual assets to flow into and out of them. This document captures a number of use-cases driving the need for interoperability between DLT systems.
 SLAAC with prefixes of arbitrary length in PIO (Variable SLAAC)
 
 draft-mishra-6man-variable-slaac-03.txt
 Date: 07/03/2021
 Authors: Gyan Mishra, Alexandre Petrescu, Naveen Kottapalli, Dusan Mudric, Dmytro Shytyi
 Working Group: Individual Submissions (none)
 Formats: txt xml
This draft proposes the use of arbitrary length prefixes in PIO for SLAAC. A prefix of length 63 in PIO, for example, would be permitted to form an address whose interface identifier length is 65, which allows several benefits. A prefix of length 65 would be allowed too, but it SHOULD NOT be used on a large scale, like at a large ISP; this is to avoid a race to the bottom. The implementation uses a parameter in the Host which is off by default. In that case, the Host respects the 64bit boundary. When the parameter is set to on the Host accepts prefixes of lengths different than 64 and forms 128bit addresses. In the past, various IPv6 addressing models have been proposed based on a subnet hierarchy embedding a 64-bit prefix. The last remnant of IPv6 classful addressing is a inflexible interface identifier boundary at /64. This document proposes flexibility to the fixed position of that boundary for interface addressing.
 Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for Strict Bundling Registration
 
 draft-yao-regext-bundling-registration-05.txt
 Date: 03/05/2021
 Authors: Jiankang Yao, Linlin Zhou, Hongtao Li, Ning Kong, Wil Tan, Jiagui Xie
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes an extension of Extensible Provisioning Protocol (EPP) domain name mapping for the provisioning and management of strict bundling registration of domain names. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of bundled domain names. This is a non-standard proprietary extension.
 QRT: QUIC RTP Tunnelling
 
 draft-hurst-quic-rtp-tunnelling-01.txt
 Date: 28/01/2021
 Authors: Sam Hurst
 Working Group: Individual Submissions (none)
 Formats: txt
QUIC is a UDP-based transport protocol for stream-orientated, congestion-controlled, secure, multiplexed data transfer. RTP carries real-time data between endpoints, and the accompanying control protocol RTCP allows monitoring and control of the transfer of such data. With RTP and RTCP being agnostic to the underlying transport protocol, it is possible to multiplex both the RTP and associated RTCP flows into a single QUIC connection to take advantage of QUIC features such as low-latency setup and strong TLS-based security.
 Realizing Network Slices in IP/MPLS Networks
 
 draft-bestbar-teas-ns-packet-02.txt
 Date: 22/02/2021
 Authors: Tarek Saad, Vishnu Beeram, Bin Wen, Daniele Ceccarelli, Joel Halpern, Shaofu Peng, Ran Chen, Xufeng Liu, Luis Contreras
 Working Group: Individual Submissions (none)
 Formats: txt
Network slicing provides the ability to partition a physical network into multiple logical networks of varying sizes, structures, and functions so that each slice can be dedicated to specific services or customers. Network slices need to operate in parallel while providing slice elasticity in terms of network resource allocation. The Differentiated Service (Diffserv) model allows for carrying multiple services on top of a single physical network by relying on compliant nodes to apply specific forwarding treatment (scheduling and drop policy) on to packets that carry the respective Diffserv code point. This document proposes a solution based on the Diffserv model to realize network slicing in IP/MPLS networks.
 A Yang Data Model for IETF Network Slice NBI
 
 draft-wd-teas-ietf-network-slice-nbi-yang-02.txt
 Date: 21/02/2021
 Authors: Bo Wu, Dhruv Dhody, Liuyan Han, Reza Rokui
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document provides a YANG data model for the IETF Network Slice NBI (Northbound Interface). The model can be used by a higher level system to request configuration, and management IETF Network Slices from the IETF Network Slice Controller (NSC). The YANG modules in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.
 Guidance on End-to-End E-mail Security
 
 draft-dkg-lamps-e2e-mail-guidance-01.txt
 Date: 22/02/2021
 Authors: Daniel Gillmor
 Working Group: Individual Submissions (none)
 Formats: txt html xml
End-to-end cryptographic protections for e-mail messages can provide useful security. However, the standards for providing cryptographic protection are extremely flexible. That flexibility can trap users and cause surprising failures. This document offers guidance for mail user agent implementers that need to compose or interpret e-mail messages with end-to-end cryptographic protection. It provides a useful set of vocabulary as well as suggestions to avoid common failures.
 BGP NLRI App Meta Data for 5G Edge Computing Service
 
 draft-dunbar-idr-5g-edge-compute-app-meta-data-02.txt
 Date: 08/03/2021
 Authors: Linda Dunbar, Kausik Majumdar, Haibo Wang
 Working Group: Individual Submissions (none)
 Formats: txt
This draft describes a new BGP Network Layer Reachability Information (BGP NLRI) Path Attribute, AppMetaData, for egress router to advertise the running status and environment of the directly attached 5G Edge Computing servers. The AppMetaData can be used by the ingress routers in the 5G Local Data Network to make intelligent path selection for flows from UEs. The goal is to improve latency and performance for 5G Edge Computing services. The extension enables a feature, called soft anchoring, which makes one Edge Computing Server at one specific location to be more preferred than others for the same application to receive packets from a specific source (UE).
 A Simplified Scalable ELAN Service Model with Segment Routing Underlay
 
 draft-boutros-bess-elan-services-over-sr-02.txt
 Date: 21/02/2021
 Authors: Sami Boutros, Siva Sivabalan, Himanshu Shah, Jim Uttaro, Dan Voyer, Bin Wen, Luay Jalil
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document proposes a new approach for deploying Ethernet LAN (ELAN) services with an objective of achieving high scalability, faster network convergence, and reduced operational complexity. Furthermore, it naturally brings the benefits of All-Active multihoming as well as MAC learning in data-plane.
 Separation of Data Path and Data Flow Sublayers in the Transport Layer
 
 draft-asai-tsvwg-transport-review-01.txt
 Date: 22/02/2021
 Authors: Hirochika Asai
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document reviews the architectural design of the transport layer. In particular, this document separates the transport layer into two sublayers; the data path and the data flow layers. The data path layer provides functionality on the data path, such as connection handling, path quality and trajectory monitoring, waypoint management, and congestion control. The data flow layer provides additional functionality upon the data path layer, such as flow control for the receive buffer management, retransmission for reliable data delivery, and transport layer security. The data path layer multiplexes multiple data flow layer protocols and provides data path information to the data flow layer to control data transmissions, such as prioritization and inverse multiplexing for multipath protocols.
 Compressed SRv6 SID List Requirements
 
 draft-srcompdt-spring-compression-requirement-06.txt
 Date: 28/03/2021
 Authors: Weiqiang Cheng, Chongfeng Xie, Ron Bonica, Darren Dukes, Cheng Li, Shaofu Peng, Wim Henderickx
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies requirements for solutions to compress SRv6 SID lists.
 Network measurement intent
 
 draft-yang-nmrg-network-measurement-intent-01.txt
 Date: 22/02/2021
 Authors: Danyang Chen, Hongwei Yang, Kehan Yao
 Working Group: Individual Submissions (none)
 Formats: txt
As an important technical means to detect network state, network measurement has attracted more and more attention in the development of network. However, the current network measurement technology has the problem that the measurement method and the measurement purpose cannot match well. To solve this problem, this memo introduces network measurement intent, namely the process of realizing user or network operator to allocate network states as needed. And it can be as a specified user case of intent based network.
 Segment Routing for Redundancy Protection
 
 draft-geng-spring-sr-redundancy-protection-02.txt
 Date: 22/02/2021
 Authors: Xuesong Geng, Mach Chen, Fan Yang
 Working Group: Individual Submissions (none)
 Formats: txt
Redundancy protection is one of the mechanisms to achieve service protection, following the principle of PREOF (Packet Replication/Elimination/Ordering Function). To empower the Segment Routing with the capability of redundancy protection, two types of Segment including Redundancy Segment and Merging Segment are introduced. The instantiation of Redundancy and Merging Segments can be applied to both segment routing over MPLS (SR-MPLS) and segment routing over IPv6 (SRv6).
 Network Monitoring For IGP
 
 draft-gu-opsawg-network-monitoring-igp-01.txt
 Date: 19/02/2021
 Authors: Yunan Gu, Shuanglong Chen, Yingzhen Qu, Huanan Chen, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: txt
To evolve towards automated network OAM (Operations, administration and management), the monitoring of control plane protocols is a fundamental necessity. This document proposes network monitoring for IGP to facilitate troubleshooting by collecting the IGP monitoring data and reporting it to the network monitoring server in real-time. In this document, the operations of network monitoring for ISIS are described, and the corresponding network monitoring message types and message formats are defined.
 Research on multipriority scheduling technology for real-time interconnection between industrial field data and cloud information
 
 draft-tang-iiot-industrial-scheduling-03.txt
 Date: 19/11/2020
 Authors: Chaowei Tang, Ruan Shuai, Huang Baojin, Wen Haotian, Feng Xinxin
 Working Group: Individual Submissions (none)
 Formats: xml txt html
This document describes the multipriority scheduling technology for the interconnection between industrial field and cloud data in the application of 5G communication. The technology includes spectrum resource scheduling based on 5G slice in the process of accessing industrial data and task collaborative scheduling based on edge computing.
 Architecture Based on IPv6 and 5G for IIoT
 
 draft-tang-iiot-architecture-01.txt
 Date: 16/11/2020
 Authors: Chaowei Tang, Wen Haotian, Ruan Shuai, Baojin Huang, Feng Xinxin
 Working Group: Individual Submissions (none)
 Formats: html txt xml
As the foundation of the current new round of industrial revolution, the Industrial Internet of Things (IIoT) based on cyber-physical systems (CPS) [smart-factory] has become the focus of research in various countries. One of the key issues in the entire development stage of IIoT is the standardization of the IIoT architecture. With the development of intelligent manufacturing technology, the number of IIoT devices is expected to increase sharply, and large amounts of data will be generated in the industrial manufacturing process. However, traditional industrial networks cannot meet the IIoT requirements for high data rates, low latency, massive connections, interconnection, and interoperability. Current IIoT architectures also have various limitations, including those in mobility, security, scalability, and communication reliability. These limitations hinder the development and implementation of IIoT. As a network layer protocol, IPv6 can solve the problem of IPv4 address exhaustion. Meanwhile, as a high-speed, low-latency, wireless communication technology, 5G has great potential in promoting IIoT. To solve the aforementioned problems, this draft proposes an IIoT architecture based on IPv6 and 5G. The architecture can provide high-speed, low- latency communication services and possesses massive connectivity, mobility, scalability, security, and other features for industrial devices. It can also provide generalized, refined, flexible network services for devices outside factories. Moreover, an information model is defined to standardize the representation of information in IIoT. The security challenges in and recommendations for IIoT are also discussed.
 Explicit Flow Measurements Techniques
 
 draft-mdt-ippm-explicit-flow-measurements-01.txt
 Date: 22/02/2021
 Authors: Mauro Cociglio, Alexandre Ferrieux, Giuseppe Fioccola, Igor Lubashev, Fabio Bulgarella, Isabelle Hamchaoui, Massimo Nilo, Riccardo Sisto, Dmitri Tikhonov
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes protocol independent methods called Explicit Flow Measurement Techniques that employ few marking bits, inside the header of each packet, for loss and delay measurement. The endpoints, marking the traffic, signal these metrics to intermediate observers allowing them to measure connection performance, and to locate the network segment where impairments happen. Different alternatives are considered within this document. These signaling methods apply to all protocols but they are especially valuable when applied to protocols that encrypt transport header and do not allow traditional methods for delay and loss detection.
 IETF Network Slice Controller and its associated data models
 
 draft-contreras-teas-slice-controller-models-01.txt
 Date: 22/02/2021
 Authors: Luis Contreras, Reza Rokui, Jeff Tantsura, Bo Wu, Xufeng Liu, Dhruv Dhody, Sergio Belotti
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the major functional components of an IETF Network Slice Controller (NSC) as well as references the data models required for supporting the requests of IETF network slices and their realization.
 Privacy Pass: Centralization Problem Statement
 
 draft-mcfadden-pp-centralization-problem-01.txt
 Date: 04/05/2021
 Authors: Mark McFadden
 Working Group: Individual Submissions (none)
 Formats: txt
This document discusses the problems associated with strict upper bounds on the number of Privacy Pass servers in the proposed Privacy Pass ecosystem. It documents a proposed problem statement.
 Protocol and Engineering Effects of Consolidation
 
 draft-lazanski-consolidation-01.txt
 Date: 22/02/2021
 Authors: Dominique Lazanski, Mark McFadden, Eliot Lear
 Working Group: Individual Submissions (none)
 Formats: txt
This document contributes to the ongoing discussion surrounding Internet consolidation. Though there has been much interest in the topic, the conversation has waned. This document aims to discuss recent areas of Internet consolidation that are technical, economic and engineering focused and provide some suggestions for advancing the discussion.
 BIER Egress Protection
 
 draft-chen-bier-egress-protect-01.txt
 Date: 21/02/2021
 Authors: Huaimo Chen, Mike McBride, Aijun Wang, Gyan Mishra, Yisong Liu, Yanhe Fan, Lei Liu, Xufeng Liu
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes a mechanism for fast protection against the failure of an egress node of a "Bit Index Explicit Replication" (BIER) domain. It does not have any per-flow state in the core of the domain. For a multicast packet to an egress node of the domain, when the egress node fails, its upstream hop as a PLR sends the packet to the egress' backup node once the PLR detects the failure.
 BIER Fast ReRoute
 
 draft-chen-bier-frr-02.txt
 Date: 21/02/2021
 Authors: Huaimo Chen, Mike McBride, Aijun Wang, Gyan Mishra, Yisong Liu, Yanhe Fan, Lei Liu, Xufeng Liu
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes a mechanism for fast re-route (FRR) protection against the failure of a node or link in the core of a "Bit Index Explicit Replication" (BIER) domain. It does not have any per-flow state in the core. For a multicast packet to traverse a node in the domain, when the node fails, its upstream hop as a PLR reroutes the packet around the failed node once it detects the failure.
 IKEv2 support for per-queue Child SAs
 
 draft-pwouters-multi-sa-performance-01.txt
 Date: 22/02/2021
 Authors: Antony Antony, Steffen Klassert, Paul Wouters
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines two Notification Payloads for the Internet Key Exchange Protocol Version 2 (IKEv2): NUM_QUEUES and QUEUE_INFO. These payloads add support for indicating that the negotiating of multiple identical Child SAs are to be used to optimize performance based on the number of queues or CPUs, or to create multiple Child SAs for different Quality of Service (QoS) levels. It indicates that a newer idetnical Child SA should not be interpreted as a replacement Child SA. Using multiple identical Child Sa's has the benefit that each stream has its own Sequence Number, ensuring that CPU's don't have to synchronize their crypto state or disable their packet replay detection.
 YANG Data Model for SR Service Programming
 
 draft-jags-spring-sr-service-programming-yang-01.txt
 Date: 22/02/2021
 Authors: Jaganbabu Rajamanickam, Kamran Raza, daniel.bernier@bell.ca, Gaurav Dawra
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a YANG data model for Segment Routing (SR) Service Programming. The model serves as a base framework for configuring and managing an SR based service programming. Additionally, this document specifies the model for a Service Proxy for SR-unaware services. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA).
 What To Do With Multiple Active Paths in QUIC
 
 draft-dawkins-quic-what-to-do-with-multipath-03.txt
 Date: 06/01/2021
 Authors: Spencer Dawkins
 Working Group: Individual Submissions (none)
 Formats: xml txt
The IETF QUIC working group has been chartered to produce extensions that would "enable ... multipath capabilities" since the working group was formed in 2016, but because multipath was an extension, work on multipath, and the other extensions named in the charter, waited while work proceeded on the core QUIC protocol specifications. After the QUIC working group chairs requested publication for the core QUIC protocol specifications, they scheduled a virtual interim meeting to understand the use cases that various groups inside and outside the IETF were envisioning for multipath with QUIC. As part of that discussion, it became obvious that people had a variety of ideas about how multiple paths would be used, because they weren't looking at the same use cases. This document is intended to capture that variety of ideas, to inform further discussion in the working group.
 Framework and Data Model for OTN Network Slicing
 
 draft-zheng-ccamp-yang-otn-slicing-01.txt
 Date: 22/02/2021
 Authors: Haomian Zheng, Italo Busi, Aihua Guo, Victor Lopez
 Working Group: Individual Submissions (none)
 Formats: txt
The requirement of slicing network resource with desired quality of service is emerging at every network technology, including the Optical Transport Networks (OTN). As a part of the transport network, OTN can provide hard pipes with guaranteed data isolation and deterministic low latency, which are highly demanded in the Service Level Agreement (SLA). This document describes a framework for OTN network slicing and a YANG data model augmentation of the OTN topology model. Additional YANG data model augmentations will be defined in a future version of this draft.
 Describing TCP with Augmented Packet Header Diagrams
 
 draft-mcquistin-augmented-tcp-example-01.txt
 Date: 05/05/2021
 Authors: Stephen McQuistin, Vivian Band, Dejice Jacob, Colin Perkins
 Working Group: Individual Submissions (none)
 Formats: txt html xml
This document describes TCP, and a number of its extensions, using Augmented Packet Header Diagrams. This document is an example of the Augmented Packet Header Diagram language: it is not intended as a contribution to any ongoing or future work on maintaining or extending TCP.
 Describing UDP with Augmented Packet Header Diagrams
 
 draft-mcquistin-augmented-udp-example-01.txt
 Date: 05/05/2021
 Authors: Stephen McQuistin, Vivian Band, Dejice Jacob, Colin Perkins
 Working Group: Individual Submissions (none)
 Formats: xml txt html
This document describes UDP using Augmented Packet Header Diagrams. This document is an example of the Augmented Packet Header Diagram language: it is not intended as a contribution to any ongoing or future work on maintaining or extending UDP.
 An Extension of I2NSF Framework for Security Management Automation in Cloud-Based Security Services
 
 draft-jeong-i2nsf-security-management-automation-01.txt
 Date: 22/02/2021
 Authors: Jaehoon Jeong, Patrick Lingga, J., PARK
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes an extension of the framework of Interface to Network Security Functions (I2NSF) for Security Management Automation (SMA) in cloud-based security services. The security management automation in this document deals with a security polity translation and a feedback-based security service enforcement. To support these two features in SMA, this document specifies an augmented architecture of the I2NSF framework with a new system component and a new interface.
 Messaging Use Cases and Extensions for STIR
 
 draft-peterson-stir-messaging-01.txt
 Date: 22/02/2021
 Authors: Jon Peterson, Chris Wendt
 Working Group: Individual Submissions (none)
 Formats: txt
Secure Telephone Identity Revisited (STIR) provides a means of attesting the identity of a telephone caller via a signed token in order to prevent impersonation of a calling party number, which is a key enabler for illegal robocalling. Similar impersonation is sometimes leveraged by bad actors in the text messaging space. This document considers the applicability of STIR's Persona Assertion Token (PASSporT) and certificate issuance framework to instant text and multimedia messaging use cases, both for messages carried or negotiated by SIP, and for non-SIP messaging.
 Internet Threat Model Evolution: Background and Principles
 
 draft-arkko-farrell-arch-model-t-redux-01.txt
 Date: 22/02/2021
 Authors: Jari Arkko, Stephen Farrell
 Working Group: Individual Submissions (none)
 Formats: txt
Communications security has been at the center of many security improvements in the Internet. The goal has been to ensure that communications are protected against outside observers and attackers. This memo suggests that the existing RFC 3552 threat model, while important and still valid, is no longer alone sufficient to cater for the pressing security and privacy issues seen on the Internet today. For instance, it is often also necessary to protect against endpoints that are compromised, malicious, or whose interests simply do not align with the interests of users. While such protection is difficult, there are some measures that can be taken and we argue that investigation of these issues is warranted. It is particularly important to ensure that as we continue to develop Internet technology, non-communications security related threats, and privacy issues, are properly understood.
 Running an IETF Hackathon
 
 draft-eckel-shmoo-ietf-hackathon-04.txt
 Date: 15/04/2021
 Authors: Charles Eckel
 Working Group: Individual Submissions (none)
 Formats: txt html xml
IETF Hackathons encourage the IETF community to collaborate on running code related to existing and evolving Internet standards. This document provides a set of practices for running IETF Hackathons.
 Transaction ID Mechanism for NETCONF
 
 draft-lindblad-netconf-transaction-id-00.txt
 Date: 06/11/2020
 Authors: Jan Lindblad
 Working Group: Individual Submissions (none)
 Formats: html txt xml
TODO Abstract 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/janlindblad/netconf-transaction-id.
 Per-Application Networking Considerations
 
 draft-per-app-networking-considerations-00.txt
 Date: 15/11/2020
 Authors: Lorenzo Colitti, Tommy Pauly
 Working Group: Individual Submissions (none)
 Formats: txt html xml
This document describes considerations for and implications of using application identifiers as a method of differentiating traffic on networks. Specifically, it discusses privacy considerations, possible mitigations, and considerations for user experience and API design. 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/tfpauly/per-app-networking-considerations.
 Using Messaging Layer Security (MLS) to Provide Keys for SFrame
 
 draft-barnes-sframe-mls-00.txt
 Date: 15/11/2020
 Authors: Richard Barnes, Raphael Robert
 Working Group: Individual Submissions (none)
 Formats: txt html xml
Secure Frames (SFrame) defines a compact scheme for encrypting real- time media. In order for SFrame to address cases where media are exchanged among many participants (e.g., real-time conferencing), it needs to be augmented with a group key management protocol. The Messaging Layer Security (MLS) protocol provides continuous group authenticated key exchange, allowing a group of participants in a media session to authenticate each other and agree on a group key. This document defines how the group keys produced by MLS can be used with SFrame to secure real-time sessions for groups.
 Mailing List Manager (MLM) Transformations
 
 draft-vesely-dmarc-mlm-transform-01.txt
 Date: 02/02/2021
 Authors: Alessandro Vesely
 Working Group: Individual Submissions (none)
 Formats: html xml txt
The widespread adoption of Domain-based Message Authentication, Reporting, and Conformance (DMARC) led Mailing List Managers (MLM) to rewrite the From: header field as a workaround. This document describes cases where it is possible to revert MLM transformations and hence verify DomainKeys Identified Mail (DKIM) signatures that were applied at submission time. For reliable results, some compliance is required of all agents involved, author domain signers, MLMs, forwarders, and final recipients. MLM transformation reversion reduces the DMARC's effects on indirect mail flows.
 Automated Certificate Management Environment (ACME) Server Capability Advertisements
 
 draft-tweedale-acme-server-capabilities-00.txt
 Date: 16/11/2020
 Authors: Fraser Tweedale
 Working Group: Individual Submissions (none)
 Formats: html txt xml
Automated Certificate Management Environment (ACME) servers typically support only a subset of the ACME identifier types and validation types that have been defined. This document defines new fields for the the ACME directory object to allow servers to advertise their capabilities, assisting clients to select a suitable server.
 Identity Header Error Handling
 
 draft-wendt-stir-identity-header-errors-handling-01.txt
 Date: 22/02/2021
 Authors: Chris Wendt
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document extends STIR and the Authenticated Identity Management in the Session Initiation Protocol (SIP) related to error handling for STIR verification services and how they feedback errors to STIR authentication services. Specifically, the use of a Reason header field and addressing scenarios that use multiple identity headers where some may have errors and others may not and the handling of those situations is defined.
 The IPv6 Link-Local Address Type Field
 
 draft-templin-6man-lla-type-02.txt
 Date: 23/11/2020
 Authors: Fred Templin
 Working Group: Individual Submissions (none)
 Formats: txt xml
IPv6 link-local addresses are formed from the prefix fe80::/10 which is followed by 54 "zero" bits, then followed by a 64-bit Interface Identifier. There are multiple methods for generating link-local addresses, and multiple may be in use by nodes on the same link (and sometimes even the same interface) at the same time. This document defines an IPv6 link-local address "Type" field that identifies the type of link-local address being used.
 RADIUS Extension for Certificate-based SSH Authentication
 
 draft-vishwakarma-opsawg-ssh-cert-radius-00.txt
 Date: 17/11/2020
 Authors: Devendra Vishwakarma, Prakash suthar, Vivek Agarwal, Anil Jangam
 Working Group: Individual Submissions (none)
 Formats: txt
A scalable and centralized mechanism is required for a certificate- based administrative access to multitude of virtualized and physical network functions. While there are mechanisms that exist today to provide secure administrative command-line and API-based access, there are certain management and maintenance overheads as well as certain scalability challenges related to it. In this draft we discuss these challenges and propose a standardized, centralized server-based mechanism to authenticate a user over an SSH session using its client certificate.
 The Idempotency HTTP Header Field
 
 draft-idempotency-header-01.txt
 Date: 23/11/2020
 Authors: Jayadeba Jena, Sanjay Dalal
 Working Group: Individual Submissions (none)
 Formats: txt xml
The "HTTP" Idempotency request header field can be used to carry idempotency key in order to make non-idempotent "HTTP" methods such as "POST" or "PATCH" fault-tolerant.
 Key Exchange Without Forward Secrecy is Not Recommended
 
 draft-mattsson-tls-psk-ke-dont-dont-dont-00.txt
 Date: 18/11/2020
 Authors: John Mattsson
 Working Group: Individual Submissions (none)
 Formats: txt xml
Key exchange without forward secrecy enables passive monitoring [RFC7258]. Massive pervasive monitoring attacks relying on key exchange without forward secrecy has been reported [I-D.ietf-emu-aka-pfs]. If key exchange without Diffe-Hellan is used, compromise of the long-term authenticatation key enables a passive attacker to compromise past and future sessions. All TLS 1.2 cipher suites without forward secrecy has been marked as NOT RECOMMENDED [RFC8447], and static RSA has been forbidden in TLS 1.3 [RFC8446]. psk_ke does not provide forward secrecy and is NOT RECOMMENDED. This document sets the IANA registration of psk_ke to NOT RECOMMENDED.
 A Generic Ciphertext Format
 
 draft-sheffer-ietf-ciphertext-format-01.txt
 Date: 15/01/2021
 Authors: Yaron Sheffer, Gleb Keselman, Yoav Nir
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines a set of structured headers for encrypted data. The main goal of this format is to enable detection of encrypted data in large data stores, and associating it back to the system where it was created and the key with which it was encrypted. This allows organizations to extend the concept of data governance to encrypted data, and to manage such data even when encrypted by multiple different systems and cloud providers.
 JWS Clear Text JSON Signature Option (JWS/CT)
 
 draft-jordan-jws-ct-04.txt
 Date: 15/04/2021
 Authors: Bret Jordan, Samuel Erdtman, Anders Rundgren
 Working Group: Individual Submissions (none)
 Formats: html txt xml
This document describes a method for extending the scope of the JSON Web Signature (JWS) standard, called JWS/CT. By combining the detached mode of JWS with the JSON Canonicalization Scheme (JCS), JWS/CT enables JSON objects to remain in the JSON format after being signed (also known as "Clear Text" signing). In addition to supporting a consistent data format, this arrangement also simplifies documentation, debugging, and logging. The ability to embed signed JSON objects in other JSON objects, makes the use of counter- signatures straightforward.
 DMARC Fallback Domains
 
 draft-levine-dmarcwalk-00.txt
 Date: 20/11/2020
 Authors: John Levine
 Working Group: Individual Submissions (none)
 Formats: html xml txt
This document specifies a new tree walk algorithm to find a DMARC Fallback Domain.
 NTPv5 use cases and requirements
 
 draft-gruessing-ntp-ntpv5-requirements-01.txt
 Date: 29/12/2020
 Authors: James Gruessing
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the use cases, requirements, and considerations that should be factored in the design of a successor protocol to supercede version 4 of the NTP protocol [RFC5905] presently referred to as NTP version 5 ("NTPv5"). This document is non-exhaustive and does not in its current version represent working group consensus.
 Network Time Protocol Version 5
 
 draft-mlichvar-ntp-ntpv5-02.txt
 Date: 17/02/2021
 Authors: Miroslav Lichvar
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the version 5 of the Network Time Protocol (NTP).
 Targeted HTTP Response Header Fields for Cache Control
 
 draft-cdn-control-header-01.txt
 Date: 17/03/2021
 Authors: Stephen Ludin, Mark Nottingham, Yuchen Wu
 Working Group: Individual Submissions (none)
 Formats: xml html txt
This specification defines a convention for HTTP response header fields that allow directives controlling caching to be targeted at specific caches or classes of caches. It also defines one such header field, targeted at Content Delivery Network (CDN) caches.
 OpenMetrics,a cloud-native,highly scalable metrics protocol
 
 draft-richih-opsawg-openmetrics-00.txt
 Date: 25/11/2020
 Authors: Richard Hartmann, Ben Kochie, Brian Brazil, Rob Skillington
 Working Group: Individual Submissions (none)
 Formats: txt
OpenMetrics specifies today's de-facto standard for transmitting cloud-native metrics at scale, with support for both text representation and Protocol Buffers and brings it into IETF. It supports both pull and push-based data collection.
 Constrained Join Proxy for Bootstrapping Protocols
 
 draft-anima-constrained-join-proxy-02.txt
 Date: 03/02/2021
 Authors: Michael Richardson, Peter van der Stok, Panos Kampanakis
 Working Group: Individual Submissions (none)
 Formats: txt pdf xml
This document defines a protocol to securely assign a pledge to a domain, represented by a Registrar, using an intermediary node between pledge and Registrar. This intermediary node is known as a "constrained Join Proxy". This document extends the work of [I-D.ietf-anima-bootstrapping-keyinfra] by replacing the Circuit- proxy by a stateless/stateful constrained (CoAP) Join Proxy. It transports join traffic from the pledge to the Registrar without requiring per-client state.
 NAT64 Tunnel Protocol
 
 draft-dupont-6man-nat64tp-02.txt
 Date: 29/11/2020
 Authors: Kasper Dupont
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes a stateless NAT64 extension which allows for creation of reliable tunnels between islands of IPv6 deployment.
 IS-IS Optimal Distributed Flooding for Dense Topologies
 
 draft-white-lsr-distoptflood-00.txt
 Date: 29/11/2020
 Authors: Russ White, Shraddha Hegde, Shawn Zandi
 Working Group: Individual Submissions (none)
 Formats: txt xml
In dense topologies, such as data center fabrics based on the Clos and butterfly fabric topologies, flooding mechanisms designed for sparse topologies, when used in these dense topologies, can "overflood," or carry too many copies of topology and reachability to fabric devices. This results in slower convergence times and higher resource utilization. The modifications to the flooding mechanism in the Intermediate System to Intermediate System (IS-IS) link state protocol described in this document reduce resource utilization to a minimum, while increaseing convergence performance in dense topologies. Note that a Clos fabric is used as the primary example of a desne flooding topology throughout this document. However, the flooding optimizations described in this document apply to any dense topology.
 Trusted Resolution System and Protocol Extension
 
 draft-chen-trusted-resolution-00.txt
 Date: 29/11/2020
 Authors: Yuying Chen, Jiahui Wang, Bo Zhang, Zhipeng Fan, Xufeng Ma, Zhiping Li, Jiagui Xie
 Working Group: Individual Submissions (none)
 Formats: txt
The Handle System [1][2]is a name service system for handle resolution and management over the public Internet. Handle System protocol [3] is designed to be transmitted as a byte stream via a TCP connection. This document describes a Trusted Resolution System and the protocol extension based on Handle System protocol. Trusted resolution aims to achieve credibility verification through data signing. The Trusted Resolution System determines whether to perform trusted resolution and verification on the response according to the trusted flag requested by the client.
 Use of the SM2 and SM3 Algorithms in Handle System
 
 draft-chen-sm2-sm3-algorithms-00.txt
 Date: 29/11/2020
 Authors: Yuying Chen, Jiahui Wang, Bo Zhang, Zhipeng Fan, Xufeng Ma, Zhiping Li, Jiagui Xie
 Working Group: Individual Submissions (none)
 Formats: txt
The Handle System is a global name service that allows secured handle resolution and administration over the public Internet according to [1][5][3]. Handle System protocol [3] is designed to be transmitted as a byte stream via a TCP connection. In this document, SM2 and SM3 algorithms [4][5]are introduced into the handle system to enhance the security and compactivity. Trusted resolution and message credential are extended to support SM2 and SM3 algorithms.
 In-band Edge-to-Edge Round Trip Time Measurement
 
 draft-song-ippm-inband-e2e-rtt-measurement-00.txt
 Date: 30/11/2020
 Authors: Haoyu Song, Linda Dunbar
 Working Group: Individual Submissions (none)
 Formats: txt xml
This draft describes a lightweight in-band edge-to-edge network round trip time measurement architecture and suggests implementations.
 Detecting Malicious Middleboxes In Service Function Chaining
 
 draft-park-sfc-malicious-middlebox-00.txt
 Date: 01/12/2020
 Authors: Canh Nguyen, Minho Park
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document addresses problems caused by malicious middleboxes and proposes a scheme that can detect them in Service Function Chaining (SFC) by combining two mechanisms: direct and indirect. The direct mechanism injects a tool into the middleboxes to observe and report the state of each middlebox. In contrast, the indirect mechanism creates a probe service chain, which includes trustful middleboxes, to investigate the operation of other middleboxes in the network.
 Comparing ALPS and Half-RTT Data
 
 draft-davidben-tls-alps-half-rtt-00.txt
 Date: 03/12/2020
 Authors: David Benjamin
 Working Group: Individual Submissions (none)
 Formats: html xml txt
This document compares the Application Layer Protocols Settings extension with the half-RTT feature in TLS 1.3.
 IPv6 Hop-by-Hop Options Processing Procedures
 
 draft-hinden-6man-hbh-processing-00.txt
 Date: 03/12/2020
 Authors: Robert Hinden, Gorry Fairhurst
 Working Group: Individual Submissions (none)
 Formats: txt html xml
This document specifies procedures for how IPv6 Hop-by-Hop options are processed. It modifies the procedures specified in the IPv6 Protocol Specification (RFC8200) to make processing in routers more practical with the goal of making IPv6 Hop-by-Hop options useful to deploy in the Internet. When published, this document updates RFC8200.
 RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks
 
 draft-pthubert-roll-rfc6550bis-00.txt
 Date: 04/12/2020
 Authors: Pascal Thubert, Tim Winter
 Working Group: Individual Submissions (none)
 Formats: txt xml html
Low-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen to thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported. Support for point-to-point traffic is also available.
 Questions for Multiple Paths In QUIC
 
 draft-dawkins-quic-multipath-questions-01.txt
 Date: 17/01/2021
 Authors: Spencer Dawkins
 Working Group: Individual Submissions (none)
 Formats: txt xml
The IETF QUIC working group has been chartered to produce extensions that would "enable ... multipath capabilities" since the working group was formed in 2016, but because multipath was an extension, work on multipath, and the other extensions named in the charter, waited while work proceeded on the core QUIC protocol specifications. After the QUIC working group chairs requested publication for the core QUIC protocol specifications, they scheduled a virtual interim meeting to understand the use cases that various groups inside and outside the IETF were envisioning for multipath with QUIC. As part of that discussion, it became obvious that people had a variety of ideas about how multiple paths would be used, because they weren't looking at the same use cases, and so had different assumptions about how applications might use QUIC over multiple paths. This document is intended to capture questions that have come up in discussions, with some suggested answers, to inform further discussion in the working group.
 Requirements for P4 Program Splitting for Heterogeneous Network Nodes
 
 draft-hsingh-coinrg-reqs-p4comp-03.txt
 Date: 18/02/2021
 Authors: Hemant Singh, Marie-Jose Montpetit
 Working Group: Individual Submissions (none)
 Formats: txt
For distributed computing, the P4 research community has published a paper to show how to split a P4 program into sub-programs which run on heterogeneous network nodes in a network. Examples of nodes are a network switch, a smartNIC, or a host machine. The paper has developed artifacts to split program based on latency, data rate, cost, etc. However, the paper does not mention any requirements. To provide guidance, this document covers requirements for splitting P4 programs for heterogeneous network nodes.
 SRH TLV Processing Programming
 
 draft-li-spring-srh-tlv-processing-programming-00.txt
 Date: 08/12/2020
 Authors: Cheng Li, Yang Xia, Dhruv Dhody, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document proposes a mechanism to program the processing rules of Segment Routig Header (SRH) optional TLVs explicitly on the ingress node. In this mechanism, there is no need to configure local configuration at the node to support SRH TLV processing. A network operator can program to process specific TLVs on specific segment endpoint nodes for specific packets on the ingress node, which is more efficient for SRH TLV processing.
 Automated Certificate Management Environment (ACME) Extension for Single Sign On Challenges
 
 draft-biggs-acme-sso-01.txt
 Date: 08/04/2021
 Authors: Andrew Biggs, Richard Barnes, Rory Moynihan
 Working Group: Individual Submissions (none)
 Formats: txt html xml
This document specifies an extension to the ACME protocol [RFC8555] to enable ACME servers to validate a client's control of an email identifier using single sign-on (SSO) technologies. An extension to the CAA [RFC8659] resource record specification is also defined to provide domain owners a means to declare a set of SSO providers that ACME servers may rely upon when employing SSO for identifier validation on their domain.
 JSON Schema: A Media Type for Describing JSON Documents
 
 draft-bhutton-json-schema-00.txt
 Date: 08/12/2020
 Authors: Austin Wright, Henry Andrews, Ben Hutton, Greg Dennis
 Working Group: Individual Submissions (none)
 Formats: txt xml
JSON Schema defines the media type "application/schema+json", a JSON- based format for describing the structure of JSON data. JSON Schema asserts what a JSON document must look like, ways to extract information from it, and how to interact with it. The "application/ schema-instance+json" media type provides additional feature-rich integration with "application/schema+json" beyond what can be offered for "application/json" documents.
 JSON Schema Validation: A Vocabulary for Structural Validation of JSON
 
 draft-bhutton-json-schema-validation-00.txt
 Date: 08/12/2020
 Authors: Austin Wright, Henry Andrews, Ben Hutton
 Working Group: Individual Submissions (none)
 Formats: xml txt
JSON Schema (application/schema+json) has several purposes, one of which is JSON instance validation. This document specifies a vocabulary for JSON Schema to describe the meaning of JSON documents, provide hints for user interfaces working with JSON data, and to make assertions about what a valid document must look like.
 Relative JSON Pointers
 
 draft-bhutton-relative-json-pointer-00.txt
 Date: 08/12/2020
 Authors: Geraint Luff, Henry Andrews, Ben Hutton
 Working Group: Individual Submissions (none)
 Formats: xml txt
JSON Pointer is a syntax for specifying locations in a JSON document, starting from the document root. This document defines an extension to the JSON Pointer syntax, allowing relative locations from within the document.
 IPv6 Addressing Considerations
 
 draft-gont-v6ops-ipv6-addressing-considerations-01.txt
 Date: 21/02/2021
 Authors: Fernando Gont, Guillermo Gont
 Working Group: Individual Submissions (none)
 Formats: txt
IPv6 addresses can differ in a number of properties, such as scope, stability, and intended usage type. This document analyzes the impact of these properties on aspects such as security, privacy, interoperability, and network operations. Additionally, it identifies challenges and gaps that currently prevent systems and applications from leveraging the increased flexibility and availability of IPv6 addresses.
 Multipath Extension for QUIC
 
 draft-liu-multipath-quic-03.txt
 Date: 07/03/2021
 Authors: Yanmei Liu, Yunfei Ma, Christian Huitema, Qing An, Zhenyu Li
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies multipath extension for the QUIC protocol to enable the simultaneous usage of multiple paths for a single connection. The extension is compliant with the single-path QUIC design. The design principle is to support multipath by adding limited extension to [QUIC-TRANSPORT].
 SDP Superimposition Grouping framework
 
 draft-abhishek-mmusic-superimposition-grouping-01.txt
 Date: 01/02/2021
 Authors: Rohit Abhishek, Stephan Wenger
 Working Group: Individual Submissions (none)
 Formats: txt pdf xml
This document defines semantics that allow for signaling a new SDP group "supim" for superimposed media in an SDP session. The "supim" attribute can be used by the application to relate all the superimposed visual media streams enabling them to be added as an overlay on top of any visual media stream. The superimposition grouping semantics is helpful, if the media data is separate and transported via different sessions.
 An ECN Extension to CONNECT-UDP
 
 draft-schinazi-masque-connect-udp-ecn-01.txt
 Date: 05/01/2021
 Authors: David Schinazi
 Working Group: Individual Submissions (none)
 Formats: txt xml html
The CONNECT-UDP method allows proxying UDP packets over HTTP. This document describes an extension to CONNECT-UDP that allows conveying ECN information on proxied UDP packets. Discussion of this work is encouraged to happen on the MASQUE IETF mailing list (masque@ietf.org (mailto:masque@ietf.org)) or on the GitHub repository which contains the draft: https://github.com/DavidSchinazi/draft-connect-udp-ecn.
 http2 window size use case
 
 draft-chen-httpbis-window-size-use-case-00.txt
 Date: 13/12/2020
 Authors: chenmeiling, Li Su
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document presents an use case which actually happening in our network, when window_size_increment in the window update frame less than 128 bytes and the increased window size also less than 128 bytes, then network connection will come to an error.
 http2 window size setting
 
 draft-chen-httpbis-window-size-00.txt
 Date: 13/12/2020
 Authors: chenmeiling, Li Su
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document proposed the minimum value setting mechanism of HTTP2.0 Window and Window_update, and a Window_update frame sending mechanism.
 RIFT Keys Structure and Well-Known Registry in Key Value TIE
 
 draft-przygienda-rift-kv-registry-00.txt
 Date: 13/12/2020
 Authors: Tony Przygienda
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes key structure of keys contained within RIFT key-value TIEs.
 APN Scope and Gap Analysis
 
 draft-peng-apn-scope-gap-analysis-01.txt
 Date: 22/02/2021
 Authors: Shuping Peng, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: xml txt
The APN work in IETF is focused on developing a framework and set of mechanisms to derive, convey and use an identifier to allow for the implementation of fine-grain user (group)-, application (group)-, and service-level requirements at the network layer. APN aims to apply various policies in different nodes along a network path onto a traffic flow altogether, that is, at the headend to steer into corresponding path, at the midpoint to collect corresponding performance measurement data, and at the service function to execute particular policies. Currently there is still no way to realise this composite network service provisioning along the path very efficiently. This document further clarifies the scope of the APN work and describesthe solution gap analysis.
 SRv6 In-situ Active Measurement
 
 draft-song-spring-siam-00.txt
 Date: 15/12/2020
 Authors: Haoyu Song, Tian Pan
 Working Group: Individual Submissions (none)
 Formats: xml txt
This draft describes an in-band active measurement method for SRv6. A probing packet contains an SRH with a flag bit set. The IOAM header and data are encapsulated in UDP payload. The probing packet originates from a segment source node and terminates at a configured segment endpoint node. Each segment node on the path, when detecting the flag, parses the UDP header and the IOAM header, and adds data to the IOAM node data fields. Multiple applications can be supported by the method.
 JMAP Sharing
 
 draft-jenkins-jmap-sharing-00.txt
 Date: 15/12/2020
 Authors: Neil Jenkins
 Working Group: Individual Submissions (none)
 Formats: html txt xml
This document specifies a data model for sharing data between users using JMAP.
 Optimizations for Using TLS Early Data in HTTP/2
 
 draft-thomson-httpbis-h2-0rtt-00.txt
 Date: 15/12/2020
 Authors: Martin Thomson
 Working Group: Individual Submissions (none)
 Formats: html txt xml
This proposes an extension to HTTP/2 that enables the use of server settings by clients that send requests in TLS early data. In particular, this allows extensions to the protocol to be used. This amends the definition of settings defined in RFC 7540 and RFC 8441 and introduces new registration requirements for HTTP/2 settings.
 Using Entropy Label for Network Slice Identification in MPLS networks.
 
 draft-decraene-mpls-slid-encoded-entropy-label-id-01.txt
 Date: 22/02/2021
 Authors: Bruno Decraene, Clarence Filsfils, Wim Henderickx, Tarek Saad, Vishnu Beeram, Luay Jalil
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a solution to encode a slice identifier in MPLS in order to distinguish packets that belong to different slices, to allow enforcing per network slice policies (.e.g, Qos). The slice identification is independent of the topology. It allows for QoS/DiffServ policy on a per slice basis in addition to the per packet QoS/DiffServ policy provided by the MPLS Traffic Class field. In order to minimize the size of the MPLS stack and to ease incremental deployment the slice identifier is encoded as part of the Entropy Label. This document also extends the use of the TTL field of the Entropy Label in order to provide a flexible set of flags called the Entropy Label Control field.
 Scalable Network Slicing over SR Networks
 
 draft-bestbar-spring-scalable-ns-01.txt
 Date: 22/02/2021
 Authors: Tarek Saad, Vishnu Beeram, Ran Chen, Shaofu Peng, Bin Wen, Daniele Ceccarelli
 Working Group: Individual Submissions (none)
 Formats: txt
Multiple network slices can be realized on top of a single shared network. A router that requires forwarding of a packet that belongs to a slice aggregate may have to decide on the forwarding action to take based on selected next-hop(s), and the forwarding treatment (e.g., scheduling and drop policy) to enforce based on the slice aggregate per-hop behavior. Segment Routing is a technology that enables the steering of packets in a network by encoding pre- established segments within the network into the packet header. This document introduces mechanisms to enable forwarding of packets over a specific slice aggregate along a Segment Routing (SR) path.
 On loading MUD URLs from QR codes
 
 draft-richardson-mud-qrcode-00.txt
 Date: 17/12/2020
 Authors: Michael Richardson, Jacques Latour, Hassan Gharakheili
 Working Group: Individual Submissions (none)
 Formats: xml html txt
This informational document details the mechanism used by the CIRA Secure Home Gateway (SHG) to load MUD definitions for devices which have no integrated MUD (RFC8520) support. RFCEDITOR please remove: Pull requests and edit welcome at: https://github.com/CIRALabs/securehomegateway-mud/tree/ietf
 A DODAG Metric Used for DODAG Selection in Low-Power and Lossy Networks
 
 draft-hushe-roll-dodag-metric-00.txt
 Date: 18/12/2020
 Authors: Huimin She, Li Zhao, Pascal Thubert
 Working Group: Individual Submissions (none)
 Formats: xml html txt
This document extends [RFC6551] by defining a new DODAG metric called DODAG size, which can be used for DODAG selection in Low-Power and Lossy Networks (LLNs). DODAG size is an important metric for nodes to decide which DODAG to join, or which DODAG to migrate. This document proposes methods to disseminate DODAG size from the Root to all nodes in the DODAG, so that the DODAG size can be advertised to new joining nodes.
 PCAP Capture File Format
 
 draft-gharris-opsawg-pcap-01.txt
 Date: 21/12/2020
 Authors: Guy Harris, Michael Richardson
 Working Group: Individual Submissions (none)
 Formats: xml html txt
This document describes the format used by the libpcap library to record captured packets to a file. Programs using the libpcap library to read and write those files, and thus reading and writing files in that format, include tcpdump.
 JOSE signed Voucher Artifacts for Bootstrapping Protocols
 
 draft-richardson-anima-jose-voucher-00.txt
 Date: 22/12/2020
 Authors: Michael Richardson, Thomas Werner
 Working Group: Individual Submissions (none)
 Formats: txt xml html
This document describes a serialiation of the RFC8366 voucher format to a JSON format is then signed using the JSON Object Signing and Encryption mechanism described in RFC7515. In addition to explaining how the format is created, MIME types are registered and examples are provided.
 The update registries draft
 
 draft-rsalz-update-registries-02.txt
 Date: 03/02/2021
 Authors: Rich Salz
 Working Group: Individual Submissions (none)
 Formats: txt xml html
The Network Time Protocol (NTP) and Network Time Security (NTS) documents define a number of assigned number registries, collectively called the NTP registries. Some registries have wrong values, some registries do not follow current common practice, and some are just right. For the sake of completeness, this document reviews all NTP and NTS registries. 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/richsalz/draft-rsalz-update-registries.
 QUIC Performance
 
 draft-banks-quic-performance-00.txt
 Date: 23/12/2020
 Authors: Nick Banks
 Working Group: Individual Submissions (none)
 Formats: txt xml
The QUIC performance protocol provides a simple, general-purpose protocol for testing the performance characteristics of a QUIC implementation. With this protocol a generic server can support any number of client-driven performance tests and configurations. Standardizing the performance protocol allows for easy comparisons across different QUIC implementations.
 CDNI Request Routing Extensions
 
 draft-sopher-cdni-footprint-types-extensions-01.txt
 Date: 23/12/2020
 Authors: Nir Sopher, Sanjay Mishra
 Working Group: Individual Submissions (none)
 Formats: txt xml
Open Caching architecture is a use case of Content Delivery Networks Interconnection (CDNI) in which the commercial Content Delivery Network (CDN) is the upstream CDN (uCDN) and the ISP caching layer serves as the downstream CDN (dCDN). This document supplements to the CDNI Metadata Footprint Types defined in RFC 8006. The Footprint Types defined in this document can be used for Footprint objects as part of the Footprint & Capabilities Advertisement interface (FCI) defined in RFC 8008. The defined Footprint Types are derived from requirements raised by Open Caching but are also applicable to CDNI use cases in general.
 Photonic firewall oriented routing and spectrum allocation strategy in optical networks
 
 draft-li-rtgwg-photonic-firewall-rsa-00.txt
 Date: 25/12/2020
 Authors: Li Xin, Lu Zhang, Ying Tang, Zicheng Shi, Shanguo Huang
 Working Group: Individual Submissions (none)
 Formats: txt
The photonic firewall oriented routing and spectrum allocation strategy in elastic optical networks is proposed. For the security detecting requirement, each light-path should pass through at least a photonic firewall. To reduce the blocking rate and improve the spectrum efficiency, the whole network is divided into several parts according to the locations of all deployed photonic firewalls. A photonic firewall is responsible for the security detecting for each part. This strategy has a low complexity and is suitable for large- scale optical networks.
 A High-capacity and Real-time LISP Mapping Framework
 
 draft-mi-lisp-high-capacity-00.txt
 Date: 27/12/2020
 Authors: Wei Mi, Jingguo Ge
 Working Group: Individual Submissions (none)
 Formats: xml txt
This draft describes how the LISP mapping framework designed to be have the capability to provide efficient, real-time, high concurrent services when guarantee the scale.
 A taxonomy of eavesdropping attacks
 
 draft-richardson-saag-onpath-attacker-02.txt
 Date: 22/02/2021
 Authors: Michael Richardson, Jonathan Hoyland
 Working Group: Individual Submissions (none)
 Formats: xml html txt
The terms on-path attacker and Man-in-the-Middle Attack have been used in a variety of ways, sometimes interchangeably, and sometimes meaning different things. This document offers an update on terminology for network attacks. A consistent set of terminology is important in describing what kinds of attacks a particular protocol defends against, and which kinds the protocol does not.
 Architecture and application scenario for fused service function chain
 
 draft-dai-sfc-fused-architecture-and-scenario-00.txt
 Date: 28/12/2020
 Authors: Jinyou Dai, Xueshun Wang, Jun Gao
 Working Group: Individual Submissions (none)
 Formats: txt
This document discusses the architecture and application scenarios of fused service function chain. Fused service function chain means that two or more service function chains are fused to become a single service function chain from the view of data plane and control plane. Anyhow, some mechanism or methods need to be used when two or more service function chains are fused to be a single service function chain.
 Discussion of Requirements for ADD
 
 draft-zhang-add-requirement-discusses-00.txt
 Date: 28/12/2020
 Authors: Man Zhang
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document discusses various usage scenarios and corresponding requirements for discovering and using encrypted DNS technology.
 Network File System (NFS) Version 4 Minor Version 1 Protocol
 
 draft-dnoveck-nfsv4-rfc5661bis-base-01.txt
 Date: 30/12/2020
 Authors: David Noveck, Chuck Lever
 Working Group: Individual Submissions (none)
 Formats: txt html xml
This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 7530) and protocol extensions made subsequently. The later minor version has no dependencies on NFS version 4 minor version 0, and is considered a separate protocol. This document obsoletes RFC 5661. It substantially revises the treatment of features relating to multi-server namespace, superseding the description of those features appearing in RFC 5661. The content of this document reflects that of RFC8881, presented in the form of an I-D. This is intended to provide a helpful point of comparision for drafts leading to an eventual rfc5661bis to enable use of rfcdiff when reviewing such drafts.
 Asset Profile Definitions for DLT Interoperability
 
 draft-sardon-blockchain-interop-asset-profile-00.txt
 Date: 30/12/2020
 Authors: Aetienne Sardon, Thomas Hardjono, Benedikt Schuppli
 Working Group: Individual Submissions (none)
 Formats: txt
In order for virtual assets to be traded or exchanged within online transactions, the parties involved in the transaction must have share a common definition of what constitute the virtual asset. Parties transacting on a DLT system must have the unambiguous means to refer to a common definition of an virtual asset, independent of the implementation of the virtual asset in question. This specification defines a JSON representation of a number of common information fields within asset profiles.
 Network File System (NFS) Version 4 Minor Version 1 Protocol
 
 draft-dnoveck-nfsv4-rfc5661bis-00.txt
 Date: 31/12/2020
 Authors: David Noveck
 Working Group: Individual Submissions (none)
 Formats: txt html xml
This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 7530) and protocol extensions made subsequently. The later minor version has no dependencies on NFS version 4 minor version 0, and is considered a separate protocol. This document obsoletes RFC 8881. In addition to many corrections and clarifications, it relies on NFSv4-wide documents to substantially revise the treatment of protocol extension, internationalization, and security, superseding the descriptions of those aspects of the protocol appearing in RFCs 5661 and 8881.
 Lightweight Directory Access Protocol (LDAP) Procedures and Schema Definitions for the Storage of X.660 Registration Information
 
 draft-coretta-x660-ldap-05.txt