Individual Submissions (none) Internet Drafts


      
 The ARK Identifier Scheme
 
 draft-kunze-ark-24.txt
 Date: 21/06/2020
 Authors: John Kunze, Emmanuelle Bermes
 Working Group: Individual Submissions (none)
 Formats: txt xml
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-32.txt
 Date: 09/09/2020
 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-29.txt
 Date: 09/09/2020
 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-30.txt
 Date: 09/09/2020
 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-28.txt
 Date: 09/09/2020
 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-27.txt
 Date: 09/09/2020
 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-27.txt
 Date: 09/09/2020
 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-26.txt
 Date: 09/09/2020
 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-24.txt
 Date: 09/09/2020
 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.
 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-20.txt
 Date: 28/07/2020
 Authors: Paul Amer, Martin Becke, Thomas Dreibholz, Nasif Ekiz, Jana Iyengar, Preethi Natarajan, Randall Stewart, Michael Tuexen
 Working Group: Individual Submissions (none)
 Formats: txt
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-16.txt
 Date: 10/07/2020
 Authors: Huaimo Chen
 Working Group: Individual Submissions (none)
 Formats: 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-16.txt
 Date: 10/07/2020
 Authors: Huaimo Chen
 Working Group: Individual Submissions (none)
 Formats: txt
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-21.txt
 Date: 09/09/2020
 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-21.txt
 Date: 09/09/2020
 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-19.txt
 Date: 10/07/2020
 Authors: Huaimo Chen
 Working Group: Individual Submissions (none)
 Formats: txt
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-18.txt
 Date: 10/07/2020
 Authors: Huaimo Chen
 Working Group: Individual Submissions (none)
 Formats: 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-19.txt
 Date: 14/05/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-14.txt
 Date: 30/04/2020
 Authors: Huaimo Chen
 Working Group: Individual Submissions (none)
 Formats: 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. 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-17.txt
 Date: 06/08/2020
 Authors: Vina Ermagan, Dino Farinacci, Darrel Lewis, Fabio Maino, Marc Portoles-Comeras, Jesper Skriver, Chris White, Albert Bresco
 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-15.txt
 Date: 09/06/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.
 IS-IS Topology-Transparent Zone
 
 draft-chen-isis-ttz-12.txt
 Date: 18/08/2020
 Authors: Huaimo Chen, Renwei Li, Yi Yang, Yanhe Fan, Ning So, Vic liu, Mehmet Toy, Lei Liu, Kiran Makhijani
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents a topology-transparent zone in an area. A zone is a block/piece of an area, which comprises a group of routers and a number of circuits connecting them. It is abstracted as a virtual entity such as a single virtual node or zone edges mesh. Any router outside of the zone is not aware of the zone. The information about the circuits and routers inside the zone is not distributed to any router outside of the zone.
 ICANN Registry Interfaces
 
 draft-lozano-icann-registry-interfaces-13.txt
 Date: 25/06/2020
 Authors: Gustavo Lozano, 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.
 Dynamic Service Negotiation
 
 draft-boucadair-connectivity-provisioning-protocol-22.txt
 Date: 25/06/2020
 Authors: Mohamed Boucadair, Christian Jacquenet, Dacheng Zhang, Panos Georgatsos
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines the Connectivity Provisioning Negotiation Protocol (CPNP) which is designed to facilitate the dynamic negotiation of service parameters. CPNP is a generic protocol that can be used for various negotiation purposes that include (but are not necessarily limited to) connectivity provisioning services, storage facilities, Content Delivery Networks, etc.
 Binary Encodings for JavaScript Object Notation: JSON-B,JSON-C,JSON-D
 
 draft-hallambaker-jsonbcd-16.txt
 Date: 27/07/2020
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: html txt xml
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-12.txt
 Date: 21/09/2020
 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-05.txt
 Date: 27/04/2020
 Authors: Robert Kebler, Pavan Kurapati, Saud Asif, Mankamana Mishra, Stig Venaas
 Working Group: Individual Submissions (none)
 Formats: txt xml
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.
 6bed4: IPv6 Anywhere in support of Reliable Peering
 
 draft-vanrein-6bed4-04.txt
 Date: 09/07/2020
 Authors: Rick van Rein
 Working Group: Individual Submissions (none)
 Formats: txt xml
The purpose of 6bed4 is to support IPv6-only networks, hosts and applications. It passes IPv6 frames over UDP between IPv4 sites. Peers connected over 6bed4 can switch to direct routes over UDP/IPv4 after deducing that this will be reliable. 6bed4 lets peer-to-peer applications benefit from transparant addressing in IPv6 and delegates NAPT concerns to 6bed4. It is possible to use 6bed4 as a fallback for IPv6, or as an additional route. Servers can be setup as IPv6-only servers with NAT64 for IPv4-only customers who only need client-server facilities, and add a 6bed4router to also facilitate reliable peer-to-peer protocols.
 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-13.txt
 Date: 13/07/2020
 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-07.txt
 Date: 17/09/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-14.txt
 Date: 09/09/2020
 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.
 Pronouncing and Using Chinese Personal Names
 
 draft-deng-chinese-names-06.txt
 Date: 17/09/2020
 Authors: Hui Deng, Zhen Cao
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document gives general rules for how to pronounce Mandarin Chinese names in conversation, and how to determine which name is someone's surname. It also covers some other related topics about Chinese names. The intent is to allow IETF participants who are not familiar with Chinese to communicate better with Chinese participants.
 Extensions to PCEP for Distributing Label Cross Domains
 
 draft-chen-pce-label-x-domains-11.txt
 Date: 10/07/2020
 Authors: Huaimo Chen, Autumn Liu, Mehmet Toy, Vic liu
 Working Group: Individual Submissions (none)
 Formats: 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-14.txt
 Date: 25/05/2020
 Authors: Bin Liu, Yantao Sun, Jing Cheng, Yichen Zhang, Bhumip Khasnabish
 Working Group: Individual Submissions (none)
 Formats: xml txt
This draft describes a generic routing method and protocol for a regular data center network, named the Fault-Avoidance Routing (FAR) protocol. The FAR protocol provides a generic routing method for all types of regular topology network architectures that have been proposed for large-scale cloud-based data centers over the past few years. The FAR protocol is designed to leverage any regularity in the topology and compute its routing table in a simplistic manner. Fat-tree is taken as an example architecture to illustrate how the FAR protocol can be applied in real operational scenarios.
 SAML Profile for the Metadata Query Protocol
 
 draft-young-md-query-saml-13.txt
 Date: 13/07/2020
 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.14.
 Scalable-Group Tag eXchange Protocol (SXP)
 
 draft-smith-kandula-sxp-10.txt
 Date: 24/05/2020
 Authors: Michael Smith, Rakesh Kandula, Syam Appala
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document discusses scalable-group tag exchange protocol (SXP), a control protocol to propagate IP address to Scalable Group Tag (SGT) binding information across network devices.
 Extensions to the Path Computation Element Protocol (PCEP) to Support Resource Sharing-based Path Computation
 
 draft-zhang-pce-resource-sharing-13.txt
 Date: 16/10/2020
 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-07.txt
 Date: 25/06/2020
 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.
 WebRTC Dependencies
 
 draft-jennings-rtcweb-deps-24.txt
 Date: 30/05/2020
 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-10.txt
 Date: 27/07/2020
 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.
 Mandatory Tags for DKIM Signatures
 
 draft-levine-dkim-conditional-04.txt
 Date: 30/08/2020
 Authors: John Levine
 Working Group: Individual Submissions (none)
 Formats: txt html xml
The DKIM protocol applies a cryptographic signature to an e-mail message. This specification extends DKIM to allow new signature tags that validators are required to evaluate. The first such tag specifies a second signature that must be present for a signature to be valid.
 PCAP Next Generation (pcapng) Capture File Format
 
 draft-tuexen-opsawg-pcapng-02.txt
 Date: 28/09/2020
 Authors: Michael Tuexen, Fulvio Risso, Jasper Bongertz, Gerald Combs, Guy Harris, Michael Richardson
 Working Group: Individual Submissions (none)
 Formats: html xml txt
This document describes a format to record captured packets to a file. This format is extensible; Wireshark can currently read and write it, and libpcap can currently read some pcapng files. RFCEDITOR-please-remove: this document is being worked on at: https://github.com/pcapng/pcapng.git
 A JSON Encoding for HTTP Field Values
 
 draft-reschke-http-jfv-12.txt
 Date: 01/09/2020
 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 HTTP fields.
 Label Distribution Using ARP
 
 draft-kompella-mpls-larp-08.txt
 Date: 13/07/2020
 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-12.txt
 Date: 09/09/2020
 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-10.txt
 Date: 21/09/2020
 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-03.txt
 Date: 24/08/2020
 Authors: Mike Amundsen, Leonard Richardson, Mark Foster
 Working Group: Individual Submissions (none)
 Formats: xml txt
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.
 Extensions to OSPF for Advertising Prefix/Link Administrative Tags
 
 draft-acee-ospf-admin-tags-06.txt
 Date: 23/09/2020
 Authors: Acee Lindem, Peter Psenak
 Working Group: Individual Submissions (none)
 Formats: txt
It is useful for routers in an OSPFv2 or OSPFv3 routing domain to be able to associate tags with prefixes and links. Previously, OSPFv2 and OSPFv3 were relegated to a single tag for AS External and Not-So- Stubby-Area (NSSA) prefixes. With the flexible encodings provided by OSPFv2 Prefix/Link Attribute Advertisement and OSPFv3 Extended LSAs, multiple administrative tags may advertised for all types of prefixes and links. These administrative tags can be used for many applications including route redistribution policy, selective prefix prioritization, selective IP Fast-ReRoute (IPFRR) prefix protection, and many others. The ISIS protocol supports a similar mechanism that is described in RFC 5130.
 Additional XML Security Uniform Resource Identifiers (URIs)
 
 draft-eastlake-rfc6931bis-xmlsec-uris-12.txt
 Date: 28/06/2020
 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 corrrects 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-12.txt
 Date: 03/07/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.
 A Simple Control Protocol for MPLS SFLs
 
 draft-bryant-mpls-sfl-control-08.txt
 Date: 08/06/2020
 Authors: Stewart Bryant, George Swallow, Siva Sivabalan
 Working Group: Individual Submissions (none)
 Formats: xml txt
In draft-ietf-mpls-sfl-framework the concept of MPLS synonymous flow labels (SFL) was introduced. This document describes a simple control protocol that runs over an associated control header to request, withdraw, and extend the lifetime of such labels. It is not the only control protocol that moght be used to support SFL, but it has the benefit of being able to be used without modifying of the existing MPLS control prodocols. The existance of this design is not intended to restrict the ability to enhance an existing MPLS control protocol to add a similar capability. A Querier MUST wait a configured time (suggested wait of 60 seconds) before re-attempting a Withdraw request. No more than three Withdraw requests SHOULD be made. These restricctions are to prevent overloading the control plane of the actioning router.
 Recognized Transformations of Messages Bearing DomainKeys Identified Mail (DKIM) Signatures
 
 draft-kucherawy-dkim-transform-02.txt
 Date: 05/07/2020
 Authors: Murray Kucherawy
 Working Group: Individual Submissions (none)
 Formats: txt xml
DomainKeys Identified Mail (DKIM) introduced a mechanism whereby a mail operator can affix a signature to a message that validates at the level of the signer's domain name. It specified two possible ways of converting the message body to a canonical form, one intolerant of changes and the other tolerant of simple changes to whitespace within the message body. The provided canonicalization schemes do not tolerate changes in a message such as conversion between transfer encodings or addition of new message content. It is useful to have these capabilities to allow for transport through gateways, and also for transport through handlers (such as mailing list services) that might add content that would invalidate a signature generated using the existing canonicalization schemes. This document presents a mechanism for declaring that a message underwent any of a handful of well-defined transformations prior to being re-signed by a mediator, so that a verifier might rewind such modification(s) and thereby confirm that the original signature still verifies against the original content.
 HTTP SEARCH Method
 
 draft-snell-search-method-02.txt
 Date: 02/09/2020
 Authors: Julian Reschke, Ashok Malhotra, James Snell
 Working Group: Individual Submissions (none)
 Formats: xml html txt
This specification updates the definition and semantics of the HTTP SEARCH request method originally defined by RFC 5323.
 Encapsulating IP in UDP
 
 draft-xu-intarea-ip-in-udp-09.txt
 Date: 10/09/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-04.txt
 Date: 10/10/2020
 Authors: Shumon Huque, Viktor Dukhovni
 Working Group: Individual Submissions (none)
 Formats: xml html 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-04.txt
 Date: 27/07/2020
 Authors: Greg Mirsky, Jeff Tantsura
 Working Group: Individual Submissions (none)
 Formats: txt xml
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-10.txt
 Date: 05/10/2020
 Authors: Alberto Rodriguez-Natal, 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.
 SMTP Service Extension for Client Identity
 
 draft-storey-smtp-client-id-09.txt
 Date: 04/06/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.
 Annotated Example SDP for WebRTC
 
 draft-ietf-rtcweb-sdp-12.txt
 Date: 09/05/2020
 Authors: Suhas Nandakumar, Cullen Jennings
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Web Real Time Communications (WebRTC) family of protocols defines mechanisms for direct interactive rich communication using audio, video and data between two peers' web browsers. Within the WebRTC framework, the Session Description protocol (SDP) is used for negotiating session capabilities between the peers. Such a negotiation happens based on the SDP Offer/Answer exchange mechanism This document provides an informational reference in describing the role of SDP and the Offer/Answer exchange mechanism for the most common WebRTC use-cases.
 PCEP extensions for Distribution of Link-State and TE Information
 
 draft-dhodylee-pce-pcep-ls-17.txt
 Date: 13/07/2020
 Authors: Dhruv Dhody, Shuping Peng, Young Lee, Daniele Ceccarelli, Aijun Wang
 Working Group: Individual Submissions (none)
 Formats: txt xml
In order to compute and provide optimal paths, 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 traffic engineering extensions. This document extends the Path Computation Element Communication Protocol (PCEP) with Link-State and TE Information.
 MS-originated SMRs
 
 draft-rodrigueznatal-lisp-ms-smr-11.txt
 Date: 05/10/2020
 Authors: Alberto Rodriguez-Natal, Albert Cabellos-Aparicio, Vina Ermagan, Fabio Maino, Sharon Barkai
 Working Group: Individual Submissions (none)
 Formats: txt xml
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-10.txt
 Date: 21/09/2020
 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.
 Problems in and among industries for the prompt realization of IoT and safety considerations
 
 draft-baba-iot-problems-09.txt
 Date: 08/09/2020
 Authors: Hiroyuki BABA, Yoshiki Ishida, Takayuki Amatsu, Koichi KUNITAKE, Kaoru Maeda
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document contains opinions gathered from enterprises engaging in the IoT business as stated in the preceding version hereof, and also examines the possibilities of new social problems in the IoT era. Recognition of the importance of information security has grown in step with the rising use of the Internet. Closer examination reveals that the IoT era may see a new direct physical threat to users. For instance, the situation at a smart house may lead it to judge that the owner has only temporarily stepped out, causing it to unlock the front door, which in turn makes it easier for thieves to enter. These kinds of scenarios may occur without identity fraud, hacking, and other means of compromising information security. Therefore, for the purpose of this document, this issue shall be referred to as "IoT Safety" to distinguish it from Information Security. We believe that it is necessary to deepen our understanding of these new IoT-related threats through discussion and ensure there are measures to address these threats in the future. At the same time, we must also coordinate these measures with the solutions to the problems described in the previous version of this document.
 PCEP Extensions for BIER-TE
 
 draft-chen-pce-bier-07.txt
 Date: 18/05/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-09.txt
 Date: 03/06/2020
 Authors: Naoki Matsuhira
 Working Group: Individual Submissions (none)
 Formats: txt
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-09.txt
 Date: 03/06/2020
 Authors: Naoki Matsuhira
 Working Group: Individual Submissions (none)
 Formats: 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-06.txt
 Date: 13/07/2020
 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-05.txt
 Date: 02/05/2020
 Authors: Huaimo Chen, Zhenbin Li, Zhenqiang Li, Yanhe Fan, Mehmet Toy, Lei Liu
 Working Group: Individual Submissions (none)
 Formats: xml txt
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-26.txt
 Date: 30/06/2020
 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-10.txt
 Date: 01/09/2020
 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-10.txt
 Date: 20/04/2020
 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-02.txt
 Date: 10/10/2020
 Authors: Shumon Huque, Viktor Dukhovni
 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-14.txt
 Date: 27/07/2020
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: html xml txt
The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that makes computers easier to use by making them more secure. The Mesh provides a set of protocol and cryptographic building blocks that enable encrypted data stored in the cloud to be accessed, managed and exchanged between users with the same or better ease of use than traditional approaches which leave the data vulnerable to attack. 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.
 Mathematical Mesh: Reference Implementation
 
 draft-hallambaker-mesh-developer-10.txt
 Date: 27/07/2020
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt html 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. This document describes the Mesh reference code and how to install, run and make use of it in applications. It does not form a part of the Mesh specifications and is not normative. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-developer.html.
 Considerations for stateful vs stateless join router in ANIMA bootstrap
 
 draft-richardson-anima-state-for-joinrouter-03.txt
 Date: 22/09/2020
 Authors: Michael Richardson
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document explores a number of issues affecting the decision to use a stateful or stateless forwarding mechanism by the join router (aka join assistant) during the bootstrap process for ANIMA.
 Multiple IPv4 - IPv6 mapped IPv6 address (M46A)
 
 draft-matsuhira-m46a-08.txt
 Date: 03/06/2020
 Authors: Naoki Matsuhira
 Working Group: Individual Submissions (none)
 Formats: 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-08.txt
 Date: 03/06/2020
 Authors: Naoki Matsuhira
 Working Group: Individual Submissions (none)
 Formats: txt
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-08.txt
 Date: 03/06/2020
 Authors: Naoki Matsuhira
 Working Group: Individual Submissions (none)
 Formats: 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-08.txt
 Date: 03/06/2020
 Authors: Naoki Matsuhira
 Working Group: Individual Submissions (none)
 Formats: 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-08.txt
 Date: 03/06/2020
 Authors: Naoki Matsuhira
 Working Group: Individual Submissions (none)
 Formats: 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-08.txt
 Date: 03/06/2020
 Authors: Naoki Matsuhira
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies Multiple IPv4 address and port number - IPv6 address mapping encapulation (M4P6E) specification.
 Publishing Organization Boundaries in the DNS
 
 draft-levine-dbound-dns-05.txt
 Date: 04/10/2020
 Authors: John Levine
 Working Group: Individual Submissions (none)
 Formats: xml html txt
The organization that manages a subtree in the DNS is often different from the one that manages the tree above it. We describe an architecture to publish in the DNS the boundaries between organizations that can be adapted to various policy models and can be queried with a small number of DNS lookups.
 Multi-Stage Transparent Server Load Balancing
 
 draft-matsuhira-mslb-08.txt
 Date: 03/06/2020
 Authors: Naoki Matsuhira
 Working Group: Individual Submissions (none)
 Formats: txt
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-10.txt
 Date: 03/08/2020
 Authors: Cheng Li, Haomian Zheng, Siva Sivabalan, Samuel Sidor
 Working Group: Individual Submissions (none)
 Formats: xml txt
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 pending path computation requests. This information may then be considered when computing new traffic engineered LSPs, and for associated and dependent LSPs, received from Path Computation Clients (PCCs). RFC 7470 defines a facility to carry vendor-specific information in PCEP. This document extends this capability for the Stateful PCEP messages.
 Additional Considerations for UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets
 
 draft-tuexen-tsvwg-sctp-udp-encaps-cons-03.txt
 Date: 29/09/2020
 Authors: Michael Tuexen, Randall Stewart
 Working Group: Individual Submissions (none)
 Formats: xml html txt
RFC 6951 specifies the UDP encapsulation of SCTP packets. The described handling of received packets requires the check of the verification tag. However, RFC 6951 misses a specification for the handling of received packets for which this check is not possible. This document updates RFC 6951 by specifying the handling of received packets where the verification tag can not be checked.
 A YANG model to manage the optical parameters for in a WDM network
 
 draft-galimbe-ccamp-iv-yang-11.txt
 Date: 22/09/2020
 Authors: Gabriele Galimberti, Ruediger Kunze, Dharini Hiremagalur, Gert Grammel
 Working Group: Individual Submissions (none)
 Formats: txt
This memo defines a Yang model that translate the information model to support Impairment-Aware (IA) Routing and Wavelength Assignment (RWA) functionality. The information model is defined in draft-ietf- ccamp-wson-iv-info and draft-martinelli-ccamp-wson-iv-encode. This document defines proper encoding and extend to the models defined in draft-lee-ccamp-wson-yang tu support Impairment-Aware (IA) Routing and Wavelength Assignment (RWA) functions The Yang model defined in this memo can be used for Optical Parameters monitoring and/or configuration of the multivendor Endpoints and ROADMs. The use of this model does not guarantee interworking of transceivers over a DWDM. Optical path feasibility and interoperability has to be determined by means outside the scope of this document. The purpose of this model is to program interface parameters to consistently configure the mode of operation of transceivers.
 LISP Distinguished Name Encoding
 
 draft-farinacci-lisp-name-encoding-10.txt
 Date: 30/08/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-10.txt
 Date: 04/10/2020
 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-08.txt
 Date: 03/06/2020
 Authors: Naoki Matsuhira
 Working Group: Individual Submissions (none)
 Formats: txt
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-10.txt
 Date: 26/05/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-03.txt
 Date: 21/09/2020
 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.
 OpenPGP Message Format
 
 draft-ietf-openpgp-rfc4880bis-10.txt
 Date: 31/08/2020
 Authors: Werner Koch, brian carlson, Ronald Tse, Derek Atkins, Daniel Gillmor
 Working Group: Individual Submissions (none)
 Formats: xml html txt
{ Work in progress to update the OpenPGP specification from RFC4880 } This document specifies the message formats used in OpenPGP. OpenPGP provides encryption with public-key or symmetric cryptographic algorithms, digital signatures, compression and key management. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws.
 Hierarchical PCE Determination
 
 draft-chen-pce-h-discovery-07.txt
 Date: 10/07/2020
 Authors: Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei Liu, Zhenqiang Li
 Working Group: Individual Submissions (none)
 Formats: 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-07.txt
 Date: 10/07/2020
 Authors: Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei Liu, Zhenqiang Li
 Working Group: Individual Submissions (none)
 Formats: txt
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-07.txt
 Date: 10/07/2020
 Authors: Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei Liu, Zhenqiang Li
 Working Group: Individual Submissions (none)
 Formats: 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-06.txt
 Date: 12/07/2020
 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).
 PCEP Extension for Distribution of Link-State and TE information for Optical Networks
 
 draft-lee-pce-pcep-ls-optical-10.txt
 Date: 08/09/2020
 Authors: Young Lee, Haomian Zheng, Daniele Ceccarelli, Wei Wang, Peter Park, Bin-Yeong Yoon
 Working Group: Individual Submissions (none)
 Formats: txt
In order to compute and provide optimal paths, Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). Traditionally this Link State and TE information has been obtained from a link state routing protocol (supporting traffic engineering extensions). This document extends the Path Communication Element Communication Protocol (PCEP) with Link-State and TE information for optical networks.
 Mathematical Mesh: Platform Configuration
 
 draft-hallambaker-mesh-platform-06.txt
 Date: 27/07/2020
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt html 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. This document describes how Mesh profiles are stored for application access on Windows, Linux and OSX platforms. This document is also available online at http://prismproof.org/Documents/draft-hallambaker-mesh-platform.html.
 The OpenConnect VPN Protocol Version 1.2
 
 draft-mavrogiannopoulos-openconnect-03.txt
 Date: 02/10/2020
 Authors: Nikos Mavrogiannopoulos
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies version 1.2 of the OpenConnect Virtual Private Network (VPN) protocol, a secure VPN protocol that provides communications privacy over the Internet. That protocol is believed to be compatible with CISCO's AnyConnect VPN protocol. The protocol allows the establishment of VPN tunnels in a way that is designed to prevent eavesdropping, tampering, or message forgery.
 Guidelines for Autonomic Service Agents
 
 draft-carpenter-anima-asa-guidelines-09.txt
 Date: 25/07/2020
 Authors: Brian Carpenter, Laurent Ciavaglia, Sheng Jiang, Peloso Pierre
 Working Group: Individual Submissions (none)
 Formats: xml txt html
This document proposes guidelines for the design of Autonomic Service Agents for autonomic networks, as a contribution to describing an autonomic ecosystem. It is based on the Autonomic Network Infrastructure outlined in the ANIMA reference model, using the Autonomic Control Plane and the Generic Autonomic Signaling Protocol.
 Compact Format of IKEv2 Payloads
 
 draft-smyslov-ipsecme-ikev2-compact-08.txt
 Date: 23/09/2020
 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-11.txt
 Date: 27/08/2020
 Authors: Alexandre Dulaunoy, Andras Iklody
 Working Group: Individual Submissions (none)
 Formats: xml txt
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-08.txt
 Date: 12/07/2020
 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 computations in response to Path Computation Clients (PCCs) requests. The stateful PCE extensions allow stateful control of Multi-Protocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE 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 on 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 sessions 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-10.txt
 Date: 09/05/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-03.txt
 Date: 17/05/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-05.txt
 Date: 13/09/2020
 Authors: Xiaohu Xu, Shraddha Hegde, Dacheng Zhang, Liang Xia
 Working Group: Individual Submissions (none)
 Formats: txt xml
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 interconnect WAN 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 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.
 Report on Problem Solving Experiment for Realization of Web-API-based IoT
 
 draft-baba-iot-webapi-07.txt
 Date: 09/09/2020
 Authors: Hiroyuki BABA, Yoshiki Ishida, Takayuki Amatsu, Hiroshi Masuda, Shintaro Ogura, Koichi KUNITAKE
 Working Group: Individual Submissions (none)
 Formats: txt xml
The University of Tokyo (UOT) is currently performing a demonstration experiment in COMMA House, the experimental smart-house owned by UOT and used as a connected house. The things installed in the house (Things) are operated using applications on smartphones and other devices. The various Things in the smart-house are operated online via a Web API that has been created as a prototype. This report is an overview of the experimental demonstration, which is gradually clarifying that Web API should be effective for solving issues for IoT.
 Service Function Chaining Use Cases in Fog RAN
 
 draft-bernardos-sfc-fog-ran-08.txt
 Date: 17/09/2020
 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-04.txt
 Date: 17/05/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.
 Thing-to-Thing Data Hub
 
 draft-hartke-t2trg-data-hub-06.txt
 Date: 09/05/2020
 Authors: Klaus Hartke
 Working Group: Individual Submissions (none)
 Formats: txt
A "Thing-to-Thing Data Hub" is a RESTful, hypermedia-driven Web application that can be used in Thing-to-Thing communications to share data items such as thing descriptions, configurations, resource descriptions, or firmware updates at a central location.
 Adaptive IPv4 Address Space
 
 draft-chen-ati-adaptive-ipv4-address-space-07.txt
 Date: 03/06/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.
 Internet Protocol version 10 (IPv10) Specification
 
 draft-omar-ipv10-12.txt
 Date: 17/09/2020
 Authors: Khaled Omar
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies version 10 of the Internet Protocol (IPv10), a solution that allows IPv4-only hosts to communicate with IPv6-only hosts and vice versa.
 Mobility Capability Negotiation and Protocol Selection
 
 draft-yan-dmm-man-07.txt
 Date: 20/09/2020
 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.
 Hypertext Transfer Protocol (HTTP) over multicast QUIC
 
 draft-pardue-quic-http-mcast-07.txt
 Date: 07/08/2020
 Authors: Lucas Pardue, Richard Bradbury, Sam Hurst
 Working Group: Individual Submissions (none)
 Formats: xml 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.
 RFC Style Guide
 
 draft-flanagan-7322bis-06.txt
 Date: 04/10/2020
 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-09.txt
 Date: 07/05/2020
 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. Also, 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-08.txt
 Date: 07/05/2020
 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.
 Signaling extensions for Media Channel sub-carriers configuration in Spectrum Switched Optical Networks (SSON) in Lambda Switch Capable (LSC) Optical Line Systems.
 
 draft-ggalimbe-ccamp-flexigrid-carrier-label-10.txt
 Date: 22/09/2020
 Authors: Gabriele Galimberti, Domenico Fauci, Andrea Zanardi, Lorenzo Galvagni, Julien Meuric
 Working Group: Individual Submissions (none)
 Formats: txt
This memo defines the signaling extensions for managing Spectrum Switched Optical Network (SSON) parameters shared between the Client and the Network and inside the Network in accordance to the model described in [RFC7698]. The extensions are in accordance and extending the parameters defined in ITU-T Recommendation G.694.1.[ITU.G694.1] and its extensions and G.872.[ITU.G872].
 OSPF Extensions for Broadcast Inter-AS TE Link
 
 draft-chen-ospf-ias-lk-05.txt
 Date: 10/07/2020
 Authors: Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei Liu, Zhenqiang Li, Yi Yang
 Working Group: Individual Submissions (none)
 Formats: 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-05.txt
 Date: 10/07/2020
 Authors: Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei Liu, Zhenqiang Li, Yi Yang
 Working Group: Individual Submissions (none)
 Formats: txt
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-07.txt
 Date: 03/06/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-09.txt
 Date: 19/05/2020
 Authors: Daniel 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.
 The 'payto' URI scheme for payments
 
 draft-dold-payto-14.txt
 Date: 01/05/2020
 Authors: Florian Dold, Christian Grothoff
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines the 'payto' Uniform Resource Identifier (URI) scheme for designating targets for payments. A unified URI scheme for all payment target types allows applications to offer user interactions with URIs that represent payment targets, simplifying the introduction of new payment systems and applications.
 NEAT Sockets API
 
 draft-dreibholz-taps-neat-socketapi-07.txt
 Date: 28/07/2020
 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-06.txt
 Date: 17/05/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-10.txt
 Date: 29/06/2020
 Authors: Greg Mirsky, Giuseppe Fioccola, Tal Mizrahi
 Working Group: Individual Submissions (none)
 Formats: xml txt
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-11.txt
 Date: 18/10/2020
 Authors: Greg Mirsky, Gyan Mishra
 Working Group: Individual Submissions (none)
 Formats: txt xml
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-09.txt
 Date: 23/06/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-06.txt
 Date: 30/05/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-08.txt
 Date: 02/10/2020
 Authors: Daniel King, John Drake, Haomian Zheng
 Working Group: Individual Submissions (none)
 Formats: xml txt
Network abstraction is a technique that can be applied to a network domain that 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 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.
 Definition of the ROLIE configuration checklist Extension
 
 draft-mandm-sacm-rolie-configuration-checklist-02.txt
 Date: 13/07/2020
 Authors: Stephen Banghart, Bill Munyan, Adam Montville, Gabriel Alford
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document extends the Resource-Oriented Lightweight Information Exchange (ROLIE) core to add the information type categories and related requirements needed to support security configuration checklist use cases. Additional categories, properties, and requirements based on content type enables a higher level of interoperability between ROLIE implementations, and richer metadata for ROLIE consumers. Additionally, this document discusses requirements and usage of other ROLIE elements in order to best syndicate security configuration checklists.
 BFD in Demand Mode over Point-to-Point MPLS LSP
 
 draft-mirsky-bfd-mpls-demand-08.txt
 Date: 09/09/2020
 Authors: Greg Mirsky
 Working Group: Individual Submissions (none)
 Formats: txt xml
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.
 BGP signalled private MPLS-labels
 
 draft-kaliraj-bess-bgp-sig-private-mpls-labels-01.txt
 Date: 18/08/2020
 Authors: Kaliraj Vairavakkalai, Jeyananth Jeganathan
 Working Group: Individual Submissions (none)
 Formats: txt xml
The MPLS-forwarding-layer in a core network is a shared resource. The MPLS FIB at nodes in this layer contains labels that are dynamically allocated and locally significant at that node. For some usecases like upstream-label-allocation, it is useful to be able to create virtual private MPLS-forwarding-layers over this shared MPLS-forwarding-layer. This allows installing deterministic private label-values in the private-FIBs created at nodes participating in this private MPLS forwarding-layer, while preserving the "locally significant" nature of the underlying shared 'public' MPLS-forwarding-layer. This specification describes the procedures to create such virtual private MPLS-forwarding layers (private MPLS-planes) using a new BGP family. And gives a few example use-cases on how this private forwarding-layers can be used.
 SFC OAM for path consistency
 
 draft-ao-sfc-oam-path-consistency-08.txt
 Date: 03/06/2020
 Authors: Greg Mirsky, Ting Ao, Zhonghua Chen, Kent Leung
 Working Group: Individual Submissions (none)
 Formats: xml 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 as a result of classification. SFC Operation, Administration and Maintenance can monitor the continuity of the SFC, i.e., that all elements of the SFC 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 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-06.txt
 Date: 03/06/2020
 Authors: Greg Mirsky, Ting Ao, Zhonghua Chen
 Working Group: Individual Submissions (none)
 Formats: 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.
 SOCKS Protocol Version 6
 
 draft-olteanu-intarea-socks-6-10.txt
 Date: 13/07/2020
 Authors: Vladimir Olteanu, Dragos Niculescu
 Working Group: Individual Submissions (none)
 Formats: txt xml
The SOCKS protocol is used primarily to proxy TCP connections to arbitrary destinations via the use of a proxy server. Under the latest version of the protocol (version 5), it takes 2 RTTs (or 3, if authentication is used) before data can flow between the client and the server. This memo proposes SOCKS version 6, which reduces the number of RTTs used, takes full advantage of TCP Fast Open, and adds support for 0-RTT authentication.
 MPT Network Layer Multipath Library
 
 draft-lencse-tsvwg-mpt-06.txt
 Date: 13/06/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.
 PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of SR-LSPs
 
 draft-zhao-pce-pcep-extension-pce-controller-sr-07.txt
 Date: 13/07/2020
 Authors: Zhenbin Li, Shuping Peng, Mahendra Negi, Quintin Zhao, Chao Zhou
 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. Thus, the LSP can be calculated/setup/initiated and the label forwarding entries can also be downloaded through a centralized PCE server to each network devices along the path while leveraging the existing PCE technologies as much as possible. 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, in addition to computing the paths for packet flows in a segment routing network and telling the edge routers what instructions to attach to packets as they enter the network.
 ALTSVC Frame in HTTP/QUIC
 
 draft-bishop-httpbis-altsvc-quic-01.txt
 Date: 15/05/2020
 Authors: Mike Bishop
 Working Group: Individual Submissions (none)
 Formats: xml html txt
[RFC7838] defines the ALTSVC frame for HTTP/2 [RFC7540]. This frame is equally applicable to HTTP/QUIC ([I-D.ietf-quic-http]), but needs to be separately registered. This document describes the ALTSVC frame for HTTP/QUIC.
 Problem Statement and Considerations for ROAs issued with Multiple Prefixes
 
 draft-yan-sidrops-roa-considerations-05.txt
 Date: 20/09/2020
 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.
 Linkset: Media Types and a Link Relation Type for Link Sets
 
 draft-wilde-linkset-07.txt
 Date: 16/10/2020
 Authors: Erik Wilde, Herbert Van de Sompel
 Working Group: Individual Submissions (none)
 Formats: txt xml
This specification defines two document formats and respective media types for representing sets of links as stand-alone resources. One format is JSON-based, the other aligned with the format for representing links in the HTTP "Link" header field. This specification also introduces a link relation type to support discovery of sets of links.
 LISP for the Mobile Network
 
 draft-farinacci-lisp-mobile-network-09.txt
 Date: 08/09/2020
 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-09.txt
 Date: 09/08/2020
 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.
 Signed HTTP Exchanges
 
 draft-yasskin-http-origin-signed-responses-09.txt
 Date: 27/07/2020
 Authors: Jeffrey Yasskin
 Working Group: Individual Submissions (none)
 Formats: txt html xml
This document specifies how a server can send an HTTP exchange--a request URL, content negotiation information, and a response--with signatures that vouch for that exchange's authenticity. These signatures can be verified against an origin's certificate to establish that the exchange is authoritative for an origin even if it was transferred over a connection that isn't. The signatures can also be used in other ways described in the appendices. These signatures contain countermeasures against downgrade and protocol-confusion attacks.
 IPv6 Source Routing for ultralow Latency
 
 draft-foglar-ipv6-ull-routing-07.txt
 Date: 27/07/2020
 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.
 Simple Group Keying Protocol (SGKP)
 
 draft-ietf-trill-group-keying-06.txt
 Date: 13/07/2020
 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-06.txt
 Date: 02/10/2020
 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.
 A YANG Data Model for Ethernet TE Topology
 
 draft-zheng-ccamp-client-topo-yang-09.txt
 Date: 03/06/2020
 Authors: Haomian Zheng, Aihua Guo, Italo Busi, Yunbin Xu, Yang Zhao, Xufeng Liu
 Working Group: Individual Submissions (none)
 Formats: txt xml
A transport network is a server-layer network to provide connectivity services to its client. In this draft the topology of Ethernet with TE is described with YANG data model.
 A YANG Data Model for Client-layer Tunnel
 
 draft-zheng-ccamp-client-tunnel-yang-07.txt
 Date: 17/08/2020
 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.
 BIER BFD
 
 draft-hu-bier-bfd-07.txt
 Date: 10/07/2020
 Authors: Quan Xiong, Greg Mirsky, fangwei hu, Chang Liu
 Working Group: Individual Submissions (none)
 Formats: txt
Point to multipoint (P2MP) BFD is designed to verify multipoint connectivity. This document specifies the application of P2MP BFD in BIER network.
 BIER in IPv6 (BIERin6)
 
 draft-zhang-bier-bierin6-07.txt
 Date: 30/07/2020
 Authors: Zheng Zhang, Zhaohui Zhang, IJsbrand Wijnands, Hooman Bidgoli, Mike McBride
 Working Group: Individual Submissions (none)
 Formats: xml txt
BIER is a new architecture for the forwarding of multicast data packets. This document defines native IPv6 encapsulation for BIER hop-by-hop forwarding or BIERin6 for short.
 PCEP Extension for Stateful Inter-Domain Tunnels
 
 draft-dugeon-pce-stateful-interdomain-04.txt
 Date: 10/07/2020
 Authors: Olivier Dugeon, Julien Meuric, Young Lee, Daniele Ceccarelli
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies how to combine a Backward Recursive or Hierarchical method with inter-domain paths in the context of stateful Path Computation Element (PCE). It relies on the PCInitiate message to set up independent paths per domain. Combining these different paths together enables to operate them as end-to-end inter- domain paths without the need for a signaling session between inter- domain border routers. A new Stitching Label is defined, new Path Setup Types, a new Association Type and a new PCEP communication Protocol (PCEP) Capability are considered for that purpose.
 Echo Request/Reply for Enabled In-situ OAM Capabilities
 
 draft-xiao-ippm-ioam-conf-state-07.txt
 Date: 04/09/2020
 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.
 DHCPv6_PD,PDP and NDP Implementation in IoT Router (DANIR)
 
 draft-shytyi-v6ops-danir-05.txt
 Date: 20/05/2020
 Authors: Dmytro Shytyi, Alexandre Petrescu
 Working Group: Individual Submissions (none)
 Formats: pdf xml txt
This document provides a description of the implementation of Dynamic Host Configuration Protocol version 6 Prefix Delegation, Neighbour Discovery Protocol and of the use of the Packet Data Protocol in an Internet of Things Router. This Internet of Things Router is connected on a cellular network; it is a DHCPv6-PD Client and it requests a /56 pool of prefixes from the server; the DHCPv6-PD server is placed in the PGW and is a part of the cellular infrastructure. After the pool of prefixes is delegated, the Internet of Things Router derives sub-prefixes from the prefix pool; each one of these sub-prefixes is aimed at one ingress interface. After the Internet of Things Router finishes the network prefix assignment procedure, it advertises the network prefixes on the ingress links by using the Neighbour Discovery protocol. Finally, when Hosts receive the sub-prefixes via Router Adverticement messages, they configure the Global Unique Address with the Stateless Address Auto-configuration protocol.
 YANG Model for QoS Operational Parameters
 
 draft-asechoud-rtgwg-qos-oper-model-07.txt
 Date: 09/07/2020
 Authors: Aseem Choudhary, Ing-Wher Chen
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a YANG model for Quality of Service (QoS) operational parameters.
 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-10.txt
 Date: 30/06/2020
 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-05.txt
 Date: 25/07/2020
 Authors: Bernhard Haindl, Manfred Lindner, Reshad Rahman, Marc Portoles-Comeras, Victor Moreno, Fabio Maino, Balaji Venkatachalapathy
 Working Group: Individual Submissions (none)
 Formats: xml txt
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-07.txt
 Date: 30/04/2020
 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.
 Resource Orchestration for Multi-Domain,Exascale,Geo-Distributed Data Analytics
 
 draft-xiang-alto-multidomain-analytics-05.txt
 Date: 13/07/2020
 Authors: Qiao Xiang, Jensen Zhang, Franck Le, Y. Yang, Harvey Newman
 Working Group: Individual Submissions (none)
 Formats: txt
As the data volume increases exponentially over time, data analytics is transiting from a single-domain network to a multi-domain, geo- distributed network, where different member networks contribute various resources, e.g., computation, storage and networking resources, to collaboratively collect, share and analyze extremely large amounts of data. Such a network calls for a resource orchestration framework that emphasizes the performance predictability of data analytics jobs, the high utilization of resources, and the autonomy and privacy of member networks. This document presents the design of Unicorn, a unified resource orchestration framework for multi-domain, geo-distributed data analytics, which uses the Application-Layer Traffic Optimization (ALTO) protocol as the key component for (1) allows member networks to provide accurate information on different types of resources; (2) keeps the private information of member networks; and (3) allows data analytics jobs to accurately describe their requirements of different types of resources. As a part of Unicorn, an ALTO extension for privacy-preserving interdomain information aggregation is also presented.
 A Decent LISP Mapping System (LISP-Decent)
 
 draft-farinacci-lisp-decent-06.txt
 Date: 13/09/2020
 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.
 Deterministic Networking Application in Ring Topologies
 
 draft-jiang-detnet-ring-06.txt
 Date: 13/07/2020
 Authors: Yuanlong Jiang, Norman Finn, Jeong-dong Ryoo, Balazs Varga, Liang Geng
 Working Group: Individual Submissions (none)
 Formats: txt
Deterministic Networking (DetNet) provides a capability to carry data flows for real-time applications with extremely low data loss rates and bounded latency. This document describes how DetNet can be used in ring topologies to support Point-to-Point (P2P) and Point-to- Multipoint (P2MP) real-time services.
 Device Enrollment in IETF protocols -- A Roadmap
 
 draft-richardson-enrollment-roadmap-03.txt
 Date: 07/10/2020
 Authors: Michael Richardson
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document provides an overview of enrollment or imprinting mechanisms in current IETF protocols. This document is being worked on in the ANIMA-WG, and on github at: https://github.com/anima-wg/enrollment-roadmap
 A feature freezer for the Concise Data Definition Language (CDDL)
 
 draft-bormann-cbor-cddl-freezer-04.txt
 Date: 15/06/2020
 Authors: Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: xml html txt
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.
 impl-info: A link relation type for disclosing implementation information
 
 draft-bormann-t2trg-rel-impl-02.txt
 Date: 27/09/2020
 Authors: Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: html txt xml
For debugging, it is often helpful to have information about the implementation of a peer. The present specification defines a link relation type, "impl-info", that can be used to convey such information via self-description, such as in the "/.well-known/core" resource.
 Simple Group Keying Protocol TRILL Use Protfiles
 
 draft-ietf-trill-link-gk-profiles-05.txt
 Date: 13/07/2020
 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-03.txt
 Date: 03/07/2020
 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-05.txt
 Date: 26/07/2020
 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.
 Information-centric Routing for Opportunistic Wireless Networks
 
 draft-mendes-icnrg-dabber-05.txt
 Date: 16/09/2020
 Authors: Paulo Mendes, Rute Sofia, Vassilis Tsaoussidis, Carlos Borrego
 Working Group: Individual Submissions (none)
 Formats: txt pdf xml
This draft describes the Data reAchaBility BasEd Routing (DABBER) protocol. DABBER aims to provide a name-based routing solution to support the operation of Information-centric Networking frameworks in opportunistic wireless networks. By "opportunistic wireless networks" it is meant multi-hop wireless networks where finding an end-to-end path between any pair of nodes at any moment in time may be a challenge. The goal is to assist in better defining opportunities for the transmission of Interest packets in a store- carry-and-forward manner, based on a proactive approach. The document describes how to integrate DABBER in a networking node that implements some ICN approach, such as Named-Data Networking (NDN) or Content Centric Networking (CCN), along with the specification of the proactive approach based on the dissemination of name-prefix information.
 Unified Identifier in IPv6 Segment Routing Networks
 
 draft-mirsky-6man-unified-id-sr-07.txt
 Date: 02/07/2020
 Authors: Weiqiang Cheng, Greg Mirsky, Shaofu Peng, Liu Aihua, Gyan Mishra
 Working Group: Individual Submissions (none)
 Formats: 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.
 Synchronizing Internet Clock frequency protocol (sic)
 
 draft-alavarez-hamelin-tictoc-sic-05.txt
 Date: 30/04/2020
 Authors: Jose Alvarez-Hamelin, David Samaniego, Alfredo Ortega, Ruediger Geib
 Working Group: Individual Submissions (none)
 Formats: xml txt
Synchronizing Internet Clock Frequency specifies a new secure method to synchronize difference clocks on the Internet, assuring smoothness (i.e., frequency stability) and robustness to man-in-the-middle attacks. In 90% of all cases, Synchronized Internet Clock Frequency is highly accurate, with a Maximum Time Interval Error less 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-06.txt
 Date: 09/07/2020
 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 the RFC 8231.
 Hierarchy of IP Controllers (HIC)
 
 draft-li-teas-hierarchy-ip-controllers-05.txt
 Date: 13/07/2020
 Authors: Zhenbin Li, Dhruv Dhody, Huaimo Chen
 Working Group: Individual Submissions (none)
 Formats: txt xml
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-18.txt
 Date: 29/07/2020
 Authors: Stanislav Smyshlyaev, Vladislav Nozdrunov, Vasily Shishkin, Ekaterina Griboedova
 Working Group: Individual Submissions (none)
 Formats: txt xml
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-13.txt
 Date: 09/10/2020
 Authors: HAIGUANG Wang, Yanjiang Yang, Xin Kang, Zhaohui Cheng, chenmeiling
 Working Group: Individual Submissions (none)
 Formats: txt xml pdf
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-04.txt
 Date: 14/06/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-06.txt
 Date: 03/08/2020
 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.
 BGP Link-State Extensions for BGP-only Fabric
 
 draft-ketant-idr-bgp-ls-bgp-only-fabric-05.txt
 Date: 08/09/2020
 Authors: Ketan Talaulikar, Clarence Filsfils, krishnaswamy ananthamurthy, Shawn Zandi, Gaurav Dawra, Muhammad Durrani
 Working Group: Individual Submissions (none)
 Formats: txt
BGP is used as the only routing protocol in some networks today. In such networks, it is useful to get a detailed view of the nodes and underlying links in the topology along with their attributes similar to one available when using link state routing protocols. Such a view of a BGP-only fabric enables use cases like traffic engineering and forwarding of services along paths other than the BGP best path selection. This document defines extensions to the BGP Link-state address-family (BGP-LS) and the procedures for advertisement of the topology in a BGP-only network. It also describes a specific use-case for traffic engineering based on Segment Routing.
 Cumulative DMZ Link Bandwidth and load-balancing
 
 draft-mohanty-bess-ebgp-dmz-02.txt
 Date: 13/07/2020
 Authors: satyamoh@cisco.com, Aaron Millisor, 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.
 Segment Routing based Virtual Transport Network for Enhanced VPN
 
 draft-dong-spring-sr-for-enhanced-vpn-10.txt
 Date: 30/08/2020
 Authors: Jie Dong, Stewart Bryant, Takuya Miyasaka, Yongqing Zhu, Fengwei Qin, Zhenqiang Li, Francois Clad
 Working Group: Individual Submissions (none)
 Formats: xml txt
I-D.ietf-spring-resource-aware-segments describes the mechanism to associate network resource attributes to Segment Routing Identifiers (SIDs). The resource-aware SIDs can be used to build SR paths with a set of reserved network resources. In addition, the resource-aware SIDs can be used to build SR based virtual networks, which can be used as virtual underlay networks with the network topology and resource attributes required by different customers or services. Such virtual networks are called virtual transport networks (VTNs). This document describes the mechanism of using resource-aware SIDs to build SR based VTNs.
 A YANG Data Model for In-Situ OAM
 
 draft-zhou-ippm-ioam-yang-08.txt
 Date: 30/07/2020
 Authors: Tianran Zhou, Jim Guichard, Frank Brockners, Srihari Raghavan
 Working Group: Individual Submissions (none)
 Formats: txt
In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in user packets while the packets traverse a path between two points in the network. This document defines a YANG module for the IOAM function.
 Geneve encapsulation for In-situ OAM Data
 
 draft-brockners-ippm-ioam-geneve-04.txt
 Date: 13/05/2020
 Authors: Frank Brockners, Shwetha Bhandari, Vengada Govindan, Carlos Pignataro, 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.
 ALTO-based Broker-assisted Multi-domain Orchestration
 
 draft-lachosrothenberg-alto-brokermdo-04.txt
 Date: 13/07/2020
 Authors: Danny Perez, Christian Rothenberg
 Working Group: Individual Submissions (none)
 Formats: txt
Evolving networking scenarios (e.g., 5G) demand new multiple administrative domain (aka multi-domain) orchestration models. This document proposes a new broker-plane approach working on top of per- domain management and orchestration functions to coordinate the delivery of a multi-operator End-to-End Network Service (E2ENS). This proposed design resorts to the Application-Layer Traffic Optimization (ALTO) protocol to offer topology and resource information from different administrative domains. The ALTO services with the proposed protocol extension offer aggregated views on various types of resources contributing to a more simple and scalable solution.
 EVPN All Active Usage Enhancement
 
 draft-eastlake-bess-enhance-evpn-all-active-05.txt
 Date: 13/07/2020
 Authors: Donald Eastlake, Zhenbin Li, Haibo Wang
 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-05.txt
 Date: 15/05/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-05.txt
 Date: 20/08/2020
 Authors: Quentin 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.
 Service Function discovery in fog environments
 
 draft-bernardos-sfc-discovery-05.txt
 Date: 17/09/2020
 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-05.txt
 Date: 27/04/2020
 Authors: Donald Eastlake, Zhenbin Li, Shunwan Zhuang
 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-05.txt
 Date: 24/05/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.
 Connected Identity for STIR
 
 draft-peterson-stir-rfc4916-update-01.txt
 Date: 13/07/2020
 Authors: Jon Peterson, Chris Wendt
 Working Group: Individual Submissions (none)
 Formats: xml 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.
 OAuth 2.0 Assisted Token
 
 draft-ideskog-assisted-token-02.txt
 Date: 21/05/2020
 Authors: Jacob Ideskog, Travis Spencer
 Working Group: Individual Submissions (none)
 Formats: html txt xml
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-05.txt
 Date: 26/06/2020
 Authors: Gustavo Lozano, 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-05.txt
 Date: 20/05/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.
 IS-IS Multi Topology Deployment Considerations
 
 draft-chunduri-lsr-isis-mt-deployment-cons-03.txt
 Date: 17/05/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-04.txt
 Date: 03/06/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-06.txt
 Date: 12/10/2020
 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-04.txt
 Date: 20/05/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-04.txt
 Date: 26/05/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.
 GREASE for HTTP/2
 
 draft-bishop-httpbis-grease-01.txt
 Date: 24/06/2020
 Authors: Mike Bishop
 Working Group: Individual Submissions (none)
 Formats: txt html xml
Reserves several values in the HTTP/2 registries to exercise the requirement that clients and servers ignore unknown values.
 Hybrid Information-Centric Networking
 
 draft-muscariello-intarea-hicn-04.txt
 Date: 20/05/2020
 Authors: Luca Muscariello, Giovanna Carofiglio, Jordan Auge, Michele Papalini, Mauro Sardara
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the hybrid information-centric networking (hICN) architecture for IPv6. The specifications describe a way to implement information-networking functionalities into IPv6. The objective is to use IPv6 without creating overlays with a new packet format as an additional encapsulation. The intent of the present design is to introduce some IPv6 routers in the network with additional packet processing operations to implement ICN functions. Moreover, the current design is tightly integrated into IPv6 to allow easy interconnection to IPv6 networks with the additional design objective to exploit existing IPv6 protocols as much as possible as they are, or extend them where needed.
 General Security Considerations for Cryptoassets Custodians
 
 draft-vcgtf-crypto-assets-security-considerations-06.txt
 Date: 18/06/2020
 Authors: Masashi Sato, Masaki Shimaoka, Hirotaka Nakajima
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document discusses the technical and operational risks of cryptoassets custodians and its security controls to avoid the unintended transactions for its customers.
 GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.2
 
 draft-smyshlyaev-tls12-gost-suites-08.txt
 Date: 25/05/2020
 Authors: Stanislav Smyshlyaev, Dmitry Belyavsky, Markku-Juhani Saarinen
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies a set of cipher suites for the Transport Layer Security (TLS) protocol Version 1.2 to support the Russian cryptographic standard algorithms.
 The IPv6 Tunnel Payload Forwarding (TPF) Option
 
 draft-bonica-6man-vpn-dest-opt-13.txt
 Date: 30/08/2020
 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.
 A Massive Data Migration Framework
 
 draft-yangcan-ietf-data-migration-standards-04.txt
 Date: 27/05/2020
 Authors: Can Yang, Yu Pan, Cong Chen, Ge Chen, Yukai Wei
 Working Group: Individual Submissions (none)
 Formats: txt xml pdf
This document describes a standardized framework for implementing the massive data migration between traditional databases and big-data platforms on the cloud via Internet, especially for an instance of Hadoop data architecture. The main goal of the framework is to provide more concise and friendly interfaces for users more easily and quickly migrate the massive data from a relational database to a distributed platform for a variety of requirements, in order to make full use of distributed storage resource and distributed computing capability to solve the bottleneck problems of both storage and computing performance in traditional enterprise-level applications. This document covers the fundamental architecture, data elements specification, operations, and interface related to massive data migration.
 Web Bundles
 
 draft-yasskin-wpack-bundled-exchanges-03.txt
 Date: 27/07/2020
 Authors: Jeffrey Yasskin
 Working Group: Individual Submissions (none)
 Formats: xml html txt
Web bundles provide a way to bundle up groups of HTTP responses, with the URLs and request URLs that produced them, to transmit or store them together. They can include multiple top-level resources with one identified as the default by a primaryUrl metadata, provide random access to their component exchanges, and efficiently store 8-bit resources.
 DNS Web Service Discovery
 
 draft-hallambaker-web-service-discovery-04.txt
 Date: 27/07/2020
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt html xml
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-07.txt
 Date: 01/09/2020
 Authors: Anurag Khare, Philippe BERGEON, John Scudder, Luay Jalil, Michael Gallagher, Kirill Kasavchenko
 Working Group: Individual Submissions (none)
 Formats: xml 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.
 Preferred Path Routing (PPR) in IS-IS
 
 draft-chunduri-lsr-isis-preferred-path-routing-06.txt
 Date: 28/09/2020
 Authors: Uma Chunduri, Renwei Li, Russ White, Jeff Tantsura, Luis Contreras, Yingzhen Qu
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies Preferred Path Routing (PPR), an extensible method of providing path based dynamic routing for a number of packet types including IPv4, IPv6 and MPLS. PPR uses a simple encapsulation to add the path identity to the packet. PPR can also be used to mitigate the MTU and data plane processing issues that may result from Segment Routing (SR) packet overhead; and also supports further extensions along the paths.
 Anchorless mobility management through hICN (hICN-AMM): Deployment options
 
 draft-auge-dmm-hicn-mobility-deployment-options-04.txt
 Date: 07/07/2020
 Authors: Jordan Auge, Giovanna Carofiglio, Luca Muscariello, Michele Papalini
 Working Group: Individual Submissions (none)
 Formats: txt
A novel mobility management approach has been proposed, that leverages routable location-independent identifiers (IDs) and an Information-Centric Networking (ICN) communication model integrated in IPv6, also referred to as Hybrid ICN (hICN). In virtue of its anchorless property, we denote this approach as hICN-AMM (hICN Anchorless Mobility Management) hereinafter. Such approach belongs to the category of pure ID-based mobility management schemes whose objective is (i) to overcome the limitations of traditional locator-based solutions like Mobile IP, (ii) to remove the need for a global mapping system as the one required by locator- identifier separation solutions like LISP or ILA. ID-based networking as proposed by ICN architectures allows to disentangle forwarding operations from changes of network location, hence removing tunnels and user plane or control plane anchors. This document discusses hICN-AMM deployment options and related tradeoffs in terms of cost/benefits. Particular attention is devoted to the insertion in the recently proposed 5G Service Based Architecture under study at 3GPP where an hICN-AMM solution might present a more efficient alternative to the traditional tunnel-based mobility architecture through GTP-U.
 PIM Backup Designated Router Procedure
 
 draft-mankamana-pim-bdr-04.txt
 Date: 27/04/2020
 Authors: Mankamana Mishra, 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-06.txt
 Date: 06/07/2020
 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 mechanisms for 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, PCEP can be used for computing paths in 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 delete PCE-initiated LSPs 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 where to make allocations on behalf of PCC. This document describes a mechanism for PCC to inform the PCE of the identifier space under its control via PCEP. The identifier could be MPLS label, SID or any other to-be-defined identifier to be allocated by a PCE.
 Anchorless mobility through hICN
 
 draft-auge-dmm-hicn-mobility-04.txt
 Date: 07/07/2020
 Authors: Jordan Auge, Giovanna Carofiglio, Luca Muscariello, Michele Papalini
 Working Group: Individual Submissions (none)
 Formats: txt
This document first discusses the use of locators and identifiers in mobility management architectures, and their implication on various anchorless properties. A new architecture is then proposed that is purely based on identifiers, and more specifically names as defined in Hybrid-ICN (hICN). The document then focuses on two main cases: the end-point sends data (data producer) or the end-point receives data (data consumer). These two cases are taken into account entirely to provide anchorless mobility management in hICN.
 IGP Extensions for Segment Routing based Enhanced VPN
 
 draft-dong-lsr-sr-enhanced-vpn-04.txt
 Date: 23/06/2020
 Authors: Jie Dong, Zhibo Hu, Zhenbin Li, Xiongyan Tang, Ran Pang, Lee JooHeon, Stewart Bryant
 Working Group: Individual Submissions (none)
 Formats: txt
Enhanced VPN (VPN+) is an enhancement to VPN services to support the needs of new applications, particularly including the applications that are associated with 5G services. These applications require enhanced isolation and have more stringent performance requirements than that can be provided with traditional overlay VPNs. An enhanced VPN may be used for 5G transport network slicing, and will also be of use in more generic scenarios. To meet the requirement of enhanced VPN services, a number of Virtual Transport Networks (VTN) need to be created, each with a subset of the underlay network topology and a set of network resources allocated to meet the requirement of a specific VPN+ service, 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. The VTNs could be used as the underlay of enhanced VPN service. The proposed mechanism is applicable to both Segment Routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6).
 TLS 1.3 Authentication and Integrity only Cipher Suites
 
 draft-camwinget-tls-ts13-macciphersuites-07.txt
 Date: 28/08/2020
 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 mutual authentication during tunnel establishment are both still mandated. Examples of such use cases are given, although a threat model is necessary to determine whether or not a given situation falls into this catergory 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 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.
 pretty Easy privacy (pEp): Contact and Channel Authentication through Handshake
 
 draft-marques-pep-handshake-05.txt
 Date: 08/07/2020
 Authors: Hernani Marques, Bernie Hoeneisen
 Working Group: Individual Submissions (none)
 Formats: xml txt
In interpersonal messaging, end-to-end encryption means for public key distribution and verification of its authenticity are needed; the latter to prevent man-in-the-middle (MITM) attacks. This document proposes a new method to easily verify a public key is authentic by a Handshake process that allows users to easily authenticate their communication channel. The new method is targeted to Opportunistic Security scenarios and is already implemented in several applications of pretty Easy privacy (pEp).
 Design Considerations for Low Power Internet Protocols
 
 draft-ayers-low-power-interop-01.txt
 Date: 13/07/2020
 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-04.txt
 Date: 08/06/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.
 BGP-LS Extensions for Advertising Path MTU
 
 draft-zhu-idr-bgp-ls-path-mtu-04.txt
 Date: 09/08/2020
 Authors: Yongqing Zhu, Zhibo Hu, Shuping Peng, Robbins Mwehair
 Working Group: Individual Submissions (none)
 Formats: xml txt
BGP Link State (BGP-LS) describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. The centralized controller (PCE/SDN) completes the service path calculation based on the information transmitted by the BGP-LS and delivers the result to the Path Computation Client (PCC) through the PCEP or BGP protocol. Segment Routing (SR) leverages the source routing paradigm, which can be directly applied to the MPLS architecture with no change on the forwarding plane and applied to the IPv6 architecture, with a new type of routing header, called SRH. The SR uses the IGP protocol as the control protocol. Compared to the MPLS tunneling technology, the SR does not require additional signaling. Therefore, the SR does not support the negotiation of the Path MTU. Since multiple labels or SRv6 SIDs are pushed in the packets, it is more likely that the packet size exceeds the path mtu of SR tunnel. This document specifies the extensions to BGP Link State (BGP-LS) to carry maximum transmission unit (MTU) messages of link. The PCE/SDN calculates the Path MTU while completing the service path calculation based on the information transmitted by the BGP-LS.
 Study Report on a Framework for Cloud Inter-connection toward the Realization of IoT
 
 draft-baba-iot-interconnection-04.txt
 Date: 09/09/2020
 Authors: Hiroyuki BABA, Izaya Miyake, Jun Matsumura, Yoshiki Ishida
 Working Group: Individual Submissions (none)
 Formats: txt xml
This paper describes issues for solutions through cloud inter- connection to structural problems, which are called as "silo effects" found in cloud-connected electric home appliances, housing equipment and sensors in the face of increasingly accelerated connection of them. Specifically, this paper explains an inter-connection agreement considered to be required for enhancement of cloud inter- connection, what performance guarantee as well as IoT supervising and management should be, necessity of inter-connection HUB which is able to provide inter-connection amongst the preponderance of private cloud groups, and the necessity of a mechanism to avoid threats that cause danger to users when we make the inter-connection.
 Security Policy Translation in Interface to Network Security Functions
 
 draft-yang-i2nsf-security-policy-translation-06.txt
 Date: 07/05/2020
 Authors: Jaehoon Jeong, Jinhyuk Yang, Chaehong Chung, Jinyong Kim
 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-04.txt
 Date: 09/09/2020
 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-02.txt
 Date: 24/04/2020
 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-04.txt
 Date: 13/07/2020
 Authors: J. Zhang, Y. Yang
 Working Group: Individual Submissions (none)
 Formats: html xml 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-04.txt
 Date: 12/07/2020
 Authors: Chandrasekar R, Vishnu Beeram, Harish Sitaraman
 Working Group: Individual Submissions (none)
 Formats: txt
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.
 LISP Control Plane for SRv6 Endpoint Mobility
 
 draft-rodrigueznatal-lisp-srv6-04.txt
 Date: 26/07/2020
 Authors: Alberto Rodriguez-Natal, Vina Ermagan, Fabio Maino, Darren Dukes, Pablo Camarillo, Clarence Filsfils
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the use of the LISP Control Plane to support endpoint mobility and Location/ID separation in Segment Routing v6 (SRv6) deployments.
 ALTO Extension: Unified Resource Representation
 
 draft-xiang-alto-unified-representation-03.txt
 Date: 13/07/2020
 Authors: Qiao Xiang, Jensen Zhang, Franck Le, Y. Yang
 Working Group: Individual Submissions (none)
 Formats: txt
The ALTO protocol [RFC7285] provides network information to applications so that applications can make network informed decisions to improve the performance. However, the base ALTO protocol only provides coarse-grained end-to-end metrics, which are insufficient to satisfy the demands of applications to solve more complex network optimization problems. The ALTO Path Vector extension [DRAFT-PV] has been introduced to allow ALTO clients to query information such as capacity regions for a given set of flows. However, the current design of this extension has a limited expressiveness. The goal of this document is to introduce a unified resource representation service as an extension of ALTO (ALTO-UR), which allows the ALTO clients to query and get the capacity regions of more complex resource information, such as Shared-Risk-Link-Group (SRLG), multi- path routing, multicast and on-demand routing, for a given set of flows.
 Terminology for Cryptoassets
 
 draft-nakajima-crypto-asset-terminology-04.txt
 Date: 02/07/2020
 Authors: Hirotaka Nakajima, Masanori Kusunoki, Keiichi Hida, Yuji Suga, Tatsuya Hayashi
 Working Group: Individual Submissions (none)
 Formats: txt
This document provides terminology used in cryptoassets.
 A YANG Data Model for Network Bridge Management
 
 draft-vassilev-netmod-network-bridge-04.txt
 Date: 06/07/2020
 Authors: Vladimir Vassilev
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document introduces new YANG model of a network bridge.
 Flexible Session Protocol
 
 draft-gao-flexible-session-protocol-04.txt
 Date: 18/04/2020
 Authors: Jun-an Gao
 Working Group: Individual Submissions (none)
 Formats: txt html
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 support o Ubiquitous authenticated encryption o 0-RTT multiplication of connections o On-the-wire compression
 Transport Network aware Mobility for 5G
 
 draft-clt-dmm-tn-aware-mobility-07.txt
 Date: 28/09/2020
 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 and Layer 2 transport networks. Slices in 5G systems are characterized by latency bounds, reservation guarantees, jitter, data rates, availability, mobility speed, usage density, criticality and priority should be mapped to transport 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 packets that transport segments use to grant transport layer services. This is based on mapping between mobile and IP transport underlays (IPv6, MPLS, IPv4, Segment Routing). Applicability of this framework and a new transport network underlay routing mechanism, Preferred Path Routing (PPR), which brings slice properties and works with any underlying transport (L2, IPv4, SR and MPLS) is also discussed.
 BGP-LS Advertisement of Segment Routing Service Segments
 
 draft-dawra-idr-bgp-ls-sr-service-segments-04.txt
 Date: 14/08/2020
 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,"The 'xml2rfc' Version 3 Vocabulary"
 
 draft-levkowetz-xml2rfc-v3-implementation-notes-11.txt
 Date: 21/07/2020
 Authors: Henrik Levkowetz
 Working Group: Individual Submissions (none)
 Formats: xml html txt
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-06.txt
 Date: 04/09/2020
 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 the subject and/or other principals related to the event. This specification formalizes the notion of subject identifiers as named sets of well-defined claims describing the subject, a mechanism for representing subject identifiers within a JSON object such as a JSON Web Token (JWT) or Security Event Token (SET), and a registry for defining and allocating names for these claim sets.
 Extensions to OSPF for Advertising Prefix Administrative Tags
 
 draft-acee-lsr-ospf-admin-tags-07.txt
 Date: 23/09/2020
 Authors: Acee Lindem, Peter Psenak
 Working Group: Individual Submissions (none)
 Formats: txt
It is useful for routers in an OSPFv2 or OSPFv3 routing domain to be able to associate tags with prefixes. Previously, OSPFv2 and OSPFv3 were relegated to a single tag for AS External and Not-So-Stubby-Area (NSSA) prefixes. With the flexible encodings provided by OSPFv2 Prefix/Link Attribute Advertisement and OSPFv3 Extended LSAs, multiple administrative tags may advertised for all types of prefixes. These administrative tags can be used for many applications including route redistribution policy, selective prefix prioritization, selective IP Fast-ReRoute (IPFRR) prefix protection, and many others. The ISIS protocol supports a similar mechanism that is described in RFC 5130.
 YANG Data Model for IS-IS SRv6
 
 draft-hu-isis-srv6-yang-04.txt
 Date: 13/07/2020
 Authors: Zhibo Hu, Dan Ye, Yingzhen Qu, Xuesong Geng
 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 Decentralized Identifier (DID) in the DNS
 
 draft-mayrhofer-did-dns-04.txt
 Date: 09/09/2020
 Authors: Alexander Mayrhofer, Dimitrij Klesev, Markus Sabadello
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies the use of the URI Resource Record Type to publish Decentralized Identifiers (DIDs) in the DNS.
 The Multihash Data Format
 
 draft-multiformats-multihash-01.txt
 Date: 18/08/2020
 Authors: Juan Benet, Manu Sporny
 Working Group: Individual Submissions (none)
 Formats: xml txt
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-05.txt
 Date: 01/10/2020
 Authors: Hongyu Li, Thomas Haag, Birgit Witschurke
 Working Group: Individual Submissions (none)
 Formats: xml txt
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-04.txt
 Date: 01/09/2020
 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.
 Asymmetric Extended Route Optimization (AERO)
 
 draft-templin-intarea-6706bis-66.txt
 Date: 05/10/2020
 Authors: Fred Templin
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies the operation of IP over Overlay Multilink Network (OMNI) interfaces using the Asymmetric Extended Route Optimization (AERO) internetworking and mobility management service. AERO/OMNI use an IPv6 link-local address format that supports operation of the IPv6 Neighbor Discovery (ND) protocol and links ND to IP forwarding. Prefix delegation/registration services are employed for network admission and to manage the routing system. Multilink operation, mobility management, quality of service (QoS) signaling and route optimization are naturally supported through dynamic neighbor cache updates. Standard IP multicasting services are also supported. AERO is a widely-applicable mobile internetworking service especially well-suited to aviation services, intelligent transportation systems, mobile Virtual Private Networks (VPNs) and many other applications.
 Guide for building an EDDSA pki
 
 draft-moskowitz-eddsa-pki-04.txt
 Date: 04/09/2020
 Authors: Robert Moskowitz, Henk Birkholz, Michael Richardson
 Working Group: Individual Submissions (none)
 Formats: txt xml
This memo provides a guide for building a PKI (Public Key Infrastructure) using openSSL. Certificates in this guide can be either ED25519 or ED448 certificates. Along with common End Entity certificates, this guide provides instructions for creating IEEE 802.1AR iDevID Secure Device certificates.
 On loading MUD URLs from QR codes
 
 draft-richardson-opsawg-securehomegateway-mud-05.txt
 Date: 08/09/2020
 Authors: Michael Richardson, Jacques Latour, Hassan Gharakheili
 Working Group: Individual Submissions (none)
 Formats: txt html xml
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
 Preparation,Enforcement,and Comparison of Internationalized Strings (PRECIS) Test Vectors
 
 draft-whited-precis-test-vectors-03.txt
 Date: 24/04/2020
 Authors: Sam Whited
 Working Group: Individual Submissions (none)
 Formats: xml html txt
This document contains machine readable test vectors for several Preparation, Enforcement, and Comparison of Internationalized Strings (PRECIS) profiles.
 A YANG Model for Network and VPN Service Performance Monitoring
 
 draft-www-bess-yang-vpn-service-pm-06.txt
 Date: 22/04/2020
 Authors: Qin WU, Mohamed Boucadair, Oscar de Dios, Bin Wen, Chang Liu, Honglei Xu
 Working Group: Individual Submissions (none)
 Formats: txt xml
The data model defined in RFC8345 introduces vertical layering relationships between networks that can be augmented to cover network/service topologies. This document defines a YANG model for both Network Performance Monitoring and VPN Service Performance Monitoring that can be used to monitor and manage network performance on the topology at higher layer or the service topology between VPN sites. This model is designed as an augmentation to the network topology YANG data model defined in RFC8345.
 A YANG Data model for ECA Policy Management
 
 draft-wwx-netmod-event-yang-09.txt
 Date: 13/07/2020
 Authors: Andy Bierman, Qin WU, Igor Bryskin, Henk Birkholz, Xufeng Liu, Benoit Claise
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a YANG data model for the Event Condition Action (ECA) policy management. The ECA policy YANG provides the ability to delegate the network management function to the server and control the configuration and monitor state change and take simple and instant action on the server when a trigger condition on the system state is met.
 Pros and Cons of IPv6 Transition Technologies for IPv4aaS
 
 draft-lmhp-v6ops-transition-comparison-05.txt
 Date: 08/07/2020
 Authors: Gabor Lencse, Jordi Martinez, Lee Howard, Richard Patterson, Ian Farrer
 Working Group: Individual Submissions (none)
 Formats: txt xml
Several IPv6 transition technologies have been developed to provide customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only access and/or core network. All these technologies have their advantages and disadvantages, and depending on existing topology, skills, strategy and other preferences, one of these technologies may be the most appropriate solution for a network operator. This document examines the five most prominent IPv4aaS technologies considering a number of different aspects to provide network operators with an easy to use reference to assist in selecting the technology that best suits their needs.
 Benchmarking Methodology for EVPN VPWS
 
 draft-kishjac-bmwg-evpnvpwstest-04.txt
 Date: 06/05/2020
 Authors: sudhin jacob, Kishore Tiruveedhula
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines methodologies for benchmarking EVPN-VPWS performance. EVPN-VPWS is defined in RFC 8214, and is being deployed in Service Provider networks. Specifically this document defines the methodologies for benchmarking EVPN-VPWS Scale convergence, Fail over,Core isolation,high availability and longevity.
 Discovery of OSCORE Groups with the CoRE Resource Directory
 
 draft-tiloca-core-oscore-discovery-06.txt
 Date: 13/07/2020
 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 OSCORE 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 OSCORE groups and to acquire information for joining them through the respective Group Manager. A given OSCORE 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 OSCORE groups based on the ACE framework for Authentication and Authorization in constrained environments.
 The Mercure Protocol
 
 draft-dunglas-mercure-07.txt
 Date: 08/07/2020
 Authors: Kevin Dunglas
 Working Group: Individual Submissions (none)
 Formats: xml html txt
Mercure is a protocol enabling the pushing of data updates to web browsers and other HTTP clients in a fast, reliable and battery- efficient way. It is especially useful for publishing real-time updates of resources served through web APIs to web and mobile apps.
 YANG Model for Transmission Control Protocol (TCP) Configuration
 
 draft-scharf-tcpm-yang-tcp-06.txt
 Date: 10/07/2020
 Authors: Michael Scharf, Vishal Murgai, Mahesh Jethanandani
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies a YANG model for TCP on devices that are configured by network management protocols. The YANG model defines a container for all TCP connections and groupings of some of the parameters that can be imported and used in TCP implementations or by other models that need to configure TCP parameters. The model includes definitions from YANG Groupings for TCP Client and TCP Servers (I-D.ietf-netconf-tcp-client-server). The model is NMDA (RFC 8342) compliant.
 Constrained Join Proxy for Bootstrapping Protocols
 
 draft-vanderstok-anima-constrained-join-proxy-04.txt
 Date: 22/09/2020
 Authors: Michael Richardson, Peter van der Stok, Panos Kampanakis
 Working Group: Individual Submissions (none)
 Formats: xml html txt
This document defines a protocol to securely assign a pledge to an owner, using an intermediary node between pledge and owner. 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 constrained (CoAP) Join Proxy. It transports join traffic from the pledge to the Registrar without requiring per- client state.
 Inband Flow Analyzer
 
 draft-kumar-ippm-ifa-02.txt
 Date: 24/04/2020
 Authors: Jai Kumar, Surendra Anubolu, John Lemon, Rajeev Manur, Hugh Holbrook, Anoop Ghanwani, Dezhong Cai, Heidi Ou, Li Yizhou, Xiaojun Wang
 Working Group: Individual Submissions (none)
 Formats: txt
Inband Flow Analyzer (IFA) records flow specific information from an end station and/or switches across a network. This document discusses the method to collect data on a per hop basis across a network and perform localized or end to end analytics operations on the data. This document also describes a transport-agnostic header definition that may be used for tunneled and non-tunneled flows alike.
 Secure EVPN
 
 draft-sajassi-bess-secure-evpn-03.txt
 Date: 13/07/2020
 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.
 Path Segment for SRv6 (Segment Routing in IPv6)
 
 draft-li-spring-srv6-path-segment-06.txt
 Date: 03/09/2020
 Authors: Cheng Li, Weiqiang Cheng, Mach Chen, Dhruv Dhody, Rakesh Gandhi
 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 sub-paths, called "segments". Segment routing architecture can be implemented over an MPLS data plane as well as an IPv6 data plane. Further, Path Segment has been defined in order to identify an SR path in SR-MPLS networks, and used for various use-cases such as end- to-end SR Path Protection and Performance Measurement (PM) of an SR path. Similar to SR-MPLS, this document defines the Path Segment in SRv6 networks in order to identify an SRv6 path.
 Enhanced Alternate Marking Method
 
 draft-zhou-ippm-enhanced-alternate-marking-05.txt
 Date: 13/07/2020
 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-04.txt
 Date: 25/08/2020
 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-04.txt
 Date: 13/07/2020
 Authors: Zhenbin Li, Shuping Peng, Xuesong Geng, Mahendra Negi
 Working Group: Individual Submissions (none)
 Formats: xml txt
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 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-04.txt
 Date: 13/07/2020
 Authors: Zhenbin Li, Shuping Peng, Xuesong Geng, Mahendra Negi
 Working Group: Individual Submissions (none)
 Formats: xml txt
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/setup/initiated and the label forwarding entries can also be downloaded through a centralized PCE server to each network devices along the P2MP path while leveraging the existing PCE technologies as much as possible. This document specifies the procedures and PCEP protocol extensions for using the PCE as the central controller for P2MP TE LSP.
 BMP for BGP Route Leak Detection
 
 draft-gu-grow-bmp-route-leak-detection-04.txt
 Date: 10/09/2020
 Authors: Yunan Gu, China Telecom, Di Ma, Shunwan Zhuang
 Working Group: Individual Submissions (none)
 Formats: txt xml
According to RFC7908 [RFC7908], Route leaks refer to the case that the delivery range of route advertisements is beyond the expected range. For many current security protection solutions, the ISPs (Internet Service Providers) are focusing on finding ways to prevent the happening of BGP [RFC4271] route leaks. However, the real-time route leak detection if any occurs is important as well, and serves as the basis for leak mitigation. This document extends the BGP Monitoring Protocol (BMP) [RFC7854] to provide a routing security scheme suitable for ISPs to detect BGP route leaks at the prefix level.
 Architecture for Use of BGP as Central Controller
 
 draft-cth-rtgwg-bgp-control-05.txt
 Date: 27/07/2020
 Authors: Yujia Luo, Liang Ou, Xiang Huang, Gyan Mishra, Huaimo Chen, Shunwan Zhuang, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: txt xml
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 Protection
 
 draft-hu-spring-segment-routing-proxy-forwarding-11.txt
 Date: 02/08/2020
 Authors: Zhibo Hu, Huaimo Chen, Junda Yao, Chris Bowers, Yongqing Zhu
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routing Traffic Engineering (SR-TE) supports the creation of explicit paths using segment lists containing adjacency-SIDs, node- SIDs, anycast-SIDs, and binding-SIDs. When the segment list defining an SR-TE path contains a node-SID, and the node fails, the network may no longer be able to properly forward traffic on that SR-TE path. [I-D.ietf-rtgwg-segment-routing-ti-lfa] describes a mechanism that allows local repair actions on the direct neighbors of the failed node to temporarily route traffic to the node immediately following the failed node on the SR-TE path segment list. However, once the IGP shortest paths have converged, the local repair mechanism is no longer sufficient to continue forwarding traffic using the original segment list of the SR-TE path, since the non-neighbors of the failed node will no longer have a route to reach the failed node. This document describes a mechanism that allows traffic to continue to be forwarded on an SR-TE path for an extended period of time after the failure of a node used in the path's segment list.
 EtherType Protocol Identification of In-situ OAM Data
 
 draft-weis-ippm-ioam-eth-04.txt
 Date: 13/05/2020
 Authors: Brian Weis, Frank Brockners, Craig Hill, Shwetha Bhandari, Vengada Govindan, Carlos Pignataro, Hannes Gredler, John Leddy, Stephen Youell, Tal Mizrahi, Aviv Kfir, Barak Gafni, Petr Lapukhov, 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 defines an EtherType that identifies IOAM data fields as being the next protocol in a packet, and a header that encapsulates the IOAM data fields.
 Edge Data Discovery for COIN
 
 draft-mcbride-edge-data-discovery-overview-04.txt
 Date: 13/07/2020
 Authors: Mike McBride, Dirk Kutscher, Eve Schooler, Carlos Bernardos, Diego Lopez
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the problem of distributed data discovery in edge computing, and in particular for computing-in-the-network (COIN), which may require both the marshalling of data at the outset of a computation and the persistence of the resultant data after the computation. Although the data might originate at the network edge, as more and more distributed data is created, processed, and stored, it becomes increasingly dispersed throughout the network. There needs to be a standard way to find it. New and existing protocols will need to be developed to support distributed data discovery at the network edge and beyond.
 Multicast/BIER As A Service
 
 draft-zzhang-bier-multicast-as-a-service-01.txt
 Date: 24/05/2020
 Authors: Zhaohui Zhang, Eric Rosen, Daniel Awduche, Liang Geng
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a framework for providing multicast as a service via Bit Index Explicit Replication (BIER) [RFC7279], and specifies a few enhancements to [draft-ietf-bier-idr-extensions] [RFC8279] [draft-ietf-bier-ospf-bier-extensions] to enable multicast/ BIER as a service.
 AC-Aware Bundling Service Interface in EVPN
 
 draft-sajassi-bess-evpn-ac-aware-bundling-02.txt
 Date: 18/08/2020
 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-04.txt
 Date: 10/07/2020
 Authors: Gunter Van de Velde, Keyur Patel, Zhenbin Li, Huaimo Chen
 Working Group: Individual Submissions (none)
 Formats: 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-13.txt
 Date: 05/10/2020
 Authors: Haoyu Song, Fengwei Qin, Huanan Chen, Jaewhan Jin, Jongyoon Shin
 Working Group: Individual Submissions (none)
 Formats: xml txt
As networks increase in scale and network operations become 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. Emerging on-path telemetry techniques which provide high-precision flow insight and real-time issue notification are required to ensure suitable quality of experience for users and applications, and identify faults or network deficiencies before they become critical. This document outlines a high-level framework to provide an operational environment that utilizes existing and emerging on-path telemetry 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 use the referenced techniques as well as to motivate further work to enhance the ecosystem .
 YANG Data Model for OSPF SRv6
 
 draft-hu-lsr-ospf-srv6-yang-02.txt
 Date: 08/10/2020
 Authors: Zhibo Hu, Xuesong Geng, Kamran Raza, Yingzhen Qu, Acee Lindem
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines a YANG data model that can be used to configure and manage OSPFv3 SRv6 [I-D.ietf-lsr-ospfv3-srv6-extensions].
 Preferred Path Route Graph Structure
 
 draft-ce-lsr-ppr-graph-04.txt
 Date: 28/09/2020
 Authors: Uma Chunduri, Toerless Eckert
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a graph structure for the Preferred Path Route (PPR) for IS-IS, OSPFv2 and OSPFv3 protocols. This structure helps further scale of the PPR and reduce domain level global entries needed in some data planes.
 SRv6 and MPLS interworking
 
 draft-agrawal-spring-srv6-mpls-interworking-03.txt
 Date: 14/08/2020
 Authors: Swadesh Agrawal, Zafar Ali, Clarence Filsfils, Daniel Voyer, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes SRv6 and MPLS/SR-MPLS interworking and co- existence procedures.
 Private Discovery
 
 draft-bradley-dnssd-private-discovery-04.txt
 Date: 02/08/2020
 Authors: Bob Bradley
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies a mechanism for advertising and discovering in a private manner.
 RPKI Route Origin Validation State Unverified
 
 draft-borchert-sidrops-rpki-state-unverified-03.txt
 Date: 09/07/2020
 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-03.txt
 Date: 09/07/2020
 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-03.txt
 Date: 21/05/2020
 Authors: Can Yang, Shiying Pan, Haibo Sun, Kemin Qu, Guoqiang Han
 Working Group: Individual Submissions (none)
 Formats: txt pdf 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.
 Uberlay Interconnection of Multiple LISP overlays
 
 draft-moreno-lisp-uberlay-03.txt
 Date: 03/08/2020
 Authors: Victor Moreno, Dino Farinacci, Alberto Rodriguez-Natal, Marc Portoles-Comeras, Fabio Maino, Sanjay Hooda
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the use of the Locator/ID Separation Protocol (LISP) to interconnect multiple disparate and independent network overlays by using a transit overlay. The transit overlay is referred to as the "uberlay" and provides connectivity and control plane abstraction between different overlays. Each network overlay may use different control and data plane approaches and may be managed by a different organization. Structuring the network into multiple network overlays enables the interworking of different overlay approaches to data and control plane methods. The different network overlays are autonomous from a control and data plane perspective, this in turn enables failure survivability across overlay domains. This document specifies the mechanisms and procedures for the distribution of control plane information across overlay sites and in the uberlay as well as the lookup and forwarding procedures for unicast and multicast traffic within and across overlays. The specification also defines the procedures to support inter-overlay mobility of EIDs and their integration with the intra-overlay EID mobility procedures defined in draft-ietf-lisp-eid-mobility.
 Multiple Layer Resource Optimization for Optical as a Service
 
 draft-multiple-layer-resource-optimization-03.txt
 Date: 02/05/2020
 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-04.txt
 Date: 14/06/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.
 MessageVortex Protocol
 
 draft-gwerder-messagevortexmain-05.txt
 Date: 12/09/2020
 Authors: Martin Gwerder
 Working Group: Individual Submissions (none)
 Formats: pdf xml txt
The MessageVortex (referred to as Vortex) protocol achieves different degrees of anonymity, including sender, receiver, and third-party anonymity, by specifying messages embedded within 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.
 Retransmit bit for SCTP DATA,I-DATA and SACK
 
 draft-proshin-tsvwg-sctp-rtx-bit-03.txt
 Date: 01/06/2020
 Authors: Maksim Proshin
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines a method which helps an SCTP sender to understand when a received SACK acknowledges the original transmission of a TSN or its retransmission. It is done by specifying a new bit, called Retransmit bit (R-bit), in the header of DATA, I-DATA and SACK chunks. The bit is used when a TSN is retransmitted and returned back in the acknowledgement. This document updates [RFC4960] if approved.
 Multicast DF Election for EVPN based on bandwidth or quantity
 
 draft-liu-bess-evpn-mcast-bw-quantity-df-election-02.txt
 Date: 30/06/2020
 Authors: Yisong Liu, Mike McBride, Zheng Zhang
 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.
 Flooding Topology Computation Algorithm
 
 draft-cc-lsr-flooding-reduction-09.txt
 Date: 05/06/2020
 Authors: Huaimo Chen, Mehmet Toy, Yi Yang, Aijun Wang, Xufeng Liu, Yanhe Fan, Lei Liu
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes an algorithm for a node to compute a flooding topology, which is a subgraph of the complete topology per underline physical network. When every node in an area automatically calculates a flooding topology by using a same algorithm and floods the link states using the flooding topology, the amount of flooding traffic in the network is greatly reduced. This would reduce convergence time with a more stable and optimized routing environment.
 The Universal IPv6 Configuration Option
 
 draft-troan-6man-universal-ra-option-03.txt
 Date: 06/10/2020
 Authors: Ole Troan
 Working Group: Individual Submissions (none)
 Formats: txt
One of the original intentions for the IPv6 host configuration, was to configure the network-layer parameters only with IPv6 ND, and use service discovery for other configuration information. Unfortunately that hasn't panned out quite as planned, and we are in a situation where all kinds of configuration options are added to RAs and DHCP. This document proposes a new universal option for RA and DHCP in a self-describing data format, with the list of elements maintained in an IANA registry, with greatly relaxed rules for registration.
 A Light Weight IOAM for SRv6 Network Programming
 
 draft-li-spring-light-weight-srv6-ioam-02.txt
 Date: 03/08/2020
 Authors: Cheng Li, Weiqiang Cheng, Mach Chen, Stefano Previdi, Zhenqiang Li
 Working Group: Individual Submissions (none)
 Formats: txt xml
In-situ OAM(IOAM) records OAM information within the packet while the packet traverses a particular network domain. This document defines a light weight IOAM method for SRv6 network programming. In this method, IOAM information is carried in the data packet by the SIDs in the SRH.
 The practice of NFV decoupling test
 
 draft-long-nfvrg-nfv-decoupling-test-03.txt
 Date: 14/06/2020
 Authors: louie long, Yang Song
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document mainly introduces the practice of NFV decoupling test. Based on the product development situation of the current vendors, the decoupling test is carried out between NFVI&VIM, VNFM&VNF and NFVO. Through a series of tests to explore some of the problems encountered in the current stage of NFV decoupling testing, provide ideas for the subsequent development of NFV products.
 The Multibase Data Format
 
 draft-multiformats-multibase-02.txt
 Date: 18/08/2020
 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-05.txt
 Date: 23/06/2020
 Authors: Manu Sporny, Leonard Rosenthol
 Working Group: Individual Submissions (none)
 Formats: txt xml
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-07.txt
 Date: 14/05/2020
 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 to improve quality of experience. 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.
 Mathematical Mesh 3.0 Part VI: The Trust Mesh
 
 draft-hallambaker-mesh-trust-06.txt
 Date: 27/07/2020
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt html xml
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.
 Benchmarking Methodology for EVPN Multicasting
 
 draft-vikjac-bmwg-evpnmultest-04.txt
 Date: 04/05/2020
 Authors: sudhin jacob, Vikram Nagarajan
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines methodologies for benchmarking IGMP proxy performance over EVPN-VXLAN.IGMP proxy over EVPN is defined in draft-ietf-bess-evpn-IGMP-mld-proxy-02, and is being deployed in data center networks. Specifically this document defines the methodologies for benchmarking IGMP proxy convergence, leave latency Scale,Core isolation, high availability and longevity.
 Resource Discovery in Constrained RESTful Environments (CoRE) using the Constrained RESTful Application Language (CoRAL)
 
 draft-hartke-t2trg-coral-reef-04.txt
 Date: 09/05/2020
 Authors: Klaus Hartke
 Working Group: Individual Submissions (none)
 Formats: txt
This document explores how the Constrained RESTful Application Language (CoRAL) might be used for two use cases in Constrained RESTful Environments (CoRE): CoRE Resource Discovery, which allows a client to discover the resources of a server given a host name or IP address, and CoRE Resource Directory, which provides a directory of resources on many servers.
 Brand Indicators for Message Identification (BIMI)
 
 draft-blank-ietf-bimi-01.txt
 Date: 01/08/2020
 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-02.txt
 Date: 01/08/2020
 Authors: Alexander 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.
 Credentials Provisioning and Management via EAP (EAP-CREDS)
 
 draft-pala-eap-creds-07.txt
 Date: 03/06/2020
 Authors: Massimiliano Pala
 Working Group: Individual Submissions (none)
 Formats: txt xml
With the increase number of devices, protocols, and applications that rely on strong credentials (e.g., digital certificates, keys, or tokens) for network access, the need for a standardized credentials provisioning and management framework is paramount. The 802.1x architecture allows for entities (e.g., devices, applications, etc.) to authenticate to the network by providing a communication channel where different methods can be used to exchange different types of credentials. However, the need for managing these credentials (i.e., provisioning and renewal) is still a hard problem to solve. EAP-CREDS, if implemented in Managed Networks (e.g., Cable Modems), could enable our operators to offer a registration and credentials management service integrated in the home WiFi thus enabling visibility about registered devices. During initialization, EAP- CREDS also allows for MUD files or URLs to be transferred between the EAP Peer and the EAP Server, thus giving detailed visibility about devices when they are provisioned with credentials for accessing the networks. The possibility provided by EAP-CREDS can help to secure home or business networks by leveraging the synergies of the security teams from the network operators thanks to the extended knowledge of what and how is registered/authenticated. This specifications define how to support the provisioning and management of authentication credentials that can be exploited in different environments (e.g., Wired, WiFi, cellular, etc.) to users and/or devices by using EAP together with standard provisioning protocols.
 Performance Measurement Using TWAMP Light for Segment Routing Networks
 
 draft-gandhi-spring-twamp-srpm-10.txt
 Date: 06/08/2020
 Authors: Rakesh Gandhi, Clarence Filsfils, Daniel Voyer, Mach Chen, Bart Janssens
 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 describes procedure for sending and processing probe query and response messages for Performance Measurement (PM) in Segment Routing networks. The procedure uses the messages defined in RFC 5357 (Two-Way Active Measurement Protocol (TWAMP) Light) for Delay Measurement, and uses the messages defined in this document for Loss Measurement. The procedure described is applicable to SR-MPLS and SRv6 data planes and is used for both Links and end-to-end SR Paths including SR Policies.
 Illustrations for SRv6 Network Programming
 
 draft-filsfils-spring-srv6-net-pgm-illustration-03.txt
 Date: 25/09/2020
 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 [I-D.ietf-spring-srv6-network-programming] can be used to create interoperable and protected overlays with underlay optimization and service programming.
 Performance Measurement Using RFC 6374 with UDP Path for Segment Routing Networks
 
 draft-gandhi-spring-rfc6374-srpm-udp-05.txt
 Date: 06/08/2020
 Authors: Rakesh Gandhi, Clarence Filsfils, Daniel Voyer, Stefano Salsano, Mach Chen
 Working Group: Individual Submissions (none)
 Formats: txt xml
Segment Routing (SR) leverages the source routing paradigm. Segment Routing (SR) is applicable to both Multiprotocol Label Switching (SR- MPLS) and IPv6 (SRv6) data planes. This document specifies procedures for using UDP path for sending and processing probe query and response messages for Performance Measurement (PM). The procedure uses the mechanisms defined in RFC 6374 for Performance Delay and Loss Measurement. The procedure specified is applicable to SR-MPLS and SRv6 data planes for both Links and end-to-end SR Paths including SR Policies measurements.
 Mathematical Mesh 3.0 Part II: Uniform Data Fingerprint.
 
 draft-hallambaker-mesh-udf-10.txt
 Date: 27/07/2020
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: xml txt html
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-08.txt
 Date: 27/07/2020
 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.
 Extended Link Relationships
 
 draft-montoya-xrel-02.txt
 Date: 05/05/2020
 Authors: Jose Montoya
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines XREL, a data format for describing extended hypermedia relationships identified by Uniform Resource Locators.
 Profiled Hypertext Application Language
 
 draft-montoya-phtal-01.txt
 Date: 05/05/2020
 Authors: Jose Montoya
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines PHTAL, a generic representation format for hypertext applications guided by REST constraints. PHTAL could be compared to HTML without any graphical objectives.
 The Deprecation HTTP Header Field
 
 draft-dalal-deprecation-header-03.txt
 Date: 13/06/2020
 Authors: Sanjay Dalal, Erik Wilde
 Working Group: Individual Submissions (none)
 Formats: txt xml
The HTTP Deprecation response header field can be used to signal to consumers of a URI-identified resource that the resource has been deprecated. Additionally, the deprecation link relation can be used to link to a resource that provides additional context for the deprecation, and possibly ways in which clients can find a replacement for the deprecated resource.
 The IPv6 Compact Routing Header (CRH)
 
 draft-bonica-6man-comp-rtg-hdr-23.txt
 Date: 06/10/2020
 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.
 The Per-Segment Service Instruction (PSSI) Option
 
 draft-bonica-6man-seg-end-opt-09.txt
 Date: 09/10/2020
 Authors: Ron Bonica
 Working Group: Individual Submissions (none)
 Formats: txt xml
This draft has been withdrawn..
 A One-Path Congestion Metric for IPPM
 
 draft-dang-ippm-congestion-03.txt
 Date: 13/08/2020
 Authors: Joanna Dang, Jianglong Wang, Shinyoung Lee, Hongbo Yan, Liang Cheng
 Working Group: Individual Submissions (none)
 Formats: txt xml
This memo defines a metric for one path congestion across Internet paths. The traditional mode evaluates network congestion based on the bandwidth utilization of the link. However, there is a lack of E2E path congestion that is truly service oriented. So A Path Congestion Metric is required.
 Multi-Path Concurrent Measurement for IPPM
 
 draft-dang-ippm-multiple-path-measurement-05.txt
 Date: 13/08/2020
 Authors: Joanna Dang, Jianglong Wang, Shinyoung Lee, Liang Cheng
 Working Group: Individual Submissions (none)
 Formats: xml txt
This test method can test multi-paths concurrently from one edge node to another edge node. This document details Multi-Path Concurrent Measurement (MPCM).
 Transport parameters for 0-RTT connections
 
 draft-kuhn-quic-0rtt-bdp-07.txt
 Date: 18/05/2020
 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-02.txt
 Date: 18/05/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.
 LOOPS (Localized Optimizations on Path Segments) Problem Statement and Opportunities for Network-Assisted Performance Enhancement
 
 draft-li-tsvwg-loops-problem-opportunities-06.txt
 Date: 13/07/2020
 Authors: Li Yizhou, Xingwang Zhou, Mohamed Boucadair, Jianglong Wang, Fengwei Qin
 Working Group: Individual Submissions (none)
 Formats: txt
In various network deployments, end to end forwarding paths are partitioned into multiple segments. For example, in some cloud-based WAN communications, stitching multiple overlay tunnels are used for traffic policy enforcement matters such as to optimize traffic distribution or to select paths exposing a lower latency. Likewise, in satellite communications, the communication path is decomposed into two terrestrial segments and a satellite segment. Such long- haul paths are naturally composed of multiple network segments with various encapsulation schemes. Packet loss may show different characteristics on different segments. Traditional transport protocols (e.g., TCP) respond to packet loss slowly especially in long-haul networks: they either wait for some signal from the receiver to indicate a loss and then retransmit from the sender or rely on sender's timeout which is often quite long. With the increase of end-to-end transport encryption (e.g., QUIC), traditional PEP (performance enhancing proxy) techniques such as TCP splitting are no longer applicable. LOOPS (Local Optimizations on Path Segments) is a network-assisted performance enhancement over path segment and it aims to provide local in-network recovery to achieve better data delivery by making packet loss recovery faster. In an overlay network scenario, LOOPS can be performed over a variety of the existing, or purposely created, tunnel-based path segments.
 Support for Path MTU (PMTU) in the Path Computation Element (PCE) communication Protocol (PCEP).
 
 draft-li-pce-pcep-pmtu-02.txt
 Date: 23/08/2020
 Authors: Shuping Peng, Cheng Li, Liuyan Han
 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 in IPv6 (SRv6) support in Path Computation Element Communications Protocol (PCEP)
 
 draft-li-pce-pcep-srv6-yang-01.txt
 Date: 07/07/2020
 Authors: Cheng Li, Siva Sivabalan, Shuping Peng, Mike Koldychev, Luc-Fabrice Ndifor
 Working Group: Individual Submissions (none)
 Formats: xml txt
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. 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-08.txt
 Date: 12/07/2020
 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-03.txt
 Date: 28/07/2020
 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-04.txt
 Date: 05/09/2020
 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 for traffic generator and traffic analyzer.
 Considerations for ID/Location Separation Protocols in IPv6-based Vehicular Networks
 
 draft-kjsun-ipwave-id-loc-separation-03.txt
 Date: 15/10/2020
 Authors: Sun Kj, Younghan Kim
 Working Group: Individual Submissions (none)
 Formats: txt xml
ID/Location separation protocols are proposed for scalable routing, enhancing mobility and privacy in IPv6-based vehicular networks. In IPv6-based vehicular networks, ID/Location separation architecture is expected to offer benefits. This document analyzes how ID/Location separation protocols can adjust into IP based vehicular networks and suggests requirements for efficient ID/Location separation in vehicular networks.
 Encapsulation For MPLS Performance Measurement with Alternate Marking Method
 
 draft-cheng-mpls-inband-pm-encapsulation-04.txt
 Date: 08/09/2020
 Authors: Weiqiang Cheng, Xiao Min, Tianran Zhou, Ximing Dong, Yoav Peleg
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines the encapsulation for MPLS performance measurement with alternate marking method, which performs flow-based packet loss, delay, and jitter measurements on live traffic.
 SRv6 Midpoint Protection
 
 draft-chen-rtgwg-srv6-midpoint-protection-03.txt
 Date: 15/10/2020
 Authors: Huanan Chen, Zhibo Hu, Huaimo Chen, Xuesong Geng
 Working Group: Individual Submissions (none)
 Formats: txt xml
The current local repair mechanism, e.g., TI-LFA, allows local repair actions on the direct neighbors of the failed node to temporarily route traffic to the destination. This mechanism could not work properly when the failure happens in the destination point or the link connected to the destination. In SRv6 TE, the IPv6 destination address in the outer IPv6 header could be the dedicated endpoint of the TE path rather than the destination of the TE path. When the endpoint fails, local repair couldn't work on the direct neighbor of the failed endpoint either. This document defines midpoint protection, which enables the direct neighbor of the failed endpoint to do the function of the endpoint, replace the IPv6 destination address to the other endpoint, and choose the next hop based on the new destination address.
 Requirements and Challenges for User-level Service Managements of IoT Network by utilizing Artificial Intelligence
 
 draft-choi-icnrg-aiot-03.txt
 Date: 19/05/2020
 Authors: Junkyun Choi, Jaeseob Han, Gyeong Lee, Na Kim
 Working Group: Individual Submissions (none)
 Formats: txt
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.
 Use of BIER IPv6 Encapsulation (BIERv6) for Multicast VPN in IPv6 networks
 
 draft-xie-bier-ipv6-mvpn-03.txt
 Date: 10/10/2020
 Authors: Jingrong Xie, Mike McBride, Senthil Dhanaraj, Liang Geng, Gyan Mishra
 Working Group: Individual Submissions (none)
 Formats: txt xml
This draft defines the procedures and messages for using Bit Index Explicit Replication (BIER) for Multicast VPN Services in IPv6 networks using the BIER IPv6 encapsulation. It provides a migration path for Multicast VPN service using BIER MPLS encapsulation in MPLS networks to multicast VPN service using BIER IPv6 encapsulation (BIERv6) in IPv6 networks.
 BGP Route Policy and Attribute Trace Using BMP
 
 draft-xu-grow-bmp-route-policy-attr-trace-05.txt
 Date: 26/07/2020
 Authors: Feng Xu, Thomas Graf, Yunan Gu, Shunwan Zhuang, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: txt xml
The generation of BGP adj-rib-in, local-rib or adj-rib-out comes from BGP route exchange and route policy processing. BGP Monitoring Protocol (BMP) provides the monitoring of BGP adj-rib-in [RFC7854], BGP local-rib [I-D.ietf-grow-bmp-local-rib] and BGP adj-rib-out [I-D.ietf-grow-bmp-adj-rib-out]. By monitoring these BGP RIB's the full state of the network is visible, but how route-policies affect the route propagation or changes BGP attributes is still not. This document describes a method of using BMP to record the trace data on how BGP routes are (not) changed under the process of route policies.
 BGP Flow Specification for SRv6
 
 draft-li-idr-flowspec-srv6-03.txt
 Date: 08/06/2020
 Authors: Zhenbin Li, Lei Li, Huaimo Chen, Christoph Loibl, Yanhe Fan, Yongqing Zhu, Xufeng Liu
 Working Group: Individual Submissions (none)
 Formats: txt
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-02.txt
 Date: 03/08/2020
 Authors: Cheng Li, Zhibo Hu
 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.
 Using CBOR Web Tokens (CWTs) in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
 
 draft-tschofenig-tls-cwt-02.txt
 Date: 13/07/2020
 Authors: Hannes Tschofenig, Mathias Brossard
 Working Group: Individual Submissions (none)
 Formats: xml txt
The TLS protocol supports different credentials, including pre-shared keys, raw public keys, and X.509 certificates. For use with public key cryptography developers have to decide between raw public keys, which require out-of-band agreement and full-fletched X.509 certificates. For devices where the reduction of code size is important it is desirable to minimize the use of X.509-related libraries. With the CBOR Web Token (CWT) a structure has been defined that allows CBOR-encoded claims to be protected with CBOR Object Signing and Encryption (COSE). This document registers a new value to the "TLS Certificate Types" sub-registry to allow TLS and DTLS to use CWTs. Conceptually, CWTs can be seen as a certificate format (when with public key cryptography) or a Kerberos ticket (when used with symmetric key cryptography).
 BGP-LS Extensions for Inter-AS TE using EPE based mechanisms
 
 draft-hegde-idr-bgp-ls-epe-inter-as-03.txt
 Date: 02/06/2020
 Authors: Shraddha Hegde, Srihari Sangli, Mukul Srivastava, Xiaohu Xu
 Working Group: Individual Submissions (none)
 Formats: txt xml
In certain network deployments, a single operator has multiple Autonomous Systems(AS) to facilitate ease of management. A multiple AS network design could also be a result of network mergers and acquisitions. In such scenarios, a centralized Inter-domain TE approach could provide most optimal allocation of resources and the most controlled path placement. BGP-LS-EPE [I-D.ietf-idr-bgpls-segment-routing-epe] describes an extension to BGP Link State (BGP-LS) for the advertisement of BGP Peering Segments along with their BGP peering node and inter-AS link information, so that efficient BGP Egress Peer Engineering (EPE) policies and strategies can be computed based on Segment Routing. This document describes extensions to the BGP-LS EPE to enable it to be used for inter-AS Traffic-Engineering (TE) purposes.
 A Connectivity Monitoring Metric for IPPM
 
 draft-geib-ippm-connectivity-monitoring-03.txt
 Date: 03/07/2020
 Authors: Ruediger Geib
 Working Group: Individual Submissions (none)
 Formats: txt xml
Within a Segment Routing domain, segment routed measurement packets can be sent along pre-determined paths. This enables new kinds of measurements. Connectivity monitoring allows to supervise the state and performance of a connection or a (sub)path from one or a few central monitoring systems. This document specifies a suitable type-P connectivity monitoring metric.
 On Media-Types,Content-Types,and related terminology
 
 draft-bormann-core-media-content-type-format-02.txt
 Date: 18/08/2020
 Authors: Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: xml txt html
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-03.txt
 Date: 04/07/2020
 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.
 Deprecation of IKEv1 and obsoleted algorithms
 
 draft-pwouters-ikev1-ipsec-graveyard-05.txt
 Date: 13/07/2020
 Authors: Paul Wouters
 Working Group: Individual Submissions (none)
 Formats: xml txt
Internet Key Exchange version 1 (IKEv1) is deprecated. Accordingly, IKEv1 has been moved to Historic status. A number of old algorithms that are associated with IKEv1, and not widely implemented for IKEv2 are deprecated as well. IANA is instructed to close all IKEv1 registries.
 Autonomic setup of fog monitoring agents
 
 draft-bernardos-anima-fog-monitoring-02.txt
 Date: 18/05/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.
 EVPN Multi-Homing Extensions for Split Horizon Filtering
 
 draft-nr-bess-evpn-mh-split-horizon-03.txt
 Date: 09/09/2020
 Authors: Jorge Rabadan, Kiran Nagaraj, Wen Lin, Ali Sajassi
 Working Group: Individual Submissions (none)
 Formats: txt
Ethernet Virtual Private Network (EVPN) is commonly used along with Network Virtualization Overlay (NVO) tunnels. The EVPN multi-homing procedures may be different depending on the NVO tunnel type used in the EVPN Broadcast Domain. In particular, there are two multi-homing Split Horizon procedures to avoid looped frames on the multi-homed CE: ESI Label based and Local Bias. ESI Label based Split Horizon is used for MPLSoX tunnels, E.g., MPLSoUDP, whereas Local Bias is used for others, E.g., VXLAN tunnels. The current specifications do not allow the operator to decide which Split Horizon procedure to use for tunnel encapsulations that could support both. Examples of tunnels that may support both procedures are MPLSoGRE, MPLSoUDP, GENEVE or SRv6. This document extends the EVPN Multi-Homing procedures so that an operator can decide the Split Horizon procedure for a given NVO tunnel depending on their own requirements.
 In Situ OAM Profiles
 
 draft-mizrahi-ippm-ioam-profile-03.txt
 Date: 05/08/2020
 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.
 Enhanced AS-Loop Detection for BGP
 
 draft-chen-grow-enhanced-as-loop-detection-05.txt
 Date: 10/09/2020
 Authors: Huanan Chen, Di Ma, Yunan Gu, Shunwan Zhuang, Haibo Wang
 Working Group: Individual Submissions (none)
 Formats: xml txt
Misconfiguration and malicious manipulation of BGP AS_Path may lead to route hijack. This document proposes to enhance the BGP [RFC4271] Inbound/ Outbound route processing in the case of detecting an AS loop. It is an enhancement to the current BGP's Inbound/Outbound processing and can be implemented directly on the device, and this document also proposes a centralized usecase. This could empower networks to quickly and accurately figure out they're being victimized. Two options are proposed for the enhancement, a) a local check at the device; b) data collection/analysis at the remote network controller/ server. Both approaches are beneficial for route hijack detection.
 Multi-domain E2E Network Services
 
 draft-lachosrothenberg-alto-md-e2e-ns-02.txt
 Date: 13/07/2020
 Authors: Danny Perez, Christian Rothenberg
 Working Group: Individual Submissions (none)
 Formats: txt
Evolving networking scenarios (e.g., 5G) are considering the provision of value-added and on-demand end-to-end (E2E) network services in multi-domain (multi-operator/multi-technology) environments. This document presents different initiatives, mainly within standardization efforts and research projects, working on E2E network services across multiple domains. Problem statement and a layered network model are also described. In addition, this document raises an initial proposal towards a new ALTO service in support of E2E network service requirements. Finally, another important objective of this document is to begin a discussion about motivating use cases in scope of the ALTO WG after the re-chartering process.
 Time-Based Uni-Directional Attestation
 
 draft-birkholz-rats-tuda-03.txt
 Date: 13/07/2020
 Authors: Andreas Fuchs, Henk Birkholz, Ira McDonald, Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: xml txt
This documents defines the method and bindings used to conduct Time- based Uni-Directional Attestation (TUDA) between two RATS (Remote ATtestation procedureS) entities over the Internet. 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. Conversely, TUDA enables the creation of Secure Audit Logs that can constitute Evidence about current and past operational states of an Attester. Every RATS entity requires access to a trustable and synchronized time-source. A Handle Distributor takes on the corresponding role of a Time Stamp Authority (TSA) to provide Time Stamp Tokens (TST) to all RATS entities.
 SRv6 Implementation and Deployment Status
 
 draft-matsushima-spring-srv6-deployment-status-08.txt
 Date: 16/10/2020
 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.
 Capabilities and Limitations of an Endpoint-only Security Solution
 
 draft-taddei-smart-cless-introduction-03.txt
 Date: 13/07/2020
 Authors: Arnaud Taddei, Candid Wueest, Kevin Roundy, Dominique Lazanski
 Working Group: Individual Submissions (none)
 Formats: txt
In the context of existing, proposed and newly published protocols, this draft RFC is to establish the capabilities and limitations of endpoint-only security solutions and explore benefits and alternatives to mitigate those limits with the support of real case studies.
 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-05.txt
 Date: 10/09/2020
 Authors: Matt Campagna, Eric Crockett
 Working Group: Individual Submissions (none)
 Formats: txt xml pdf
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-03.txt
 Date: 07/05/2020
 Authors: Jaehoon Jeong, 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.
 IS-IS Optimal Distributed Flooding for Dense Topologies
 
 draft-white-distoptflood-04.txt
 Date: 27/07/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.
 Mathematical Mesh 3.0 Part X: Considerations for Quantum Cryptanalysis Resistance
 
 draft-hallambaker-mesh-quantum-02.txt
 Date: 27/07/2020
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: xml txt html
The Mathematical Mesh 'The Mesh' is an infrastructure that facilitates the exchange of configuration and credential data between multiple user devices and provides end-to-end security. This document describes. [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-quantum.html.
 Mathematical Mesh 3.0 Part IX: Considerations for Constrained Devices
 
 draft-hallambaker-mesh-constrained-02.txt
 Date: 27/07/2020
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt html xml
The Mathematical Mesh 'The Mesh' is an infrastructure that facilitates the exchange of configuration and credential data between multiple user devices and provides end-to-end security. This document describes the [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- constrained.html.
 Mathematical Mesh 3.0 Part VIII: Cryptographic Algorithms
 
 draft-hallambaker-mesh-cryptography-06.txt
 Date: 27/07/2020
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt html xml
The Mathematical Mesh 'The Mesh' is an infrastructure that facilitates the exchange of configuration and credential data between multiple user devices and provides end-to-end security. This document describes the cryptographic algorithm suites used in the Mesh and the implementation of Multi-Party Encryption and Multi-Party Key Generation used in the 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- cryptography.html.
 Mathematical Mesh 3.0 Part VII: Security Considerations
 
 draft-hallambaker-mesh-security-05.txt
 Date: 27/07/2020
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt html 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-security.html.
 Mathematical Mesh 3.0 Part V: Protocol Reference
 
 draft-hallambaker-mesh-protocol-06.txt
 Date: 27/07/2020
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml html
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.
 ARP/ND Synching And IP Aliasing without IRB
 
 draft-wang-bess-evpn-arp-nd-synch-without-irb-06.txt
 Date: 04/07/2020
 Authors: Yubao(Bob) Wang, Zheng Zhang
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document proposes an extension to [RFC7432] and [I-D.sajassi-bess-evpn-ip-aliasing] to do ARP synchronizing and IP aliasing for Layer 3 routes that is needed for EVPN signalled L3VPN to build a complete IP ECMP. The phrase "EVPN signalled L3VPN" means that there may be no MAC-VRF or IRB interface in the use case. When there are no MAC-VRF or IRB interface, EVPN signalled L3VPN is also called as "pure L3VPN instance" which is a different usecase from [I-D.sajassi-bess-evpn-ip-aliasing].
 Datagram PLPMTUD for UDP Options
 
 draft-fairhurst-tsvwg-udp-options-dplpmtud-03.txt
 Date: 30/09/2020
 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-06.txt
 Date: 01/06/2020
 Authors: Pascal Thubert
 Working Group: Individual Submissions (none)
 Formats: html xml txt
This document describes how the original IPv6 Neighbor Discovery and Wireless ND (WiND) can be applied on various abstractions of wireless media.
 Using NETCONF over QUIC connection
 
 draft-dai-quic-netconf-02.txt
 Date: 27/04/2020
 Authors: Jinyou Dai, Xueshun Wang, Yang Kou, Lifen Zhou
 Working Group: Individual Submissions (none)
 Formats: txt
The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. At present, almost all implementations of NETCONF are based on TCP based protocol. QUIC, a new UDP-based transport protocol, can facilitate to improve the transportation performance when being used as an infrastructure layer of NETCONF. This document describes how to use the QUIC protocol as the transport protocol of NETCONF (It is so called NETCONFoQUIC).
 WebTransport over QUIC
 
 draft-vvv-webtransport-quic-02.txt
 Date: 30/06/2020
 Authors: Victor Vasiliev
 Working Group: Individual Submissions (none)
 Formats: xml txt
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 QuicTransport, a transport protocol that uses a dedicated QUIC [QUIC] connection and provides support for unidirectional streams, bidirectional streams and datagrams.
 WebTransport over HTTP/3
 
 draft-vvv-webtransport-http3-02.txt
 Date: 30/06/2020
 Authors: Victor Vasiliev
 Working Group: Individual Submissions (none)
 Formats: txt 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 Http3Transport, a WebTransport protocol that is based on HTTP/3 [HTTP3] and provides support for unidirectional streams, bidirectional streams and datagrams, all multiplexed within the same HTTP/3 connection.
 BGP-LS Filters : A Framework for Network Slicing and Enhanced VPNs
 
 draft-drake-bess-enhanced-vpn-04.txt
 Date: 10/08/2020
 Authors: John Drake, Adrian Farrel, Luay Jalil, Avinash Lingala
 Working Group: Individual Submissions (none)
 Formats: xml txt
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 order to support 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.
 Service Oriented Internet Protocol
 
 draft-jiang-service-oriented-ip-03.txt
 Date: 14/05/2020
 Authors: Brian Carpenter, Sheng Jiang, Guangpeng Li
 Working Group: Individual Submissions (none)
 Formats: txt html xml
This document proposes a new, backwards-compatible, approach to packet forwarding, where the service required rather than the IP address required acts as the vector for routing packets at the edge of the network. Deeper in the network, the mechanism can interface to conventional and future methods of service or application aware networking.
 Use of the Walnut Digital Signature Algorithm with CBOR Object Signing and Encryption (COSE)
 
 draft-atkins-suit-cose-walnutdsa-05.txt
 Date: 27/07/2020
 Authors: Derek Atkins
 Working Group: Individual Submissions (none)
 Formats: txt xml
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 constrained16807 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, WalnutDSA 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-03.txt
 Date: 30/08/2020
 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.
 Coordinating Attack Response at Internet Scale 2 (CARIS2) Workshop Report
 
 draft-moriarty-caris2-04.txt
 Date: 09/10/2020
 Authors: Kathleen Moriarty
 Working Group: Individual Submissions (none)
 Formats: xml html txt
The Coordinating Attack Response at Internet Scale (CARIS) 2 workshop, sponsored by the Internet Society, took place 28 February and 1 March 2019 in Cambridge, Massachusetts, USA. Participants spanned regional, national, international, and enterprise CSIRTs, operators, service providers, network and security operators, transport operators and researchers, incident response researchers, vendors, and participants from standards communities. This workshop continued the work started at the first CARIS workshop, with a focus for CARIS 2 scaling incident prevention and detection as the Internet industry moves to a stronger and a more ubiquitous deployment of session encryption.
 Reliable and Available Wireless Technologies
 
 draft-thubert-raw-technologies-05.txt
 Date: 18/05/2020
 Authors: Pascal Thubert, Dave Cavalcanti, Xavier Vilajosana, Corinna Schmitt, Janos Farkas
 Working Group: Individual Submissions (none)
 Formats: xml html txt
This document presents a series of recent technologies that are capable of time synchronization and scheduling of transmission, making them suitable to carry time-sensitive flows with high reliability and availbility.
 LOOPS Generic Information Set
 
 draft-welzl-loops-gen-info-04.txt
 Date: 13/07/2020
 Authors: Michael Welzl, Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: txt html xml
LOOPS (Local Optimizations on Path Segments) aims to provide local (not end-to-end but in-network) recovery of lost packets to achieve better data delivery in the presence of losses. [I-D.li-tsvwg-loops-problem-opportunities] provides an overview over the problems and optimization opportunities that LOOPS could address. The present document is a strawman for the set of information that would be interchanged in a LOOPS protocol, without already defining a specific data packet format. The generic information set needs to be mapped to a specific encapsulation protocol to actually run the LOOPS optimizations. A companion document contains a sketch of a binding to the tunnel encapsulation protocol Geneve [I-D.ietf-nvo3-geneve].
 Asymmetric IPv6 for IoT Networks
 
 draft-jiang-asymmetric-ipv6-03.txt
 Date: 14/05/2020
 Authors: Sheng Jiang, Guangpeng Li, Brian Carpenter
 Working Group: Individual Submissions (none)
 Formats: html xml txt
This document describes a new approach to IPv6 header compression for use in scenarios where minimizing packet size is crucial but routing performance must be maximised.
 ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering
 
 draft-chen-lsr-isis-rfc5316bis-02.txt
 Date: 03/06/2020
 Authors: Mach Chen, Les Ginsberg, Stefano Previdi, Xiaodong Duan
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASs). It defines IS-IS extensions for the flooding of TE information about inter-AS links, which can be used to perform inter-AS TE path computation. No support for flooding information from within one AS to another AS is proposed or defined in this document. This document obsoletes RFC 5316.
 Security Considerations for SRv6 Networks
 
 draft-li-spring-srv6-security-consideration-04.txt
 Date: 09/05/2020
 Authors: Cheng Li, Zhenbin Li, Chongfeng Xie, Hui Tian, Jianwei Mao
 Working Group: Individual Submissions (none)
 Formats: xml txt
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-02.txt
 Date: 26/05/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-02.txt
 Date: 15/06/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-02.txt
 Date: 08/05/2020
 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-02.txt
 Date: 30/06/2020
 Authors: Yisong Liu, Mike McBride, Zheng Zhang
 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.
 IS-IS Flooding Parameters advertisement
 
 draft-decraene-lsr-isis-flooding-speed-04.txt
 Date: 10/06/2020
 Authors: Bruno Decraene, Chris Bowers, Jayesh J, Tony Li, Gunter Van de Velde
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document proposes a mechanism that can be used to increase the speed at which link state information is exchanged between two routers when multiple LSPs need to be flooded, such as in case of a node failure. It also reduces the likelihood of overloading the router receiving the LSPs, causing LSPs losses and delayed retransmission. This document defines a new TLV to be advertised in SNP and/or Hello messages. This TLV may carry a set of parameters indicating the performance capacity to receive LSPs: the number of LSPs which can the received back to back, the minimum delay between further two consecutive LSPs and the minimum delay before retransmission of an LSP.
 Requirement and Solution for Multicast Traffic On-path Telemetry
 
 draft-song-multicast-telemetry-05.txt
 Date: 05/10/2020
 Authors: Haoyu Song, Mike McBride, Greg Mirsky
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document discusses the requirement of on-path telemetry for multicast traffic. The existing solutions are examined and their issues are addressed with modifications adapting to the multicast scenario.
 Deterministic Networking (DetNet) Controller Plane Framework
 
 draft-malis-detnet-controller-plane-framework-04.txt
 Date: 13/07/2020
 Authors: Andrew Malis, Xuesong Geng, Mach Chen, Fengwei Qin, Balazs Varga
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document provides a framework overview for the Deterministic Networking (DetNet) controller plane. It discusses concepts and requirements that will be basis for Detnet controller plane solution documents.
 PCEP Operational Clarification
 
 draft-koldychev-pce-operational-02.txt
 Date: 26/08/2020
 Authors: Mike Koldychev, Siva Sivabalan, Mahendra Negi, 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.
 QUIC for SATCOM
 
 draft-kuhn-quic-4-sat-05.txt
 Date: 29/05/2020
 Authors: Nicolas Kuhn, Gorry Fairhurst, John Border, Stephan Emile
 Working Group: Individual Submissions (none)
 Formats: txt xml
QUIC has been designed for use across Internet paths. Initial designs of QUIC focused on common deployment scenarios for web traffic. This document focuses on the performance when using a path with a large Bandwidth-Delay Product (BDP). A large BDP path can result from using a satellite communication (SATCOM) system. The BDP is also high for paths where a satellite network segment is combined with other network technologies (Ethernet, cable modems, WiFi, cellular, radio links, etc), resulting in more complex characteristics. These path characteristics have implications on the efficiency of the network traffic and unless considered in a design can impact the end-to-end quality of experience by the transport service. This memo identifies the characteristics of a SATCOM link that impact the operation of the QUIC transport protocol. It proposes regression tests to evaluate QUIC over SATCOM links. It discusses how to ensure acceptable protocol performance.
 Carrying SID Algorithm information in PCE-based Networks.
 
 draft-tokar-pce-sid-algo-02.txt
 Date: 02/09/2020
 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.
 The Use of Path Segment in SR Inter-domain Scenarios
 
 draft-xiong-spring-path-segment-sr-inter-domain-02.txt
 Date: 13/07/2020
 Authors: Quan Xiong, Greg Mirsky, Weiqiang Cheng
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document illustrates the inter-domain scenarios for SR-MPLS networks to support end-to-end bidirectional tunnel across multiple domains with the use of Path Segments.
 The Use of Path Segment in SR-MPLS and MPLS Interworking
 
 draft-xiong-mpls-path-segment-sr-mpls-interworking-02.txt
 Date: 13/07/2020
 Authors: Quan Xiong, Greg Mirsky, Weiqiang Cheng
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document illustrates the SR-MPLS and MPLS interworking scenarios to support end-to-end bidirectional tunnel across multiple domains with the use of Path Segments.
 Advertising L2 Bundle Member Link Attributes in OSPF
 
 draft-ketant-lsr-ospf-l2bundles-02.txt
 Date: 30/06/2020
 Authors: Ketan Talaulikar, Peter Psenak
 Working Group: Individual Submissions (none)
 Formats: txt
There are deployments where the Layer 3 interface on which OSPF operates is a Layer 2 interface bundle. Existing OSPF advertisements only support advertising link attributes of the Layer 3 interface. If entities external to OSPF wish to control traffic flows on the individual physical links which comprise the Layer 2 interface bundle link attribute information about the bundle members is required. This document introduces the ability for OSPF to advertise the link attributes of layer 2 (L2) Bundle members.
 RAW use cases
 
 draft-bernardos-raw-use-cases-04.txt
 Date: 13/07/2020
 Authors: Georgios Papadopoulos, Pascal Thubert, Fabrice Theoleyre, Carlos Bernardos
 Working Group: Individual Submissions (none)
 Formats: txt
The wireless medium presents significant specific challenges to achieve properties similar to those of wired deterministic networks. At the same time, a number of use cases cannot be solved with wires and justify the extra effort of going wireless. This document presents wireless use cases demanding reliable and available behavior.
 Operations,Administration and Maintenance (OAM) features for RAW
 
 draft-theoleyre-raw-oam-support-03.txt
 Date: 10/07/2020
 Authors: Fabrice Theoleyre, Georgios Papadopoulos, Greg Mirsky
 Working Group: Individual Submissions (none)
 Formats: txt xml
Some critical applications may use a wireless infrastructure. However, wireless networks exhibit a bandwidth of several orders of magnitude lower than wired networks. Besides, wireless transmissions are lossy by nature; the probability that a packet cannot be decoded correctly by the receiver may be quite high. In these conditions, guaranteeing the network infrastructure works properly is particularly challenging, since we need to address some issues specific to wireless networks. This document lists the requirements of the Operation, Administration, and Maintenance (OAM) features recommended to construct a predictable communication infrastructure on top of a collection of wireless segments. This document describes the benefits, problems, and trade-offs for using OAM in wireless networks to achieve Service Level Objectives (SLO).
 Using GOST ciphers in ESP and IKEv2
 
 draft-smyslov-esp-gost-03.txt
 Date: 03/05/2020
 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).
 OAM for use in GENEVE
 
 draft-mmbb-nvo3-geneve-oam-04.txt
 Date: 25/09/2020
 Authors: Greg Mirsky, Sami Boutros, David Black, Santosh Pallagatti
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document lists a set of general requirements for active OAM protocols in the Geneve overlay network. Based on the requirements, IP encapsulation for active Operations, Administration, and Maintenance protocols in Geneve protocol is defined. Considerations for using ICMP and UDP-based protocols are discussed.
 BMP Extension for Path Status TLV
 
 draft-cppy-grow-bmp-path-marking-tlv-06.txt
 Date: 23/09/2020
 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].
 Observe Notifications as CoAP Multicast Responses
 
 draft-tiloca-core-observe-multicast-notifications-03.txt
 Date: 13/07/2020
 Authors: Marco Tiloca, Rikard Hoeglund, Christian Amsuess, Francesca Palombini
 Working Group: Individual Submissions (none)
 Formats: txt
The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server, and receive notifications as unicast responses upon changes of the resource state. In some use cases, such as based on publish-subscribe, it would be convenient for the server to send a single notification to all the clients observing a same target resource. This document defines how a CoAP server sends observe notifications as response messages over multicast, by synchronizing all the observers of a same resource on a same shared Token value. Besides, this document defines how Group OSCORE can be used to protect multicast notifications end-to-end from the CoAP server to the multiple observer clients.
 Group OSCORE Profile of the Authentication and Authorization for Constrained Environments Framework
 
 draft-tiloca-ace-group-oscore-profile-03.txt
 Date: 13/07/2020
 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 public key. Also, it provides proof of 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.
 IS-IS Extensions to Support Transport Network Slices using Segment Routing
 
 draft-zch-lsr-isis-network-slicing-06.txt
 Date: 04/09/2020
 Authors: Yongqing Zhu, Ran Chen, Shaofu Peng, Fengwei Qin
 Working Group: Individual Submissions (none)
 Formats: txt
[I-D.nsdt-teas-ns-framework] provides a framework of transport slices. This draft describes the IS-IS extensions required to support transport slices using Segment Routing.
 SR Path Ingress Protection
 
 draft-chen-idr-sr-ingress-protection-02.txt
 Date: 30/04/2020
 Authors: Huaimo Chen, Mehmet Toy, Aijun Wang, Zhenqiang Li, Lei Liu, Xufeng Liu
 Working Group: Individual Submissions (none)
 Formats: txt
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-03.txt
 Date: 30/04/2020
 Authors: Huaimo Chen, Mehmet Toy, Aijun Wang, Zhenqiang Li, Lei Liu, Xufeng Liu
 Working Group: Individual Submissions (none)
 Formats: 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.
 A method for dots server deployment
 
 draft-chen-dots-server-hierarchical-deployment-03.txt
 Date: 24/06/2020
 Authors: chenmeiling, Li Su
 Working Group: Individual Submissions (none)
 Formats: xml txt
As DOTS is used for DDoS Mitigation signaling, there are different deployment scenarios for DOTS agents deployment depending on the network topology. This document made recommandations for DOTS Server deployment, include ISP and enterprise deployment scenarios. The goal is to provide some guidance for DOTS agents deployment.
 BIER Source Protection
 
 draft-zhang-bier-source-protection-01.txt
 Date: 13/07/2020
 Authors: Zheng Zhang, Greg Mirsky, Quan Xiong, Yisong Liu
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the multicast source protection functions in Bit Index Explicit Replication BIER domain.
 Test Tools for IoT DDoS vulnerability scanning
 
 draft-faibish-iot-ddos-usecases-03.txt
 Date: 30/06/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.
 SRv6 and MPLS interworking for VPN service
 
 draft-pzm-spring-interdomain-vpn-02.txt
 Date: 13/08/2020
 Authors: Zheng Zhang, Shaofu Peng, Greg Mirsky, Yubao Wang
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes a method to achieve an inter-domain connection for a VPN (Virtual Private Network) service.
 BFD for Geneve
 
 draft-xiao-nvo3-bfd-geneve-03.txt
 Date: 09/07/2020
 Authors: Xiao Min, Greg Mirsky, Santosh Pallagatti, Jeff Tantsura
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol in point-to-point Generic Network Virtualization Encapsulation (Geneve) tunnels used to make up an overlay network.
 Requirement of Computing in network
 
 draft-liu-coinrg-requirement-03.txt
 Date: 12/07/2020
 Authors: Peng Liu, Liang Geng
 Working Group: Individual Submissions (none)
 Formats: xml txt
New technology such as IOT, edge computing,etc. propose the requirement of computing in network, so the convergence of network and computing has become a trend. It will bring some new directions and areas to be considered, such as the relationship between network and computing, the influence of integrating computing to the network, and so on. This document points out the requirements of computing in network according to the development of new Industry, including the network and computing requirements.
 SRv6 for Deterministic Networking (DetNet)
 
 draft-geng-spring-srv6-for-detnet-01.txt
 Date: 13/07/2020
 Authors: Xuesong Geng, Zhenbin Li, Mach Chen
 Working Group: Individual Submissions (none)
 Formats: txt xml
Deterministic Networking provides service with low jitter, bounded latency and low loss rate, using technologies of explicit route, resource reservation and service protection.This document specifies how to implement Deterministic Networking (DetNet) in a SRv6 Network.
 Distributed SFC control for fog environments
 
 draft-bernardos-sfc-distributed-control-02.txt
 Date: 26/07/2020
 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.
 Endpoint Taxonomy for CLESS
 
 draft-mcfadden-smart-endpoint-taxonomy-for-cless-02.txt
 Date: 13/07/2020
 Authors: Mark McFadden
 Working Group: Individual Submissions (none)
 Formats: txt
A separate document [I-D:draft-taddei-smart-cless-introduction] (CLESS) attempts to establish the capabilities and limitations of endpoint-only security solutions and explore potential alternative approaches. That document discusses endpoints in general terms. It has been suggested that there are classes of endpoints that have different characteristics. Those classes may have completely different threat landscapes and the endpoints may have completely different security capabilities. In support of the work on CLESS, this document provides a taxonomy of endpoints that is intended to provide a foundation for further work on CLESS and research on approaches to providing endpoint security alternatives in a diverse group of settings.
 Encapsulation of Path Segment in SRv6
 
 draft-li-6man-srv6-path-segment-encap-03.txt
 Date: 03/09/2020
 Authors: Cheng Li, Weiqiang Cheng, Zhenbin Li, Dhruv Dhody
 Working Group: Individual Submissions (none)
 Formats: txt xml
Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of sub-paths, called "segments". Segment routing architecture can be implemented over IPv6 data plane, called SRv6. In some use-cases such as end-to-end SR Path Protection and Performance Measurement (PM), SRv6 path need to be identified. This document defines the encoding and processing of Path Segment in SRv6 networks.
 BGP Request for Candidate Paths of SR TE Policies
 
 draft-li-ldr-bgp-request-cp-sr-te-policy-02.txt
 Date: 03/10/2020
 Authors: Zhenbin Li, Lei Li, Huaimo Chen, Yanhe Fan, Xufeng Liu, Lei Liu
 Working Group: Individual Submissions (none)
 Formats: xml txt
An SR Policy is a set of candidate paths. The headend of an SR Policy may learn multiple candidate paths for an SR Policy via a number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP. This document defines extensions to BGP for the headend to request BGP speaker (controller) for advertising the candidate paths.
 Application-aware IPv6 Networking (APN6) Encapsulation
 
 draft-li-6man-app-aware-ipv6-network-02.txt
 Date: 02/07/2020
 Authors: Zhenbin Li, Shuping Peng, Cong Li, Chongfeng Xie, Daniel 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 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-07.txt
 Date: 19/05/2020
 Authors: Clarence Filsfils, Pablo Camarillo, Dezhong Cai, Daniel 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
 Multicast in L3VPNs Signaled by EVPN SAFI
 
 draft-zzhang-bess-mcast-in-evpn-signaled-l3vpn-01.txt
 Date: 13/10/2020
 Authors: Zhaohui Zhang, Wen Lin, Jorge Rabadan
 Working Group: Individual Submissions (none)
 Formats: txt
[ietf-bess-evpn-prefix-advertisement] specifies an EVPN SAFI Type-5 route that can be used to signal L3VPNs. This document specifies procedures for multicast in such an L3VPN.
 Multicast Routing In Fat Trees
 
 draft-zzhang-rift-multicast-01.txt
 Date: 13/07/2020
 Authors: Zhaohui Zhang, Pascal Thubert
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies multicast procedures with RIFT. Multicast in RIFT is similar to Bidirectional Protocol Independent Multicast (PIM- Bidir), with the Rendezvous Point Link (RP-Link) simulated by a spanning tree of some Top of Fabric (TOF) nodes and sub-TOF nodes.
 DoH Preference Hints for HTTP
 
 draft-schinazi-httpbis-doh-preference-hints-02.txt
 Date: 13/07/2020
 Authors: David Schinazi, Nick Sullivan, Jesse Kipp
 Working Group: Individual Submissions (none)
 Formats: html xml txt
When using a publicly available DNS-over-HTTPS (DoH) server, some clients may suffer poor performance when the authoritative DNS server is located far from the DoH server. For example, a publicly available DoH server provided by a Content Delivery Network (CDN) should be able to resolve names hosted by that CDN with good performance but might take longer to resolve names provided by other CDNs, or might provide suboptimal results if that CDN is using DNS- based load balancing and returns different address records depending or where the DNS query originated from. This document attempts to lessen these issues by allowing the web server to indicate to the client which DoH server can best resolve its addresses. This document defines an HTTP header field that enables web host operators to inform user agents of the preferred DoH servers to use for subsequent DNS lookups for the host's domain. Discussion of this work is encouraged to happen on the ADD IETF mailing list add@ietf.org or on the GitHub repository which contains the draft: https://github.com/DavidSchinazi/draft-httpbis-doh- preference-hints.
 Yang Data Model for SRv6 based Services
 
 draft-raza-bess-srv6-services-yang-01.txt
 Date: 13/07/2020
 Authors: Kamran Raza, Bruno Decraene, Zhichun Jiang, Satoru Matsushima, Kausik Majumdar
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a YANG data model that can be used to configure and manage SRv6 based services in BGP. The YANG module in this document conforms to the Network Management Datastore Architecture (NMDA).
 Packet Loss Signaling for Encrypted Protocols
 
 draft-ferrieuxhamchaoui-tsvwg-lossbits-03.txt
 Date: 28/07/2020
 Authors: Alexandre Ferrieux, Isabelle Hamchaoui, Igor Lubashev, Dmitri Tikhonov
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes a protocol-independent method that employs two bits to allow endpoints to signal packet loss in a way that can be used by network devices to measure and locate the source of the loss. The signaling method applies to all protocols with a protocol- specific way to identify packet loss. The method is especially valuable when applied to protocols that encrypt transport header and do not allow an alternative method for loss detection.
 Describing Protocol Data Units with Augmented Packet Header Diagrams
 
 draft-mcquistin-augmented-ascii-diagrams-06.txt
 Date: 13/07/2020
 Authors: Stephen McQuistin, Vivian Band, Dejice Jacob, Colin Perkins
 Working Group: Individual Submissions (none)
 Formats: xml html 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.
 Operational Considerations for use of DNS in IoT devices
 
 draft-richardson-opsawg-mud-iot-dns-considerations-03.txt
 Date: 22/09/2020
 Authors: Michael Richardson
 Working Group: Individual Submissions (none)
 Formats: txt html xml
This document details concerns about how Internet of Things devices use IP addresses and DNS names. The issue becomes acute as network operators begin deploying RFC8520 Manufacturer Usage Description (MUD) definitions to control device access. This document explains the problem through a series of examples of what can go wrong, and then provides some advice on how a device manufacturer can best make deal with these issues. The recommendations have an impact upon device and network protocol design. {RFC-EDITOR, please remove. Markdown and issue tracker for this document is at https://github.com/mcr/iot-mud-dns-considerations.git }
 HTTP Transport Authentication
 
 draft-schinazi-httpbis-transport-auth-04.txt
 Date: 09/09/2020
 Authors: David Schinazi
 Working Group: Individual Submissions (none)
 Formats: xml html txt
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.
 Segment Routing Generic TLV for MPLS Label Switched Path (LSP) Ping/ Traceroute
 
 draft-nainar-mpls-spring-lsp-ping-sr-generic-sid-03.txt
 Date: 28/04/2020
 Authors: Nagendra Nainar, Carlos Pignataro, Zafar Ali, Clarence Filsfils, Tarek Saad
 Working Group: Individual Submissions (none)
 Formats: txt
RFC8402 introduces Segment Routing architecture that leverages source routing and tunneling paradigms and can be directly applied to the Multi Protocol Label Switching (MPLS) data plane. A node steers a packet through a controlled set of instructions called segments, by prepending the packet with Segment Routing header. SR architecture defines different types of segments with different forwarding semantics associated. SR can be applied to the MPLS directly and to IPv6 dataplane using a new routing header. 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. Various SIDs are proposed as part of SR architecture with different associated instructions that raises a need to come up with new Target FEC Stack Sub-TLV for each such SIDs. This document defines a new Target FEC Stack Sub-TLV that is used to validate the instruction associated with any SID.
 EVPN Interoperability Modes
 
 draft-krattiger-evpn-modes-interop-02.txt
 Date: 27/07/2020
 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.
 5G Wireless Wireline Convergence User Plane Encapsulation (5WE)
 
 draft-allan-5g-fmc-encapsulation-07.txt
 Date: 01/10/2020
 Authors: Dave Allan, Donald Eastlake, David Woolley
 Working Group: Individual Submissions (none)
 Formats: txt
As part of providing wireline access to the 5G Core (5GC), deployed wireline networks carry user data between 5G residential gateways and the 5G Access Gateway Function (AGF). The encapsulation method specified in this document supports the multiplexing of traffic for multiple PDU sessions within a VLAN delineated access circuit, permits legacy equipment in the data path to inspect certain packet fields, carries 5G QoS information associated with the packet data, and provides efficient encoding. It achieves this by specific points of similarity with the RFC 2516 PPPoE data packet encapsulation.
 Indication of Local DNS Privacy Service During User Access
 
 draft-yan-dprive-local-service-indication-03.txt
 Date: 28/07/2020
 Authors: Zhiwei Yan, Guanggang Geng, Yang Liu, Xinchang Zhang
 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-04.txt
 Date: 12/08/2020
 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-04.txt
 Date: 31/08/2020
 Authors: Shaofu Peng, Quan Xiong, Fengwei Qin
 Working Group: Individual Submissions (none)
 Formats: 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, specific application, color template and FA-id etc.
 Software Version Capability for BGP
 
 draft-abraitis-bgp-version-capability-08.txt
 Date: 29/08/2020
 Authors: Donatas Abraitis
 Working Group: Individual Submissions (none)
 Formats: xml txt
In this document, we introduce a new BGP capability that allows the advertisement of a BGP speaker's routing daemon version. This BGP capability is an optional advertisement. Implementations are not required to advertise the version nor to process received advertisements.
 Maintaining CCNx or NDN flow balance with highly variable data object sizes
 
 draft-oran-icnrg-flowbalance-04.txt
 Date: 24/08/2020
 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.
 Extensible Provisioning Protocol (EPP) Industrial Internet Identifier Mapping
 
 draft-chen-epp-identifier-mapping-03.txt
 Date: 18/08/2020
 Authors: Yuying Chen, Jiagui Xie, Zhiping Li, Zhipeng Fan
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes an Extensible Provisioning Protocol (EPP)mapping for the provisioning and management of Industrial Internet Identifiers. Specified in XML, the mapping defines EPP command syntax and semantics as applied to identifiers.
 Support for Data Reduction Attributes in nfsv4 Version 2
 
 draft-faibish-nfsv4-data-reduction-attributes-03.txt
 Date: 24/06/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.
 How Requests for IANA Action Will be Handled on the Independent Stream
 
 draft-ise-iana-policy-03.txt
 Date: 23/09/2019
 Authors: Adrian Farrel
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Internet Assigned Numbers Authority (IANA) maintains registries to track codepoints used by protocols such as those defined by the IETF and documented in RFCs developed on the IETF Stream. The Independent Submissions Stream is another source of documents that can be published as RFCs. This stream is under the care of the Independent Submissions Editor (ISE). This document complements RFC 4846 by providing a description of how the ISE currently handles documents in the Independent Submissions Stream that request actions from the IANA. Nothing in this document changes existing IANA registries or their allocation policies, nor does it change any previously documented processes.
 YANG Data Model for OSPFv3 Segment Routing
 
 draft-acee-lsr-ospfv3-sr-yang-02.txt
 Date: 02/08/2020
 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 dataplane.
 ShangMi (SM) Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3
 
 draft-yang-tls-tls13-sm-suites-06.txt
 Date: 27/09/2020
 Authors: Paul Yang
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies how to use the ShangMi (SM) cryptographic algorithms with Transport Layer Security (TLS) protocol version 1.3. The use of these algorithms with TLSv1.3 is not endorsed by the IETF. The SM algorithms are becoming mandatory in China, and so this document provides a description of how to use the SM algorithms with TLSv1.3 and specifies a profile of TLSv1.3 so that implementers can produce interworking implementations.
 Commercial National Security Algorithm (CNSA) Suite Profile for TLS and DTLS 1.2 and 1.3
 
 draft-cooley-cnsa-dtls-tls-profile-06.txt
 Date: 16/09/2020
 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-01.txt
 Date: 08/05/2020
 Authors: Aaron Parecki
 Working Group: Individual Submissions (none)
 Formats: txt xml
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.
 YANG Data Model for Dynamic Flooding
 
 draft-dontula-lsr-yang-dynamic-flooding-04.txt
 Date: 28/09/2020
 Authors: Srinath Dontula, Tony Li, Athar Siddiqui
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines YANG data models that can be used to configure and manage Dynamic Flooding for IS-IS and OSPF.
 RateLimit Header Fields for HTTP
 
 draft-polli-ratelimit-headers-03.txt
 Date: 26/05/2020
 Authors: Roberto Polli, Alejandro Ruiz
 Working Group: Individual Submissions (none)
 Formats: xml txt html
This document defines the RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset header fields for HTTP, thus allowing servers to publish current request quotas and clients to shape their request policy and avoid being throttled out.
 BRSKI Cloud Registrar
 
 draft-friel-anima-brski-cloud-03.txt
 Date: 24/09/2020
 Authors: Owen Friel, Rifaat Shekh-Yusef, Michael Richardson
 Working Group: Individual Submissions (none)
 Formats: txt html xml
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
 Automatic Peering for SIP Trunks
 
 draft-kinamdar-dispatch-sip-auto-peer-03.txt
 Date: 05/05/2020
 Authors: Kaustubh Inamdar, Sreekanth Narayanan, Cullen Jennings
 Working Group: Individual Submissions (none)
 Formats: txt
This draft specifies a configuration workflow to enable enterprise Session Initiation Protocol (SIP) networks to solicit the capability set of a SIP service provider network. The capability set can subsequently be used to configure features and services on the enterprise edge element, such as a Session Border Controller (SBC), to ensure smooth peering between enterprise and service provider networks.
 Hierarchical HITs for HIPv2
 
 draft-moskowitz-hip-hierarchical-hit-05.txt
 Date: 13/05/2020
 Authors: Robert Moskowitz, Stuart Card, Adam Wiethuechter
 Working Group: Individual Submissions (none)
 Formats: txt html xml
This document describes using a hierarchical HIT to facilitate large deployments of managed devices. Hierarchical HITs differ from HIPv2 flat HITs by only using 64 bits for mapping the Host Identity, freeing 32 bits to bind in a hierarchy of Registering Entities that provide services to the consumers of hierarchical HITs.
 New Cryptographic Algorithms for HIP
 
 draft-moskowitz-hip-new-crypto-05.txt
 Date: 26/07/2020
 Authors: Robert Moskowitz, Stuart Card, Adam Wiethuechter
 Working Group: Individual Submissions (none)
 Formats: txt xml 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.
 A YANG Module for uCPE management.
 
 draft-shytyi-opsawg-vysm-08.txt
 Date: 18/05/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-03.txt
 Date: 13/07/2020
 Authors: Clarence Filsfils, Pablo Camarillo, John Leddy, Daniel 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.
 Link Local Next Hop Handling for BGP
 
 draft-white-linklocalnh-01.txt
 Date: 17/06/2020
 Authors: Russ White, Donald Sharp, Dinesh Dutt, Biswajit Sadhu, Jeff Tantsura
 Working Group: Individual Submissions (none)
 Formats: txt xml
BGP, described in [RFC4271], was originally designed to provide reachability between domains and between the edges of a domain. As such, BGP assumes the next hop towards any reachable destination may not reside on the advertising speaker, but rather may either be through a router connected to the same subnet as the speaker, or through a router only reachable by traversing multiple hops through the network. Because of this, BGP does not recognize the use of IPv6 link local addresses, as described in [RFC4291], as a valid next hop for forwarding purposes. However, BGP speakers are now often deployed on point-to-point links in networks where multihop reachability of any kind is not assumed or desired (all next hops are assumed to be the speaker reachable through a directly connected point-to-point link). This is common, for instance, in data center fabrics. In these situations, a global IPv6 address is not required for the advertisement of reachability information; in fact, providing global IPv6 addresses in these kinds of networks can be detrimental to Zero Touch Provisioning (ZTP). This draft standardizes the operation of BGP over a point-to-point link using link local IPv6 addressing only.
 Oblivious DNS Over HTTPS
 
 draft-pauly-dprive-oblivious-doh-02.txt
 Date: 09/10/2020
 Authors: Eric Kinnear, Patrick McManus, Tommy Pauly, Christopher Wood
 Working Group: Individual Submissions (none)
 Formats: xml txt html
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.
 In-Flight IPv6 Extension Header Insertion Considered Harmful
 
 draft-smith-6man-in-flight-eh-insertion-harmful-02.txt
 Date: 30/05/2020
 Authors: Mark Smith, Naveen Kottapalli, Ron Bonica, Fernando Gont, Tom Herbert
 Working Group: Individual Submissions (none)
 Formats: xml txt
In the past few years, as well as currently, there have and are a number of proposals to insert IPv6 Extension Headers into existing IPv6 packets while in-flight. This contradicts explicit prohibition of this type of IPv6 packet proccessing in the IPv6 standard. This memo describes the possible failures that can occur with EH insertion, the harm they can cause, and the existing model that is and should continue to be used to add new information to an existing IPv6 and other packets.
 Quick and Dirty Secure Autonomic Control Plane for GRASP
 
 draft-carpenter-anima-quads-grasp-03.txt
 Date: 28/06/2020
 Authors: Brian Carpenter
 Working Group: Individual Submissions (none)
 Formats: txt html xml
A secure substrate known as the Autonomic Control Plane (ACP) is required by the Generic Autonomic Signaling Protocol (GRASP) used by Autonomic Service Agents. This document describes QUADS, a QUick And Dirty Secure ACP using symmetric cryptography and preconfigured keys or passwords. It also describes a simplistic QUADS Key Infrastructure based on asymmetric cryptography used over insecure instances of GRASP to create a QUADS ACP.
 Alternative Approach for Mixing Preshared Keys in IKEv2 for Post-quantum Security
 
 draft-smyslov-ipsecme-ikev2-qr-alt-02.txt
 Date: 03/08/2020
 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-03.txt
 Date: 13/09/2020
 Authors: Rakesh Gandhi, Zafar Ali, Clarence Filsfils, Frank Brockners, Bin Wen, Voitek Kozak
 Working Group: Individual Submissions (none)
 Formats: txt xml
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 using the MPLS data plane encapsulation, including Segment Routing (SR) with MPLS data plane (SR-MPLS).
 Path Steering in CCNx and NDN
 
 draft-oran-icnrg-pathsteering-01.txt
 Date: 23/04/2020
 Authors: Ilya Moiseenko, David Oran
 Working Group: Individual Submissions (none)
 Formats: html txt xml
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.
 Using QUIC Datagrams with HTTP/3
 
 draft-schinazi-quic-h3-datagram-05.txt
 Date: 12/10/2020
 Authors: David Schinazi
 Working Group: Individual Submissions (none)
 Formats: xml txt html
The QUIC DATAGRAM extension provides application protocols running over QUIC with a mechanism to send unreliable data while leveraging the security and congestion-control properties of QUIC. However, QUIC DATAGRAM frames do not provide a means to demultiplex application contexts. This document defines how to use QUIC DATAGRAM frames when the application protocol running over QUIC is HTTP/3 by adding an identifier at the start of the frame payload. Discussion of this work is encouraged to happen on the QUIC IETF mailing list (quic@ietf.org (mailto:quic@ietf.org)) or on the GitHub repository which contains the draft: https://github.com/DavidSchinazi/draft-h3-datagram.
 ACME for Subdomains
 
 draft-friel-acme-subdomains-03.txt
 Date: 09/10/2020
 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 fulfil 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-01.txt
 Date: 02/05/2020
 Authors: Prakash Jain, Victor Moreno, Sanjay Hooda
 Working Group: Individual Submissions (none)
 Formats: xml txt
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-03.txt
 Date: 26/07/2020
 Authors: Aijun Wang, Zhibo Hu, Yaqun Xiao
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the mechanism that can be used to announce the unreachable prefixes for service fast convergence.
 SRv6 and MPLS interworking for VPN service
 
 draft-pzm-bess-spring-interdomain-vpn-02.txt
 Date: 14/08/2020
 Authors: Zheng Zhang, Shaofu Peng, Greg Mirsky, Yubao Wang
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes a method to achieve an inter-domain connection for a VPN (Virtual Private Network) service.
 Lzip Compressed Format and the application/lzip Media Type
 
 draft-diaz-lzip-01.txt
 Date: 24/04/2020
 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 (de)compression. 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-04.txt
 Date: 12/09/2020
 Authors: Marc Petit-Huguenin
 Working Group: Individual Submissions (none)
 Formats: html txt xml
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.
 Using GOST R 34.10-2012 and GOST R 34.11-2012 algorithms with the Internet X.509 Public Key Infrastructure
 
 draft-deremin-rfc4491-bis-06.txt
 Date: 22/05/2020
 Authors: Dmitry Eremin-Solenikov, Vasily Nikolaev, Aleksandr Chelpanov
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes encoding formats, identifiers, and parameter formats for the algorithms GOST R 34.10-2012 and GOST R 34.11-2012 for use in Internet X.509 Public Key Infrastructure (PKI).
 GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3
 
 draft-smyshlyaev-tls13-gost-suites-02.txt
 Date: 16/06/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.
 In-situ OAM Deployment
 
 draft-brockners-opsawg-ioam-deployment-02.txt
 Date: 07/09/2020
 Authors: Frank Brockners, Shwetha Bhandari, daniel.bernier@bell.ca
 Working Group: Individual Submissions (none)
 Formats: txt xml
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 provides a framework for IOAM deployment and provides best current practices.
 Use Cases and Requirements for Web Packages
 
 draft-yasskin-wpack-use-cases-01.txt
 Date: 27/07/2020
 Authors: Jeffrey Yasskin
 Working Group: Individual Submissions (none)
 Formats: txt xml html
This document lists use cases for signing and/or bundling collections of web pages, and extracts a set of requirements from them. Note to Readers Discussion of this draft takes place on the ART area mailing list (art@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=art (https://mailarchive.ietf.org/arch/search/?email_list=art). The source code and issues list for this draft can be found in https://github.com/WICG/webpackage (https://github.com/WICG/ webpackage).
 Internet Services over ICN in 5G LAN Environments
 
 draft-trossen-icnrg-internet-icn-5glan-04.txt
 Date: 01/10/2020
 Authors: Dirk Trossen, Sebastian Robitzsch, University Essex, Mays AL-Naday, Janne Riihijarvi
 Working Group: Individual Submissions (none)
 Formats: txt xml
In this draft, we provide architecture and operations for enabling Internet services over ICN over (5G-enabled) LAN environments. Operations include ICN API to upper layers, HTTP over ICN, Service Proxy Operations, ICN Flow Management, Name Resolution, Mobility Handling, and Dual Stack Device Support.
 Compressed Routing Header (CRH) Helper Option
 
 draft-bonica-6man-crh-helper-opt-01.txt
 Date: 04/05/2020
 Authors: Xing Li, Congxiao Bao, Eddie Ruan, Ron Bonica
 Working Group: Individual Submissions (none)
 Formats: txt xml
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.
 PCEP Extensions for Signaling Multipath Information
 
 draft-koldychev-pce-multipath-03.txt
 Date: 06/07/2020
 Authors: Mike Koldychev, Siva Sivabalan, Tarek Saad, Vishnu Beeram, Hooman Bidgoli, Bhupendra Yadav, Shuping Peng
 Working Group: Individual Submissions (none)
 Formats: txt
Current PCEP standards allow only one intended and/or actual path to be present in a PCEP report or update. Applications that require multipath support such as SR Policy require an extension to allow signaling multiple intended and/or actual paths within a single PCEP message. This document introduces such an extension. Encoding of multiple intended and/or actual paths is done by encoding multiple Explicit Route Objects (EROs) and/or multiple Record Route Objects (RROs). A special separator object is defined in this document, to facilitate this. This mechanism is applicable to SR-TE and RSVP-TE and is dataplane agnostic.
 Architecture Discussion on SRv6 Mobile User plane
 
 draft-kohno-dmm-srv6mob-arch-02.txt
 Date: 09/09/2020
 Authors: Miya Kohno, Francois Clad, Pablo Camarillo, Zafar Ali
 Working Group: Individual Submissions (none)
 Formats: txt
Layer separation is a powerful concept in system architecture. In the area of mobility, by separating GTP-U that is the overlay tunnel, and the IP transport network that is the underlay, the operation of the mobile network and the transport network can be separated, allowing them to evolve independently. However, evolving individually at each layer promotes local optimization and may result in non-optimal solutions overall in the long run. When a drastic architectural transition is required, for example, in the 5G era where various SLAs and completely new data intensive services are assumed, it is necessary to reconsider the architecture holistically, not from the viewpoint of individual part. One of important value propositions of SRv6 mobile user plane is to create overlay with underlay optimization. This document discusses the architecture implication of applying SRv6 mobile user plane. Then it takes 5G use cases as an example, and describes how these use cases are simply and effectively realized. Thus it shows that SRv6 mobile use plane is a right architectural choice for 5G era.
 DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over SRv6
 
 draft-wang-detnet-tsn-over-srv6-01.txt
 Date: 30/04/2020
 Authors: Xueshun Wang, Jinyou Dai, Jianhua Liu, Jing Xu
 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.
 Support for Enterprise-specific TLVs in the BGP Monitoring Protocol
 
 draft-lucente-grow-bmp-tlv-ebit-01.txt
 Date: 05/05/2020
 Authors: Paolo Lucente, Yunan Gu
 Working Group: Individual Submissions (none)
 Formats: txt xml
Message types defined by the BGP Monitoring Protocol (BMP) do provision for optional trailing data in TLV - Type, Length, Value - format; however the space for Type value is unique and governed by IANA. To allow the usage of vendor-specific TLVs, a mechanism to define per-vendor Type values is required. With this document we want to introduce an Enterprise Bit, or E-bit, for such purpose.
 State-updating mechanism in RSVP-TE for MPLS network
 
 draft-gao-mpls-teas-rsvpte-state-update-01.txt
 Date: 30/04/2020
 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 managing 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-02.txt
 Date: 13/07/2020
 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.
 IETF Definition of Transport Slice
 
 draft-nsdt-teas-transport-slice-definition-04.txt
 Date: 09/09/2020
 Authors: Reza Rokui, Shunsuke Homma, Kiran Makhijani, Luis Contreras, Jeff Tantsura
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the definition of a slice in the transport networks and its characteristics. The purpose here is to bring clarity and a common understanding of the transport slice concept and describe related terms and their meaning. It explains how transport slices can be used in combination with end to end network slices, or independently.
 Bulk Subscription to YANG Event Notification
 
 draft-wang-netconf-bulk-subscribed-notifications-02.txt
 Date: 03/07/2020
 Authors: Zitao Wang, Qin WU, Peng Liu, Hui Cai
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a YANG data model and associated mechanism that allows subscriber applications to bulk subscribe to publishers' event streams based on bundle group information such as bundle size and bundle latency. This allows the publishers to report multiple notifications in a single bundling message.
 IS-IS YANG Model Augmentations for Additional Features - Version 1
 
 draft-acee-lsr-isis-yang-augmentation-v1-02.txt
 Date: 12/07/2020
 Authors: Acee Lindem, Stephane Litkowski, Yingzhen Qu
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines YANG data modules augmenting the IETF IS-IS YANG model to provide support for IS-IS Minimum Remaining Lifetime as defined in RFC 7987.
 Color Operation with BGP Label Unicast
 
 draft-chan-idr-bgp-lu2-02.txt
 Date: 31/08/2020
 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. There is a major change of protocol format starting from this updated draft.
 Performance Measurement for Geneve
 
 draft-xiao-nvo3-pm-geneve-01.txt
 Date: 21/05/2020
 Authors: Xiao Min, Greg Mirsky, Santosh Pallagatti
 Working Group: Individual Submissions (none)
 Formats: xml txt
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.
 Self Describing Data Object Tags
 
 draft-tao-netmod-yang-node-tags-06.txt
 Date: 22/09/2020
 Authors: Qin WU, Benoit Claise, Liang Geng, Zongpeng Du, Mohamed Boucadair
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a method to tag data objects associated with operation and management data in YANG Modules. This YANG data object tagging method can be used to classify data objects from different YANG modules and identify characteristics data. It also can provide input, instruction, indication to selection filter and filter queries of operational state on a server during a "pub/sub" service for YANG datastore updates. When the state of all subscriptions of a particular Subscriber to be fetched is huge, the amount of data to be streamed out to the destination can be greatly reduced and only targeted to the characteristics data. These data object tags may be registered as well as assigned during the module definition; assigned by implementations; or dynamically defined and set by users.
 Self-explanation data Node tag capability
 
 draft-tao-netconf-notif-node-tag-capabilities-02.txt
 Date: 08/07/2020
 Authors: Qin WU, Wu Bo, Peng Liu, Hui Cai
 Working Group: Individual Submissions (none)
 Formats: txt xml
Before a client application subscribes to updates from a datastore, server capabilities related to "Subscription to YANG Datastores" can be advertised using YANG Instance Data format. These server capabilities can be documented at implement time or reported at run- time. This document proposes a YANG module for self-explanation data Node tag capability which augments system capabilities model and provide additional self-explanation data node attributes associated with node selectors within per-node capabilities.
 A YANG Data Model for Client Signal Performance Monitoring
 
 draft-zheng-ccamp-client-pm-yang-02.txt
 Date: 13/07/2020
 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.
 BGP-LS Extensions for Segment Routing based Enhanced VPN
 
 draft-dong-idr-bgpls-sr-enhanced-vpn-02.txt
 Date: 23/06/2020
 Authors: Jie Dong, Zhibo Hu, Zhenbin Li, Xiongyan Tang, Ran Pang
 Working Group: Individual Submissions (none)
 Formats: txt
Enhanced VPN (VPN+) is an enhancement to VPN services to support the needs of new applications, particularly including the applications that are associated with 5G services. These applications require enhanced isolation and have more stringent performance requirements than that can be provided with traditional overlay VPNs. An enhanced VPN may be used for 5G transport network slicing, and will also be of use in more generic scenarios. To meet the requirement of enhanced VPN services, a number of Virtual Transport Networks (VTNs) need to be created, each with a subset of the underlay network topology and a set of network resources allocated to meet the requirement of a specific VPN+ service, 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. 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 Navigator Protocol for IP-Based Vehicular Networks
 
 draft-jeong-ipwave-context-aware-navigator-01.txt
 Date: 07/05/2020
 Authors: Jaehoon Jeong, Bien Mugabarigira, Zhong Xiang, Yiwen Shen
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document proposes a Context-Aware Navigator Protocol (CAN) for IP-based vehicular networks for cooperative navigation among vehicles in road networks. This CAN aims at the enhancement of driving safety through a light-weight driving information sharing method. The CAN 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-01.txt
 Date: 07/05/2020
 Authors: Jaehoon Jeong, Yiwen Shen, J., PARK
 Working Group: Individual Submissions (none)
 Formats: xml txt
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-03.txt
 Date: 08/07/2020
 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.
 Destination-IP-Origin-AS Filter for BGP Flow Specification
 
 draft-wang-idr-flowspec-dip-origin-as-filter-03.txt
 Date: 10/09/2020
 Authors: Haibo Wang, Aijun Wang, Shunwan Zhuang
 Working Group: Individual Submissions (none)
 Formats: txt xml
BGP Flowspec mechanism [RFC5575] [I-D.ietf-idr-rfc5575bis] propogates both traffic Flow Specifications and Traffic Filtering Actions by making use of the BGP NLRI and the BGP Extended Community encoding formats. This document specifies a new BGP-FS component type to support AS-level filtering. The match field is the origin AS number of the destination IP address that is encoded in the Flowspec NLRI. This function is applied in a single administrative domain.
 Alternative Delta Time Encoding for CCNx Using Compact Floating-Point Arithmetic
 
 draft-gundogan-icnrg-ccnx-timetlv-02.txt
 Date: 27/07/2020
 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.
 Transport Network Slice YANG Data Model
 
 draft-liu-teas-transport-network-slice-yang-01.txt
 Date: 12/07/2020
 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 transport network slices, defined as transport slices in [I-D.nsdt-teas-transport-slice-definition].
 Embedding LOOPS in Geneve
 
 draft-bormann-loops-geneve-binding-01.txt
 Date: 12/06/2020
 Authors: Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: html txt xml
LOOPS (Local Optimizations on Path Segments) aims to provide local in-network loss recovery. It can be used with tunneling protocols to efficiently recover lost packets on a single segment of an end-to-end path instead of leaving recovery to the end-to-end protocol, traversing the entire path. [I-D.welzl-loops-gen-info] defines the information to be carried between LOOPS ingress and egress nodes in a generic way, giving a guideline on defining the common elements to embed LOOPS functions in various tunnel protocols. The present document specifies how to embed LOOPS in the overlay tunnel protocol chosen for the initial LOOPS specification, Geneve [I-D.ietf-nvo3-geneve].
 Service Assurance for Intent-based Networking Architecture
 
 draft-claise-opsawg-service-assurance-architecture-03.txt
 Date: 27/07/2020
 Authors: Benoit Claise, Jean Quilbeuf, Youssef El Fathi, Diego Lopez, Daniel Voyer
 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.
 Communicating Warning Information in HTTP APIs
 
 draft-cedik-http-warning-02.txt
 Date: 23/09/2020
 Authors: Andre Cedik, Erik Wilde
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines a new HTTP field Content-Warning and a standard response format for representing warning information in HTTP APIs. Note to Readers This draft should be discussed on the rfc-interest mailing list (). Online access to all versions and files is available on GitHub ().
 pretty Easy privacy (pEp): Key Synchronization Protocol (KeySync)
 
 draft-pep-keysync-02.txt
 Date: 13/07/2020
 Authors: Volker Birk, Bernie Hoeneisen, Kelly Bristol
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the pEp KeySync protocol, which is designed to perform secure peer-to-peer synchronization of private keys across devices belonging to the same user. Modern users of messaging systems typically have multiple devices for communicating, and attempting to use encryption on all of these devices often leads to situations where messages cannot be decrypted on a given device due to missing private key data. Current approaches to resolve key synchronicity issues are cumbersome and potentially insecure. The pEp KeySync protocol is designed to facilitate this personal key synchronization in a user-friendly manner.
 Challenges and Changes in the Internet Threat Model
 
 draft-arkko-farrell-arch-model-t-04.txt
 Date: 13/07/2020
 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.
 Transport Protocol Issues of In-Network Computing Systems
 
 draft-kunze-coinrg-transport-issues-02.txt
 Date: 08/09/2020
 Authors: Ike Kunze, Klaus Wehrle
 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 discusses selected characteristics of transport protocols which have to be adapted to support COIN functionality.
 Considerations for defining a Transport Slice NBI
 
 draft-contreras-teas-slice-nbi-02.txt
 Date: 13/07/2020
 Authors: Luis Contreras, Shunsuke Homma, Jose Ordonez-Lucena
 Working Group: Individual Submissions (none)
 Formats: txt
The transport network is an essential component in the end-to-end delivery of services and, consequently, with the advent of network slicing it is necessary to understand what could be the way in which the transport network is consumed as a slice. This document analyses the needs of potential transport slice customers (i.e., use cases) in order to identify the functionality required on the North Bound Interface (NBI) of a transport slice controller for satisfying such transport slice requests.
 IS-IS Flooding Scale Considerations
 
 draft-ginsberg-lsr-isis-flooding-scale-02.txt
 Date: 17/04/2020
 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-02.txt
 Date: 13/07/2020
 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.
 Tunneling Internet protocols inside QUIC
 
 draft-piraux-quic-tunnel-03.txt
 Date: 12/08/2020
 Authors: Maxime Piraux, Olivier Bonaventure, Adi Masputra
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies methods for tunneling Ethernet frames and Internet protocols such as TCP, UDP, IP and QUIC inside a QUIC connection.
 Use of ALTO for Determining Service Edge
 
 draft-contreras-alto-service-edge-01.txt
 Date: 13/07/2020
 Authors: Luis Contreras, Danny Perez, Christian Rothenberg
 Working Group: Individual Submissions (none)
 Formats: txt
Service providers are starting to deploy and interconnect computing capabilities across the network for hosting network functions and applications. In distributed computing environments, both computing and topological information are necessary in order to determine the more convenient infrastructure where to deploy such a service or application. This document raises an initial approach towards the use of ALTO to provide such information and assist in the selection of proper execution environments.
 YANG Modules for Service Assurance
 
 draft-claise-opsawg-service-assurance-yang-05.txt
 Date: 27/07/2020
 Authors: Benoit Claise, Jean Quilbeuf, Paolo Lucente, Paolo Fasano
 Working Group: Individual Submissions (none)
 Formats: xml txt
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-02.txt
 Date: 09/09/2020
 Authors: Jonathan Hoyland, Christopher Wood
 Working Group: Individual Submissions (none)
 Formats: xml html 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.
 Publish/Subscribe over the Constrained Application Protocol (CoAP) using the Constrained RESTful Application Language (CoRAL)
 
 draft-hartke-t2trg-coral-pubsub-01.txt
 Date: 09/05/2020
 Authors: Klaus Hartke
 Working Group: Individual Submissions (none)
 Formats: txt
This document explores how the Constrained RESTful Application Language (CoRAL) might be used for enabling publish/subscribe-style communication over the Constrained Application Protocol (CoAP), which allows CoAP nodes with long breaks in connectivity and/or up-time to exchange data via a publish/subscribe broker.
 Bijective MAC for Constraint Nodes
 
 draft-urien-core-bmac-06.txt
 Date: 14/06/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.
 SIP Call-Info Parameters for Rich Call Data
 
 draft-wendt-sipcore-callinfo-rcd-03.txt
 Date: 13/07/2020
 Authors: Chris Wendt, Jon Peterson
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes a SIP Call-Info header field usage defined to include rich data associated with the identity of the calling party that can be rendered to called party for providing more useful information about the caller or the specific reason for the call. This includes extended comprehensive information about the caller such as what a jCard object can represent for describing the calling party or other call specific information such as describing the reason or intent of the call. The elements defined for this purpose are intended to be extensible to accommodate related information about calls that helps people decide whether to pick up the phone and additionally, with the use of jCard and other elements, to be compatible with the STIR/PASSporT Rich Call Data framework.
 The DANE Authentication Chain Extension for TLS
 
 draft-dukhovni-tls-dnssec-chain-02.txt
 Date: 14/06/2020
 Authors: Viktor Dukhovni, Shumon Huque, Willem Toorop, Paul Wouters, Melinda Shore
 Working Group: Individual Submissions (none)
 Formats: txt xml
This draft describes a new 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.
 User Plane Message Encoding
 
 draft-murakami-dmm-user-plane-message-encoding-02.txt,.ps
 Date: 03/09/2020
 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.
 L-band Digital Aeronautical Communications System (LDACS)
 
 draft-maeurer-raw-ldacs-06.txt
 Date: 02/10/2020
 Authors: Nils Maeurer, Thomas Graeupl, Corinna Schmitt
 Working Group: Individual Submissions (none)
 Formats: xml html txt
This document provides an overview of the architecture of the L-band Digital Aeronautical Communications System (LDACS), which provides a secure, scalable and spectrum efficient terrestrial data link for civil aviation. LDACS is a scheduled, reliable multi-application cellular broadband system with support for IPv6. LDACS shall provide a data link for IP network-based aircraft guidance. High reliability and availability for IP connectivity over LDACS are therefore essential.
 Deadline-aware Transport Protocol
 
 draft-shi-quic-dtp-02.txt
 Date: 25/07/2020
 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-02.txt
 Date: 28/05/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.
 CBOR Object Signing and Encryption (COSE): Additional Algorithms
 
 draft-schaad-cose-more-algs-01.txt
 Date: 22/05/2020
 Authors: Jim Schaad
 Working Group: Individual Submissions (none)
 Formats: xml html txt
The CBOR Object Signing and Encryption (COSE) syntax [I-D.ietf-cose-rfc8152bis-struct] allows for adding additional algorithms to the registries. This document adds one additional key wrap algorithm to the registry using the AES Wrap with Padding Algorithm [RFC5649]. This document adds Keccak Message Authentication Code (KMAC) algorithms as well as using KMAC as a Key Derivation Function (KDF).
 National Identifier Top-level Node Interface Protocol
 
 draft-chen-top-level-interface-protocol-01.txt
 Date: 07/05/2020
 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-02.txt
 Date: 04/10/2020
 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.
 Network Address Translation Support for QUIC
 
 draft-duke-quic-natsupp-03.txt
 Date: 29/07/2020
 Authors: Martin Duke
 Working Group: Individual Submissions (none)
 Formats: html txt xml
Network Address Translators (NATs) are widely deployed to share scarce public IPv4 addresses among multiple end hosts. They overwrite IP addresses and ports in IP packets to do so. QUIC is a protocol on top of UDP that provides transport-like services. QUIC is better-behaved in the presence of NATs than older protocols, and existing UDP NATs should operate without incident if unmodified. QUIC offers additional features that may tempt NAT implementers as potential optimizations. However, in practice, leveraging these features will lead to new connection failure modes and security vulnerabilities.
 Data Aggregation in IPv6-based Vehicular Networks
 
 draft-yan-ipwave-aggregation-01.txt
 Date: 17/05/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.
 LSP Object Flag Extension of Stateful PCE
 
 draft-xiong-pce-lsp-flag-02.txt
 Date: 31/05/2020
 Authors: Quan Xiong
 Working Group: Individual Submissions (none)
 Formats: txt xml
RFC8231 describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths(LSPs) via PCEP. One of the extensions is the LSP object which includes a Flag field and the length is 12 bits. However, 11 bits of the Flag field has been assigned in RFC8231, RFC8281 and RFC8623 respectively. This document proposes to define a new LSP-EXTENDED-FLAG TLV for LSP object to extend the length of the flags.
 IGP Flexible Algorithm Optimazition for Netwrok Slicing
 
 draft-peng-lsr-flex-algo-opt-slicing-02.txt
 Date: 05/09/2020
 Authors: 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 extends the use of the IGP Flex Algorithm to to be more suitable for network slicing scenarios.
 Delivering Functions over Networks: Traffic and Performance Optimization for Edge Computing using ALTO
 
 draft-yang-alto-deliver-functions-over-networks-01.txt
 Date: 13/07/2020
 Authors: Shu Yang, Laizhong Cui, Mingwei Xu, Y. Yang, Rui Huang
 Working Group: Individual Submissions (none)
 Formats: txt xml
As the rapid development of the Internet, huge amounts of data are being generated. To satisfy user demands, service providers deploy services near the edge networks. In order to achieve better performances, computing functions and user traffic need to be scheduled properly. However, it is challenging to efficiently schedule resources among the distributed edge servers due to the lack of underlying information, e.g., network topology, traffic distribution, link delay/bandwidth, utilization/capability of computing servers. In this document, we employ the ALTO protocol to help deliver functions and schedule traffic within the edge computing platform. The protocol will provide information of multiple resources for the distributed edge computing platform. The usage of ALTO will improve the efficiency of function delivery in edge computing.
 Operational Considerations for BRSKI Registrar
 
 draft-richardson-anima-registrar-considerations-04.txt
 Date: 29/07/2020
 Authors: Michael Richardson, Jie Yang
 Working Group: Individual Submissions (none)
 Formats: txt html xml
This document describes a number of operational modes that a BRSKI Registration Authority (Registrar) 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 Registrar is deployed into. This document does not change any protocol mechanisms. This document includes operational advice about avoiding unwanted consequences.
 Operatonal Considerations for Voucher infrastructure for BRSKI MASA
 
 draft-richardson-anima-masa-considerations-04.txt
 Date: 09/06/2020
 Authors: Michael Richardson, Wei Pan
 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.
 Commercial National Security Algorithm (CNSA) Suite Cryptography for Internet Protocol Security (IPSec)
 
 draft-corcoran-cnsa-ipsec-profile-01.txt
 Date: 17/08/2020
 Authors: Laura Corcoran, Michael Jenkins
 Working Group: Individual Submissions (none)
 Formats: xml txt
The United States Government has published the NSA Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using the United States National Security Agency's CNSA Suite algorithms in Internet Protocol Security. It applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ IPSec. US National Security Systems are described in NIST Special Publication 800-59. It is also appropriate for all 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.
 RTP Payload Format for Essential Video Coding (EVC)
 
 draft-zhao-avtcore-rtp-evc-02.txt
 Date: 13/07/2020
 Authors: Shuai Zhao, Stephan Wenger
 Working Group: Individual Submissions (none)
 Formats: txt xml pdf
This memo describes an RTP payload format for the video coding standard ISO/IEC International Standard 23094-1 [ISO23094-1], also known as Essential Video Coding [EVC] and developed by ISO/IEC JTC1/SC29/WG11. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload as well as fragmentation of a NAL unit into multiple RTP packets. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among other applications.
 Using cSHAKE in ORCHIDs
 
 draft-moskowitz-orchid-cshake-01.txt
 Date: 21/05/2020
 Authors: Robert Moskowitz, Stuart Card, Adam Wiethuechter
 Working Group: Individual Submissions (none)
 Formats: html xml txt
This document specifies how to use the cSHAKE hash for ORCHID generation and allows for varying sized hashes in the ORCHID along with additional information within the ORCHID. It is an addendum to ORCHIDv2 [RFC7343].
 Internationalization for the NFSv4 Protocols
 
 draft-dnoveck-nfsv4-internationalization-02.txt
 Date: 06/09/2020
 Authors: David Noveck
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the handling of internationalization for all NFSv4 protocols, including NFSv4.0, NFSv4.1, NFSv4.2 and extensions thereof, and future minor versions. It updates RFC7530 and RFC5661.
 Attribution Option for Extension Header Insertion
 
 draft-herbert-6man-eh-attrib-02.txt
 Date: 24/08/2020
 Authors: Tom Herbert
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines an "attribution option" that provides attribution for IPv6 extension headers, Hop-by-Hop options, or Destination options that are inserted by intermediate nodes in the delivery path of a packet. The purpose of this option is twofold: first it identifies the extension headers or options that have been inserted, secondly it attributes the inserted extension headers or options to the node responsible for inserting them.
 RPKI validated cache Update in SLURM over HTTPs (RUSH)
 
 draft-madi-sidrops-rush-02.txt
 Date: 29/08/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-01.txt
 Date: 21/06/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.
 Abstract
 
 draft-industrial-internet-identifier-data-escrow-01.txt
 Date: 21/06/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.
 HTTP Usage in the Industrial Internet Identifier Data Access Protocol (IIIDAP)
 
 draft-ma-identifier-access-http-02.txt
 Date: 22/06/2020
 Authors: Chendi Ma, Jian Chen, Xiaotian Fan, Meilan Chen, Zhiping Li
 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.
 Security Services for the Industrial Internet Identifier Data Access Protocol (IIIDAP)
 
 draft-mcd-identifier-access-security-02.txt
 Date: 13/07/2020
 Authors: Chendi Ma, Jian Chen, Xiaotian Fan, Meilan Chen, Zhiping Li
 Working Group: Individual Submissions (none)
 Formats: txt
The Industrial Internet Identifier Data Access Protocol (IIIDAP) provides "RESTful" web services to retrieve identifier metadata from Second-Level Node (SLN). This document describes information security services, including access control, authentication, authorization, availability, data confidentiality, and data integrity for IIIDAP.
 JSON Responses for the Industrial Internet Identifier Data Access Protocol (IIIDAP)
 
 draft-mcd-identifier-access-responce-02.txt
 Date: 13/07/2020
 Authors: Chendi Ma, Jian Chen, Xiaotian Fan, Meilan Chen
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes JSON data structures representing identifier information maintained by Second-Level Nodes (SLN). These data structures are used to form Industrial Internet Identifier Data Access Protocol (IIIDAP) query responses.
 Finding the Authoritative Registration Data (IIIDAP) Service
 
 draft-mcd-identifier-access-authority-02.txt
 Date: 13/07/2020
 Authors: Chendi Ma, Jian Chen, Xiaotian Fan, Meilan Chen, Zhiping Li
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a method to find which Industrial Internet Identifier Data Access Protocol (IIIDAP) server is authoritative to answer queries for a request of identifier data.
 Industrial Internet Identifier Data Access Protocol (IIIDAP) Query Format
 
 draft-mcd-identifier-access-query-02.txt
 Date: 13/07/2020
 Authors: Chendi Ma, Jian Chen, Xiaotian Fan, Meilan Chen, Zhiping Li
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes uniform patterns to construct HTTP URLs that may be used to retrieve identifier information from Second-Level Nodes (SLN) using "RESTful" web access patterns. These uniform patterns define the query syntax for the Industrial Internet Identifier Data Access Protocol (IIIDAP).
 IGP Flexible Algorithm with L2bundles
 
 draft-peng-lsr-flex-algo-l2bundles-04.txt
 Date: 14/10/2020
 Authors: 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-01.txt
 Date: 29/06/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.
 Threshold Modes in Elliptic Curves
 
 draft-hallambaker-threshold-03.txt
 Date: 03/09/2020
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml html
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-04.txt
 Date: 03/09/2020
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: xml html txt
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-02.txt
 Date: 18/09/2020
 Authors: Michael Richardson, Jie Yang
 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).
 BGP SR Policy Extensions to Enable IFIT
 
 draft-qin-idr-sr-policy-ifit-04.txt
 Date: 02/10/2020
 Authors: Fengwei Qin, Hang Yuan, Tianran Zhou, Giuseppe Fioccola, Yali Wang
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routing (SR) policy is a set of candidate SR paths consisting of one or more segment lists and necessary path attributes. It enables instantiation of an ordered list of segments with a specific intent for traffic steering. 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. This document defines extensions to BGP to distribute SR policies carrying IFIT information. So that IFIT methods can be enabled automatically when the SR policy is applied.
 OSPF Graceful Restart Enhancements
 
 draft-basavaraj-lsr-ospf-gr-enhancements-01.txt
 Date: 29/06/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-03.txt
 Date: 09/09/2020
 Authors: David Schinazi
 Working Group: Individual Submissions (none)
 Formats: txt html xml
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-04.txt
 Date: 28/09/2020
 Authors: Aijun Wang, Zhibo Hu, Gyan Mishra
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the mechanism that can be used to differentiate the passive interfaces from the normal interfaces within ISIS or OSPF domain.
 In-band Network Telemetry for 6TiSCH Networks
 
 draft-karaagac-6tisch-int-01.txt
 Date: 13/07/2020
 Authors: Abdulkadir Karaagac, Jeroen Hoebeke
 Working Group: Individual Submissions (none)
 Formats: pdf xml txt
This document describes In-band Network Telemetry for 6TiSCH Networks, offering a flexible monitoring solution with minimal resource consumption and communication overhead while supporting a wide range of monitoring operations and strategies for dealing with various network scenarios and use cases. It enables 6TiSCH networks to collect per-packet and per-hop monitoring information by piggybacking telemetry information onto the data packets by exploiting the remaining space in the IEEE 802.15.4e frames, thus not impacting network behavior and performance. This document also discusses the data fields and associated data types for 6TiSCH INT mechanism.
 (strong) AuCPace,an augmented PAKE
 
 draft-haase-aucpace-02.txt
 Date: 07/08/2020
 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-04.txt
 Date: 07/05/2020
 Authors: Brian Campbell
 Working Group: Individual Submissions (none)
 Formats: txt html xml
This document defines the HTTP header field "Client-Cert" that allows a TLS terminating reverse proxy to convey information about the client certificate of a mutually-authenticated TLS connection to an origin server in a common and predictable manner.
 IGP Extensions for Segment Routing Service Segment
 
 draft-lz-lsr-igp-sr-service-segments-02.txt
 Date: 10/07/2020
 Authors: Liu Yao, Zheng Zhang
 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.
 Context Label for MPLS EVPN
 
 draft-wang-bess-evpn-context-label-04.txt
 Date: 20/08/2020
 Authors: Yubao Wang, Bing Song
 Working Group: Individual Submissions (none)
 Formats: xml txt html
EVPN is designed to provide a better VPLS service than [RFC4761] and [RFC4762], and EVPN indeed introduced many new features which couldn't be achieved in those old VPLS implementions. But EVPN didn't inherit all features of old VPLS, and a few issues arises for EVPN only. Some of these issues can be imputed to the MP2P nature of EVPN labels. The PW label in old VPLS is a label for P2P VC, so it contains more context than a identifier in dataplane for it's VSI instance.But the EVPN label just identifies it's VSI instnace and it can't stand for the ingress PE in dataplane. So the following issues arises with MPLS EVPN service: * MPLS EVPN statistics can't be done per ingress PE. * MPLS EVPN can't support hub/spoke use case which the spoke PE can
 Analysis Framework For Extensions of SRv6 Encapsulation
 
 draft-filsfils-spring-analysis-fmwk-ext-srv6-encap-01.txt
 Date: 27/07/2020
 Authors: Clarence Filsfils, Darren Dukes, Keyur Patel
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document provides a framework for analysis of multiple proposals to extend SRv6 encapsulation with the objective of minimizing encapsulation size or leveraging legacy equipment. It defines relevant metrics to evaluate each proposal.
 Stateless and Scalable Network Slice Identification for SRv6
 
 draft-filsfils-spring-srv6-stateless-slice-id-01.txt
 Date: 13/07/2020
 Authors: Clarence Filsfils, Francois Clad, Pablo Camarillo, Kamran Raza
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines a stateless and scalable solution to achieve network slicing with SRv6.
 The LoST-Validation S-NAPTR Application Service Tag
 
 draft-gellens-lost-validation-09.txt
 Date: 01/07/2020
 Authors: Randall Gellens, Brian Rosen
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document adds the "LoST-Validation" service tag to the Straightforward Naming Authority PoinTeR (S-NAPTR) Application Service Tag IANA registry. This tag can appear in a Naming Authority Pointer (NAPTR) Domain Name System (DNS) record to assist clients of the Location-to-Service Translation Protocol (LoST) in identifying LoST servers explicitly willing to perform location validation. This tag and the information on its use is an update to RFC5222 that enables the explicit discovery of a server that supports location validation.
 SRv6 vSID: Network Programming extension for variable length SIDs
 
 draft-decraene-spring-srv6-vlsid-04.txt
 Date: 11/09/2020
 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.
 Authorized update to MUD URLs
 
 draft-richardson-opsawg-mud-acceptable-urls-02.txt
 Date: 22/09/2020
 Authors: Michael Richardson, Jie Yang, Eliot Lear
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document provides a way for an RFC8520 Manufacturer Usage Description (MUD) definitions to declare what are acceptable replacement URLs for a device.
 BGP-LS Extensions for Transport Slice
 
 draft-chen-idr-bgp-ls-transport-slice-02.txt
 Date: 02/09/2020
 Authors: Shaofu Peng
 Working Group: Individual Submissions (none)
 Formats: txt
[I-D.peng-teas-network-slicing] defines a unified TN-slice identifier, AII(administrative instance identifier), to indicate the topology, computing, storage resources of the dedicated virtual network for both intra-domain and inter-domain network slicing scenarios. This draft defines extensions to BGP-LS protocol in order to advertise the information of the transport slice.
 Sender Control of Acknowledgement Delays in QUIC
 
 draft-iyengar-quic-delayed-ack-01.txt
 Date: 26/07/2020
 Authors: Jana Iyengar, Ian Swett
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a QUIC extension for an endpoint to control its peer's delaying of acknowledgements. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at . Working Group information can be found at ; source code and issues list for this draft can be found at .
 BGP based Virtual Private Network (VPN) Services over SRm6 enabled IPv6 networks
 
 draft-ssangli-bess-bgp-vpn-srm6-02.txt
 Date: 07/09/2020
 Authors: Srihari Sangli, Ron Bonica
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines BGP protocol extensions for encoding and carrying SRm6 Tunnel Payload Forwarding information (TPF) to support Virtual Private Network services. This is applicable when the VPN services are offered in a SRm6 enabled IPv6 network such that the VPN payload is transported over IPv6. The Tunnel Payload Information is encoded in the IPv6 Destination Option Header in the IPv6 data packets.
 Changing the Default QUIC ACK Policy
 
 draft-fairhurst-quic-ack-scaling-03.txt
 Date: 14/09/2020
 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.
 The Grant Negotiation and Authorization Protocol
 
 draft-hardt-xauth-protocol-14.txt
 Date: 15/08/2020
 Authors: Dick Hardt
 Working Group: Individual Submissions (none)
 Formats: html txt xml
Client software often desires resources or identity claims that are independent of the client. This protocol allows a user and/or resource owner to delegate resource authorization and/or release of identity claims to a server. Client software can then request access to resources and/or identity claims by calling the server. The server acquires consent and authorization from the user and/or resource owner if required, and then returns to the client software the authorization and identity claims that were approved. This protocol may be extended on many dimensions.
 Using GOST algorithms in IKEv2
 
 draft-smyslov-ike2-gost-04.txt
 Date: 26/08/2020
 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).
 Carrying Virtual Transport Network Identifier in IPv6 Extension Header
 
 draft-dong-6man-enhanced-vpn-vtn-id-01.txt
 Date: 13/07/2020
 Authors: Jie Dong, Zhenbin Li, Chongfeng Xie, Chenhao Ma
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document proposes a new option type to carry virtual transport network identifier (VTN ID) in the IPv6 extensions headers to identify the Virtual Transport Network (VTN) the packet belongs to. The procedure of processing the VTN option is also specified. This provides a scalable solution for data plane encapsulation of enhanced VPN (VPN+) as described in I-D.ietf-teas-enhanced-vpn. One typical use case of VPN+ is to provide transport network slicing in 5G, while it could also be used in more general cases.
 Generalized SRv6 Network Programming
 
 draft-cl-spring-generalized-srv6-np-02.txt
 Date: 10/09/2020
 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-01.txt
 Date: 13/08/2020
 Authors: Zhenbin Li, Cheng Li, Weiqiang Cheng, Chongfeng Xie, Li Cong, Hui Tian, Feng Zhao
 Working Group: Individual Submissions (none)
 Formats: xml txt
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-02.txt
 Date: 13/07/2020
 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 relationship between 5G end-to-end network slice and transport network slice defined in IETF. This draft also intends to expose some gaps in the existing network management plane and data plane to support inter-domain network slice mapping. Further work may require cooperation between IETF and 3GPP (or other standard organizations). The definition of data model, signaling protocol extension and new encapsulation are out of the scope of this draft.
 BGP Extension for SR-MPLS Entropy Label Position
 
 draft-zhou-idr-bgp-srmpls-elp-01.txt
 Date: 21/08/2020
 Authors: Liu Yao, Shaofu Peng
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposed an extension for BGP to configure the entropy label position for SR-MPLS networks.
 Transmission of IP Packets over Overlay Multilink Network (OMNI) Interfaces
 
 draft-templin-6man-omni-interface-47.txt
 Date: 07/10/2020
 Authors: Fred Templin, Tony Whyman
 Working Group: Individual Submissions (none)
 Formats: txt xml
Mobile nodes (e.g., aircraft of various configurations, terrestrial vehicles, seagoing vessels, enterprise wireless devices, etc.) communicate with networked correspondents over multiple access network data links and configure mobile routers to connect end user networks. A multilink interface specification is therefore needed for coordination with the network-based mobility service. This document specifies the transmission of IP packets over Overlay Multilink Network (OMNI) Interfaces.
 SDP Mapping into HTTP structured headers
 
 draft-gruessing-sdp-http-01.txt
 Date: 14/08/2020
 Authors: James Gruessing
 Working Group: Individual Submissions (none)
 Formats: xml txt html
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/draft-gruessing-sdp-http (https://github.com/fiestajetsam/draft-gruessing-sdp-http).
 Shorter SRv6 SID Requirements
 
 draft-cheng-spring-shorter-srv6-sid-requirement-02.txt
 Date: 13/07/2020
 Authors: Weiqiang Cheng, Chongfeng Xie, Ran Pang, Zhenbin Li, Ran Chen, Lijun Zu, Xiaodong Duan, Greg Mirsky, Darren Dukes, Shay Zadok
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes a list of requirements for the use of a shortened identifier in a segment routing network with the IPv6 data plane.
 Quic Timestamps For Measuring One-Way Delays
 
 draft-huitema-quic-ts-03.txt
 Date: 10/08/2020
 Authors: Christian Huitema
 Working Group: Individual Submissions (none)
 Formats: txt xml
The TIME_STAMP frame can be added to Quic packets when one way delay measurements is useful. The timestamp is set to the number of microseconds from the beginning of the connection to the time at which the packet is sent. The draft defines the "enable_time_stamp" transport parameter for negotiating the use of this extension frame, and a new frame types for the time_stamped frame.
 Local Protection Enforcement in PCEP
 
 draft-stone-pce-local-protection-enforcement-02.txt
 Date: 17/08/2020
 Authors: Andrew Stone, Mustapha Aissaoui, Samuel Sidor, Siva Sivabalan
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document updates [RFC5440] to clarify usage of the local protection desired bit signalled in Path Computation Element Protocol (PCEP). This document also introduces a new flag for signalling protection strictness in PCEP.
 Adaptive Subscription to YANG Notification
 
 draft-wang-netconf-adaptive-subscription-02.txt
 Date: 14/10/2020
 Authors: Qin WU, Wei Song, Liang Geng, 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 both subscriber and publisher to automatically adjust the volume of telemetry traffic sent from publisher to the receivers.
 Telemetry Data Export capability
 
 draft-tao-netconf-data-export-capabilities-01.txt
 Date: 12/07/2020
 Authors: Qin WU, Liang Geng, Peng Liu
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document proposes a YANG module for telemetry data export capability which augments system Capabilities model and provides additional telemetry data export attributes associated with system capability for transport dependent capability negotiation.
 Approaches on Supporting IOAM in IPv6
 
 draft-song-ippm-ioam-ipv6-support-01.txt
 Date: 09/07/2020
 Authors: Haoyu Song, Zhenbin Li, Shuping Peng, Jim Guichard
 Working Group: Individual Submissions (none)
 Formats: txt xml
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 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.
 DHCP and Router Advertisement Options for Encrypted DNS Discovery within Home Networks
 
 draft-btw-add-home-09.txt
 Date: 21/09/2020
 Authors: Mohamed Boucadair, Tirumaleswar Reddy.K, Dan Wing, Neil Cook
 Working Group: Individual Submissions (none)
 Formats: txt xml
The document specifies new DHCP and Router Advertisement Options to discover encrypted DNS servers (e.g., DoH, DoT, DoQ). Particularly, it allows to learn an Authentication Domain Name together with a list of IP addresses and optionally a port number to reach such encrypted DNS servers. This document focuses on encrypted DNS deployment within home networks.
 Multicast and Ethernet VPN with Segment Routing Point-to-Multipoint Trees
 
 draft-parekh-bess-mvpn-evpn-sr-p2mp-01.txt
 Date: 08/09/2020
 Authors: Rishabh Parekh, Clarence Filsfils, Arvind Venkateswaran, Hooman Bidgoli, Daniel Voyer, Zhaohui Zhang
 Working Group: Individual Submissions (none)
 Formats: xml txt
A Point-to-Multipoint (P2MP) Tree in a Segment Routing domain efficiently carries traffic from a Root to a set of Leaves. This document describes extensions to BGP encodings and procedures for P2MP trees used in BGP/MPLS IP VPNs and Ethernet VPNs.
 Application-aware Networking (APN) Framework
 
 draft-li-apn-framework-01.txt
 Date: 06/09/2020
 Authors: Zhenbin Li, Shuping Peng, Daniel Voyer, Cong Li, Liang Geng, Chang Cao, Kentaro Ebisawa, Stefano Previdi, Jim Guichard
 Working Group: Individual Submissions (none)
 Formats: txt xml
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 identification and its network performance requirements is carried in the packet encapsulation in order to facilitate service provisioning, perform application-level traffic steering and network resource adjustment.
 Problem Statement and Use Cases of Application-aware Networking (APN)
 
 draft-li-apn-problem-statement-usecases-01.txt
 Date: 06/09/2020
 Authors: Zhenbin Li, Shuping Peng, Daniel Voyer, Chongfeng Xie, Peng Liu, Zhuangzhuang Qin, Kentaro Ebisawa, Stefano Previdi, Jim Guichard
 Working Group: Individual Submissions (none)
 Formats: xml txt
Network operators are facing the challenge of providing better network services for users. As the ever developing 5G and industrial verticals evolve, more and more services that have diverse network requirements such as ultra-low latency and high reliability are emerging, and therefore differentiated service treatment is desired by users. However, network operators are typically unaware of which applications are traversing their network infrastructure, which means that only coarse-grained services can be provided to users. As a result, network operators are only evolving their infrastructure to be large but dumb pipes without corresponding revenue increases that might be enabled by differentiated service treatment. As network technologies evolve including deployments of IPv6, SRv6, Segment Routing over MPLS dataplane, the programmability provided by IPv6 and Segment Routing can be augmented by conveying application related information into the network. Adding application knowledge to the network layer allows applications to specify finer granularity requirements to the network operator. This document analyzes the existing problems caused by lack of application awareness, and outlines various use cases that could benefit from an Application-aware Networking (APN) architecture.
 Enhanced Performance Delay and Liveness Monitoring in Segment Routing Networks
 
 draft-gandhi-spring-sr-enhanced-plm-03.txt
 Date: 26/09/2020
 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 procedure for Enhanced Performance Delay and Liveness Monitoring (PDLM) in Segment Routing networks. The procedure leverages the probe messages compatible with the delay measurement message formats defined in RFC 5357 (Two-Way Active Measurement Protocol (TWAMP)) and RFC 8762 (Simple Two-Way Active Measurement Protocol (STAMP)) and is applicable to end-to-end SR Paths including SR Policies for both SR-MPLS and SRv6 data planes.
 Announcing Supported Authentication Methods in IKEv2
 
 draft-smyslov-ipsecme-ikev2-auth-announce-02.txt
 Date: 09/09/2020
 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-01.txt
 Date: 13/07/2020
 Authors: Kirsty P, Ollie Whitehouse
 Working Group: Individual Submissions (none)
 Formats: txt xml
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.
 Conveying Transceiver-Related Information within RSVP-TE Signaling
 
 draft-meuric-ccamp-tsvmode-signaling-01.txt
 Date: 27/07/2020
 Authors: Julien Meuric, Esther Le Rouzic, Luay Alahdab, Gabriele Galimberti
 Working Group: Individual Submissions (none)
 Formats: xml txt
The ReSource Reservation Protocol with Traffic Engineering extensions (RSVP-TE) allows to carry optical information so as to set up channels over Wavelength Division Multiplexing (WDM) networks between a pair of transceivers. Nowadays, there are many transceivers that not only support tunable lasers, but also multiple modulation formats. This memo leverages the Generalized Multiprotocol Label Switching protocol extensions to support the signaling of the associated information as a "mode" parameter within a "transceiver type" context.
 Textual Analysis Methodology for Security Considerations Sections
 
 draft-mcfadden-smart-rfc3552-textual-research-02.txt
 Date: 09/09/2020
 Authors: Mark McFadden, Alan Mills
 Working Group: Individual Submissions (none)
 Formats: txt
[RFC3552] provides guidance to authors in crafting RFC text on Security Considerations. The RFC is more than fifteen years old. With the threat landscape and security ecosystem significantly changed since the RFC was published, RFC3552 is a candidate for update. This draft proposes that, prior to drafting an update to RFC3552, an examination of recent, published Security Considerations sections be carried out as a baseline for how to improve RFC3552. It suggests a methodology for examining Security Considerations sections in published RFCs and the extraction of both quantitative and qualitative information that could inform a revision of the older guidance. It also reports on a recent experiment on textual analysis of sixteen years of RFC Security Consideration sections.
 Inserting,Processing And Deleting IPv6 Extension Headers
 
 draft-bonica-6man-ext-hdr-update-04.txt
 Date: 30/08/2020
 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-01.txt
 Date: 13/07/2020
 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-03.txt
 Date: 11/05/2020
 Authors: Liu Yao, Shaofu Peng
 Working Group: Individual Submissions (none)
 Formats: txt
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-01.txt
 Date: 13/07/2020
 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-01.txt
 Date: 09/09/2020
 Authors: Huaimo Chen, Yanhe Fan, Aijun Wang, Lei Liu, Xufeng Liu
 Working Group: Individual Submissions (none)
 Formats: xml txt
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-03.txt
 Date: 11/05/2020
 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-01.txt
 Date: 09/09/2020
 Authors: Huaimo Chen, Aijun Wang, 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 improving the reliability or availability of a network controlled by a controller cluster.
 IGP for Network High Availability
 
 draft-chen-lsr-ctr-availability-01.txt
 Date: 09/09/2020
 Authors: Huaimo Chen, Mehmet Toy, Aijun Wang, Lei Liu, Xufeng Liu
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes protocol extensions to OSPF and IS-IS for improving the reliability or availability of a network controlled by a controller cluster.
 A Yang Data Model for Transport Slice NBI
 
 draft-wd-teas-transport-slice-yang-02.txt
 Date: 12/07/2020
 Authors: Wu Bo, Dhruv Dhody, Liuyan Han, Reza Rokui
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document provides a YANG data model for the Transport Slice NBI. The model can be used by a higher level system which is the Transport slice consumer of a Transport Slice Controller (TSC) to request, configure, and manage the components of a transport slices. The YANG modules in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342.
 Use cases of Application-aware Networking (APN) in Edge Computing
 
 draft-liu-apn-edge-usecase-01.txt
 Date: 12/07/2020
 Authors: Peng Liu, Liang Geng, Shuping Peng, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: xml txt
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-01.txt
 Date: 10/09/2020
 Authors: chenmeiling, Li Su
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document presents two 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.
 An Architecture for Network Function Interconnect
 
 draft-bookham-rtgwg-nfix-arch-01.txt
 Date: 24/06/2020
 Authors: Colin Bookham, Andrew Stone, Jeff Tantsura, Muhammad Durrani, Bruno Decraene
 Working Group: Individual Submissions (none)
 Formats: xml txt
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.
 Client-Server Explicit Performance Measurements
 
 draft-cfb-ippm-spinbit-measurements-02.txt
 Date: 03/07/2020
 Authors: Mauro Cociglio, Giuseppe Fioccola, Massimo Nilo, Fabio Bulgarella, Riccardo Sisto
 Working Group: Individual Submissions (none)
 Formats: txt
This document introduces an additional single bit signal to enhance the spin bit [I-D.trammell-ippm-spin] performance in presence of network impairments and application limited flow. In addition, it defines two new explicit per-flow transport-layer signals for hybrid measurement of connection loss rate. The former is a spin-bit dependent signal and uses a single bit. The latter is a standalone solution based on a two bits loss signal and on alternate marking RFC 8321 [RFC8321].
 Distributed SFC control operation
 
 draft-bernardos-sfc-distributed-control-operation-01.txt
 Date: 01/09/2020
 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-01.txt
 Date: 01/09/2020
 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-01.txt
 Date: 01/09/2020
 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-01.txt
 Date: 26/09/2020
 Authors: Shaofu Peng, Ran Chen
 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 IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network
 
 draft-xie-lsr-isis-sr-vtn-mt-02.txt
 Date: 12/10/2020
 Authors: Chongfeng Xie, Chenhao Ma, Jie Dong, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: xml txt
Enhanced VPN (VPN+) as defined in I-D.ietf-teas-enhanced-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 the underlay network. A Virtual Transport Network (VTN) is a virtual network which consists of a subset of the network topology and network resources allocated from the underlay network. A VTN could be used as the underlay for one or a group of VPN+ services. I-D.dong-lsr-sr-enhanced-vpn defines the IGP extensions to build a set of Segment Routing (SR) based VTNs. This document describes a simplified mechanism to build the SR based VTNs using IS-IS Multi- Topology together with other well-defined IS-IS extensions.
 Using Flex-Algo for Segment Routing based VTN
 
 draft-zhu-lsr-isis-sr-vtn-flexalgo-01.txt
 Date: 11/09/2020
 Authors: Yongqing Zhu, Jie Dong, Zhibo Hu
 Working Group: Individual Submissions (none)
 Formats: txt xml
As defined in I-D.ietf-teas-enhanced-vpn, enhanced VPN (VPN+) aims to provide enhanced VPN service to support the 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 network which consists of a subset of network topology and network resources allocated from the underlay network. A VTN could be used as the underlay for one or a group of VPN+ services. I-D.dong-lsr-sr-enhanced-vpn defines the IGP mechanisms with necessary extensions to build a set of Segment Routing (SR) based VTNs. This document describes a simplified mechanism to build the SR based VTNs using SR Flex-Algo together with minor extensions to IGP L2 bundle.
 Tunneling TCP inside QUIC
 
 draft-piraux-quic-tunnel-tcp-02.txt
 Date: 12/08/2020
 Authors: Maxime Piraux, Olivier Bonaventure
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies a new operating mode for a QUIC tunnel to efficiently convey TCP bytestreams.
 The SRT Protocol
 
 draft-sharabayko-mops-srt-01.txt
 Date: 09/09/2020
 Authors: Maria Sharabayko, Maxim Sharabayko, Jean Dube, Joonwoong Kim, Jeongseok Kim
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies Secure Reliable Transport (SRT) protocol. SRT is a user-level protocol over User Datagram Protocol and provides reliability and security optimized for low latency live video streaming, as well as generic bulk data transfer. For this, SRT introduces control packet extension, improved flow control, enhanced congestion control and a mechanism for data encryption.
 DNS Resolving service Discovery Protocol (DRDP)
 
 draft-mglt-add-rdp-03.txt
 Date: 28/07/2020
 Authors: Daniel Migault
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the DNS Resolver Discovery Protocol (DRDP) that enables a DNS client to discover various available local and global resolving service. The discovery is primarily initiated by a DNS client, but a resolving service may also inform the DNS client other resolving services are available and eventually preferred.
 BGP-LS with Multi-topology for Segment Routing based Virtual Transport Networks
 
 draft-xie-idr-bgpls-sr-vtn-mt-01.txt
 Date: 13/07/2020
 Authors: Chongfeng Xie, Cong Li, Jie Dong, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: xml txt
Enhanced VPN (VPN+) as defined in I-D.ietf-teas-enhanced-vpn aims to provide enhanced VPN service to support applications's needs of enhanced isolation and stringent performance requirements. VPN+ requries integration between the overlay VPN and the underlay network. A Virtual Transport Network (VTN) is a virtual network which consists of a subset of the network toplogy and network resources allocated from the underlay network. A VTN could be used as the underlay for one or a group of VPN+ services. I-D.dong-idr-bgpls-sr-enhanced-vpn defines the BGP-LS extensions to distribute the information of Segment Routing (SR) based VTNs to external entities, such as the network controllers. This document describes a simplified mechanism to distribute the information of SR based VTNs using BGP-LS with Multi-Topology.
 Security Considerations for Protocol Designers
 
 draft-lazanski-protocol-sec-design-model-t-01.txt
 Date: 13/07/2020
 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.
 Auto-adjustment of Encapsulation Information in APN6
 
 draft-du-apn6-auto-encapsulation-adjustment-01.txt
 Date: 13/07/2020
 Authors: Zongpeng Du, Peng Liu, Liang Geng
 Working Group: Individual Submissions (none)
 Formats: txt
This document introduces a method to adjust the encapsulation information in Application-aware IPv6 Networking.
 BCP72 - A Problem Statement
 
 draft-mcfadden-smart-threat-changes-01.txt
 Date: 10/07/2020
 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 sixteen years have passed since RFC3552 was written and the structure and topology of the Internet has changed. With those changes comes a question: has the Internet Threat Model changed? Or, is the model described in RFC3552 still largely accurate? This draft attempts to describe an 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.
 Parameterized Nameserver Delegation with NS2 and NS2T
 
 draft-tapril-ns2-01.txt
 Date: 13/07/2020
 Authors: Tim April
 Working Group: Individual Submissions (none)
 Formats: txt html xml
Within the DNS, there is no mechanism for authoritative servers to advertise which transport methods they are capable of. If secure transport methods are adopted by authoritative operators, transport signaling would be required to negotiate how authoritative servers would be contacted by resolvers. This document provides two new Resource Record Types, NS2 and NS2T, to facilitate this negotiation by allowing zone owners to signal how the authoritative nameserver(s) for their zone(s) may accept queries.
 Forwarding Layer Problem Statement
 
 draft-bryant-arch-fwd-layer-ps-01.txt
 Date: 13/07/2020
 Authors: Stewart Bryant, Uma Chunduri, Toerless Eckert, Alexander Clemm
 Working Group: Individual Submissions (none)
 Formats: xml txt
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-01.txt
 Date: 13/07/2020
 Authors: Wei Huang, Yunfei Zhang, Richard Yang, Chunshan Xiong, Yixue Lei, Yunbo Han, Gang Li
 Working Group: Individual Submissions (none)
 Formats: pdf 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-01.txt
 Date: 09/06/2020
 Authors: Tim Taubert, Christopher Wood
 Working Group: Individual Submissions (none)
 Formats: xml html 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-01.txt
 Date: 08/09/2020
 Authors: Ina Fink, Klaus Wehrle
 Working Group: Individual Submissions (none)
 Formats: xml 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. In-network computing allows the processing of traffic and data directly in the network and at line- rate. Thus, the in-network computing paradigm presents a promising solution for efficiently providing security and privacy mechanisms as well as event analysis. This document discusses select mechanisms to demonstrate how in-network computing concepts can be applied to counter existing shortcomings of cyber-security and data privacy.
 Framework for Transport Network Slices
 
 draft-nsdt-teas-ns-framework-04.txt
 Date: 13/07/2020
 Authors: Eric Gray, John Drake
 Working Group: Individual Submissions (none)
 Formats: txt
This memo discusses setting up special-purpose transport connections using existing IETF technologies. These connections are called transport slices for the purposes of this memo. The memo discusses the general framework for this setup, the necessary system components and interfaces, and how abstract requests can be mapped to more specific technologies. The memo also discusses related considerations with monitoring and security. This memo is intended for discussing interfaces and technologies. It is not intended to be a new set of concrete interfaces or technologies. Rather, it should be seen as an explanation of how some existing, concrete IETF VPN and traffic-engineering technologies can be used to create transport slices. Note that there are a number of these technologies, and new technologies or capabilities keep being added. This memo is also not intended presume any particular technology choice.
 Proxy Operations for CoAP Group Communication
 
 draft-tiloca-core-groupcomm-proxy-01.txt
 Date: 13/07/2020
 Authors: Marco Tiloca, Esko Dijk
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies the operations performed by a forward-proxy, when using the Constrained Application Protocol (CoAP) in group communication scenarios. Proxy operations involve the processing of individual responses from servers, as reply to a single request sent by the client over unicast to the proxy, and then distributed by the proxy over IP multicast to the servers. When receiving the different responses via the proxy, the client is able to distinguish them and their originator servers, by acquiring their addressing information.
 A CBOR Tag for Unprotected CWT Claims Sets
 
 draft-birkholz-rats-uccs-01.txt
 Date: 01/06/2020
 Authors: Henk Birkholz, Jeremy O'Donoghue, Nancy Cam-Winget, Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: txt xml
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.
 Transport Slice Intent
 
 draft-contreras-nmrg-transport-slice-intent-03.txt
 Date: 26/07/2020
 Authors: Luis Contreras, Panagiotis Demestichas, Jeff Tantsura
 Working Group: Individual Submissions (none)
 Formats: xml txt
Slicing at the transport network is expected to be offered as part of end-to-end network slices, fostered by the introduction of new services such as 5G. This document explores the usage of intent technologies for requesting transport slices.
 CBOR Profile of X.509 Certificates
 
 draft-mattsson-cose-cbor-cert-compress-01.txt
 Date: 13/07/2020
 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/compression of RFC 7925 profiled certificates. By using the fact that the certificates are profiled, the CBOR certificate compression algorithms can in many cases compress RFC 7925 profiled certificates with over 50%. This document also specifies COSE headers for CBOR encoded certificates as well as the use of the CBOR certificate compression algorithm with TLS Certificate Compression in TLS 1.3 and DTLS 1.3.
 Mathematical Mesh 3.0 Part XIII: Mesh Ceremonies
 
 draft-hallambaker-mesh-ceremonies-02.txt
 Date: 27/07/2020
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml html
Ceremonies are security protocols that involve human participants as principal actors. Ceremonies for onboarding devices, establishing trust between parties and obtaining multi-factor authenticated responses from users are presented and analyzed with particular application to the Mathematical Mesh. https://mailarchive.ietf.org/arch/browse/mathmesh/ (http://whatever)Discussion of this draft should take place on the MathMesh mailing list (mathmesh@ietf.org), which is archived at .
 Reference Integrity Measurement Extension for Concise Software Identities
 
 draft-birkholz-rats-coswid-rim-01.txt
 Date: 13/07/2020
 Authors: Henk Birkholz, Patrick Uiterwijk, Ned Smith, Jessica Fitzgerald-McKay, David Waltermire, Shwetha Bhandari
 Working Group: Individual Submissions (none)
 Formats: xml txt
Concise Software Identification (CoSWID) tags identify and describe individual software components, patches, and installation bundles. CoSWID is based on ISO/IEC 19770-2:2015 2:2015 that provides a complementary XML schema definition (XSD) for Software Identification (SWID) tags. CoSWID supports the same features as the corresponding XML SWID tags. The CoSWID specification also includes more structured extensibility features and reduces a few of ambiguities that are not explicitly resolved in the ISO XSD. In this document, these extensibility features (extension points) are used to add attributes to the CoSWID specification. The new attributes allow for the use of CoSWID as Reference Integrity Measurements (RIM). There are four sets of RIM features defined in this specification. 1.) attributes that support RIM manifests for Measured Boot, 2.) attributes that support package manager managed structures, 3.) attributes that allow for OID to be used in the description of Reference Integrity Measurements, and 4.) attributes for object trees in support of Target Environments that are chained via Layered Attestation.
 BGP Well Known Large Community
 
 draft-heitz-idr-wklc-01.txt
 Date: 09/09/2020
 Authors: Jakob Heitz, Kotikalapudi Sriram, Brian Dickson, John Heasley
 Working Group: Individual Submissions (none)
 Formats: txt xml
A range of BGP Autonomous System Numbers is reserved to create a set of BGP Well Known Large Communities.
 Multipath schedulers
 
 draft-bonaventure-iccrg-schedulers-01.txt
 Date: 09/09/2020
 Authors: Olivier Bonaventure, Maxime Piraux, Quentin Coninck, Matthieu Baerts, Christoph Paasch, Markus Amend
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document proposes a series of abstract packet schedulers for multipath transport protocols equipped with a congestion controller.
 Considerations of Deploying ALTO using BGP - Link State (BGP-LS) Advertisement
 
 draft-zhang-alto-bgp-ls-01.txt
 Date: 13/07/2020
 Authors: Jingxuan Zhang, Kai Gao, Luis Contreras, Anais Escribano, Patricia Cano, Francisco Cano
 Working Group: Individual Submissions (none)
 Formats: html txt xml
This document discusses the requirements and deployment considerations of providing Application-Layer Traffic Optimization (ALTO) information in the inter-domain scenario using Border Gateway Protocol - Link State (BGP-LS) extension.
 WebTransport using HTTP/2
 
 draft-kinnear-webtransport-http2-01.txt
 Date: 13/07/2020
 Authors: Alan Frindell, Eric Kinnear, Tommy Pauly, Victor Vasiliev, Guowu Xie
 Working Group: Individual Submissions (none)
 Formats: html xml txt
WebTransport 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 Http2Transport, a WebTransport protocol that is based on HTTP/2 and provides support for either endpoint to initiate streams multiplexed within the same HTTP/2 connection.
 Supporting Multi-domain Use Cases with ALTO
 
 draft-lachos-alto-multi-domain-use-cases-01.txt
 Date: 13/07/2020
 Authors: Danny Perez, Christian Rothenberg, Qiao Xiang, Y. Yang, Borje Ohlman, Sabine Randriamasy, Farni Boten, Luis Contreras, J. Zhang, Kai Gao
 Working Group: Individual Submissions (none)
 Formats: txt
The goal of this document is to summarize current standardization efforts in the IETF ALTO working group to support important multi- domain use cases and show how they can benefit from network information exposure using ALTO. Besides, key design requirements of network information exposure to support multi-domain use cases are also presented along with information about novel mechanisms and abstractions to improve the base ALTO framework in multi-domain scenarios.
 Multi-domain Service Function Chaining with ALTO
 
 draft-lachos-sfc-multi-domain-alto-01.txt
 Date: 13/07/2020
 Authors: Danny Perez, Qiao Xiang, Christian Rothenberg, Y. Yang
 Working Group: Individual Submissions (none)
 Formats: txt
The delivery of network services often require service functions and their specific order, called a service function chain (SFC). A SFC request is usually composed by distributed resources which are expected to available across multiple domains with different technology and/or administration. This document describes different standardization activities and research projects addressing the challenges posed by SFC across multiple domains (specifically, multiple administrative domains). In addition, this document presents an initial approach to realize inter-domain service chains leveraging the Application Layer Traffic Optimization (ALTO) protocol. Finally, another important concern of this document is to initiate a discussion (ALTO, SFC as well as other WGs) regarding if, how, and under what conditions ALTO can be useful to improve the multi-domain SFC process.
 Abstract
 
 draft-wu-identifier-data-escrow-interface-01.txt
 Date: 13/09/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-04.txt
 Date: 20/05/2020
 Authors: Robert Moskowitz, Stuart Card, Adam Wiethuechter, Shuai Zhao, Henk Birkholz
 Working Group: Individual Submissions (none)
 Formats: xml 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-02.txt
 Date: 09/09/2020
 Authors: David Schinazi
 Working Group: Individual Submissions (none)
 Formats: html xml 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.
 Export of MPLS Segment Routing Label Type Information in IP Flow Information Export (IPFIX)
 
 draft-tgraf-ipfix-mpls-sr-label-type-05.txt
 Date: 12/09/2020
 Authors: Thomas Graf
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document introduces additional code points in the mplsTopLabelType Information Element for IS-IS, OSPFv2, OSPFv3 and BGP MPLS Segment Routing (SR) extensions to enable Segment Routing label protocol type information in IP Flow Information Export (IPFIX).
 Additional Criteria for Nominating Committee Eligibility
 
 draft-carpenter-eligibility-expand-06.txt
 Date: 13/10/2020
 Authors: Brian Carpenter, Stephen Farrell
 Working Group: Individual Submissions (none)
 Formats: html xml txt
This document defines a process experiment under RFC 3933 that temporarily updates the criteria for qualifying volunteers to participate in the IETF Nominating Committee. It therefore also updates the criteria for qualifying signatories to a community recall petition. The purpose is to make the criteria more flexible in view of increasing remote participation in the IETF and a reduction in face-to-face meetings. The experiment is of fixed duration and will apply to one, or at most two, Nominating Committee cycles. This document temporarily varies the rules in RFC 8713.
 JSON Type Definition
 
 draft-ucarion-json-type-definition-04.txt
 Date: 28/06/2020
 Authors: Ulysse Carion
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes a format, called JSON Type Definition (JTD), for describing the shape of JavaScript Object Notation (JSON) messages. Its main goals are to enable code generation from schemas as well as portable validation with standardized error indicators. To this end, JTD is intentionally limited to be no more expressive than the type systems of mainstream programming languages. This intentional limitation, as well as the decision to make JTD schemas be JSON documents, makes tooling atop of JTD easier to build. This document does not have IETF consensus and is presented here to facilitate experimentation with the concept of JTD.
 DNS Server Selection: DNS Server Information with Assertion Token
 
 draft-reddy-add-server-policy-selection-05.txt
 Date: 31/08/2020
 Authors: Tirumaleswar Reddy.K, Dan Wing, Michael Richardson, Mohamed Boucadair
 Working Group: Individual Submissions (none)
 Formats: txt xml
The document defines a mechanism that allows communication of DNS resolver information to DNS clients for use in server selection decisions. In particular, the document defines a mechanism for a DNS server to communicate its filtering policy and privacy statement URL to DNS clients. This information is cryptographically signed to attest its authenticity. Such information is used for the selection of DNS resolvers. Typically, evaluating the DNS privacy statement, filtering policy, and the signatory, DNS clients with minimum human intervention can select the DNS server that best supports the user's desired privacy and filtering policy. This assertion is useful for encrypted DNS (e.g., DNS-over-TLS, DNS- over-HTTPS, DNS-over-QUIC) servers that are either public resolvers or discovered in a local network.
 Extensions to Salted Challenge Response (SCRAM) for 2 factor authentication
 
 draft-melnikov-scram-2fa-01.txt
 Date: 13/07/2020
 Authors: Alexey Melnikov
 Working Group: Individual Submissions (none)
 Formats: xml txt
This specification describes an extension to family of Simple Authentication and Security Layer (SASL; RFC 4422) authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which provides support for 2 factor authentication. This specification also gives an example how TOTP (RFC 6238) can be used as the second factor.
 Using JSContact in Registration Data Access Protocol (RDAP) JSON Responses
 
 draft-loffredo-regext-rdap-jcard-deprecation-03.txt
 Date: 31/07/2020
 Authors: Mario Loffredo, Gavin Brown
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes an RDAP extension which represents entity contact information in JSON responses using JSContact.
 DRIP Identity Claims
 
 draft-wiethuechter-drip-identity-claims-01.txt
 Date: 20/09/2020
 Authors: Adam Wiethuechter, Stuart Card, Robert Moskowitz
 Working Group: Individual Submissions (none)
 Formats: txt html xml
This document describes 7 Identity Claims for use in various Drone Remote ID Protocols (DRIP).
 DRIP Authentication Formats
 
 draft-wiethuechter-drip-auth-04.txt
 Date: 21/09/2020
 Authors: Adam Wiethuechter, Stuart Card, Robert Moskowitz
 Working Group: Individual Submissions (none)
 Formats: xml html txt
This document describes how to include trust into the ASTM Remote ID specification defined in ASTM 3411-19 under a Broadcast Remote ID (RID) scenario. It defines a few different message schemes (based on the Authentication Message) that can be used to assure past messages sent by a UA and also act as an assurance for UA trustworthiness in the absence of Internet connectivity at the receiving node.
 Performance Measurement Using Simple TWAMP (STAMP) for Segment Routing Networks
 
 draft-gandhi-spring-stamp-srpm-02.txt
 Date: 06/08/2020
 Authors: Rakesh Gandhi, Clarence Filsfils, Daniel Voyer, Mach Chen, Bart Janssens
 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 specifies procedure for sending and processing probe query and response messages for Performance Measurement (PM) in Segment Routing networks. The procedure uses the mechanisms defined in RFC 8762 (Simple Two-Way Active Measurement Protocol (STAMP)) for Delay Measurement, and uses the mechanisms defined in this document for Loss Measurement. The procedure specified is applicable to SR-MPLS and SRv6 data planes and is used for both Links and end-to-end SR Paths including SR Policies.
 Real-time text solutions for multi-party sessions
 
 draft-hellstrom-avtcore-multi-party-rtt-solutions-03.txt
 Date: 08/08/2020
 Authors: Gunnar Hellstrom
 Working Group: Individual Submissions (none)
 Formats: xml txt html
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.
 IGP Extensions for Shorter SRv6 SID
 
 draft-chen-lsr-igp-shorter-srv6-extensions-02.txt
 Date: 11/05/2020
 Authors: Ran Chen, Shaofu Peng
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the IGP extensions required to support the Shorter SRv6 SIDs( Compressing SRv6 SIDs).
 BGP-LS Extensions for Shorter SRv6 SID
 
 draft-liu-idr-bgp-ls-shorter-srv6-extensions-01.txt
 Date: 15/10/2020
 Authors: Liu Yao, Shaofu Peng
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the BGP-LS extensions required to support the Shorter SRv6 SIDs(Compressing SRv6 SIDs).
 UAS Operator Privacy for RemoteID Messages
 
 draft-moskowitz-drip-operator-privacy-05.txt
 Date: 21/08/2020
 Authors: Robert Moskowitz, Stuart Card, Adam Wiethuechter
 Working Group: Individual Submissions (none)
 Formats: html txt xml
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-04.txt
 Date: 06/07/2020
 Authors: Pascal Thubert, Georgios Papadopoulos, Rex Buddenberg
 Working Group: Individual Submissions (none)
 Formats: html xml 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.
 Reflexive Forwarding for CCNx and NDN Protocols
 
 draft-oran-icnrg-reflexive-forwarding-01.txt
 Date: 17/04/2020
 Authors: David Oran, Dirk Kutscher
 Working Group: Individual Submissions (none)
 Formats: html xml txt
Current Information-Centric Networking protocols such as CCNx and NDN have a wide range of useful applications in content retrieval and other scenarios that depend only on a robust two-way exchange in the form of a request and response (represented by an _Interest-Data exchange_ in the case of the two protocols noted above). A number of important applications however, require placing large amounts of data in the Interest message, and/or more than one two-way handshake. While these can be accomplished using independent Interest-Data exchanges by reversing the roles of consumer and producer, such approaches can be both clumsy for applications and problematic from a state management, congestion control, or security standpoint. This specification proposes a _Reflexive Forwarding_ extension to the CCNx and NDN protocol architectures that eliminates the problems inherent in using independent Interest-Data exchanges for such applications. It updates RFC8569 and RFC8609.
 The Vulcain Protocol
 
 draft-dunglas-vulcain-01.txt
 Date: 12/09/2020
 Authors: Kevin Dunglas
 Working Group: Individual Submissions (none)
 Formats: txt html xml
This specification defines new HTTP headers (and query parameters) allowing a client to inform the server of the exact data it needs: * "Preload" informs the server that relations of the main requested resource will be necessary. The server can then reduce the number of round-trips by sending the related resources ahead of time using HTTP/2 [RFC7540] Server Push. When using Server Push isn't possible (resources served by a different authority, client or server not supporting HTTP/2...), the server can hint the client to fetch those resources as early as possible by using the "preload" link relation [W3C.CR-preload-20190626] and the "103" status code [RFC8297]. * "Fields" informs the server of the list of fields of the retrieved resources that will be used. In order to improve performance and reduce bandwidth usage, the server can omit the fields not requested.
 Secure UAS Network RID and C2 Transport
 
 draft-moskowitz-drip-secure-nrid-c2-01.txt
 Date: 27/09/2020
 Authors: Robert Moskowitz, Stuart Card, Adam Wiethuechter, Andrei Gurtov
 Working Group: Individual Submissions (none)
 Formats: txt xml html
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-02.txt
 Date: 21/09/2020
 Authors: Martin Duke
 Working Group: Individual Submissions (none)
 Formats: html xml txt
The QUIC transport protocol [QUIC-TRANSPORT] 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.
 YANG data model for shorter srv6
 
 draft-chen-spring-shorter-srv6-yang-01.txt
 Date: 14/10/2020
 Authors: Ran Chen
 Working Group: Individual Submissions (none)
 Formats: txt
This document is to define the YANG data model for shorter srv6( Compressing SRv6 ).
 Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS
 
 draft-btw-add-ipsecme-ike-01.txt
 Date: 09/09/2020
 Authors: Mohamed Boucadair, Tirumaleswar Reddy.K, Dan Wing, Valery Smyslov
 Working Group: Individual Submissions (none)
 Formats: txt xml
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).
 BGP Extensions to Support Packet Network Slicing in SR Policy
 
 draft-liu-idr-bgp-network-slicing-01.txt
 Date: 15/10/2020
 Authors: Liu Yao, Shaofu Peng
 Working Group: Individual Submissions (none)
 Formats: txt xml
[I-D.peng-teas-network-slicing] defines a unified TN-slice identifier, AII(administrative instance identifier), to indicate the topology, computing, storage resources of the dedicated virtual network for both intra-domain and inter-domain network slicing scenarios. This document defines extensions to BGP in order to advertise AII in SR policies.
 BGP-LS Extensions for Transport Slice over IPv6 Dataplane
 
 draft-chen-idr-bgp-ls-transport-slice-srv6-01.txt
 Date: 13/10/2020
 Authors: Shaofu Peng
 Working Group: Individual Submissions (none)
 Formats: txt
[I-D.peng-teas-network-slicing]defines a unified TN-slice identifier, AII(administrative instance identifier), to indicate the topology, computing, storage resources of the dedicated virtual network for both intra-domain and inter-domain network slicing scenarios. This draft defines extensions to BGP-LS protocol in order to advertise the information of the transport slice over IPv6 dataplane..
 BGP Maximum Prefix Limits Inbound
 
 draft-sas-idr-maxprefix-inbound-01.txt
 Date: 16/10/2020
 Authors: Melchior Aelmans, stucchi-lists@glevia.com, Job Snijders
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes mechanisms to limit the negative impact of route leaks [RFC7908] and/or resource exhaustion in BGP [RFC4271] implementations.
 Invisible Canonical Name Implementation
 
 draft-yaoyuan-dnsext-idr-adr-00.txt
 Date: 17/04/2020
 Authors: Yaoyuan Chen
 Working Group: Individual Submissions (none)
 Formats: txt
To accomplish the goal that not exposing redundant and unuseful CNAME chains in answers responded to clients, this document describes two new DNS resource records called "IDR" and "ADR" for hiding CNAME iterative process and better safety consideration.
 Multicast Path MTU
 
 draft-nandy-singla-utkarsh-pim-mcast-path-mtu-00.txt
 Date: 19/04/2020
 Authors: tathagata nandy, Nitin Singla
 Working Group: Individual Submissions (none)
 Formats: txt
Path MTU discovery (rfc1191) is a standard technique to determine the supported MTU between two Internet Protocol (IP) hosts to avoid any fragmentation. In a multicast distribution tree, source will not know where the receivers are located. So the technique used to compute the path MTU for a unicast stream does not work in a multicast network. This document describes a method to discover multicast path MTU with the goal to avoid traffic loss. This solution also aims to solve the problem of traffic loss in for multicast streams because of incorrect MTU setting and no path MTU support for multicast networks.
 EVPN Egress Protection
 
 draft-wang-bess-evpn-egress-protection-03.txt
 Date: 22/08/2020
 Authors: Yubao Wang, Ran Chen
 Working Group: Individual Submissions (none)
 Formats: html txt xml
A fast reroute framework for egress node protection is specified by [RFC8679] . But it cannot be applied to EVPN directly. This document specifies a mechanism to apply Egress Node Protection to EVPN nodes and apply Egress Link Protection to EVPN EAD/EVI routes. In Section 6.2, this draft is compared with three other drafts. These drafts are: * VTEP Group - [I-D.eastlake-bess-evpn-vxlan-bypass-vtep]. * DT2UL DX2L - [I-D.hu-bess-srv6-vpn-bypass-sid]. * Mirror SID - [I-D.ietf-rtgwg-srv6-egress-protection].
 RPL Storing Root-ACK
 
 draft-jadhav-roll-storing-rootack-01.txt
 Date: 05/06/2020
 Authors: Rahul Jadhav
 Working Group: Individual Submissions (none)
 Formats: xml txt
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-00.txt
 Date: 20/04/2020
 Authors: Tong Li, Kai Zheng, Rahul Jadhav, Jiao Kang
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document analyzes the problems caused by contentions and collisions on wireless medium between data packets and ACKs in WLAN and it proposes an optimized ACK mechanism that can minimize the intensity of ACK Frame in QUIC, improving the performance of transport layer connection.
 Timing Parameters in the RPKI based Route Origin Validation Supply Chain
 
 draft-ymbk-rpki-rov-timing-00.txt
 Date: 21/04/2020
 Authors: Randy Bush, Job Snijders
 Working Group: Individual Submissions (none)
 Formats: txt
This document explores, and makes recommendations for, timing of Resource Public Key Infrastructure publication, propagation, and use of RPKI ROV data in relying parties and routers.
 The Problem Statement for Precise Transport Networking
 
 draft-xiong-rtgwg-precise-tn-problem-statement-00.txt
 Date: 24/04/2020
 Authors: Quan Xiong, Peng Liu
 Working Group: Individual Submissions (none)
 Formats: xml txt
As described in [xiong-rtgwg-precise-tn-requirements], the deterministic networks not only need to offer the Service Level Agreements (SLA) guarantees such as low latency and jitter, low packet loss and high reliability, but also need to support the precise services such as flexible resource allocation and service isolation so as to the Precise Transport Networking. However, under the existing IP network architecture with statistical multiplexing characteristics, the existing deterministic technologies are facing long-distance transmission, queue scheduling, dynamic flows and per- flow state maintenance and other controversial issues especially in Wide Area Network (WAN) applications. This document analyses the problems in existing deterministic technologies to provide precise services in various industries such as 5G networks.
 The Requirements for Precise Transport Networking
 
 draft-xiong-rtgwg-precise-tn-requirements-00.txt
 Date: 24/04/2020
 Authors: Quan Xiong, Peng Liu
 Working Group: Individual Submissions (none)
 Formats: txt xml
The future networks not only need to offer the Service Level Agreements (SLA) guarantees such as low lantency and jitter, low packet loss and high reliability, but also need to support the precise services such as flexible resource allocation and service isolation. This document proposes a set of performance requirements and precise properties for Precise Transport Networking in various industries such as 5G networks.
 Timing Parameters in the RPKI based Route Origin Validation Supply Chain
 
 draft-ymbk-sidrops-rpki-rov-timing-00.txt
 Date: 24/04/2020
 Authors: Randy Bush, Jay Borkenhagen, Tim Bruijnzeels, Job Snijders
 Working Group: Individual Submissions (none)
 Formats: txt
This document explores, and makes recommendations for, timing of Resource Public Key Infrastructure publication of ROV data, their propagation, and their use in Relying Parties and routers.
 Upgrading Communication from Stub Resolvers to DoT or DoH
 
 draft-pp-add-stub-upgrade-02.txt
 Date: 30/06/2020
 Authors: Puneet Sood, Paul Hoffman
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes methods for a DNS stub resolver to upgrade its communications with a known recursive resolver to include encrytion using DoT or DoH. This protocol is designed for the scenario where the stub resolver already has the IP address of the recursive resolver. Other protocols under develpment address scenarios where the stub resolver wants to discover recursive resolvers that use DoT or DoH. This document does not cover such discovery.
 DNS Resolver Information Self-publication
 
 draft-pp-add-resinfo-02.txt
 Date: 30/06/2020
 Authors: Puneet Sood, Paul Hoffman
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes methods for DNS resolvers to self-publish information about themselves. The information is returned as a JSON object. The names in this object are defined in an IANA registry that allows for light-weight registration. Applications and operating systems can use the methods defined here to get the information from resolvers in order to make choices about how to send future queries to those resolvers.
 Describing QUIC's Protocol Data Units with Augmented Packet Header Diagrams
 
 draft-mcquistin-quic-augmented-diagrams-02.txt
 Date: 13/07/2020
 Authors: Stephen McQuistin, Vivian Band, Dejice Jacob, Colin Perkins
 Working Group: Individual Submissions (none)
 Formats: txt xml html
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 packet header diagram language, and not as a contribution to the development of the QUIC protocol.
 Recommendations for Forwarding Packets Marked with EXP/LU DSCPs in Diffserv Networks
 
 draft-blake-explu-dscp-rec-00.txt